AT Protocol is a framework for building social applications on shared, account-owned data. It provides portable identity, public data repositories, a schema language, repository synchronization, and APIs that applications can use to assemble their own views of the network.
This page is the ATProto subject map for this wiki. It defines the vocabulary used by the linked pages and distinguishes current protocol specifications from draft proposals and application-level design patterns.
Core vocabulary
Account and DID
An ATProto account is identified by a DID, or decentralized identifier. A user-facing handle can change, and the account can move between Personal Data Servers, but the DID remains the stable account identity.
Repository and record
Each account has a repository containing its public ATProto data. A record is a schema-defined data object stored at a path inside that repository. Posts, profiles, likes, bookmarks, annotations, and application-specific objects can all be represented as records.
In this section of the wiki, the word record means an ATProto record unless a page explicitly says otherwise.
AT URI and CID
An AT URI is the stable address of an ATProto record. A CID, or content identifier, is a fingerprint of one exact encoded version of that record. Updating a record can preserve its AT URI while changing its CID.
ATProto Records and Provenance explains these identifiers, signed repository state, and the standard URI-plus-CID strong reference.
Lexicon
A Lexicon is ATProto's schema format. It describes record types, API methods, and event-stream messages. Lexicons make data interpretable across services, but schema validity does not establish whether a claim is true or whether an application should accept it.
AppView
An AppView is an application service that indexes ATProto data and turns records into a product view, such as a feed, profile, thread, or forum. Repository ownership and AppView presentation are separate: a user can own a record while an AppView decides whether and how it appears.
Public records and permissioned data
ATProto's deployed public-broadcast model uses public, signed, redistributable repositories. Applications can crawl those repositories and build their own indexes and interfaces.
Proposal 0016 Permissioned Data explores an additional protocol for records with an access perimeter. It introduces spaces, permissioned repositories, space credentials, and direct synchronization between authorized services. The proposal is explicitly a draft, and its terminology and behavior may change.
Permissioned data provides access control, not end-to-end confidentiality. Authorized services and repository hosts can read the data they handle.
Forum design notes
Nick Gerakines's article “Permissioned Data Shapes: Forums” explores how a forum might be built on the draft permissioned-data model. Two pages in this wiki examine patterns from that design:
- Admission Wrappers in ATProto explains the proposed split between a member-owned content record and a forum-owned record that admits it into a category.
- Approving Mutable ATProto Records examines what should happen when the member edits the content after the forum admitted a specific version.
These are application-design notes, not descriptions of deployed ATProto behavior.
Status labels used in this section
This wiki uses three levels of authority when discussing ATProto:
- Protocol specification: behavior documented in the current ATProto specifications.
- Draft proposal: behavior proposed for future ATProto work, such as permissioned data.
- Application design: a record pattern or policy built on the protocol or proposal, such as Gerakines's forum wrappers.
Keeping those levels separate prevents an experimental application shape from being mistaken for protocol vocabulary.