On 13 August 2026, Bluesky quietly consolidated its public infrastructure under a new banner: Bluesky Protocol Services. On the surface it reads like a documentation tidy-up. Underneath it is one of the more consequential infrastructure announcements of the year for anyone whose product touches a social graph, and almost nobody in the business press noticed.
The headline feature is Jetstream v2 with Network Replay. In plain terms: you can now consume the entire public history of a 43-million-user social network, from any point in the past, and cut over to the live stream with no gap. The live tail requires no API key at all. Bluesky has stated it has no plans to change that.
If you have ever had a product feature killed by someone else’s pricing page, that sentence should get your attention.
TL;DR
- Bluesky Protocol Services launched 13 August 2026, unifying the relays, Jetstream instances and API endpoints Bluesky operates on the AT Protocol network, and clarifying the service contracts around them.
- Jetstream v2 adds Network Replay: a compressed archive of the whole network over HTTP, stateless cursor-based catch-up, and a seamless handover to the live WebSocket stream.
- The live stream stays open and unauthenticated. Only bandwidth-heavy archive requests now need an API token, to keep the service cheap and reliable to run.
- The commercial argument is platform risk, not ideology. AT Protocol puts identity, social graph and data in a portable, self-hostable form, which is a structurally different exposure profile from building on a closed platform API.
- It is not a free lunch. Ingesting a public firehose makes you a data controller under GDPR, the practical audience is far smaller than the incumbents, and Bluesky the company still operates most of the infrastructure in practice.
What actually shipped
Protocol Services is a brand and a documentation home for infrastructure that already existed, which is why it is easy to dismiss. The substance sits in three places.
Jetstream v2. The original Jetstream was a pragmatic answer to a real engineering problem: the raw AT Protocol firehose ships signed CBOR and CAR blocks, which is correct for verification and miserable for the ninety per cent of consumers who just want to read public posts. Jetstream converts it to filterable JSON and, by Bluesky’s own measurement, shrinks the stream by more than 99 per cent. Version 2 keeps a compressed archive of the entire network and serves archived segments over HTTP while live data continues over WebSocket, with the cursor semantics arranged so replay is stateless. You are not rebuilding a backfill pipeline; you are asking for a point in time.
Official SDKs. New TypeScript and Go clients handle reconnection, deduplication, cursor management and typed event decoding. Anyone who has run a long-lived firehose consumer in production knows that this list is the actual work.
A stated service contract. This is the underrated part. Bluesky drew an explicit line: archive requests need a token because they are bandwidth-intensive, and the live tail does not, with no plans to change. Vague generosity is what platform APIs offer immediately before they stop being generous. A stated boundary is something you can actually put in an architecture decision record.
Why “no API key required” is a strategic claim
Every technical leader who lived through 2023 knows the pattern. Twitter’s API repricing wiped out a generation of third-party clients and research tooling within weeks. Reddit’s API changes did the same to its client ecosystem. Facebook’s 2018 Graph API lockdown removed capabilities that businesses had built roadmaps on. In each case the engineering was fine. The dependency was the defect.
We have written before about payment providers as single points of failure and about vendor acquisitions quietly rewriting your integration surface. Social platform APIs are the same category of risk, usually carried with less scrutiny because the integration started as a marketing experiment rather than an architectural decision.
AT Protocol changes the shape of that exposure, and it is worth being precise about how, because the marketing around decentralisation is generally worse than the technology itself.
Identity is a DID, a decentralised identifier that is not owned by the application you signed up through. Handles are domain names, so a company can be verified on the network simply by proving it controls its own domain, which is a genuinely elegant answer to a problem other platforms monetise. User data lives in a signed repository of JSON records, described by shared schemas called lexicons. The network splits into a personal data server that holds your repository, a relay that aggregates events, and an AppView that builds the product experience on top. Any of those can be replaced or self-hosted.
The honest caveat: Bluesky the company runs the relay and the AppView that constitute “the network” for nearly all real usage, so this is not an absence of dependency. It is a dependency with a documented exit, which is a meaningfully different thing and roughly the standard we apply when we advise clients on cloud portability.
Where this is commercially useful
Being opinionated about this: most companies should not be building a social product on AT Protocol. Four applications do stand up to scrutiny.
Social listening and brand monitoring at sane cost. Enterprise firehose access on incumbent platforms is priced for agencies with retainers to match. Here the live stream is open, and Network Replay means a monitoring product can be backfilled at launch rather than starting blind. For an SME wanting genuine share-of-voice data rather than a dashboard of vanity metrics, the economics are different by an order of magnitude.
Community and discussion features without building an identity system. If your product needs comments, profiles or a follow graph, the alternatives are building authentication and moderation yourself or renting someone’s SDK. Using an existing portable identity layer is a third option, and it composes with the shift towards self-hosted authentication we have covered previously.
Domain-based verification as brand infrastructure. Setting your handle to your own domain is a small change with a real trust payoff, and it costs nothing beyond a DNS record.
A structured public corpus for AI systems. This is the one we would watch. Typed, schema-described, hyperlinked, replayable public data is a dramatically better input for retrieval and agent systems than scraping HTML behind bot challenges, particularly as crawler access to the open web gets more contested and more adversarial. If you are building anything that needs a live view of public conversation, the difference between an official replayable stream and a scraper you maintain forever is the difference between a feature and a liability.
The limits worth stating plainly
The audience is not the incumbents. Bluesky has crossed 43.5 million registered users, which is substantial and also not LinkedIn. Do not move your demand generation here on the strength of an architecture argument.
Ingesting a public firehose has compliance consequences that teams routinely underestimate. Public does not mean unregulated. The moment you persist personal data from that stream, you are a controller with lawful basis, retention, subject access and erasure obligations, and “it was public” has never been a defence under GDPR. Design the retention and deletion path before the ingestion pipeline, not after.
The archive is now token-gated, which is entirely reasonable and also a reminder that free tiers have edges. And full network replay is a genuine storage and processing commitment; filter server-side and be specific about the collections you need.
What to do about it
- Audit your platform API dependencies. List every social or third-party API a revenue-generating feature depends on, and write down what happens if pricing changes by ten times. Most teams have never done this exercise.
- Claim your domain handle. Low cost, immediate brand benefit, and it establishes the identity primitive before you need it.
- Prototype against the live stream. No key required means no procurement cycle. A developer can validate whether the data supports your use case in an afternoon.
- Treat ingestion as a data protection project. Lawful basis, retention window and deletion mechanism, agreed before the first record is stored.
- Record the decision. If you adopt an open protocol specifically to reduce platform risk, write down the exit path you are buying, or the reasoning will be lost in eighteen months.
The broader pattern
We keep seeing the same shape in 2026. Proprietary infrastructure primitives acquire credible open implementations, and the interesting question stops being “is the technology good” and becomes “what is my exit”. Durable execution, edge databases and stateful serverless have all been through this in the past year. Social identity is now in the same cycle.
None of this obliges you to care about decentralisation as a philosophy. It obliges you to notice that the cost of switching away from a closed platform API is a number, that number is usually large, and that a viable alternative now exists with no key required to try it.
At REPTILEHAUS we build and integrate this kind of infrastructure for entrepreneurs and management teams: platform architecture, API strategy, AI systems and the DevOps to run them without drama. If you are carrying a dependency you would rather not be carrying, or you want to know whether an open protocol genuinely fits your product, get in touch.
📷 Photo by Taylor Vick on Unsplash
