Wirechat Laravel Package

Product Decisions This Supports

• Build vs. buy for team messaging: Wirechat remains a credible "buy" (MIT, free) shortcut for private chats, group conversations, approval-gated message requests, and an embeddable widget inside an existing Laravel/Livewire product — avoiding 3–6 months of in-house messaging UI and data-model work.
• Roadmap sequencing: Ship a support inbox, internal team chat, or marketplace buyer/seller messaging as a v1 surface and reserve differentiation for workflow features (automation, routing, integrations) rather than chat plumbing. New message-request (approval-first) flows make it viable for marketplace/support inboxes where unsolicited DMs were previously a blocker.
• Time-to-validation: Full-page + widget duality covers "destination" chat (/chats) and "ambient" chat (in-app drawer), and panel-level route/mount-URL/search controls now let you run multiple differently-behaved chat surfaces from one codebase — useful for testing modality and audience segmentation before committing.
• Growth and acquisition loops: Group invite links plus join requests, lobby screens, request management, and banned/past-member handling mean "invite a teammate" can be a product feature on the roadmap rather than a separate epic — directly relevant to virality/seat-expansion decisions.
• Trust, safety, and abuse decisions: Approval-first message requests, configurable per-user privacy settings, and blocked/locked recipient states let a PM scope a defensible v1 safety posture (who can DM whom) instead of deferring it post-launch.
• Segmentation and multi-tenancy decisions: Polymorphic participants, multi-guard panels, and per-user settings storage let you decide whether chat spans user types (admins, customers, vendors) or stays single-persona without re-architecting later.
• Compliance positioning (carefully): Configurable message encryption with metadata/payload handling supports a "we don't store readable message bodies" claim for some deployments — but it is application-level encryption with keys we manage, not E2E or a compliance certification. Good input to a security review; not a substitute for one.
• Retention/engagement levers: User notification settings plus per-user Wirechat settings give a hook for digest, push, and preference-center decisions without building preferences infrastructure.
• Extensibility posture: Panel providers, model overrides, the WirechatUser contract, and now broader panel controls (tones, routes, mounts, query customization, message actions, search behavior) reinforce a "configure, don't fork" strategy — though the configuration surface is materially larger than v0.5.
• Scope negotiation: Presence of groups, invites, join requests, permissions, message requests, settings, and attachments lets a PM defer those from v1 scope and enable via panel config rather than scoping separate epics.

When to Consider This Package

Consider adoption when:

• Your product is already Laravel 11–13 + Livewire (v0.6.0 dropped Laravel 10; PHP 8.1–8.5; Livewire 3.7/4.0). Stack mismatch turns the integration benefit into a liability; being on Laravel 10 is now a hard blocker.
• You need team-style messaging: private 1:1 chats, groups with roles, approval-gated message requests, and/or an in-app support widget.
• You need controlled inbound contact — marketplaces, creator platforms, support desks — where unsolicited messages must be requested and accepted, with lobby/join-request handling for groups.
• You have more than one authenticatable user model or guard, or expect to — polymorphic participants and multi-guard panels are first-class here.
• You want UI included: panel-driven with theming, layout, tone/color, and component-level configuration, so a small team can ship without a dedicated frontend build.
• Real-time behavior matters but you want it optional and configurable — Echo broadcasting, queues, web push, and notification settings are panel/user-scoped toggles, not hard dependencies.
• You can accept Livewire as a UX constraint (server-driven interactivity) — fine for chat, less ideal for deeply custom client-side interactions.
• You have an owner for encryption and attachment storage decisions — key handling, metadata retention, disk/visibility/directories, and secure download paths are now first-class config you must own.

Look elsewhere when:

• Your stack is not Laravel/Livewire (React/Vue SPA, Node, Django).
• You are pinned to Laravel 10 or older PHP — v0.6.0 removed that support; adopting now forces a framework upgrade.
• You need enterprise messaging guarantees (true E2E encryption, compliance retention, federation, SLA-backed support). MIT + ~577 stars + zero dependents still signals a young, single-maintainer project without commercial backing; in-app encryption does not change that.
• You require audited, SOC2-grade third-party components or mandated vendor support contracts.
• You need deep moderation/compliance tooling (full audit trails, eDiscovery, DLP) — the package now covers requests, bans, and privacy settings, not enterprise governance.
• Your messaging is highly specialized (voice/video, Slack-style threading, workflow bots) — you will end up forking, and the AGENTS.md explicitly asks for package-compatibility preservation, which fights deep customization.
• Operational risk tolerance is low: no dependents and a fast-moving 0.x line (features plus a Laravel 10 drop inside one minor release) mean you should budget for maintaining a fork and pinning versions.

Adoption criteria checklist: Livewire stack + Laravel ≥ 11 ✅, clear owner for the fork ✅, defined v1 scope (private-only vs. groups vs. requests) ✅, storage plan for attachments (disk/visibility/directories/secure downloads) ✅, broadcasting decision (sync vs. Echo) ✅, encryption and key/metadata retention decision ✅, abuse policy for invite links and message requests ✅, and a per-user settings storage plan ✅.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add private and group messaging to our Laravel product in weeks rather than quarters by adopting an MIT-licensed, Laravel-native package. It ships the full experience — chat pages, an embeddable widget, group roles, invite links and join requests, approval-first message requests, notification and privacy settings, attachments, and optional encryption and real-time updates — with configuration instead of custom code. Cost is engineering integration time plus ongoing small maintenance ownership, since the project is young and single-maintainer; assume we maintain a fork. Two caveats to plan for: v0.6.0 dropped Laravel 10 support, so confirm our framework version before committing to a date, and the built-in encryption is application-level with keys we manage — useful, but not end-to-end encryption and not a compliance certification. The trade-off is a Livewire-based UI and no vendor support contract; acceptable for internal/team messaging, and reversible because the data model is standard Laravel Eloquent.

For engineering (the real story): Well-structured Laravel package with documented public API: panel providers, model overrides, WirechatUser contract, and Livewire component aliases. Integration work is now broader than v0.5: implement the contract on our user model, register panel(s) with the new route/mount/query/message-action/search/tone controls, configure storage and broadcasting, decide encryption + metadata retention and secure-download paths, and migrate the per-user settings table. Note the breaking change: Laravel 10 is no longer supported, and new migrations (message requests, per-user settings, encryption metadata) mean a real upgrade path if we are already on an earlier version — test migration index names and existing conversations. Risk is maintenance and configuration sprawl, not integration — treat every panel method, route, component alias, and config key as a durable surface we do not want to fork. Concretely: pin the version, keep changes in panels/config/model subclasses, add regression tests around group, invite, join-request, and message-request flows, verify both full-page and widget modes plus empty/locked states before shipping UI changes, and document our encryption key handling. Recommend a one-sprint spike to validate broadcasting, attachment storage, encryption key lifecycle, and the Laravel 11+ upgrade before committing to a roadmap date.