Filagora Messages Laravel Package

Product Decisions This Supports

• Feature scoping for messaging v1 vs v1.1: Private messaging is table stakes; the roadmap question is usually "do we ship file sharing in DMs?" v0.2.0 lets you decouple that decision — ship conversations now, enable attachments later by adding filagora/forums ^0.6 without re-platforming or rewriting message flows.
• Build vs buy on attachment plumbing: The hard parts of DM attachments are not uploads, they're entitlement and lifecycle — who may still see a file after being removed from a conversation (MessageAttachmentAccess), and what happens to files when a conversation or user is deleted (foreign keys that clear rather than cascade). That is meaningful security/compliance work you would otherwise spec, build, and test yourself.
• Data-retention and privacy posture: Clear-not-cascade semantics mean attachments are detached rather than destroyed on deletion — a defensible default for audit and legal-hold conversations, but it must be reconciled with your retention policy and GDPR erasure commitments. Settle that in product, not in a migration.
• Integration cost as a product constraint: Attachments are gated on a separate package and are explicitly optional. This keeps the messaging package adoptable standalone, but it means "attachments" is a bundling decision, not a checkbox — relevant when pricing tiers, packaging, or self-host vs. hosted offerings are on the table.
• Operational risk for existing deployments: The migration, the filagora:messages:link-attachments command, and the AttachmentLinks idempotent installer together signal that partial/aborted rollouts are an expected state. That is a rollout-plan input (maintenance window, support runbook), not just an engineering note.

When to Consider This Package

Consider it when:

• You need private, one-to-one or group conversations inside a Laravel app and would rather not own message-thread modeling, read state, and access control.
• File sharing in DMs is on the roadmap but not in the first release — the optional, additive attachment path is exactly the shape you want.
• You already run filagora/filagora-forums (or are willing to adopt it), since attachments reuse its attachments table via a declared schema extension that filagora:adopt recognizes.
• Your deletion semantics tolerate detach over destroy for message attachments, or you can layer a purge job on top.

Look elsewhere when:

• You need attachments as a first-class, dependency-free capability — this release requires a second package, and the migration is inert without it.
• You need end-to-end encrypted DMs, or virus scanning / content moderation on attachments — nothing here indicates either, so assume you own that layer.
• You cannot accept a pre-1.0 dependency for a user-facing surface: v0.2.0 plus a ^0.6 sibling package means APIs and schema can still move.
• Your compliance model requires cascade deletion of files with the conversation, with no orphan window.

How to Pitch It (Stakeholders)

To executives: This release closes the most common gap in in-app messaging — sharing files inside a private conversation — without forcing us to build file permissions and deletion handling from scratch. It's opt-in: we can ship messaging first and switch attachments on later, so it doesn't block the current timeline. The genuine value is in the access and lifecycle rules (only current conversation participants can see a file; deletions detach rather than silently destroy), which is the part that usually becomes a security or legal review. Main caveat to price in: it depends on a second pre-1.0 package, and the upgrade path is designed for partial failure, so we should budget a runbook and a retention-policy decision alongside the engineering ticket.

To engineering: Attachments land as an optional integration, not a hard dependency. A migration dated after the forums attachments table adds private_message_id and private_conversation_id as clearing (not cascading) foreign keys; filagora:messages:link-attachments adds them post-hoc, and AttachmentLinks converges any half-applied state, so rollout is safely re-runnable. Sending and replying claim the sender's own pending uploads referenced in the body (ClaimMessageAttachments), visibility is enforced through MessageAttachmentAccess, and PrivateMessage::attachments() is the read path. The columns are declared as a schema extension of the forums snapshot so filagora:adopt accepts an already-extended table. Two asks before we commit: pin and verify the ^0.6 forums contract, and confirm our orphan-cleanup story for cleared keys.