Skip to content
Desert Thunder

AT Protocol

The Authenticated Transfer Protocol (AT Protocol) is an open, decentralized protocol for social networking. It is the foundation of Bluesky and designed to give users ownership of their data and identity.

Core Principles

Section titled “Core Principles”
  1. Account Portability: Users can move their data between service providers without losing their identity, followers, or content.
  2. Algorithmic Choice: Users can choose custom feeds and algorithms, not locked to one provider’s choices.
  3. Interoperability: Open standards enable a federated ecosystem where services can communicate.
  4. Performance at Scale: Designed to handle billions of users with a hybrid federated/indexed architecture.

Architecture

Section titled “Architecture”

The AT Protocol uses a layered architecture:

┌─────────────────────────────────────────────────┐
│                   App Views                     │  (Bluesky, custom apps)
├─────────────────────────────────────────────────┤
│                   Lexicons                      │  (Schema definitions)
├─────────────────────────────────────────────────┤
│          Personal Data Repositories             │  (User data storage)
├─────────────────────────────────────────────────┤
│          Identity Layer (DIDs + Handles)        │  (Decentralized identity)
└─────────────────────────────────────────────────┘

Identity

Section titled “Identity”
  • DIDs (Decentralized Identifiers): Persistent identifiers (e.g., did:plc:abc123) that remain stable across server migrations.
  • Handles: Human-readable names (e.g., @alice.bsky.social) that resolve to DIDs via DNS or HTTP.

Personal Data Servers (PDS)

Section titled “Personal Data Servers (PDS)”

Every user’s data lives in a Personal Data Server.

A PDS:

  • Stores the user’s repository (a signed, Merkle-tree-based data structure).
  • Handles authentication and authorization.
  • Syncs data to relays and indexers.

Relay (BGS)

Section titled “Relay (BGS)”

Relays aggregate data from many PDSs into a unified firehose, enabling:

  • Efficient indexing for search and discovery.
  • Feed generators to access content across the network.

App View

Section titled “App View”

An App View consumes the firehose and provides application-specific APIs. For example, the Bluesky app view provides the social networking experience.

Data Model

Section titled “Data Model”

Repositories

Section titled “Repositories”

A repository is a user’s complete data store, structured as a Merkle Search Tree (MST).

  • Records: Individual data items (posts, likes, follows) stored as DAG-CBOR.
  • Collections: Namespaced groups of records (e.g., app.bsky.feed.post).
  • Commits: Signed snapshots of the repository state.

Lexicons

Section titled “Lexicons”

Lexicons are JSON schemas that define:

  • Record types and their fields.
  • XRPC methods (HTTP-like RPC calls).
  • Subscriptions for real-time data.

Example Lexicon ID: app.bsky.feed.post

AT-URIs

Section titled “AT-URIs”

Records are addressed using AT-URIs:

Terminal window
at://did:plc:abc123/app.bsky.feed.post/3jqw2f7

Format: at://<authority>/<collection>/<rkey>

Key Technologies

Section titled “Key Technologies”
ComponentPurpose
DAG-CBORCanonical binary serialization format
MSTContent-addressed, verifiable key-value storage
CARArchive format for repository export/sync
CIDsContent identifiers linking to any data block
XRPCHTTP-based RPC protocol for API calls

Sync & Federation

Section titled “Sync & Federation”

Repo Sync

Section titled “Repo Sync”

Repositories are synchronized using:

  1. com.atproto.sync.getRepo: Full repository export as a CAR file.
  2. com.atproto.sync.subscribeRepos: Real-time firehose of commits across the network.

Event Stream

Section titled “Event Stream”

The firehose emits events:

  • Commit: New or updated records.
  • Handle: Handle changes.
  • Identity: DID document updates.
  • Tombstone: Account deletions.

References

Section titled “References”