Hyperlinked JSON on the atmosphere

The AT protocol connects distributed servers into a single web of hyperlinked JSON data. Every piece of content receives its own unique at:// URI to reference across apps.

“Together, all servers speaking the AT protocol comprise the atmosphere —a web of hyperlinked JSON.”

Flipping traditional web authority

In standard HTTPS links, the server hosting the content is the primary authority. AT protocol URIs flip this around by making the creator of the data the literal authority instead.

“In at:// URIs, whoever created the data is the authority, in the most literal sense.”

Storing pure data, not UI

Records retrieved from at:// URIs contain raw data like post text and timestamps. They define the data format using type fields rather than specifying layout or user interface.

“It’s pure data as a piece of JSON , not a piece of UI.”

Three steps of URI resolution

Because host locations change over time, finding the physical JSON requires three distinct steps: handle resolution, identity lookup, and data requesting.

Handles are fragile identifiers

Human-readable domain handles like username.com can be changed at any time by the user. Relying on handles alone in database links would quickly lead to broken connections.

“The user may choose to change their at:// handle later, and it is important for that not to break any links.”

Querying DNS for handle lookup

To resolve a handle to a permanent identity, clients first query DNS TXT records. Looking up the domain yields an immutable Decentralized Identifier, or DID.

Falling back to HTTPS resolution

When DNS queries return no records, protocols fall back to an HTTPS request to a well-known endpoint on the domain to fetch the owner's assigned DID.

Requiring bidirectional verification

Finding a DID from a handle only proves half of the connection. The system must also verify that the identity document explicitly points back to that same handle.

“We’ll need to verify that whoever controls the identity agrees with the handle being theirs.”

Canonical permalinks with DIDs

Converting handles to DIDs creates permanent URIs. These permalinks ensure logical links between documents remain intact even if users change handles or hosts.

“Think of at:// links with DIDs as 'permalinks'.”

Passport of the web

A DID Document acts as a digital passport for an identity. It specifies the user's handle, public signing keys, and current physical hosting server address.

“A DID Document really is like an internet passport for an identity.”

Resolving did:web identities

The did:web method constructs an HTTPS URL directly from the domain path. Fetching its JSON file exposes the user's signing key and hosting service endpoint.

Fragility of web domains

The major downside of did:web is domain dependency. If a user loses control of their domain or fails to renew it, they lose their cryptographic identity entirely.

“If he ever loses control of the domain, he will lose control over his DID Document.”

Resolving did:plc identities

Default Bluesky accounts use did:plc, an identity managed through a dedicated public ledger. Querying this directory returns the same standard DID Document structure.

“PLC officially stands for a Public Ledger of Credentials—essentially, it is like an npm registry but for DID Documents.”

Protecting identity from domain loss

Identities backed by did:plc remain safe even if domain registration expires. Users can update both handle and hosting host without jeopardizing account identity.

“I can change both my handle and my hosting without disruption to my social apps.”

Centralization risks in PLC

While did:plc secures identity against domain loss, it introduces dependency on the registry operator. To mitigate this risk, governance is moving to independent organizations.

“The downside of a did:plc identity is that whoever operates the PLC registry has some degree of control over my identity.”

Reaching physical host endpoints

Once the service endpoint is extracted from the DID Document, clients make direct HTTPS requests to that host server to retrieve the actual JSON payload.

Requesting records via XRPC

Requests to personal data servers use XRPC endpoints like getRecord. The query passes the repository name, record collection type, and record key as parameters.

Optimizing performance with caches

Making step-by-step DNS and HTTPS requests for every link causes significant latency. Production applications rely on resolution caches to drastically speed up queries.

“For good performance, you’ll want to hit a resolution cache instead of doing DNS/HTTPS lookups on every request.”

Event streams versus pull requests

Many applications rarely resolve URIs on demand. Instead, they stream updates continuously over websockets into local databases while retaining at:// URIs as identifiers.

“The data itself will get pushed to you rather than pulled by you.”

Abstraction over existing standards

The AT protocol builds directly on top of HTTP, DNS, and JSON. It turns standard internet infrastructure into a unified decentralized application platform.

“The AT protocol is fundamentally an abstraction over HTTP, DNS, and JSON.”

Realizing true data ownership

Decoupling user identities from hosting providers guarantees content portability. Web applications become presentation layers for data that strictly belongs to users.

“It turns the web into a place where your content belongs to you, not to the apps that display it.”