Glossary of terms

The AT Protocol uses a lot of terms that may not be immediately familiar. This page gives a quick reference to these terms and includes some links to move information.

Atmosphere

The "Atmosphere" is the term we use to describe the ecosystem around the AT Protocol.

AT Protocol

The AT Protocol stands for "Authenticated Transfer Protocol." This name is in reference to the fact that all user-data is signed by the authoring users, which makes it possible to broadcast the data through many services and prove it's real without having to speak directly to the originating server.

The name is also a play on the "@" symbol, aka the "at" symbol, since atproto is designed for social systems.

PDS (Personal Data Server)

A PDS, or Personal Data Server, is a server that hosts a user. A PDS will always store the user's data repo and signing keys. It may also assign the user a handle and a DID. Many PDSes will host multiple users.

A PDS communicates with AppViews to run applications. A PDS doesn't typically run any applications itself, though it will have general account management interfaces such as the OAuth login screen. PDSes actively sync their data repos with Relays.

AppView

An AppView is an application in the Atmosphere. It's called an "AppView" because it's just one view of the network. The canonical data lives in data repos which is hosted by PDSes, and that data can be viewed many different ways.

AppViews function a bit like search engines on the Web: they aggregate data from across the Atmosphere to produce their UIs. The difference is that AppViews also communicate with users' PDSes to publish information on their repos, forming the full application model. This communication is established as a part of the OAuth login flow.

Relay

A Relay is an aggregator of data repos from across the Atmosphere. They sync the repos from PDSes and produce a firehose of change events. AppViews use a Relay to fetch user data.

Relays are an optimization and are not strictly necessary. An AppView could communicate directly with PDSes (in fact, this is encouraged if needed). The Relay serves to reduce the number of connections that are needed in the network.

Lexicon

Lexicon is a schema language. It's used in the Atmosphere to describe data records and HTTP APIs. Functionally it's very similar to JSON-Schema and OpenAPI.

Lexicon's sole purpose is to help developers build compatible software.

• An introduction to Lexicon
• Lexicon spec

Data Repo

The "data repository" or "repo" is the public dataset which represents a user. It is comprised of collections of JSON records and unstructured blobs. Every repo is assigned a single permanent DID which identifies it. Repos may also have any number of domain handles which act as human-readable names.

Data repositories are signed merkle trees. Their signatures can be verified against the key material published under the repo's did.

• An introduction to data repos
• Repository spec

Collection

The "collection" is a bucket of JSON records in a data repository. They support ordered list operations. Every collection is identified by an NSID which is expected to map to a Lexicon schema.

Record

A "record" is a JSON document inside a repo collection. The type of a record is identified by the $type field, which is expected to map to a Lexicon schema. The type is also expected to match the collection which contains it.

• Record key spec

Blob

Blobs are unstructured data stored inside a repo. They are most commonly used to store media such as images and video.

Label

Labels are metadata objects which are attached to repos and records. They are typically referenced by their values, such as "nudity" or "graphic-media," which identify the meaning of the label. Labels are primarily used by applications for moderation, but they can be used for other purposes.

• Labels spec

Handle

Handles are domain names which are used to identify data repos. More than one handle may be assigned to a repo. Handles may be used in at:// URIs in the domain segment.

• Handle spec
• URI Scheme spec

DID (Decentralized ID)

DIDs, or Decentralized IDentifiers, are universally-unique identifiers which represent data repos. They are permanent and non-human-readable. DIDs are a W3C specification. The AT Protocol currently supports did:web and did:plc, two different DID methods.

DIDs resolve to documents which contain metadata about a repo, including the address of the repo's PDS, the repo's handles, and the public signing keys.

• DID spec

NSID (Namespaced ID)

NSIDs, or Namespaced IDentifiers, are an identifier format used in the Atmosphere to identify Lexicon schemas. They follow a reverse DNS format such as app.bsky.feed.post. They were chosen because they give clear schema governance via the domain ownership. The reverse-DNS format was chosen to avoid confusion with domains in URIs.

• NSID spec

TID (Timestamp ID)

TIDs, or Timestamp IDentifiers, are an identifier format used for record keys. They are derived from the current time and designed to avoid collisions, maintain a lexicographic sort, and efficiently balance the data repository's internal data structures.

• Record keys spec

CID (Content ID)

CIDs, or Content Identifiers, are cryptographic hashes of records. They are used to track specific versions of records.

DAG-CBOR

DAG-CBOR is a serialization format used by atproto. It was chosen because it provides a reliable canonical form, which is important for cryptographic verification.

• Data model spec

XRPC

XRPC is a term we are deprecating, but it was historically used to describe atproto's flavor of HTTP usage. It stood for "Cross-organizational Remote Procedure Calls" and we regret inventing it, because really we're just using HTTP.

• HTTP API spec