Filament Chat Laravel Package

Product Decisions This Supports

• Build vs. buy for in-panel messaging. This package supplies the commodity 80% of a chat feature — conversation/message/participant models, a Filament dock UI, polling, unread counters, toasts — so the team's effort goes into the differentiated 20% (workflow, routing to the right person, business context attached to a thread). v1.5.0 strengthens the buy case by closing an extension-authoring footgun and adding the two hooks most often requested in product discovery.
• Feature: "seen / unread" states. conversation_participants.last_read_at makes read receipts and per-participant unread badges a config-and-UI decision rather than a schema project. This unlocks concrete roadmap items: unread-first inbox ordering, "last read" indicators, and — importantly for internal support use cases — response-time and backlog reporting off a field we now own.
• Feature: ambient awareness without infrastructure. The filament-chat-incoming browser event (ChatDock::EVENT_INCOMING, payload {conversation, message, open}) decouples "tell the user something arrived" from notifications.toasts. We can ship a sound or desktop notification as a product choice, and let users opt in, without committing to websockets, a queue worker tier, or a third-party realtime vendor. That is a scheduling decision (days, not a sprint) and a cost decision (no new infra line).
• Feature: lightweight activity signals. ChatService::changed($conversation) deliberately notifies members without creating a message or a bell. This is the primitive behind "this conversation changed, re-render it" — typing-ish indicators, "someone is editing/marking up the image", collaborative annotation. It also gives us a notification-fatigue lever: we can distinguish signal (re-render) from interrupt (bell/toast) and tune each separately.
• Reliability as a roadmap input. The setRelation fix means messages found via a conversation arrive with conversation already loaded, so extensions reading $message->conversation in a hook no longer lazy-load per message — previously a hard crash under Model::preventLazyLoading(). Product consequence: we can turn on strict lazy-loading prevention (a performance/quality guardrail we'd otherwise defer) and trust chat history rendering to not degrade linearly with conversation length.
• Sequencing and upgrade risk. The last_read_at migration is additive and optional (ChatConfig::readTimeAvailable()); without it the chat behaves exactly as before. That lets us take the upgrade for the bug fix and event hooks now, and treat read receipts as a separately-scheduled, separately-communicated feature — no forced flag day.
• Use cases this is now credible for: internal ops/admin messaging inside a Filament panel, reviewer↔submitter threads on a record, lightweight support triage where staff already live in the admin, and annotation-style collaboration. It is not yet a decision-grade fit for public-facing, high-concurrency support inboxes.

When to Consider This Package

Adopt when most of these hold:

• You are already running Filament and want messaging inside the panel rather than a second app or a bolted-on widget.
• Message volume is moderate and human-paced — polling plus the new browser event is an acceptable latency trade (sub-second realtime is not a stated requirement).
• You need a conversation thread attached to your domain objects, not a standalone chat product.
• You expect to extend it (custom hooks, relation reads, re-render signals) — this release is explicitly aimed at extension authors, so the extension surface is a supported path rather than a fork.
• You want read state and unread counts and are willing to schedule the optional third migration.
• You value non-breaking, incremental upgrades — this release adds capability without changing existing behavior, which is a good sign for long-term maintenance cost.

Look elsewhere when any of these are true:

• You need true realtime at scale (typing indicators with millisecond fidelity, presence, thousands of concurrent connections) — you want a websocket/queue-backed service, not polling.
• You need a public or customer-facing support inbox with routing, assignment, SLAs, macros, CSAT, and search at scale — that's a support platform, and this package would become a growth-risk bottleneck.
• You need compliance-grade retention, audit trails, export, or E2E encryption — nothing here addresses that, and retrofitting it is a rebuild.
• You are not on Filament, or your admin stack is likely to change — the value is heavily coupled to that UI layer.
• You need mobile push or email fallback for missed messages — the new event is browser-scoped and fires only when the app is open.

How to Pitch It (Stakeholders)

To executives: This is a small, low-risk dependency that gives us in-product messaging without building it. The new version adds read receipts and desktop/sound notifications without new servers or a realtime vendor — so the engagement features we scoped are now a UI-and-config effort, not an infrastructure project. The upgrade is backward compatible and the one schema change is optional, so we can ship the reliability fix immediately and treat read receipts as a separately-approved increment. Cost of ownership stays low; the main strategic caveat is that this is an internal-tooling-grade chat, not a customer support platform — if we later want a public support channel with SLAs and routing, that's a buy decision, not an extension of this.

To engineering: Upgrade is safe — the setRelation fix removes an N+1 that crashed under Model::preventLazyLoading(), and both new capabilities are additive. ChatService::changed() gives us a signal channel separate from notifications (re-render without a bell); the filament-chat-incoming DOM event gives us sound/desktop alerts without a socket and independent of notifications.toasts; last_read_at is a third, optional migration gated by ChatConfig::readTimeAvailable(), so no forced migration on deploy. Please land the upgrade with the lazy-loading guard enabled in CI so the fix is actually exercised, and confirm our extensions read $message->conversation rather than re-querying.