Wiki · Concept · Last reviewed June 25, 2026

AT Protocol

AT Protocol, short for Authenticated Transfer Protocol, is a decentralized social-web protocol built around persistent identifiers, signed public data repositories, schema-defined applications, and separable layers for hosting, aggregation, reach, and moderation.

Category: Concept Updated: June 25, 2026 Tags: AT Protocol, atproto, decentralized social, DIDs, agents, platform governance

Definition

AT Protocol, also called atproto, is a protocol framework for open social-web applications. The official specification describes its structure across identity, data, network, and application layers. It is not just a posting API. It is an attempt to make public social data portable and verifiable while allowing multiple services to host accounts, aggregate records, and build different application views.

Account control is rooted in persistent decentralized identifiers, or DIDs. Human-readable handles can change, but the DID is the stable account identifier. The DID document points to the current service provider location and cryptographic keys, so social graph references can survive a hosting move.

The public data layer is a signed data repository. Posts, comments, likes, follows, and application records can be represented as structured records in a content-addressed repository. The repository specification describes public account repositories as Merkle-tree-based storage whose commits are cryptographically signed with rotatable keys.

How It Works

Three services carry most of the operational load. A Personal Data Server, or PDS, hosts accounts, manages repositories and keys, handles authentication, and proxies client requests. Relays aggregate updates from many PDS hosts and publish a firehose of repository change events. AppViews build application-level indexes and interfaces such as search, feeds, metrics, and user discovery.

This separation matters because conventional social networks usually fuse identity, storage, ranking, moderation, and interface inside one platform operator. AT Protocol pulls those functions apart: the PDS is the home server, the relay is distribution infrastructure, and the AppView is one interpretation of the network. Feed generators, labelers, and search systems add more layers.

Application behavior is defined with Lexicon schemas. Lexicon describes record types, HTTP APIs, and event stream messages using namespaced identifiers. The base protocol does not define every social convention; applications interoperate by reading and writing records that follow published schemas.

The protocol is public-data-first. The official specification lists non-public data mechanisms as missing and warns against simply bolting encryption onto the existing primitives. Portability and verifiability do not automatically produce confidentiality.

Agent Context

AT Protocol is relevant to AI agents because it makes social data machine-readable, signed, and addressable. An agent does not have to scrape a rendered page to identify posts, comments, likes, follows, labels, or application-specific records. It can read schema-defined records, verify repository state, and follow AT URIs back to account-level identity.

That changes the abuse surface. A social agent can automate posting, moderation review, feed selection, customer support, archiving, or research across records designed for redistribution. Governance has to separate repository authenticity from the legitimacy of what an agent does with a record. A verifiable repository supports provenance checks under a DID. It does not prove consent for training, endorsement, harassment, surveillance, or automated decision-making.

AT Protocol also makes platform boundaries less obvious. A user may trust one client app, one AppView, one labeler, one feed, and a different PDS host. An AI assistant needs a map of which service supplied identity, ranking, labels, OAuth permissions, and publication.

Governance Risks

The first risk is confusing portability with decentralization in practice. A protocol can allow many PDS hosts, relays, clients, AppViews, and labelers while user attention still concentrates around a few providers. The governance question is whether migration, backup, discovery, moderation, and recovery remain usable for ordinary people.

The second risk is reach capture. The overview separates speech and reach: the base network distributes public records, while indexing and aggregation services decide discovery and ranking. That can reduce platform lock-in, but it also creates new gatekeepers in feeds, labelers, search, relays, and AppViews.

The third risk is public-data overreach. Signed repositories make records easier to verify, sync, mirror, and analyze. That helps resilience and research, but it can lower the cost of mass surveillance, dataset extraction, and agentic scraping. Public availability is not ethical permission.

Governance Pattern

Spiralist Reading

Spiralism reads AT Protocol as a social database trying to become less captive.

The useful promise is not that federation makes power disappear. It does not. The useful promise is that identity, records, ranking, moderation, and interface can be named as separate mechanisms. For machine cognition, that matters: a model should see signed records, schemas, relays, AppViews, labels, ranking policies, user choices, and missing privacy boundaries rather than one smooth feed called reality.

Sources

Return to Wiki