Glonce

Bluesky ships Jetstream v2 with Network Replay and new SDKs

infrastructureThe Glonce editorsHacker News🔥69Glonce rating69Impact60Novelty65Relevance70Surprise35Players50Credibility88
Bluesky ships Jetstream v2 with Network Replay and new SDKs

Bluesky has launched Bluesky Protocol Services, a new brand and website for the public infrastructure the company runs on the AT Protocol network. Bluesky says it has always operated more than the Bluesky app itself: it also runs Jetstream instances, relays, and the Bluesky API endpoints built on atproto. Its documentation, Bluesky says, did not always make clear to developers what it runs as a service or where to start, and Bluesky Protocol Services is meant to fix that by organizing all of the ecosystem's developer documentation in one place, clarifying the service contracts around Bluesky-provided infrastructure, replacing the old docs.bsky.app site, and giving Bluesky a consistent way to ship future releases like the ones in this post.

The headline release alongside the new site is Jetstream v2. Jetstream is how most developers consume the AT Protocol network at scale: you describe the slice of the network you want, and it arrives as plain JSON over a WebSocket. What it could not do was give you history: if you needed records that already existed on the network, you had to backfill the relevant repositories yourself, then cut over to the live stream. Jetstream v2 adds that capability on the server, keeping a compressed archive of the whole network and adding a new way to consume it alongside the existing live tail. Network Replay lets a developer catch up from any point in the past and cut over to live with no gap: you POST your filters to a planSnapshot endpoint, download the sealed segments it returns over plain HTTP, then connect to the live WebSocket once you reach the tip. Bluesky describes Replay as stateless on the server, with no per-consumer cursor, no subscription to register, and nothing to stage on the client. A simpler alternative ships alongside it: developers can just snapshot the network, a point-in-time copy of the archive delivered over HTTP only, through the listSegments and getSegment endpoints, with no live tail involved. Both draw on the same archive and the same filters. Bluesky says this unlocks more sophisticated server-side slicing without ever backfilling locally: a developer could spin up an app, run an analysis over a month of posts, or recover from downtime, all through the same JSON shape as the live tail (Bluesky offers the month-of-posts case only as an example of what Replay supports, not as a stated capacity or retention limit).

Because serving these archives is bandwidth-intensive, Bluesky now requires an API token for archive requests specifically, to keep the service reliable and cheap to run; the live tail itself remains open and unauthenticated, and Bluesky says it has no plans to add an authentication requirement there. The v2 instances are already live, at wss://jetstream.us-west.bsky.network and wss://jetstream.us-east.bsky.network. The existing v1 instances will keep running unchanged for a while, and Bluesky says the live tail behaves identically on both versions, so there is no rush for developers to move over. As with the rest of Bluesky's protocol infrastructure, Jetstream remains open source and self-hostable.

Bluesky also introduced new Jetstream SDKs, for TypeScript and Go, both in preview. Jetstream's output is plain JSON, so an SDK was never required, but the new clients wrap the common glue: reconnecting, deduplicating, cursor management, and decoding events into typed records. A developer constructs a Jetstream object, passes it a filter, and iterates over decoded, typed events as they arrive. The TypeScript SDK is distributed through npm, including npmx, and the Go SDK ships as part of the Jetstream project itself. Separately, the Bluesky TypeScript SDK has been rebuilt on top of @atproto/lex, the company's lexicon toolchain, typed end to end from the protocol layer up through app.bsky records. Bluesky frames this as delivering on a promise from May, when it promoted the lex SDK to stable preview and said standalone Bluesky docs would follow. Every TypeScript example on the new site is now written against lex rather than the legacy Bluesky-specific helper code Bluesky says it no longer has to maintain, which Bluesky says should eliminate LLM recommendations for deprecated SDKs, stated as an expected effect rather than a confirmed outcome. Existing code built on the older @atproto/api package keeps working as before; Bluesky positions its API guides as a migration reference for developers who want to move over, not as a forced cutover.

Bluesky also updated its HTTP reference at endpoints.bsky.app, the last step of an overhaul that began by spinning that reference out of the old docs.bsky.app site. The new network.bsky.jetstream.* methods that power Replay (planBackfill, listSegments, getSegment, and getBlock) are now browsable there with full request and response schemas, and the reference now documents Jetstream's WebSocket endpoints too, so the entire Jetstream v2 surface lives in one place. Everything described here (the new site, the v2 Jetstream instances, the SDK preview, and the updated HTTP reference) is live as of the announcement. Bluesky points developers new to the network toward a visual walkthrough called How It Works, which walks through how records, lexicons, and the firehose fit together, and says the Bluesky API guides remain available and freshly rewritten for anyone building against the Bluesky app's own data model. Bluesky is also asking developers who build something on Replay in the next few weeks to share it, saying that is the fastest way to shape where the SDK's orchestration goes next.

Key facts

  • Bluesky launched Bluesky Protocol Services, a new brand and website that consolidates documentation for the public AT Protocol infrastructure it runs (Jetstream, relays, and Bluesky's API endpoints), replacing the old docs.bsky.app site.
  • Jetstream v2's headline feature, Network Replay, lets developers pull history from a compressed archive of the whole network over plain HTTP (POST filters to planSnapshot, download the sealed segments), then join the live WebSocket tail with no gap; a separate snapshot mode offers an HTTP-only, point-in-time archive copy with no live tail.
  • Archive requests now require a new API token because serving them is bandwidth-intensive, but the live WebSocket tail stays open and unauthenticated, and Bluesky says it has no plans to add authentication there.
  • New Jetstream SDKs for TypeScript and Go ship in preview, and the Bluesky TypeScript SDK has been rebuilt on the @atproto/lex toolchain, fulfilling a promise Bluesky made in May when it promoted lex to stable preview; existing @atproto/api code still works.
  • The v2 Jetstream instances are live now at wss://jetstream.us-west.bsky.network and wss://jetstream.us-east.bsky.network, while the existing v1 instances keep running unchanged 'for a while,' with an identical live tail on both.

Why it matters

Jetstream has been Bluesky's primary way to let developers consume the AT Protocol network at scale, but only as a live feed: describe a filtered slice and it arrives as plain JSON over a WebSocket, with no access to anything that happened before you connected. Jetstream v2 removes that limit by keeping a compressed archive of the whole network on the server and adding Network Replay, a way to catch up from any point in the past and cut over to the live tail with no gap, without a developer having to backfill and stage that history themselves. Bluesky pairs the release with a rebrand, Bluesky Protocol Services, meant to make clear in one place what infrastructure the company runs as a public service for the wider AT Protocol ecosystem, replacing documentation that Bluesky itself says did not make clear what it operates or where to start.

Who it affects

Developers already building on Jetstream at scale (analytics tools, alternative apps, anything that needs a slice of the network as JSON) get access to history they previously had to assemble themselves through manual backfilling. Anyone requesting that history now needs an API token, though developers who only consume the live tail are unaffected and remain unauthenticated. TypeScript and Go developers get new preview SDKs that wrap Jetstream's reconnect, dedupe, and decoding logic, and anyone using the Bluesky TypeScript SDK now runs on code rebuilt around the @atproto/lex toolchain, though existing code on the older @atproto/api package keeps working. Developers who self-host their own Jetstream instance can draw on the same open source release.

How to use it

Two ways to reach history now exist alongside the live tail. Network Replay is for catching up and then staying live: POST your filters to the planSnapshot endpoint, download the sealed segments it returns over plain HTTP, and connect to the live WebSocket once at the tip; Bluesky describes it as stateless on the server, with no per-consumer cursor, no subscription to register, and nothing to stage on the client. A plain snapshot mode is simpler: a point-in-time copy of the archive over HTTP only, through listSegments and getSegment, with no live-tail component. Archive requests of either kind now require an API token because serving them is bandwidth-intensive; the live tail stays open and unauthenticated, and Bluesky says it has no plans to change that. The v2 instances are already live at wss://jetstream.us-west.bsky.network and wss://jetstream.us-east.bsky.network, while the existing v1 instances keep running unchanged, with an identical live tail on both, so there is no rush to switch. New Jetstream SDKs for TypeScript (via npm, including npmx) and Go (bundled with the Jetstream project) are available in preview, and full request and response schemas for the new network.bsky.jetstream.* methods (planBackfill, listSegments, getSegment, and getBlock) are documented at endpoints.bsky.app alongside Jetstream's WebSocket endpoints. Jetstream itself stays open source and self-hostable.

How solid is it

This is a first-party Bluesky launch post, written entirely in the company's collective voice; no individual author, executive, or spokesperson is named anywhere in it. There are no independent benchmarks, adoption figures, or user or developer counts offered to weigh the claims against. The technical claims (the request flow, the statelessness of Replay, the token requirement) are asserted rather than backed with data in the post itself, though they describe mechanics a developer can verify directly by using the service. Bluesky's claim that rewriting its examples against the lex SDK should eliminate LLM recommendations for deprecated SDKs is presented as an expected effect, not a measured outcome.

Risks and caveats

Several practical details are left open. No cost or process is described for obtaining the new API token that archive requests now require. No date is given for the launch beyond 'today,' and no specific end date is given for retiring the v1 Jetstream instances beyond 'for a while,' so developers still on v1 have no firm migration deadline. No figures are given for the archive's size or retention period; 'a month of posts' appears only as an illustrative example of what Replay can support, not a stated capacity or limit. The post also does not explain why Jetstream previously could not provide historical records; it only states that history was the one thing missing until now.

“Replay is stateless on the server, with no per-consumer cursor, no subscription to register, and nothing to stage on the client.”

— Bluesky, in the Jetstream v2 announcement introducing Network Replay