# Bluesky Put the Whole Network on Replay. Who Holds the Archive? **Summary:** Jetstream v2 can replay filtered AT Protocol history and cut over to live data. Bluesky still holds the default archive, so recovery is easier while decentralization remains unfinished. - Canonical: https://markhuang.ai/news/bluesky-network-replay-who-holds-archive - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-08-13 - Section: News - Tags: Bluesky, AT Protocol, Jetstream, Decentralized Social, Developer Infrastructure - Source: [AT Protocol](https://atproto.com/blog/introducing-bluesky-protocol-services) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![Distributed network nodes feed a live blue stream through a gated stack of transparent archive segments](https://cdn.markhuang.ai/news/bluesky-network-replay-who-holds-archive/hero.webp) *Replay makes network history easier to consume. It also makes the operator holding that history easier to see.* On August 13, 2026, [Bluesky launched Bluesky Protocol Services](https://atproto.com/blog/introducing-bluesky-protocol-services), a new name and documentation home for the public AT Protocol infrastructure it operates. The release includes Jetstream v2, which keeps a compressed archive of the whole network and can replay a filtered slice of past records before handing the same stream over to live updates. That handoff is the part I care about. A developer can recover after downtime or build an index without crawling every Personal Data Server and writing a fragile history-to-live cutover. Bluesky requires an API key for archive requests because those downloads are bandwidth intensive. The live WebSocket remains open and unauthenticated. My read is mixed but mostly positive. Bluesky has turned a difficult piece of network plumbing into a usable service. It has also made the network's current dependency easier to name. The protocol is open. The convenient archive most developers will reach for is still operated by Bluesky. ## Replay fixes an unglamorous failure mode Jetstream already offered selected AT Protocol events as plain JSON over a WebSocket. That was useful for a live feed, labeler, bot, or search index, but it did not solve history. A new consumer had to fetch existing repositories, manage a backfill, and then switch to the live stream without missing or duplicating records. The new [Network Replay flow](https://bsky.network/docs/jetstream-replay) plans the requested archive range, downloads sealed segments over HTTP, and connects to the live tail at the archived tip. The server does not keep a cursor or subscription for each consumer. The client persists its last handled sequence number, and the SDK deduplicates the seam between the archive and live data. That is more than documentation cleanup. Recovery goes from a custom data project to a resumable service call. The archive endpoints are metered by compressed response bytes rather than request count. If a client reaches its limit during a download, the service returns a retry interval and supports resuming from the previous byte offset. > **Info:** > > I would use Replay for recovery and controlled backfills, but I would still persist my own cursor, make event handling idempotent, and rehearse a rebuild. A managed archive reduces the work; it does not transfer responsibility for my index. ## The token marks the expensive boundary Bluesky's split between an open live stream and token-gated history is sensible. Live fan-out is comparatively cheap. Serving old data means storing the archive, scanning it for a requested slice, and moving substantial numbers of bytes. A token gives the operator a way to meter that load and protect other consumers. It also creates a service boundary that developers should treat as a dependency. Bluesky has not announced a price in the launch post or Replay documentation. An API key is not evidence of a future fee, and I would not invent one. It does mean archive access now has an account, quotas, and operator policy attached to it. Those are normal properties of hosted infrastructure, but they belong in the architecture diagram and the failure plan. Early [Reddit discussion](https://www.reddit.com/r/BlueskySocial/comments/1vnk5vc/introducing_bluesky_protocol_services/) barely engages with that tradeoff. Some commenters want user-facing features instead; another reduces at-scale data access to more bots. That reaction is thin evidence, yet it captures the launch's communication problem. A replay service matters to developers precisely because ordinary users should never have to notice the backfill that kept an app's view complete. ## Open source still needs an operator Jetstream is open source and self-hostable. That matters. The [self-hosting guide](https://bsky.network/docs/jetstream-self-host) says one static Go binary can serve the live tail, replay, and snapshots without a separate database. An operator can keep the archive on its own hardware, choose retention, and audit the data it serves. The same guide gives independence a cost even without quoting dollars. A full-network archive is already multi-terabyte and grows with the network. Memory needs are a few GiB in steady state, and the guide describes CPU demand as modest. Disk and network traffic are the serious requirements. Open code makes an alternative possible. Someone still has to fund and operate it. This is where I find the older criticism from the [Electronic Frontier Foundation](https://www.eff.org/deeplinks/2024/12/what-you-should-know-when-joining-bluesky) useful. In December 2024, EFF argued that Bluesky's "credible exit" was not the same as a decentralized network because core hosting, relay, moderation, and identity infrastructure remained concentrated around the company. The specific network counts in that article are dated, so I would not reuse them now. The distinction still holds: software that another operator can run is different from infrastructure another operator is already running at useful scale. There is progress beyond Bluesky's own machines. The AT Protocol guide now lists relays from Microcosm, Blacksky, UpCloud, Firehose, and Bluesky. In March 2026, Bluesky also announced a $20,000 grant for [Hubble](https://atproto.com/blog/introducing-hubble-a-public-mirror-for-the-whole-atmosphere), an independently maintained project intended to keep public repository data available when a Personal Data Server goes offline. The announcement says Hubble will mirror current public state rather than event history, so it is not a replacement for Jetstream Replay. Its funding plan is closer to what credible exit requires: pay another operator to build and run a copy, then make that software available to others. ## Who should hold the archive? For a small team, I would start with Bluesky's hosted Jetstream. Rebuilding network ingestion before proving the product would be expensive theater. I would record the API limits, retain cursors and derived data I can legally keep, and make the dependency explicit. For an app whose promise depends on complete history, independent moderation, or surviving a Bluesky outage, the answer changes. I would test self-hosting or a second provider before calling the system resilient. Public source code answers whether replacement is possible. I care how long that replacement takes when the default endpoint is unavailable. Bluesky Protocol Services gives the network a cleaner front door, and Jetstream v2 solves a real problem behind it. I think that is good infrastructure work. I will call the replay layer decentralized when developers can choose among working operators. Today, Bluesky has made the default much better and the remaining dependency much clearer.