Andrew Mercer
on this page

What it is

The AT Protocol (Authenticated Transfer Protocol, "atproto") is the open protocol Bluesky is built on — developed by Bluesky PBC but designed, deliberately, to allow other independent applications to build on the same network. Where ActivityPub decentralizes at the server level, atproto decentralizes at the account level: your identity and data are meant to be portable between hosting providers without losing your handle, your followers, or your post history.

Architecture: three layers instead of two

atproto splits the problem into three distinct services (see The AT Stack and Federation Architecture for the canonical explanations):

  1. Personal Data Server (PDS) — your actual home. It hosts your repository (posts, likes, follows, profile — everything you've created), manages your signing key, handles login, and proxies your requests to the rest of the network. A PDS is deliberately thin: it doesn't need to know about the rest of the network to do its job, and you can technically run an atproto application against a single PDS with no relay involved at all.
  2. Relay — solves the "big-world" aggregation problem. It crawls as many PDSs as it can reach and re-emits everything as one combined, ordered stream: the firehose. Relays don't interpret the records they carry; they just store and forward them. Today there's effectively one full-network relay that matters in practice — Bluesky's own bsky.network — which is a real, protocol-acknowledged centralization pressure point even though nothing in the spec requires there to be only one.
  3. App View — consumes the firehose and builds an actual product: feeds, search, notification counts, whatever a given application needs. The Bluesky app is one App View among potentially many that could read the same underlying data.

There's also Tap, a newer convenience layer that handles firehose connection, backfill, cryptographic verification, and filtering for you, so an application doesn't have to hand-roll binary CBOR parsing just to consume events for the records it actually cares about.

The firehose

The firehose is the mechanism a huge amount of the atproto ecosystem is built on — feed generators, moderation labelers, bots, and search engines all typically start by subscribing to it via the com.atproto.sync.subscribeRepos WebSocket endpoint. It's technically dense (binary DAG-CBOR encoding, CAR files), which is why Jetstream exists as a simplified alternative that fans the same data out as plain JSON for consumers who don't need the full cryptographic verification story.

Schemas: Lexicon and XRPC

Unlike ActivityPub's loosely-typed JSON-LD, atproto records are strictly schema'd through Lexicon. Every record type — app.bsky.feed.post, app.bsky.graph.follow, and so on — has a formally defined shape that servers validate against, using reverse-DNS-style NSIDs (Namespaced Identifiers) as type names. The API surface itself — both HTTP methods and WebSocket event streams — is described via XRPC, atproto's RPC convention layered on Lexicon schemas. This buys atproto more predictable cross-implementation behavior than ActivityPub's loose typing, at the cost of needing a more formal schema-versioning story as the protocol grows — and, notably, Lexicon schemas themselves are published as ordinary atproto records, resolved the same way user identities are (DNS TXT record → DID → PDS → fetch the schema record).

Identity: DIDs, not server addresses

This is atproto's single biggest architectural departure from ActivityPub. Your durable identity is a DID (Decentralized Identifier, typically did:plc:...), not an address tied to a hosting server. Your human-readable handle (you.bsky.social, or a custom domain) is just a DNS-verifiable pointer to your DID — resolved via a _atproto DNS TXT record or an /.well-known/atproto-did HTTPS endpoint (see the Identity guide for the full resolution chain). Everything that actually matters — your repository, your posts, your social graph — references the DID, not the handle and not the PDS.

The practical payoff: you can move your account to a different PDS provider — including a self-hosted one — without losing your identity, your followers, or your post history. Most accounts use did:plc, resolved against a public PLC directory; if you're confident you'll retain control of a domain long-term, you can instead use did:web, which resolves directly via HTTPS from your own domain rather than depending on the PLC directory at all. (Notably, the PLC method's own maintainers describe it as not truly decentralized in its current form, and expect it to eventually be replaced — worth knowing if you're evaluating how durable this identity layer actually is today.)

Moderation: composable labelers

Rather than moderation living inside a single company's trust-and-safety team or being an all-or-nothing per-server decision (ActivityPub's defederation model), atproto's approach is composable moderation: independent labeler services attach labels to content or accounts (e.g. "likely spam," "graphic media," a topic-specific content flag), and users individually choose which labelers to subscribe to — each with a per-label action of Off, Warn, or Hide. Bluesky runs its own default labelers, but anyone can run one; an organization like a fact-checking group or a community moderation team can publish their own label set for others to opt into. Users can subscribe to up to 20 labelers at once (3 of which are occupied by Bluesky's own default moderation services in the standard app).

Bluesky-the-app's features built on this

A few of Bluesky's most distinctive user-facing features are direct expressions of the atproto architecture rather than things bolted on top:

  • Custom feeds — algorithmic or rule-based feeds built by anyone as an independent App View/feed generator, selectable by any user as an alternative to the default timeline.
  • Starter packs — shareable bundles of up to 150 accounts and 3 custom feeds, used to onboard new users straight into a curated slice of the network.
  • Account portability — genuinely move your account between PDS providers, a direct consequence of DID-based identity.

Strengths and weaknesses

Strengths: portable identity independent of hosting; strict schemas give more predictable cross-implementation behavior; moderation is user-selectable and composable rather than company-decided or instance-blunt; the firehose model makes building alternative apps/feeds on the same data genuinely straightforward.

Weaknesses: relay centralization is a real, currently-unsolved practical bottleneck (one relay dominates); the protocol and ecosystem are younger and faster-moving than ActivityPub's, with more churn in tooling; did:plc — the identity method almost everyone actually uses — is, by its own maintainers' admission, not fully decentralized yet.

Further reading