AT Protocol: Decentralized Social Networking

Updated 26 January 2026

AT Protocol is a decentralized, schema-driven architecture for social media that enables composable, federated networking and true data portability.
It employs cryptographic hash chains and verifiable records stored on personal data servers to ensure content integrity and portable, secure identity.
Its modular design integrates independent PDS, relays, and client applications to balance decentralized control with centralized indexing for a familiar user experience.

The AT Protocol (Authenticated Transfer Protocol) is a decentralized, schema-driven architecture for feed-based social media, underpinning platforms such as Bluesky Social and open scientific networks like the Astrosky Ecosystem. It is specifically engineered to distribute power over identity, content, and moderation away from monolithic corporate providers while preserving data portability and a familiar user experience. Core to its design is the explicit mapping of protocol components and interaction primitives, positioning it as a hybrid model—between full decentralization and the practical affordances of centralized infrastructure—capable of composable, federated social networking at scale (Oshinowo et al., 29 May 2025, Kleppmann et al., 2024, Hunt et al., 23 Jan 2026).

1. Core Components and Data Model

The AT Protocol operationalizes social networking through a minimal set of cooperating services and verifiable data structures:

Personal Data Server (PDS): Each user is associated with a PDS storing their append-only activity ledger—every post, follow, like, profile edit is a record in this ledger. PDSes serve as back-end storage, exposing HTTP and WebSocket APIs.
Relay: Relays are Aggregator nodes that ingest and redistribute updates from all known PDSes into a unified, ordered event log. They synchronize the global Space and ensure content propagation.
Feed Generators and Moderation Services: These consume the relay stream, apply policy or algorithmic transformations, and emit subset “feeds.” Services may implement ranking, filtering, or specialized timelines.
Client Applications: Apps (e.g., Bluesky, Graysky) implement the client-to-PDS API, mediating all local user interaction, content curation, and optionally custom moderation plugins.

The AT Protocol employs JSON-like, lexicon-driven schemas for actors, posts, follows, and moderation records. For example, a post record takes the form:

{
  "$id": "app.bsky.feed.post",
  "type": "object",
  "properties": {
    "text": { "type": "string" },
    "createdAt": { "type": "string", "format": "date-time" },
    "replyTo": { "type": "string" }
  },
  "required": ["text", "createdAt"]
}

Every record is content-addressed via a cryptographic multihash (CID) and lives in a user's Merkle Search Tree (MST), supporting tamper-evidence and efficient data replication (Hunt et al., 23 Jan 2026, Kleppmann et al., 2024).

2. Cryptographic Guarantees and Identity Portability

Integrity and authenticity are enforced by chaining records cryptographically:

Let $r_1, r_2, \dots, r_n$ denote serialized records. The hash chain state evolves as

$s_i = H(s_{i-1} \parallel r_i)$

Each record $r_i$ is signed using the user’s Ed25519 keypair:

$\sigma_i = \mathrm{Sign_{ed25519}}(\mathit{sk}, H(r_i \parallel s_{i-1}))$

A content identifier is derived as

$\mathrm{cid}_i = \mathrm{MH}(\text{"sha2-256"}, r_i)$

where $MH$ is the multihash construction. Control over DIDs (Decentralized Identifiers) aligns with the W3C DID specification, ensuring provable, portable identity. When migrating accounts (credible exit), all history, social graph edges, and the associated identity keypair can be exported/imported between PDSes without data loss (Kleppmann et al., 2024, Hunt et al., 23 Jan 2026).

3. Federated and Decentralized Architecture

The architectural model is characterized by a single global Space, eschewing the multi-instance model of ActivityPub. All PDSes participate in this network-wide Space. The relay-aggregator layer synchronizes content by creating an append-only event log and rebroadcasting events. Feed generators, moderation services, and clients subscribe to this event firehose to construct feeds, apply opinionated policies, and maintain real-time consistency.

Components may be independently deployed:

Component	Typical Operator	Function
PDS	User or third-party	Identity, storage
Relay	Corporation or anyone	Global event aggregation
Feed Generator	Independent developer	Timeline, ranking, topic feeds
Client	Anyone	UX, curation, moderation

This explicit separation allows arbitrary mixing of providers. Any third party can instantiate a PDS, relay, or feed generator, and clients can federate queries or actions across providers (Oshinowo et al., 29 May 2025, Kleppmann et al., 2024, Hunt et al., 23 Jan 2026).

4. Moderation, Labeling, and Feed Curation

The protocol externalizes moderation and curation, encapsulating opinionated decisions as signed records:

Labelers: Specialized services produce label records (e.g., marking spam, NSFW, or abusive content) affecting either post CIDs or user DIDs.
Feed Generators: Determine feed inclusion criteria, potentially implementing “community rules,” custom ranking, or domain-specific filters.
Personal Curators: Mute, block, and reply-gating lists are stored as ordinary records. Their public availability allows any feed generator or client to enforce user preferences.

There is no hardcoded consensus or moderation logic in the core protocol—Community rules and byzantine voting mechanisms are built as higher-order applications subscribing to streams of relevant events (Kleppmann et al., 2024, Oshinowo et al., 29 May 2025).

5. Socio-Technical Power Distribution and Political Trade-offs

Analysis by Oshinowo, Hwang, Zhang, and Monroy-Hernández introduces a two-tiered conceptual framework— $\mathcal{C}_{arch}$ (architectural components) and $\mathcal{C}_{int}$ (interaction primitives)—to clarify how protocols can encode social and political balances of power.

In the AT Protocol:

PDS Operators control user storage and local policy enforcement, with practical autonomy for self-hosted instances.
Relay Operators aggregate and rebroadcast the global feed, conferring significant influence. Today, major relays are largely operated by Bluesky PBC, indicating a pragmatic re-centralization of indexing.
App Developers and End Users control client-side UX (algorithms, plugins, curation), with end users able to override blocklists or migrate to new PDSes to escape local policies.

This configuration introduces graduated decentralization: protocol guarantees on identity and data-ownership, with selective re-centralization at the relay/indexing tier for UX and network effect purposes (Oshinowo et al., 29 May 2025). Trade-offs include:

Accessibility vs. Autonomy: Password-based identity is friendlier but places key custody with the server.
Consistency vs. Pluralism: Unified relay logs combat fragmentation but enable oligopoly risk at the relay layer.
Innovation vs. Oligopoly: Interoperability of Apps and custom feeds fosters innovation, but client-layer lock-in by network effects persists.

6. Practical Implementations and Ecosystem Extensions

The protocol's viability is evidenced by operational systems:

Bluesky Social: The canonical app, growing to 10 million users by October 2024, demonstrates mainstream scalability (Kleppmann et al., 2024).
Astrosky Ecosystem: Uses AT Protocol now for science communication by running open-source feed generators and PDS hosting for astronomers. The entire toolchain is available in Python and exposed as XRPC APIs (Hunt et al., 23 Jan 2026).

Practical request/response flows use simple REST endpoints for reading feeds, posting records, and following accounts. Example:

POST /xrpc/com.atproto.repo.createRecord
Host: user.pds.example.com
Authorization: Bearer <token>
{
  "collection": "app.bsky.graph.follow",
  "repo": "did:plc:alice123",
  "record": {
    "$type": "app.bsky.graph.follow",
    "subject": "did:plc:bob456",
    "createdAt": "2024-05-01T12:50:00Z"
  }
}

Astrosky’s Python SDK shows direct posting and reading of domain-specific timelines, with filter compositions driven by custom feed generators (Hunt et al., 23 Jan 2026).

7. Comparative Analysis and Future Directions

A comparison of AT Protocol to ActivityPub, Nostr, and Farcaster highlights its distinguishing single-global-append-only-ledger mediated by relays, portable but server-stored identity, and composable client-layer modularity (Oshinowo et al., 29 May 2025):

Protocol	Identity	Aggregation	Federation Model	Moderation Power
AT Protocol	Server-held, exportable	Relay (Aggregator)	Single global Space	PDS, Relays, Apps, Users
ActivityPub	Instance-held	None	Peer-to-peer instances	Instance, User
Nostr	User-held private keys	None (multi-relay)	Clients to relays	Clients, Relays
Farcaster	Ethereum wallet	None (gossip-all)	Full replication	Clients

Prospective work includes direct integration with ORCID-linked DIDs, transient alert feeds, semantic enrichment for research, and protocol bridges to ActivityPub or Matrix, extending reach and utility for scientific, academic, and public-interest communities (Hunt et al., 23 Jan 2026). This suggests AT Protocol’s schema-driven, cryptographically-secured, and federated architecture is already supporting resilient, domain-specific networks beyond general-purpose microblogging.

References

"Seeing the Politics of Decentralized Social Media Protocols" (Oshinowo et al., 29 May 2025)
"Bluesky and the AT Protocol: Usable Decentralized Social Media" (Kleppmann et al., 2024)
"The Astrosky Ecosystem: An independent online platform for science communication and social networking" (Hunt et al., 23 Jan 2026)