Laravel Bluesky Laravel Package

Product Decisions This Supports

• Channel expansion: should Bluesky be in our distribution mix? Still yes, and now cheaper in more places. But the more interesting shift in 1.1.0 is that the package is no longer only an outbound pipe. The FirehoseSyncMessage event and sync handler plus activity-subscription methods on AppBskyNotification mean the same dependency can answer "is anyone engaging with us on Bluesky?" — the question that actually determines whether a channel earns a permanent slot, not just whether we can post to it.
• Outbound vs. inbound as separate bets. Worth splitting the roadmap item in two: (a) cross-posting, unchanged from before — a sprint-sized experiment; (b) engagement/listening ingest, which is new capability and a materially different operational commitment (a long-running consumer, cursor persistence, reconnect/backfill handling). Decide on (a) on cost-per-experiment grounds; decide on (b) on whether you're prepared to run and monitor a stateful process. Don't let the fact that one package does both collapse them into one decision.
• Build vs. buy vs. wrap. The "wrap" answer still holds for outbound. For inbound, the calculation is different: a firehose consumer is a service-ownership decision, not a library decision. A thin wrapper gets you a first version fast, but the operational surface (downtime, cursors, event ordering, schema drift) belongs to you regardless of the dependency.
• Per-user posting on behalf of customers. The transition:email scope, DPoP proof URL refinement, and JWT exp claim are all AT Protocol OAuth machinery, which strongly suggests the package is building out the authorization-code flow alongside app passwords. That directly addresses the biggest previously-open question — "can we post on behalf of our users, not just our brand accounts?" Worth a spike before scoping a build; the answer may now be "the library helps."
• Notification/engagement routing. AppBskyNotification activity subscriptions map cleanly onto support workflows: watch for mentions and replies to a brand account, route into the existing queue, respond from the admin panel. This was previously listed as out of scope; it now moves into "possible with effort."
• Prototyping a unified Channel abstraction. Still the best near-term use. A single package now exercises both push and pull sides of the protocol, which is a genuinely useful reference shape for designing your own Channel interface — one adapter that informs both the publisher and the listener sides of the design.
• Buy/build signal from the numbers. Unchanged and worth restating: tiny adoption, no dependents, single maintainer. Version 1.1.0 adding OAuth plumbing, a firehose event, and notification subscriptions does not change the risk profile in the direction of "load-bearing infrastructure" — it increases the amount of surface your small dependency now owns. Net PM read: broader package surface means a larger share of the integration is now someone else's unowned code. Adopt narrowly, vendor, own the risk — and now watch scope carefully.

When to Consider This Package

Reasonable fit when:

• The stack is already Laravel/PHP 8.x+ and the team is comfortable reading a small vendor package.
• The scope is thin and outbound: publish a post (text plus link or image), delete one, refresh a session. Close to free value.
• You need a first engagement/reply feed rather than a production-grade listener. If you can tolerate "we run this and we watch it," the firehose/notification pieces get you to a demo or a low-volume internal tool quickly.
• You want per-user authorization and can verify the OAuth path before committing. Check whether 1.1.0 ships a complete authorization-code flow with token storage and refresh — the DPoP and scope changes are suggestive, not conclusive. If the flow is complete and documented, this materially lowers the cost of "post on behalf of our users." If it's partial plumbing, still a build.
• You can accept MIT-licensed code you may need to fork or patch, and you have someone to own it.
• You're prototyping or running a time-boxed experiment where the alternative is "don't ship the channel at all."

Look elsewhere (or build in-house) when:

• Bluesky becomes a primary channel. Anything revenue-critical or high-volume should be your code or a supported vendor with an SLA. That was true before; 1.1.0 makes it more true, not less — OAuth, token refresh, DPoP proofs, and firehose consumption are all failure modes you do not want a 44-star dependency to own.
• You need reliable inbound events. A sync handler is a starting point, not a subscription service. You still own cursor persistence, at-least-once delivery semantics, backfill on restart, deduplication, and monitoring. If "we missed an hour of mentions" is a customer-visible incident, run this behind your own queue with your own cursor store — or buy a listening vendor.
• You need scheduling, approvals, threads, or rich embeds. Still your application layer (or a social-media-management API like Buffer/Ayrshare/Typefully). Unchanged.
• Compliance matters. Regulated communications need audit trails, retention, and a supplier who will answer a questionnaire. MIT plus solo maintainer is not that — and adding OAuth means the package now touches user authorization tokens, which raises the security review bar rather than lowering it.
• You're not on Laravel, or outside the package's tested version range.
• You need more than one network. Still standardize on a queue plus your own Channel interface with swappable adapters.

Mitigation checklist before committing (updated): pin the version and read the diff — 1.1.0 is a minor release but it touches auth (DPoP, JWT claims, scopes), so verify existing app-password flows and any token handling you depend on still behave; vendor or fork it; wrap it behind your own SocialPublisher interface and, separately, a SocialEventSource interface so the inbound path is replaceable independently; write contract tests against the live API so protocol changes surface as test failures; run any firehose consumer in your own supervised worker with your own cursor persistence, never inside a request cycle; and keep the blast radius to non-critical announcements.

How to Pitch It (Stakeholders)

To executives: The channel-expansion case is unchanged and still cheap — roughly one sprint to find out whether Bluesky deserves budget, no vendor contract, no headcount. What's new is that the same library now also covers the listening half of the problem: notifications and a real-time event feed, plus the beginnings of per-user authorization. That means one small experiment can answer both "can we reach people there?" and "are people responding?" without a second procurement. The caveat is the same as before and worth saying out loud: this is a small, single-maintainer open-source project, and the latest release makes it do more, which means more of our integration sits in code nobody is paid to support. Recommendation: fund it as a time-boxed experiment with pre-agreed success metrics (referral traffic, engagement rate, attributed signups) and a kill criterion, and fund the listening piece only if we're prepared to operate a background service. We are buying an inexpensive option on a channel that might matter — not standardizing on a dependency.

To engineering: Version 1.1.0 broadens the package meaningfully, in three directions you should evaluate separately. First, auth: DPoP proof URL handling, a JWT exp claim, and a transition:email scope on BlueskyProvider are all AT Protocol OAuth machinery — read the diff and confirm whether this is a complete authorization-code flow or partial plumbing before you plan per-user posting around it, and confirm app-password flows and any token handling you already depend on are untouched. Second, inbound: a FirehoseSyncMessage event plus sync handler. Treat that as a building block, not a service — you own the worker, cursor persistence, backfill, dedup, and alerting, and it must not run inside a request. Third, notifications: activity-subscription methods on AppBskyNotification give you a mention/reply feed, which is useful for support routing and engagement metrics but still needs your own storage and polling cadence. Plan to pin and vendor, put outbound behind a SocialPublisher interface and inbound behind a separate SocialEventSource interface so each side is replaceable independently, cover auth, session/token refresh, post with link and image, delete, and one end-to-end event-received path in integration tests, and assume you may patch it. The trade is explicit — we accept ownership risk in exchange for skipping the protocol learning curve, and 1.1.0 has enlarged the amount of protocol we're skipping. Scheduling, threads, rich embeds, and durable engagement analytics remain scoped builds on our side.