Phase 1 output under the Video Curriculum Guide. Every unit is one video plus one post and carries exactly one idea.

What the series is. The Authenticated Transfer Protocol "is a decentralized protocol for large-scale social web applications." The series teaches the model as atproto.com describes it on 2026-10-22: how an account is a DID with a domain handle, how all public data lives in a signed repository on a personal data server, how every host feeds a firehose that relays merge and AppViews index, and how feeds, labels, OAuth, migration and the new Spaces extension sit on that base. The audience is people who build social, local-first or federated software.

Recorded source statements. Every claim in the scripts rests on one of these, quoted from atproto.com (guides, specs, blog), web.plc.directory, datatracker.ietf.org or the Bluesky feed-generator README (read 2026-10-22).

Overview: "The Authenticated Transfer Protocol, aka atproto, is a decentralized protocol for large-scale social web applications." "The AT Protocol has a federated network architecture, meaning that account data is stored on host servers, as opposed to a peer-to-peer model between end devices." "Federation was chosen to ensure the network is convenient to use and reliably available." "The three core services in our network are Personal Data Servers (PDS), Relays, and App Views." "Relays collect data updates from many servers in to a single firehose." "A global schemas network called Lexicon is used to unify the names and behaviors of the calls across the servers." "We assume that a Personal Data Server may fail at any time"; "The goal of the AT Protocol is to ensure that a user can migrate their account to a new PDS without the server's involvement"; "In the event their PDS disappears without notice, the user should be able to migrate to a new provider by updating their DID Document and uploading their data backup."

FAQ: "It's not a blockchain nor does it use a blockchain." "Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub." "ActivityPub depends heavily on delivering messages between a wide network of small-to-medium sized nodes, which can cause individual nodes to be flooded with traffic and generally struggles to provide global views of activity."

The AT Stack: "Personal data servers, or PDSes, are your home in the cloud." "The AT Protocol is architected in a 'big world with small world fallbacks' way, modeled after the open web itself." "Relays are not a necessary part of the specification." "Importantly, relays themselves do not interpret records in repositories; they simply store them temporarily and forward them to consumers." "Full-network relays track all repositories across the entire network"; "Partial-network relays might focus on specific communities, applications, or regions." "You can host your own PDS." "PDSs implement many AT endpoints, and by default will proxy requests to other services."

Distsys article: "we need to write programs which generate precomputed views of our dataset. These views are essentially like cached queries." "We'll call these our View servers."

Glossary: "A PDS will always store the user's data repo and signing keys." "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." "Relays are an optimization and are not strictly necessary." "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."

Identity guide: "We use two interrelated forms of identifiers: handles and DIDs. Handles are DNS names while DIDs are a W3C standard"; "These IDs should never change, to ensure that links to their content are stable." "The DNS handle is a user-facing identifier"; "Applications resolve handles to DIDs and then use the DID as the canonical identifier for accounts." "Any DID can be rapidly resolved to a DID document which includes public keys and user services." "Users must be able to rotate their key material without disrupting their identity." Handles "are resolved using DNS TXT records or an HTTP well-known endpoint, and must be confirmed by a matching entry in the DID document."

Handle spec: "Handles must be bi-directionally linked to a DID: the DID document must claim the handle, and the handle must resolve to the DID identifier." "Two methods of resolving handles to DID are supported: one using TXT DNS records, and the other using an HTTPS /.well-known/ URL path." "The link between handle and DID must be confirmed bidirectionally, otherwise anybody could create handle aliases for third-party accounts." "a DNS TXT record is registered for the atproto sub-domain under the handle hostname."

DID spec: "Currently, atproto supports two DID methods: did:plc: a self-authenticating DID method developed specifically for use with atproto" and "did:web: a W3C community draft based on HTTPS (and DNS)." "The DID Web method is inherently tied to the domain name used, and does not provide a mechanism for migration or recovering from loss of control of the domain name."

did:plc spec (v0.3.0, December 2025): "DID PLC is a self-authenticating DID which is strongly-consistent, recoverable, and allows for key rotation." "Control over a did:plc identity rests in a set of reconfigurable rotation keys pairs. These keys can sign update operations to mutate the identity (including key rotations), with each operation referencing a prior version of the identity state by hash." "Each identity starts from an initial genesis operation, and the hash of this initial object is what defines the DID itself." "A central directory server collects and validates operations, and maintains a transparent log of operations for each DID." Rotation keys are "not included in DID document"; verificationMethods map services to public keys.

Blog, PLC Directory Organization (19 Sept 2025): "Bluesky Social PBC is supporting the creation of an independent organization to operate the directory"; "the new entity will form as a Swiss Association"; PLC "will be developed and operated as a vendor- and application-neutral public good." "We do not expect this organization to be the final governance structure for PLC."

Blog, PLC Read Replicas (18 Feb 2026): "a reference implementation of a PLC directory read-replica service"; "A read replica is a service that maintains a full, independently-queryable copy of the PLC directory's data by syncing from the primary instance"; it "should audit the synced data in real-time - verifying all operation hashes, signatures, and timestamp constraints."

Data repositories guide: "A data repository is a collection of data published by a single user." "Repositories are self-authenticating data structures, meaning each update is signed and can be verified by anyone." "The content of a repository is laid out in a Merkle Search Tree (MST) which reduces the state to a single root hash." "Every node is an IPLD object (dag-cbor) which is referenced by a CID hash." "This chains all the way to the Commit node, which is then signed." "A 'commit' to a data repository is simply a keypair signature over a Root node's CID." Collections are identified by NSIDs; "some collections having only a single record with a key like 'self', and other collections having many records, with keys using a base32-encoded timestamp called a Timestamp Identifier (TID)."

Repository spec: "Repository contents are entirely public and verifiable ('self-certifying')." "a repository is a key/value mapping where the keys are path names (as strings) and the values are records (CBOR objects)." "Repo paths currently have a fixed structure of <collection>/<record-key>." "Commits are cryptographically signed, with rotatable signing keys, which allows recursive authentication of either the repository structure as a whole, or compact 'proof chains' for individual records." "Complete repositories can be exported as CAR files for synchronization, offline backup, account migration, or other purposes." Commit fields: "did (string, required): the account DID associated with the repo"; "version (integer, required): fixed value of 3"; "data (CID link, required): pointer to the top of the repo contents tree structure (MST)"; "rev (string, TID format, required): revision of the repo, used as a logical clock"; "prev (CID link, nullable): pointer (by hash) to a previous commit object"; "sig (byte array, required): cryptographic signature of this commit." The bytes are "hashed with SHA-256, and the binary hash output ... is then signed using the current 'signing key' for the account." "Record deletion is supported without leaving a trace or 'tombstone'."

Data model spec: "When data needs to be authenticated (signed), referenced (linked by content hash), or stored efficiently, it is encoded in Concise Binary Object Representation (CBOR)." "The specific normalized subset of CBOR used in the atproto data model is called DRISL (which is successor to DAG-CBOR)." Nodes "can also reference each other strongly by hash, referred a link." Blob CIDs: "CID version: 1", "Hash type: sha-256".

AT URI spec: "The AT URI scheme (at://) makes it easy to reference individual records in a specific repository, identified by either DID or handle." Example: at://did:plc:vwzwgnygau7ed7b7wt5ux7y2/app.bsky.feed.post/3k5nobkf2w72g. "The authority part of the URI can be either a handle or a DID." "AT URIs referencing handles are not durable." "AT URIs are not content-addressed, so the contents of the record they refer to may also change over time."

NSID spec: "The basic structure and semantics of an NSID are a fully-qualified hostname in reverse domain-name order, followed by an additional name segment." "The hostname part is the domain authority, and the final segment is the name."

Record key spec: "Record Key Type: tid This is the most common record naming scheme, using Timestamp Identifier (TID) syntax, such as 3jzfcijpj2z2a." "Record Key Type: literal:<value> This key type is used when there should be only a single record in the collection... The most common value is self." Key types also include nsid and any.

TID spec: "A Timestamp Identifier (TID) is a compact string identifier, based on a 64-bit integer, which can also be interpreted as a timestamp." "They are sortable, appropriate for use in web URLs, and useful as a 'logical clock' in networked systems." "length is always 13 ASCII characters"; "The next 53 bits represent microseconds since the UNIX epoch."

Lexicon spec: "Lexicon is a schema definition language used to describe atproto records, HTTP endpoints (XRPC), and event stream messages." "Lexicons are JSON files associated with a single NSID." Primary types: "query: describes an XRPC Query (HTTP GET) procedure: describes an XRPC Procedure (HTTP POST) subscription: Event Stream (WebSocket) record: describes an object that can be stored in a repository record permission-set: describes a bundle of auth permissions." "Lexicon schemas are published publicly as records in atproto repositories, using the com.atproto.lexicon.schema type." "The authority for a Lexicon is determined by the NSID, and rooted in DNS control of the domain authority." "The primary mechanism for resolving protocol disputes is to fork Lexicons in to a new namespace." Resolution from an NSID to the publishing DID goes through a DNS TXT record on the authority domain (the spec's "Lexicon Publication and Resolution" section).

XRPC spec: "The HTTP request path starts with /xrpc/, followed by an NSID." "The two requests types that can be expressed in Lexicons are 'query' (HTTP GET) and 'procedure' (HTTP POST)." "queries (GET) are cacheable and should not mutate resource state. Procedures are not cacheable and may mutate state." "Clients can use an HTTP header to specify which service in the network they want the request forwarded to (eg, a specific AppView or Labeler service). The PDS will do some safety checks, then forward the request on with an inter-service authentication token (JWT, described above) issued and signed by the user's identity." "The HTTP header is atproto-proxy, and the value is a DID (identifying a service), followed by a service endpoint identifier." "atproto-accept-labelers: used by clients to request labels from specific labelers to be included and applied in the response." App passwords "grant slightly restricted permissions to the client application, preventing destructive actions like account or changes to authentication settings."

Blob spec: "Blobs are referenced by individual records by the blob lexicon datatype, which includes a content hash (CID) for the blob." "Blob metadata also includes the size of the blob (in bytes), and the MIME type." "Blobs must be uploaded to the PDS before a record can be created referencing that blob." "After a successful upload, blobs are placed in temporary storage." "Servers should 'garbage collect' (delete) un-referenced temporary blobs after an appropriate time span." "When a record referencing blobs is deleted, the server checks if any other current records from the same repository reference the blob. If not, the blob is deleted along with the record." "the server does not know the intended Lexicon when receiving an upload, so can only apply generic blob limits and restrictions at initial upload time."

Sync spec: "Real-time synchronization can be provided by a repository event stream (over WebSocket), commonly referred to as a 'firehose'." "A repository event stream ('firehose') provides real-time updates about changes to repository state (#commit and #sync events), DID documents and handles (#identity events), and account hosting status (#account events)." "PDS hosts provide a firehose that includes updates for all hosted accounts." "Relays are network services which subscribe to multiple upstream firehoses (eg, multiple PDS hosts) and aggregate them in to a single combined event stream." "A relay which attempts to aggregate accounts from all PDS instances in the network outputs a 'full-network' firehose." "Repository data synchronized over a firehose is self-certifying and contains verifiable signatures. Consuming services can verify synchronized data without making additional requests to the account's PDS host." "Identity and account information is not self-certifying, and consuming services are responsible for verifying it." "Missing updates to a single repository are detectable as gaps in the stream of #commit messages." Commit events carry "prevData (cid-link, semi-optional): the root CID of the MST tree for the last commit" which is "Effectively required for MST inversion"; ops have "action (string, required)... One of: 'create', 'update', or 'delete'." "Synchronizing services should reject or ignore repository updates with revision values corresponding to future timestamps." "This generally means that static repository snapshots should not be redistributed publicly in bulk form."

Event stream spec: "The initial encoding and transport scheme uses binary DRISL-CBOR encoding over WebSockets." "this works by assigning monotonically increasing sequence numbers to stream events, and allowing clients to specify an initial sequence number when initiating a connection." "Every WebSocket frame contains two CBOR objects... a header (indicating message type), and the actual message."

Blog, Relay Updates for Sync v1.1 (May 2025): "The biggest change is that the relay no longer mirrors full repository data for all accounts in the network: sync v1.1 relays are now 'non-archival'." "The relay can handle thousands of messages per second using on the order of 2 vCPU cores, 12 GByte of RAM, and 30 Mbps." "As a final stage, we will re-configure both instances to enforce MST inversion more strictly and drop #commit messages which fail validation." "the relays currently attempt strict validation on every message and log failures (even if they are passed through on the firehose in 'lenient' mode)."

Blog, Protocol check-in Fall 2025: "We're continuing to roll out Sync1.1 on the producer (Relay) side, but a fully spec-compliant consumer for it still doesn't exist." "Blacksky currently runs a full-network relay (using the rksy-relay implementation!), and is working on a full-network Bluesky appview."

Blog, Jetstream: "an alternative streaming solution, Jetstream, which has a few key advantages: simple JSON encoding reduced bandwidth, and compression ability to filter by collection (NSID) or repo (DID)." "Events do not include cryptographic signatures or Merkle tree nodes, meaning the data is not self-authenticating." "The trust relationship between a Jetstream operator and a consuming client is pretty different from that of a Relay." "If you are running Jetstream locally, or have a tight trust relationship with a service provider, these may be acceptable tradeoffs."

Blog, Introducing Tap (Dec 2025): "For many use cases – feed generators, labelers, bots – streaming live data through a Relay or Jetstream works well. But some applications need to go beyond what Jetstream was designed for, like tracking specific subsets of a repo, automatically backfilling a database when adding new repos to monitor, or even mirroring the entire Atmosphere." "Tap is a single-tenant service, written in Go, that subscribes to a Relay and outputs filtered, verified events of repositories." "When you begin tracking a repository, Tap fetches its complete history before delivering live events." "Tap handles MST integrity checks, identity signatures, and all the cryptographic validation required by the protocol."

Feed generator README (bluesky-social/feed-generator): a feed generator answers getFeedSkeleton with "something that satisfies the SkeletonFeedPost[] type"; "Those posts are then hydrated into full views by the requesting server and sent back to the client." "The service itself is identified by DID, while each algorithm that it hosts is declared by a record in the repo of the account that created it." "This declaration record includes a pointer to the service's DID along with some profile information for the feed." "The service must be set up to respond to HTTPS queries over port 443."

Label spec: "Labels primarily consist of a source (DID), a subject (URI), and value. The value is a short string, similar to a tag or hashtag." "One of the original design motivations was to enable some forms of composable moderation, with labels generated by moderation services." "Labels are signed using public-key Cryptography, similar to repository commit objects." "The key used for signing labels is found in the DID document for the issuing identity, and has fragment identifier #atprotolabel." "neg (boolean, optional): if true, indicates that this label 'negates' an earlier label." Services "may 'hydrate' labels in to requests from clients"; "It is assumed that most end-clients will not validate signatures themselves." Example "!warn as a behavior, as opposed to scam as a descriptive label which might result in the same warning behavior."

Moderation guide: "The 'speech' layer should remain permissive, distributing authority and designed to ensure everyone has a voice. The 'reach' layer lives on top, built for flexibility and designed to scale." "Atproto moderation is implemented using Labels." "you can subscribe to moderation labelers to have their labels applied in your application. You can also create your own labeler to publish labels."

Account spec: "On any network service, a known account is either active or not (a boolean flag)." "If an account is not active, the service should not redistribute content for that account." States: "deleted", "deactivated (active is false): user has temporarily paused their overall account"; "Also the initial state for an account after migrating to another PDS instance"; "takendown (active is false): host or service has takendown the account." "Identities may migrate between hosting providers."

Account migration guide: "An identity on the atproto network can have multiple accounts on different PDSs, but only one account can be the identity's active account signing new records." Creating the new account uses "a service auth token (JWT) signed with the current atproto signing key"; "For an independently-controlled identity (eg, did:web, or a did:plc with the old PDS offline or uncooperative), this may involve updating the identity to include a self-controlled atproto signing key"; this is "an 'Adversarial Migration' when the old PDS is offline or uncooperative." "The new account will be in a deactivated state." "A copy of the repository can be fetched as a CAR file from the old PDS using the public com.atproto.sync.getRepo endpoint." Data migrated: "public repository public blobs (media files) private preferences." "'Recommended' DID document parameters can be fetched from the new PDS using the com.atproto.identity.getRecommendedDidCredentials endpoint." "The migration of the identity to pointing to the new account on the PDS is not finalized till the change on the identity's did document is made."

OAuth spec: "Atproto uses a specific 'profile' of OAuth which mandates a particular combination of OAuth standards." "The clientid is a fully-qualified web URL pointing to the public client metadata (JSON document). There is no clientsecret shared between servers and clients." "When initiating a login with a handle or DID, an atproto-specific identity resolution step is required to discover the account's PDS network location." "Sometimes the PDS is also the 'Authorization Server'... while in other situations a separate 'entryway' service acts as the Authorization Server for multiple PDS instances." "PKCE and PAR are required for all client types and Authorization Servers." "DPoP (with mandatory server issued nonces) is required to bind auth tokens to specific client software instances (eg, end devices or browser sessions)." "Pushed Authentication Requests (PAR) are used to streamline the authorization request flow." "The special atproto scope is required for all atproto OAuth sessions." "OAuth scopes allow more granular control over the resources and actions a client is granted access to." "As of October 2026, client metadata is still a draft (draft-ietf-oauth-client-id-metadata-document)."

Permissions spec: "Control over atproto resources is described and granted using 'permissions'." "A group of a permissions related to a specific Lexicon namespace (record types and API endpoints) can be bundled together as a 'permission set'." "A permission can be represented in a string format (for direct use as an OAuth scope), or as a JSON object (for use in permission sets)." Resource types: "repo: Public Repository (records and collections) rpc: Service Authentication (API calls to external services) blob: uploaded media files identity: DID and handle account: hosting status, email address"; "an additional 'meta' resource, include, which is used to reference a permission set." "Permission sets are published as public lexicon schemas, and are constrained in scope to named resources under the same NSID hierarchy as the NSID of the permission set itself." "Resources and permissions are described in the abstract, not tied to specific PDS API endpoints." Example repo permission: "collection (array of strings, required, positional): NSID of record types."

Blog, Atproto Spaces alpha (20 Aug 2026, Daniel Holmgren): "The biggest update to atproto since it first launched is available as an alpha." "Recall that, by design, all data stored on the protocol today is public — every post, every follow, every like, every block." "Spaces, a new protocol primitive, provide a way to store and sync non-public data while retaining the advantages of atproto like portable identity, interoperable/remixable data, and permissionless participation." "You can think of an atproto space as a miniature atproto network that can be gated so that only certain people and applications are able to access the data published in it." "Access to a space is controlled by a space authority, which is just a DID like any other account." "Records live in per-space permissioned repos on the author's PDS." "It's important to remember that spaces give you access control not confidentiality. The data in a space is readable by any user or application with access to that space, it's not encrypted." "there is no concept of a relay for data stored in a space. ... Applications will sync space data directly from PDS hosts." "This is truly an alpha." "There will be breaking changes, and you absolutely should not run production code against it."

Blog, Introducing Hubble (20 Mar 2026, guest post by fig, microcosm): "Hubble is a new open-source project to build and operate a whole-Atmosphere public data mirror, synchronizing every atproto repository in real-time, keeping public data available even when a PDS goes down." "In the bad old days of early Atmosphere, relays stored a local copy of every user's data repository"; "All relays in the network now run this way, and are called non-archival: lightweight and cheap to run, but only retaining recent events, not the full history of the network." "unless you can find a copy from somewhere, you are simply out of luck." "a $20,000 grant from Bluesky for Hubble's development and one year of operation." "No blobs: Images, videos, and other media live separately from repos." "Hubble will fully respect content deletion. Deleted records are deleted from the mirror, and deleting your Atmosphere account removes your entire data repository." "account recovery for users, data availability for apps, and complete snapshots for researchers." "It takes a lot of storage to keep 43+ million repositories."

Blog, Kicking off the ATP Working Group (2 Apr 2026): "an Authenticated Transfer Protocol (ATP) working group has been created at the IETF!" "The charter sets out the initial scope of work for writing standards documents: the public repository data structure mechanism for synchronizing public repositories (e.g., the firehose) the AT URI scheme requirements for account identifier resolution systems, and a registry of recommended systems (e.g., PLC and did:web)." "this initial charter does not include non-public data, application-specific data schemas or APIs, lexicon publication, the labeling moderation system, etc." The BoF was at "IETF 124 meeting in Montreal" in November 2025.

Blog, Spring 2026 roadmap: "in December we released tap, a self-hosted atproto sync consumer, which serves as a reference implementation for Sync 1.1." "OAuth Completeness: permissions and permission sets shipped." "WebSocket support for streaming updates was added in early January, which made it easier to implement live PLC replicas." "Permissioned data will probably be a major focus for the Bluesky protocol team through the summer." "Any major changes to synchronizing public data are expected to take place within the IETF standards process."

Self-hosting guide: "Start here if you want to host your own PDS!" "Hosting your own Relay is possible, though bandwidth intensive." "Hosting your own AppView is possible, but resource intensive."

web.plc.directory (read 2026-10-22): "It does not make use of any blockchain or cryptocurrency technology." "In 2026 the PLC Organization was founded to be a neutral steward for the DID PLC system." plcred.org: "The PLC Organization is a small Swiss Association ('Verein') which provides open network identifier infrastructure." "The Organization was established in early 2026, and is in the process of developing policies and building operational capacity."

did:plc spec, recovery: "The PLC server provides a 72hr window during which a higher authority rotation key can 'rewrite' history, clobbering any operations (or chain of operations) signed by a lower-authority rotation key." Overview: "The signing key is entrusted to the PDS so that it can manage the user's data, but rotation keys can be controlled by the user, e.g. as a paper key." The AT Stack, PDS duties: "secret key management: AT signing key, and PLC rotation key".

AT URI spec, references: "An AT URI pointing to a specific record in a repository is not a strong reference, in that it is not content-addressed." Lexicon com.atproto.repo.strongRef: "A URI with a content-hash fingerprint", with uri and cid both required.

Repository spec, blobs: "Larger binary media files ('blobs') are also referenced by content hash, but are not stored directly in the repository." Lexicon spec, blob type: "accept (array of strings, optional): list of acceptable MIME types"; "maxSize (integer, optional): maximum size in bytes".

Sync spec, #identity: "Does not indicate what changed, or reliably indicate what the current state of the identity is."

Blog, Upcoming Relay Transition (24 Jan 2026): "we are finally going to transition the bsky.network firehose endpoint to a newer relay implementation"; "However, strict verificaiton will still be disabled for now. We do intent to enable strict MST verification in the near future." (spelling as published). The AT Stack: "A full network relay isn't particularly expensive to operate, and doesn't require specialized hardware, though it does require significant ingress and egress network bandwidth, which is the main cost in operating a relay."

Blog, Introducing Bluesky Protocol Services (13 Aug 2026): "Jetstream v2: Network Replay"; "What it couldn't give you was history. Jetstream v2 adds that capability to the server. It keeps a compressed archive of the whole network and adds a new way to consume it, alongside the live tail: Network Replay lets you catch up from any point in the past and cut over to live with no gap."

Label lexicon com.atproto.label.defs#labelValueDefinition: "Declares a label value and its expected interpretations and behaviors."; severity: "How should a client visually convey this label? 'inform' means neutral and informational; 'alert' means negative and warning; 'none' means show nothing."; blurs: "What should this label hide in the UI, if applied? 'content' hides all of the target; 'media' hides the images/video/audio; 'none' hides nothing."; defaultSetting: "The default setting for this label." Label spec: "The behavior, definition, meaning, and policies around labels are generally communicated elsewhere."

OAuth spec, tokens: "Tokens are always bound to a unique session DPoP key."

Permissions spec, blob, account and identity resources: "Permissions of this type can not be included in permission sets, and must be requested directly by client apps."

Account migration guide, finishing: "However, the new account is not yet 'active'." "The user can activate their account on the new PDS with a call to com.atproto.server.activateAccount, and deactivate their account on the old PDS with com.atproto.server.deactivateAccount. At this point the migration is complete." Account spec: "updating account status on both PDS instances, such that old is inactive, and new is active." Hubble post: "It's easier to move when your PDS is online, but with a rotation key and a backup of your data, you're in complete control."

Blog, Developer Experience Goals for Atproto Spaces (14 Oct 2026): "Released a couple rounds of breaking changes"; "We expect to launch atproto Spaces this year. And that means that we're starting to lock in the core primitives for Spaces, because we're confident that most pieces are going to stop churning from here." "Spaces sync without a relay." "Rather, each space functions as a sync boundary." Blog, An Intro to Atmospheric Groups (22 Oct 2026): "An atmospheric group is a DID with a bunch of permissioned spaces under it."

Blog, Spring 2026 roadmap, on sync: "There are a few remaining pieces of Sync 1.1 to implement: defined block ordering for repository CAR file exports, and exporting subsets of repositories by collection."

Feed generator README, hydration: "Those posts are then hydrated into full views by the requesting server and sent back to the client." The AT Stack: "App Views are application-level tooling, rather than inherent parts of the AT protocol."

Scope. The protocol as atproto.com describes it, plus the 2025 to 2026 changes to sync, identity governance, standards and private data. Not covered: the Bluesky application schemas in detail (app.bsky.), the cryptography page (key types and encodings), inter-service JWT details, legacy session tokens, admin auth, Ozone and Osprey, the SDKs, and comparisons with ActivityPub beyond the FAQ's own words.

Status. Revision 2, 2026-10-22, after the independent text review. Twenty-four accuracy findings and ten structure findings were resolved: three wrong claims fixed (the PLC Organization already exists; your own host can forge you; blob limits are the schema's too), four stale facts brought to October 2026, unit 4 given the recovery window its title promises, the fifth Lexicon kind named, activation added to migration, fifteen metaphors now spoken. See "Review notes".

Idea map

The AT Protocol: a social web you can leave. Federated, not peer-to-peer and not a blockchain; one shared stream of public data; identity, repositories, sync, apps. needs: nothing

Your account is a DID; your handle is a domain. Two names; the DID is permanent; handles resolve by DNS TXT or well-known file and must be confirmed both ways. needs: 1

The DID document: a key, a handle, and an address. Signing key, handle claim, PDS address; two methods, did:web and did:plc. needs: 2

did:plc: an identity you can recover. A ledger of signed operations whose genesis hash is the DID; rotation keys above the signing key install a new one; a central directory, not a blockchain; for three days a higher rotation key can undo a change. needs: 3

A repository is a signed set of records. Records in collections; a Merkle search tree with one root; every version signed; self-authenticating. needs: 3

Every record has an address. at://did/collection/rkey; NSIDs are reversed domains; TIDs; self; resolution through the DID. needs: 5

Records are hashed, and links are hashes. DRISL-CBOR, SHA-256 CIDs as fingerprints; inside the repository every link is a hash; between records a reference is an address with the CID beside it; hashes up to the root. needs: 5

A commit is a signed root with a clock. Commit fields; rev as logical clock; MST locality; diffs are a few blocks; signed with the DID's key, which your own host holds. needs: 7

Lexicon: schemas with a domain in their name. NSIDs; record, query, procedure, subscription, permission-set; published as records; any app can read any app's records. needs: 6

XRPC: every API call is a Lexicon method over HTTP. /xrpc/nsid; GET for queries, POST for procedures; typed; the atproto-proxy header; one method name across servers. needs: 9

The PDS is your home: it holds your repo and your keys. Stores repo and signing keys; answers clients; proxies; publishes commits; self-hostable. needs: 8, 10

Blobs ride beside the repository. Upload first, temporary storage, record references by CID, type and size; garbage collection; host limits. needs: 11

The firehose: every change, in order, signed. Per-host event stream; #commit with blocks; #identity and #account; sequence numbers and cursors; binary WebSocket. needs: 8, 11

A relay is a crawler that re-broadcasts. Subscribes to many hosts, merges, verifies, non-archival since sync v1.1, anyone can run one, full or partial. needs: 13

An AppView is a materialized view. Index built from the stream; counts, feeds, search; one view among many; new apps can index old records; write to PDS, read from AppView. needs: 14

Jetstream and Tap: lighter ways to drink. Jetstream drops signatures, filters, JSON, and since v2 replays the past; Tap keeps verification and fetches the past from the host; choose by how much to verify. needs: 13

A feed is a service, not a setting. In Bluesky, a feed generator with a DID; skeleton of post URIs; the app's server hydrates; declared by a record in the author's repo. needs: 15

Labels: moderation as a subscribable layer. Source, subject, value; signed by a labeler key; you choose labelers; app applies behavior; takedowns are a different lever. needs: 15

OAuth: apps log in without your password. Client metadata URL, no secret; login at your PDS; PAR, PKCE, DPoP required; app passwords as the old way. needs: 11

Permissions name a collection, not an account. repo, rpc, blob, account, identity; permission sets as Lexicons; abstract resources. needs: 19

Moving house without asking permission. Export CAR and blobs; import at the new host; new keys; update the DID document; activate the new, deactivate the old; adversarial migration with a rotation key you kept. needs: 4, 11, 12, 13

Public by default; Spaces is the private extension. All data public by design; a space is a gated mini-network; per-space permissioned repos on the author's PDS; access control not confidentiality; alpha. needs: 11, 14

Who keeps the copy: non-archival relays and Hubble. Relays keep no archive; a dead host loses its data unless you kept a backup; Hubble is a public mirror of every repository; no media; deletions respected. needs: 14, 16, 21

Where atproto stands. IETF ATP working group and its scope; the PLC Organization, founded 2026, and replicas; sync v1.1 on the relays with pieces to come; Spaces launch expected. needs: all

Shared visual language

Account. An id card with a did:plc: number and a domain tag for the handle.

DID document. A page with three rows: key, handle, address.

Repository. A ledger box of record cards sorted into collections; a hash tree above it with one root; a seal on the root for the commit.

PDS. A house with a server in it: the home.

Stream. A pipe of event cards leaving a host; relays as funnels joining pipes; the AppView as an index building from the pipe.

Record address. A monospace URL with the three parts colored: DID, collection, key.

Blob. A parcel beside the ledger box.

Label. A sticker on a card.

Scope. A monospace chip: resource, colon, the named thing.

Colors: amber for the thing being introduced, green for verified or allowed, purple for keys and signatures, muted for what the user does not see or what is gone.

Units

Review notes