Loading today’s stories
Build1 distinct publisher3 min readUpdated
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
Compiled by The EngineerSomething wrong?How this is made
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.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Because serving the archives is bandwidth-intensive, Bluesky now requires an API token for archive requests; the live tail remains open and unauthenticated.
Existing @atproto/api code continues to work as before, and the Bluesky API guides serve as a migration reference.
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.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Specific but single-sourced and secondary
The technical detail is unusually checkable for a one-source cluster — named RPCs (planSnapshot, listSegments, getSegment), two live WebSocket endpoints, npm and GitHub distribution, and the @atproto/lex rebuild — which raises confidence that a real release exists. But every claim traces to one enthusiast dev.to post that quotes no primary Bluesky announcement, links no changelog, and offers no independent confirmation, benchmark, or practitioner report. Capability assertions such as eliminating local backfill are restated, not demonstrated.
Live endpoints, no usage evidence
Adoption evidence stops at availability. Endpoints are reported live, SDKs are reported published to npm and GitHub, and a token requirement is in force — all shipped artifacts rather than promises. There is no user count, download figure, named third-party consumer, or migration report anywhere in the cluster, and v1 continuing unchanged means no forced migration pressure that would reveal uptake.
Framing outruns the substance
The verifiable core is a documentation rebrand plus one genuinely useful capability (archive replay) and an SDK refresh. The article scales that to 'changes the game', 'removes several of the biggest practical barriers', and 'the most credible open alternative to centralized social media infrastructure', with no adoption or performance evidence behind any of it. It also frames the release as purely enabling while the single restrictive fact — authentication now required on the archive path, with no quota or issuance terms disclosed — is stated and then left unexamined. Positive gap is moderate rather than severe because the underlying artifacts do appear to be shipped and the technical description is precise.
Promotional relay of a vendor release
The cluster's only source is a developer-community post that reproduces a vendor release narrative in vendor-favourable language, with no author disclosure, no primary link, and no critical questioning; its own incentive is engagement on an enthusiast platform. The subject also has a visible interest of its own: Bluesky is the operator of the infrastructure being branded, and it is introducing token-based authentication on the bandwidth-expensive archive tier while keeping the free tail open — a cost-control and access-control move that the source presents only as a technical footnote. Scored above the midpoint but not extreme, because the concrete artifacts and the token restriction are reported plainly rather than concealed.
Low — one publisher, no corroboration
Every canonical claim rests on a single secondary publisher, so there is no cross-source corroboration, no contradiction to weigh, and no way to confirm dates or terms. Internal specificity (endpoint hostnames, RPC names, package channels) makes the factual skeleton plausible, which keeps confidence from bottoming out, but the capability, service-contract, and market claims are unverified and the operationally decisive token terms are undisclosed.
build
A JSON queue with no database holds up, if unclassified items land mid-rank not last1 distinct publisher
product
Divine bans AI video and bets two million old Vines can hold an audience1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 16, 2026