Build1 publisher3 min readPublished
Bluesky names its infrastructure, and puts a token on the archive
Jetstream v2 adds network replay, so AT Protocol builders can recover from downtime without backfilling repos themselves. The catch is that archive requests now need an API token.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Bluesky launched Bluesky Protocol Services, a new brand and website for the public infrastructure Bluesky operates on the AT Protocol network.
- The launch includes Jetstream v2 with network replay, a new Jetstream SDK, and a rebuilt TypeScript SDK.
- Bluesky already operated Jetstream instances, relays, and the Bluesky API endpoints built on the AT Protocol.
- For developers building on that infrastructure, the docs did not always make it clear what Bluesky runs as a service or where to start.
- With Jetstream, a developer describes the slice of data they want and it arrives as plain JSON over a WebSocket; what it could not give was history.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
Bluesky has put a brand and a website on infrastructure it was already running, launching Bluesky Protocol Services alongside Jetstream v2 with network replay, new Jetstream SDKs, and a rebuilt TypeScript SDK [1][2]. The consequence for anyone building on the AT Protocol is not the branding: it is that the hardest operational problem in the stack, catching up on history, has moved from your machines to Bluesky's.
The situation before this was unglamorous. Bluesky ran Jetstream instances, relays, and the Bluesky API endpoints, but the documentation did not make clear what was offered as a service or where to begin [3][4]. Jetstream itself was the pragmatic path: describe the slice of the network you want and it arrives as plain JSON over a WebSocket, with no history [5]. If you needed records that already existed, you backfilled repos yourself and then cut over to the live tail [6]. That is a second system to build, operate, and pay for, and it is the part most side projects never finished.
Jetstream v2 keeps a compressed archive of the whole network [7]. Network Replay lets a consumer catch up from any point in the past and cut over to live with no gap: POST your filters to planSnapshot, download the sealed segments it returns over plain HTTP, then connect the WebSocket once at the tip [8][9]. Replay is stateless on the server, with no per-consumer cursor, no subscription to register, and nothing to stage on the client [10]. There is also an archive-only mode using listSegments and getSegment over HTTP, same filters, no live tail [11]. The framing in the dev.to write-up of the launch is that this covers spinning up an app, running an analysis over a month of posts, or recovering from downtime, all in the same JSON shape as the live stream [12].
Read that list again with an operator's eye. Recovering from downtime is the one that matters, because it is the failure mode you cannot design away. Until now, a consumer that fell behind its cursor either lost data or needed its own backfill machinery. Now it replays. The price is a dependency: because serving archives is bandwidth-intensive, Bluesky requires an API token for archive requests, while the live tail stays open and unauthenticated [13]. So the free, anonymous part of the network is still the firehose, and the part that makes the firehose survivable is metered and identified. That is a normal shape for hosted infrastructure. It is also new for this stack.
The rest is debt paydown. Two v2 endpoints are live, us-west and us-east, and the v1 instances keep running unchanged [14][15]. New Jetstream SDKs in TypeScript and Go absorb the reconnect, dedupe, cursor and decode glue [16], distributed via npm and the Jetstream GitHub project [17]. The Bluesky TypeScript SDK is now rebuilt on @atproto/lex, following the lex stable preview in May, and Bluesky is no longer maintaining legacy code paths for Bluesky-specific helpers [18][19]. Existing @atproto/api code keeps working, with the API guides as migration reference [20].
What to watch: the launch says service contracts around Bluesky-provided infrastructure are clarified [21], but the write-up does not state the numbers, so the retention window on the archive, the rate limits on tokens, and what happens when a token is refused are the terms to read before you design around replay.