atmospheric computing: a paradigm of "connected clouds." if traditional servers are "the cloud" (centralized, closed), the AT Protocol creates an "atmosphere" where millions of personal clouds float and interoperate.

sovereign: users run their own "personal cloud" (PDS) and own their identity.
connected: services aggregate data from these personal clouds to build shared experiences.
open: applications compete on service quality, not by locking away data.

architecture #

┌─────────┐     ┌─────────┐     ┌─────────┐
│   PDS   │     │   PDS   │     │   PDS   │    user repos
└────┬────┘     └────┬────┘     └────┬────┘
     │               │               │
     └───────────────┼───────────────┘
                     │ firehose
                     ▼
               ┌───────────┐
               │   Relay   │                   aggregates events
               └─────┬─────┘
                     │ firehose
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
  ┌─────────┐  ┌───────────┐  ┌─────────┐
  │ AppView │  │   Feed    │  │ Labeler │     consume & process
  │         │  │ Generator │  │         │
  └────┬────┘  └───────────┘  └─────────┘
       │
       │ read/write
       ▼
  ┌─────────┐
  │   PDS   │                                  back to user repos
  └─────────┘

components #

PDS (Personal Data Server) is your "personal cloud". it hosts your account, stores your data repo (a signed merkle tree), handles auth, and emits changes. users can migrate their PDS without losing identity or data.

Relay aggregates firehose streams from many PDSes into one. an optimization - downstream services subscribe to one relay instead of thousands of PDSes. multiple relays can exist; anyone can run one.

AppView indexes firehose data into queryable databases. serves the application UI - timelines, search, notifications. also proxies writes back to user PDSes. this is what most people think of as "the app."

Feed Generator subscribes to firehose, applies custom selection logic, returns post URIs on request. enables algorithmic choice - the "For You" feed on bluesky runs on someone's gaming PC.

Labeler produces signed metadata about content (spam, nsfw, etc). appviews and clients subscribe to labelers they trust. enables moderation without centralized control.

data flow #

user creates a record (post, like, follow) via client
client sends write to appview, which forwards to user's PDS
PDS commits record to repo, emits event to firehose
relay aggregates, downstream services consume
appviews update their indices, labelers apply labels
next time someone requests that content, appview serves from index

contents #

identity + data model #

identity - DIDs, handles, resolution, PLC operations
data - repos, records, collections, references
lexicons - schema language, namespaces, what PDS validation actually checks
spaces - permissioned data alpha: where the lexicon contract lives, the wire shapes that bit, what bulletin expects
blobs - raw-leaf CIDs, reference-counted authorization, defensive serving

the write and sync path #

repo-writes - per-repo serialization, lazy MST, rev monotonicity, swap preconditions
car-export - reachability-based getRepo, full-vs-incremental roots, backfill isolation
sync-verification - inductive proof chains, MST inversion, sync 1.1
relay-sync-observability - relay-eval vocabulary for stream gaps, hosting status evidence, and API shape
network-backfill - enumerating and fetching every repo: deep crawl vs relay listRepos, largest-first ordering, why a late rate collapse means completion
record-retrieval - the four access paths (CAR, directory + point reads, directory + CAR walk, archive slice), the read-amplification economics underneath, and which shape each one wins

event streams #

firehose - consuming: the CDC model, jetstream, cursor semantics
serving-event-streams - emitting: precomputed frames, durability watermarks, pull-based fan-out, drop-and-count
firehose-as-sound - fig's observation that atproto rates fall in the audible-frequency band, and what becomes hearable when you map ev/s → Hz directly

auth + services #

auth - OAuth flow, scopes, sessions (client and server side), service auth
oauth - operational OAuth notes: scopes, permission sets, server-side DPoP
xrpc - request/response shape, errors, retries, rate limits
service-proxying - the atproto-proxy header, PDS as dumb pipe, the default-appview fallback, read-after-write
labels - moderation, signed assertions
appviews - building appviews, XRPC, frameworks (quickslice, hatk), backfill, link previews
the-smallest-app-has-no-server - when every read and write is scoped to the signed-in user, the PDS is the database; static hosting, the 127.0.0.1 loopback client, shipping a ranked corpus as an asset, and the ladder off it

sources #

atproto.com - official documentation
atmospheric computing - paul frazee on the "connected clouds" paradigm
introduction to atproto - mackuba
federation architecture - bluesky
plyr.fm - music streaming on atproto
pdsx - atproto CLI/MCP
zds - PDS in zig (repo writes, CAR export, blobs, OAuth/DPoP, PLC)
stream - jetstream reimplementation in zig (cursor contract, fan-out, verification-in-practice)