Bluesky Rebranded Its Infrastructure and Shipped Jetstream v2. Here's What Changes If You Build on AT Protocol.
Bluesky put a new name on infrastructure it's been running for a while: Bluesky Protocol Services, a rebrand that bundles its relay, Jetstream firehose, and API endpoints and replaces the old docs.bsky.app site. The headline technical change is Jetstream v2, which lets a client describe the slice of the network it wants and get it back as plain JSON over a WebSocket, no CBOR decoding required. If you've tried to build anything on AT Protocol before, that last part is the one that matters.
I've poked at Bluesky bots and small analytics scripts a couple of times over the past year and bounced off the same wall each time: figuring out which parts of the stack were Bluesky's servers, which were "the protocol" that anyone could run, and how to actually parse the firehose without wading through the CBOR spec. This update is Bluesky admitting that confusion was a real onboarding cost, and doing something about it.
What actually shipped
Three things, per Bluesky's own post. First, a documentation reorg: the new site draws an explicit line between infrastructure Bluesky operates as a service, relays, the Jetstream firehose, App View, and the open AT Protocol specification that anyone can implement and self-host. That distinction has existed conceptually since AT Protocol launched, but it lived in scattered docs and community knowledge rather than one place that says "here's what we run, here's what's yours to run."
Second, Jetstream v2. The original firehose delivers the full, unfiltered stream of network events as CBOR-encoded records, which is efficient but means every consumer needs a CBOR parser and enough bandwidth to handle a firehose that includes every post, like, and follow across the network, then filter client-side. Jetstream v2 flips that: you describe what you want (specific collections, specific DIDs, specific record types) and the server does the filtering, handing you JSON over a WebSocket. Less bandwidth, less parsing code, a much shorter path from "I have an idea for a Bluesky bot" to "it's running."
Third, and this is more of a signal than a feature: Bluesky treating its own operational infrastructure as a documented product surface instead of internal plumbing that third parties happen to be allowed to poke at. That's a meaningful posture shift for a company whose entire pitch is that the protocol matters more than any single implementation, including its own.
Why the documentation gap mattered
AT Protocol's whole design premise is that Bluesky the company and Bluesky the network are supposed to be separable, you can self-host a personal data server (PDS), run your own relay, build a competing client, and none of it requires Bluesky's cooperation. That's a real architectural advantage over closed platforms. But in practice, "you technically can run your own infrastructure" and "there's a clear, documented path to actually doing it without reverse-engineering the reference implementation" are different things, and AT Protocol has spent more time on the former than the latter.
The old docs.bsky.app site worked, but it read like documentation written for people who already understood the architecture, not for someone deciding whether to spend a weekend building on top of it. A dedicated Protocol Services site with a name and a clear "here's the service contract" framing is a small thing that compounds: it's the difference between a developer bouncing off confusing docs in twenty minutes and a developer shipping something in a weekend.
What this means if you build tools on social platforms
Solo operators building on Bluesky have historically split into two camps: people willing to reverse-engineer the firehose for a specific project, and everyone else who defaulted to X or nothing because the barrier was too high. Jetstream v2 plus real documentation moves the second group's math. A JSON WebSocket feed you can filter server-side is genuinely closer to "hook this up to a serverless function and ship" than "spend a week building a CBOR parser and a filtering layer before you write a single line of actual product logic."
That matters more now than it would have a year ago because Bluesky's user base and posting volume have grown enough that building tools there, alerting bots, niche analytics dashboards, moderation aids, content aggregators, is a plausible small business, not just a hobby project with no audience. Lower the cost of the plumbing and more of that gets built.
What I'd actually do
If you've been putting off a Bluesky-adjacent side project because the firehose felt like too much infrastructure work, this is the moment to reconsider. Start with Jetstream v2's filtered subscription model rather than defaulting to the full firehose, most tools don't need every event on the network, and the bandwidth and parsing savings compound fast at any real scale.
Where I'd push back on my own enthusiasm: a rebrand and a better WebSocket API don't fix the harder problem, which is that AT Protocol's network effects are still smaller than X's or even smaller decentralized alternatives depending on your niche. Better developer experience makes it cheaper to build the tool. It doesn't guarantee an audience wants it. Validate the demand side before you invest real time in the plumbing side, even though the plumbing just got a lot easier to justify.
Author
Lukas
@lukcombinator