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 more information.
Atmosphere
The "Atmosphere" is the term we use to describe the ecosystem around theAT Protocol.
AT Protocol
The AT Protocol stands for "Authenticated Transfer Protocol," and is frequently shortened to "atproto." The 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'sdata repo and signing keys. It may also assign the user ahandle and aDID. Many PDSes will host multiple users.
A PDS communicates withAppViews 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 theirdata repos withRelays.
AppView
An AppView is an application in theAtmosphere. It's called an "AppView" because it's just one view of the network. The canonical data lives indata repos which is hosted byPDSes, 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 theirrepos, forming the full application model. This communication is established as a part of the OAuth login flow.
Relay
A Relay is an aggregator ofdata repos from across theAtmosphere. They sync the repos fromPDSes and produce a firehose of change events.AppViews use a Relay to fetch user data.
Relays are an optimization and are not strictly necessary. AnAppView could communicate directly withPDSes (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 theAtmosphere to describedata records and HTTP APIs. Functionally it's very similar toJSON-Schema andOpenAPI.
Lexicon's sole purpose is to help developers build compatible software.
Data Repo
The "data repository" or "repo" is the public dataset which represents a user. It is comprised ofcollections of JSONrecords and unstructuredblobs. Every repo is assigned a single permanentDID which identifies it. Repos may also have any number ofdomain 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'sdid.
Collection
The "collection" is a bucket of JSONrecords in adata repository. They support ordered list operations. Every collection is identified by anNSID which is expected to map to aLexicon schema.
Record
A "record" is a JSON document inside arepocollection. The type of a record is identified by the$type field, which is expected to map to aLexicon schema. The type is also expected to match thecollection which contains it.
Blob
Blobs are unstructured data stored inside arepo. They are most commonly used to store media such as images and video.
Label
Labels are metadata objects which are attached to accounts (DIDs) andrecords. 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.
Handle
Handles are domain names which are used to identifydata repos. More than one handle may be assigned to a repo. Handles may be used inat:// URIs in the domain segment.
DID (Decentralized ID)
DIDs, or Decentralized IDentifiers, are universally-unique identifiers which representdata repos. They are permanent and non-human-readable. DIDs are aW3C specification. The AT Protocol currently supportsdid:web anddid:plc, two different DID methods.
DIDs resolve to documents which contain metadata about arepo, including the address of the repo'sPDS, the repo'shandles, and the public signing keys.
NSID (Namespaced ID)
NSIDs, or Namespaced IDentifiers, are an identifier format used in theAtmosphere to identifyLexicon schemas. They follow a reverse DNS format such asapp.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.
TID (Timestamp ID)
TIDs, or Timestamp IDentifiers, are an identifier format used forrecord keys. They are derived from the current time and designed to avoid collisions, maintain a lexicographic sort, and efficiently balance thedata repository's internal data structures.
CID (Content ID)
CIDs, or Content Identifiers, are cryptographic hashes ofrecords. They are used to track specific versions of records.
DAG-CBOR
DAG-CBOR is a serialization format used byatproto. It was chosen because it provides a reliable canonical form, which is important for cryptographic verification.
XRPC
XRPC is a term we are deprecating, but it was historically used to describeatproto'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.