Glossary
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 people use to describe the open social internet ecosystem around the AT Protocol. Other people can make their own apps in the Atmosphere, including their own versions of Bluesky.
AT Protocol
The AT Protocol, short for Authenticated Transfer Protocol, and can be further shortened to 'atproto', is a protocol that ensures data is securely signed by its creators. This 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 is a server that hosts user data and manages their identity. It stores the user's data repository and signing keys, and may also assign a handle and DID. Multiple users can be hosted on a single PDS.
A PDS can also communicate with AppViews to run applications, but doesn't typically run applications past authentication itself.
AppView
An AppView is an application that provides a unique perspective on the data stored in the Atmosphere. It's similar to a search engine that aggregates data from various sources to create a user-friendly interface.
AppView is named after the term 'materialized view' from relational database theory, which is a precomputed view of a database that is stored in a separate table. AppViews, therefore, are a sort of 'materialized view' for the data stored in the Atmosphere.
Relay
A Relay is a service that aggregates data from multiple PDSes and provides a stream of updates, similar to a funnel. AppViews use Relays to fetch user data, making it easier to build applications.
Technically, Relays are not strictly necessary, and AppViews can communicate directly with the PDS if needed. Relays are more of an optimization tool, allowing AppViews to listen to data from multiple PDSes in parallel and increase efficiency.
Lexicon
Lexicon is a schema language used to describe data records and HTTP APIs. It's similar to JSON-Schema and OpenAPI, and helps developers build compatible software.
Basically, if you build a lexicon for your app, you're saying 'I want the data shape to look like this for this item'.
Data Repo
A data repository, or repo, is a collection of data that represents a user. It's made up of JSON records and unstructured data, and is identified by a unique DID. It can also be associated with 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.
Collection
A collection is a group of JSON records within a data repository. It's similar to a object storage bucket in that stores related data, and supports ordered list operations.
Record
A record is a single JSON document within a collection, identified by a record key. The type of a record is expected to be identified by a unique $type
field, which is mapped to a Lexicon schema.
Blob
Blobs are unstructured data stored within a repo, such as images or videos.
Label
Labels are metadata objects attached to accounts or records. They're used for moderation and other purposes.
Handle
A handle is a domain name that identifies a data repository. It's like a username, but in the form of a domain name. They're verified via either DNS or a special .well-known
page.
DID (Decentralized ID)
A Decentralized Identifier (DID) is a universally unique, permanent identifier assigned to a data repository. It is used to resolve metadata about the repository, such as its PDS, handles, and public signing keys. The AT Protocol currently supports two DID methods: did:web
and did:plc
.
NSID (Namespaced ID)
NSIDs are used to identify Lexicon schemas in a unique and organized manner. They follow a reverse DNS format (e.g., app.bsky.feed.post
) to give clear schema governance and avoid conflicts with domain names in URIs.
TID (Timestamp ID)
TIDs are mainly used as record keys and are derived from the current timestamp. They are designed to be unique, sortable, and efficient for data repository management.
CID (Content ID)
CIDs are cryptographic hashes of records, and are used to track specific versions of data.
DAG-CBOR
DAG-CBOR is a way of encoding data that's used by the AT Protocol. It encodes data in a deterministic way, meaning that any given data structure will always be encoded in the same way. This consistency is crucial for verifying data integrity and authenticity.
Imagine you're sending a package to a friend. You need to wrap the contents carefully to ensure they arrive safely. DAG-CBOR is like a specialized wrapping technique that ensures the data inside is protected and easy to understand.
XRPC
The term "XRPC" is used to describe atproto's flavor of HTTP usage, standing for "Cross-organizational Remote Procedure Calls". Bluesky is looking at deprecating this term as it's now recognized that this term was unnecessary because atproto simply utilizes standard HTTP.
This document is heavily based on https://atproto.com/guides/glossary.