AT Protocol Deep Dive: How Bluesky Really Works

The Authenticated Transfer Protocol (AT Protocol or atproto) is an open networking protocol for building decentralized social applications. Developed by Bluesky PBC, it is now governed as an open specification. AT Protocol's core design goals are:

• •

  Account portability: Users can migrate between hosting providers without losing their identity, followers, or content.

• •

  Self-authenticating data: Every piece of data is cryptographically signed by the user's key, so any observer can verify authenticity without trusting a central server.

• •

  Interoperability: Any developer can build an AT Protocol client, server, or application — the protocol defines the interfaces, not the implementations.

• •

  Algorithmic choice: Users choose their own feed algorithms via open feed generators, rather than being locked into a platform's proprietary ranking.

Every Bluesky account is backed by a DID — a W3C Decentralized Identifier — that is independent of any server. Your DID persists even if you move your data to a different host or if Bluesky PBC ceases to exist.

A PDS is an HTTPS server that stores your AT Protocol repository — all of your posts, likes, follows, and profile data. Unlike Mastodon where your data is bound to an instance, your AT Protocol repository is cryptographically signed and fully portable.

A Lexicon is a JSON schema document that defines the structure of a record type, XRPC method, or event type in the AT Protocol. Lexicons serve as the interoperability contract between AT Protocol services.

Bluesky posts store plain text in the text field and annotate it with facets — structured objects that mark byte ranges of the text and attach a feature type. This separation of text from markup makes posts portable and parseable without custom HTML.

{
  "text": "Hello @atproto.com! Check https://bsky.app #bluesky",
  "facets": [
    {
      "index": { "byteStart": 6, "byteEnd": 17 },
      "features": [{ "$type": "app.bsky.richtext.facet#mention", "did": "did:plc:..." }]
    },
    {
      "index": { "byteStart": 25, "byteEnd": 40 },
      "features": [{ "$type": "app.bsky.richtext.facet#link", "uri": "https://bsky.app" }]
    },
    {
      "index": { "byteStart": 41, "byteEnd": 49 },
      "features": [{ "$type": "app.bsky.richtext.facet#tag", "tag": "bluesky" }]
    }
  ]
}

The AT Protocol uses a Relay — a server that aggregates repository events from all PDS hosts and re-broadcasts them as a unified event stream called the Firehose. Any service can subscribe to the Firehose at com.atproto.sync.subscribeRepos and receive every post, like, follow, and profile update on the entire network in real time.

This architecture is what enables global search, custom feed generators, and third-party analytics to work across the entire Bluesky network without needing to crawl individual servers. The main relay is operated by Bluesky PBC at bsky.network, but anyone can run a relay.

A Feed Generator is any web service that implements the app.bsky.feed.getFeedSkeleton Lexicon — it returns a list of post URIs in a ranked order. Users subscribe to Feed Generators and see them alongside their Following feed.

Because Feed Generators consume the Firehose and implement an open Lexicon, the community can build and publish feeds without any permission from Bluesky PBC. The Discover feed at bsky.app is itself just one of thousands of available feeds.