Bluesky Protocol Services

# Introducing Bluesky Protocol Services - AT Protocol Source: [https://atproto.com/blog/introducing-bluesky-protocol-services](https://atproto.com/blog/introducing-bluesky-protocol-services) Today we’re launching**[Bluesky Protocol Services](https://bsky.network/)**: a new brand, and a new website, for the public infrastructure Bluesky operates on the[AT Protocol](https://atproto.com/)network\. Bluesky has always run more than the Bluesky app\. We operate Jetstream instances, relays, and the Bluesky API endpoints built on atproto\. But if you were a developer trying to build on that infrastructure, our docs didn’t always make it easy to tell what we run as a service or where to start\. We’re fixing that today\. Bluesky Protocol Services organizes all the documentation developers need within the ecosystem, clarifies the service contracts around Bluesky\-provided infrastructure, replaces the old docs\.bsky\.app site and gives us a clean way to ship future releases like the ones in this post\! The headline release shipping alongside the new site is**Jetstream v2**\. Jetstream is the best way for most developers to use the network at scale: you describe the slice you want, and it arrives as plain JSON over a WebSocket\. What it couldn’t give you was*history*\. If you needed the records that already existed on the network, you had to backfill repos yourself then cut over to the live stream\. Jetstream v2 adds that capability to the server\. It keeps a compressed archive of the whole network and adds a new way to consume it, alongside the live tail: **Network Replay**lets you catch up from any point in the past and cut over to live with no gap\. You`POST`your filters to`planSnapshot`, download the sealed segments it returns over plain HTTP, then connect the live WebSocket once at the tip\. Replay is**stateless on the server**, with no per\-consumer cursor, no subscription to register, and nothing to stage on the client\. Jetstream is your buffer\. You can also*just*snapshot the network — a point\-in\-time copy of the archive over HTTP only \(`listSegments`\+`getSegment`\), with no live tail\. Same archive, same filters, no WebSocket\. This unlocks much more sophisticated server\-side slicing without ever backfilling locally: you can spin up an[App](https://atproto.com/guides/the-at-stack), run an analysis over a month of posts, or recover from downtime, all through the same JSON shape as the live tail\. Serving these archives is bandwidth\-intensive\. To ensure the service remains reliable and cheap to run, we’re now requiring an[API token just for these requests](https://bsky.network/account)\. The live tail remains open and unauthenticated, it’s only when you request an archive that we require a token\. We have no plans to introduce an auth requirement for the live stream\. The v2 instances are live now 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 the live tail behaves identically on both, so there’s no rush to move\. Read the full flow in the[Network Replay docs](https://bsky.network/docs/jetstream-replay)\. And\! As always, this infrastructure is open source and self\-hostable\. See[Running your own Jetstream](https://bsky.network/docs/jetstream-self-host)for details\. Jetstream is plain JSON, so you never*need*an SDK\. But there’s some common glue: reconnecting, deduping, cursor management, decoding events into typed records\. Hence, the new**Jetstream SDKs**: TypeScript and Go clients where you construct a`Jetstream`object, pass a filter, and`for await`over decoded, typed events: The TypeScript SDK is available from npm, including[npmx](https://npmx.dev/package/@bsky/jetstream)\. The Go SDK is available as part of the[Jetstream project](https://github.com/bluesky-social/jetstream)\. The[Jetstream SDK docs](https://bsky.network/docs/jetstream-sdk)go into more detail\. Back in May we[promoted the`lex`SDK to stable preview](https://atproto.com/blog/ts-sdk-upgrades)and promised that the standalone Bluesky docs would follow\. That’s now done: the[**Bluesky TypeScript SDK**](https://npmx.dev/package/@bsky/sdk)is rebuilt on top of[`@atproto/lex`](https://www.npmjs.com/package/@atproto/lex), which means we’re no longer maintaining legacy code paths for Bluesky\-specific helpers\. This is the lexicon toolchain, fully typed end to end, from the protocol layer up through`app\.bsky`records\. Every TypeScript example on this new site is written against it, marking a huge move away from legacy technical debt—this is good code hygiene for us, and should eliminate LLM recommendations for deprecated SDKs\. If you’re still using`@atproto/api`code, it continues to work as before, and the[Bluesky API guides](https://bsky.network/docs/bluesky-api)serve as a migration reference\. Finally, the[HTTP reference](https://endpoints.bsky.app/)has been updated\. Spinning those docs*out of*[https://docs\.bsky\.app](https://docs.bsky.app/)was actually step 1 of this overhaul; we’re now landing the remainder\. The new`network\.bsky\.jetstream\.\*`methods that power Replay —`planBackfill`,`listSegments`,`getSegment`, and`getBlock`— are now browsable 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 above is live today: the[new site](https://bsky.network/), the v2 Jetstream instances, the SDK preview, and the updated HTTP reference\. If you’re new to the network, start with[How It Works](https://bsky.network/docs/how-it-works), a visual walkthrough of how records, lexicons, and the firehose fit together\. If you’re building against the Bluesky app’s data model, the[Bluesky API guides](https://bsky.network/docs/bluesky-api)are all still there, freshly rewritten \(more on that below\) If you build something on Replay in the next few weeks, we’d love to hear about it; the fastest way to shape where the SDK’s orchestration goes is to show us what you’re folding the stream into\.