Statamic Bluesky Comments Laravel Package

Product Decisions This Supports

• Roadmap sequencing for Statamic 6 migration: release 0.0.5 adds Statamic 6 compatibility, which converts this addon from "blocks the platform upgrade" to "safe to carry into the v6 migration." That directly informs whether the Statamic 6 upgrade can be scheduled this cycle or must wait on dependent addons.
• Build vs buy for on-site discussion: a Bluesky-backed comment layer lets you ship community discussion without standing up a moderation queue, spam filter, or user account system. The decision is whether social-graph-hosted conversation is acceptable for your audience versus a first-party comments store you own.
• Feature scope: this is a narrow integration (render and surface Bluesky replies against a page), not a full commenting platform. Treat it as a discovery/engagement feature, not a replacement for forums, support ticketing, or gated customer feedback.
• Architecture bet on AT Protocol: adopting this package ties content strategy to Bluesky's ecosystem and public API behavior. Worth an explicit call-out in roadmap risk review: engagement depth depends on your audience actually living on Bluesky.
• Upgrade gating on a 0.0.x dependency: pre-1.0 versioning means minor bumps can change behavior. Budget for pinning the version and re-testing comment rendering on each release rather than floating the constraint.

When to Consider This Package

Consider it when:

• Your site runs Statamic (now including Statamic 6) and you want threaded discussion on entries without building or hosting a comment system.
• Your audience or community already exists on Bluesky — the value proposition collapses if nobody there is replying to your posts.
• You want zero-database, zero-moderation-surface comments: conversation lives on the social network, and you're comfortable with that trade-off in ownership, data retention, and moderation policy.
• You need something small and readable to audit — an early-stage addon is easier to fully review than a mature comments platform.
• You're prototyping engagement and want to validate demand before investing in a first-party system.

Look elsewhere when:

• You need guaranteed stability and a support contract — 0.0.x versioning, small maintainer surface, and recent contributor turnover (a first-time contributor shipped the v6 support) mean you are effectively self-supporting. Pin the version and be ready to vendor or fork.
• You require moderation tooling, spam controls, user identity, or GDPR-scoped data handling you control end to end.
• Your audience is not on Bluesky, or your content strategy is platform-agnostic. A provider-agnostic or self-hosted comments layer is the better bet.
• You need comment data for analytics, search, or CRM — you do not own the underlying conversation.
• You are on a Statamic version older than the currently supported pair and unwilling to upgrade; compatibility churn on a pre-1.0 addon is a recurring tax.

How to Pitch It (Stakeholders)

For executives: this is a small, low-cost addon that puts community discussion on our Statamic pages by surfacing Bluesky replies, with no new database, no user accounts, and no moderation backlog to staff. The 0.0.5 release adds Statamic 6 support, which is the reason it's now viable — it no longer holds back our platform upgrade. The trade-off to accept consciously: the conversation lives on Bluesky, so we don't own the data or the moderation policy, and the upside only materializes if our audience is active there. Recommendation: adopt as a scoped pilot on a subset of pages, measure reply volume and referral traffic for one quarter, then decide on expansion. Cost of being wrong is a removed addon, not a migration.

For engineering: addon provides Bluesky comment rendering for Statamic entries; 0.0.5 is a compatibility release adding Statamic 6 support (PR #3, first contribution from @martyf) with no reported breaking changes or deprecations. Constraints to plan around: pre-1.0 versioning, so pin exactly and treat each bump as a re-test; small maintainer base — assume we own the failure mode, keep the fork path open, and isolate the integration behind a thin wrapper so it can be swapped or removed without touching templates. Verify the Bluesky API call path, caching behavior, and graceful degradation when the upstream API is unavailable or rate-limited before this goes near production traffic.