# Record
**Author:** @cameron.stream (`did:plc:gfrmhdmjvxn2sjedzboeudef`)

## `knowledge-atproto`
**Collection:** `site.standard.document`
**AT URI:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.document/knowledge-atproto`

**Title:** AT Protocol
**Published:** Mon, 20 Jul 2026 22:19:48 GMT
**Updated:** Mon, 20 Jul 2026 21:20:00 GMT
**Description:** A map of this wiki's notes on ATProto identity, repositories, records, strong references, permissioned data, and application-level authority.
**Publication:** `at://did:plc:gfrmhdmjvxn2sjedzboeudef/site.standard.publication/3mr4py6clps2f`
**Path:** /atproto
**Tags:** knowledge, concept, atproto, protocols, identity, repositories, permissioned-data

**Content:**
```json
{
  "text": "[AT Protocol](https://atproto.com/) 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.\n\nThis 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.\n\n## Core vocabulary\n\n### Account and DID\n\nAn 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.\n\n### Repository and record\n\nEach 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.\n\nIn this section of the wiki, the word **record** means an ATProto record unless a page explicitly says otherwise.\n\n### AT URI and CID\n\nAn **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.\n\n[ATProto Records and Provenance](https://cameron.stream/knowledge/atproto-records-and-provenance) explains these identifiers, signed repository state, and the standard URI-plus-CID strong reference.\n\n### Lexicon\n\nA **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.\n\n### AppView\n\nAn **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.\n\n## Public records and permissioned data\n\nATProto's deployed public-broadcast model uses public, signed, redistributable repositories. Applications can crawl those repositories and build their own indexes and interfaces.\n\nProposal [0016 Permissioned Data](https://github.com/bluesky-social/proposals/blob/main/0016-permissioned-data/README.md) 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.\n\nPermissioned data provides access control, not end-to-end confidentiality. Authorized services and repository hosts can read the data they handle.\n\n## Forum design notes\n\nNick Gerakines's article [“Permissioned Data Shapes: Forums”](https://ngerakines.leaflet.pub/3mr3uqjjaxs2d) explores how a forum might be built on the draft permissioned-data model. Two pages in this wiki examine patterns from that design:\n\n- [Admission Wrappers in ATProto](https://cameron.stream/knowledge/atproto-admission-wrappers) explains the proposed split between a member-owned content record and a forum-owned record that admits it into a category.\n- [Approving Mutable ATProto Records](https://cameron.stream/knowledge/atproto-approving-mutable-records) examines what should happen when the member edits the content after the forum admitted a specific version.\n\nThese are application-design notes, not descriptions of deployed ATProto behavior.\n\n## Status labels used in this section\n\nThis wiki uses three levels of authority when discussing ATProto:\n\n1. **Protocol specification**: behavior documented in the current ATProto specifications.\n2. **Draft proposal**: behavior proposed for future ATProto work, such as permissioned data.\n3. **Application design**: a record pattern or policy built on the protocol or proposal, such as Gerakines's forum wrappers.\n\nKeeping those levels separate prevents an experimental application shape from being mistaken for protocol vocabulary.\n\n## Sources\n\n- [AT Protocol specification](https://atproto.com/specs/atp)\n- [AT Protocol repository specification](https://atproto.com/specs/repository)\n- [AT Protocol Lexicon specification](https://atproto.com/specs/lexicon)\n- [ATProto Permissioned Data proposal](https://github.com/bluesky-social/proposals/blob/main/0016-permissioned-data/README.md)\n- [Permissioned Data Shapes: Forums](https://ngerakines.leaflet.pub/3mr3uqjjaxs2d)",
  "$type": "site.standard.content.markdown",
  "version": "1.0"
}
```

---
*Fetched from https://enoki.us-east.host.bsky.network via `com.atproto.repo.getRecord`*