Your engineering team is probably already discussing Bluesky. Whether you’re fielding migration questions or evaluating competitive positioning, you need more than marketing claims about “decentralisation.”
The decentralisation landscape is full of architectures that promise distribution but deliver new forms of centralisation. Bluesky’s AT Protocol claims to solve the portability and interoperability problems that plague federation protocols like ActivityPub. The pitch sounds good: cryptographically-owned accounts that migrate between providers, standardised schemas preventing vendor lock-in, and scalable infrastructure supporting global social networking.
This article examines AT Protocol’s architecture as concrete technical systems with measurable costs, operational requirements, and trade-offs. We’re not here to sell you on adoption. We’re providing evidence-based analysis so you can make your own strategic evaluation of decentralised platforms.
What is the AT Protocol and how does it work?
AT Protocol (Authenticated Transfer Protocol) is a federated protocol for decentralised social applications. It works differently from document-passing federation models like ActivityPub. Rather than exchanging JSON-LD documents between servers, AT Protocol exchanges schematic data using standardised Lexicons. This lets different implementations work together through shared vocabulary.
The architecture achieves scalability through relay infrastructure that aggregates updates from thousands of Personal Data Servers into a network-wide firehose. Cryptographic identity (DIDs) separates account ownership from hosting provider control.
The protocol’s core philosophy centres on semantic data exchange rather than document exchange. When ActivityPub servers communicate, they pass complete documents—posts, likes, follows—encoded as JSON-LD with flexible schemas. When AT Protocol servers communicate, they exchange structured records conforming to predefined Lexicons that specify exact data shapes and behaviours.
Here’s what that means in practice. When you post on AT Protocol, your PDS sends structured records like app.bsky.feed.post with defined fields—text, timestamp, media references. ActivityPub servers exchange entire JSON-LD documents that each server interprets according to its own implementation. This difference affects everything from how servers validate data to how applications handle schema evolution.
AT Protocol implements a three-layer stack:
- Data Hosting (Personal Data Server): Individual PDS instances host user data and identity, broadcasting updates to the network
- Aggregation (Relay): Relay services collect data from all known PDS instances into comprehensive firehose streams
- Application (App View): Application services consume firehose data to provide features like search, metrics, and discovery
This layered architecture accepts relay centralisation—currently only Bluesky runs a full-network relay—in exchange for scalability and comprehensive network features.
Unlike pure peer-to-peer models where data lives only on user devices, AT Protocol’s account-based federation stores data on servers. Unlike fully centralised platforms where one company controls everything, AT Protocol distributes data across independent PDS providers. The result sits between decentralisation extremes. More convenient than peer-to-peer, more distributed than traditional platforms, but with architectural centralisation points worth examining.
The federation model relies on signed repositories. Think Git-like data structures containing user posts, follows, likes, and other records. Each repository is cryptographically signed, letting you verify it independent of the hosting provider.
When you post content, your PDS adds a signed record to your repository and broadcasts the update over HTTP or WebSockets. Relays subscribing to that PDS receive the update and add it to their aggregated firehose—a continuous stream of every public action across the network. App Views consuming the firehose process the update and make it available through their APIs. Client applications query App Views to display content to users.
Decentralised Identifiers (DIDs) provide the cryptographic foundation enabling this architecture. Each account has a permanent DID containing references to their current PDS and cryptographic keys for signing data and rotating identity. Because identity is cryptographic rather than namespace-based, you can theoretically migrate between PDS providers without losing your account. That’s a fundamental difference from traditional platforms where your identity is tied to the provider’s namespace.
The protocol defines two categories of Lexicons. Core com.atproto.* schemas define repository syncing, authentication, and identity management. Application schemas like app.bsky.* define social features such as posts, follows, and likes. Third parties can develop new Lexicons for custom features while maintaining interoperability with the broader ecosystem—at least in theory. In practice, Lexicon governance and adoption beyond Bluesky’s own schemas remains limited.
This architecture reflects deliberate trade-offs. AT Protocol optimises for global features requiring comprehensive network data—follower counts, trending topics, full-text search—at the cost of requiring relay infrastructure. ActivityPub optimises for decentralisation at the cost of making such global features difficult to implement. Neither approach is objectively superior. They represent different positions on the centralisation-decentralisation spectrum with different operational consequences.
| Feature | AT Protocol | ActivityPub | |———|————-|————-| | Data Exchange | Schematic (Lexicons) | Document-based (JSON-LD) | | Federation Model | Relay aggregation | Server-to-server messaging | | Account Portability | Cryptographic (DIDs) | Domain-based | | Global Features | Enabled (via relay) | Difficult to implement | | Centralisation Risk | Relay monopoly | Highly distributed |
How do Personal Data Servers enable account portability?
Personal Data Servers host your account data and identity but don’t own the account itself. Ownership resides in cryptographic keys you control. Decentralised Identifiers (DIDs) containing signing keys and rotation keys establish this cryptographic ownership. This lets you migrate between PDS providers by updating your DID document and uploading a signed data backup.
Migration theoretically works without original provider involvement if you control your rotation key. That separates account identity from hosting infrastructure.
The technical mechanism relies on a dual-key structure. Every DID document publishes a signing key that validates your data repository—all posts, follows, likes, and other records are cryptographically signed using this key. The PDS manages the signing key on your behalf to handle day-to-day operations.
But DIDs also include rotation keys that assert changes to the DID document itself. These rotation keys can be user-controlled—stored as a paper key, hardware key, or user device—rather than PDS-managed. This creates a trust hierarchy where the rotation key serves as a master key controlling account ownership.
Account migration follows this process:
- You back up your signed data repository—a Git-like structure containing all your posts and interactions
- You generate a new DID document pointing to your new PDS provider
- You sign the updated DID document using your rotation key
- You upload your repository backup to the new PDS
- The new PDS broadcasts updates to the relay network
- Your account appears at the new location with complete history intact
This migration typically completes within minutes once initiated, though new PDS indexing by relays may take longer for full network visibility.
The dependency here is rotation key control. If you control your rotation keys, you can execute this migration without permission from your original PDS provider—even if that provider has disappeared or become hostile. If PDS providers control rotation keys—as most currently do because key custody is operationally complex for average users—migration requires provider cooperation and the portability claim weakens substantially.
This represents a significant improvement over traditional platforms where account identity is namespace-based. On Twitter, you’re @username—an identity owned by Twitter. If Twitter bans you or disappears, that identity vanishes. On AT Protocol, you’re a DID like did:plc:24characterstring—an identity you own cryptographically. The PDS provider can’t revoke it, censor it, or prevent migration as long as you control the rotation key.
Domain-based verification provides human-readable handles mapped to DIDs. You configure a domain name—like @username.bsky.social or @company.com—that points to your DID through DNS records or HTTPS verification. This creates memorable usernames while maintaining cryptographic identity underneath. If you migrate PDS providers, you keep your domain handle by updating the verification to point to your new PDS location.
The signed data repository model ensures data integrity across migration. Because every record in your repository is cryptographically signed and timestamped, the new PDS can verify that the data is authentic and complete. There’s no opportunity for the old PDS to modify history or for the new PDS to fabricate records. The cryptographic signature chain provides tamper-proof verification.
However, practical portability depends on infrastructure realities beyond cryptographic capabilities. You need somewhere to migrate to—independent PDS providers willing to host accounts. You need technical capability to execute migration, including managing rotation keys and repository backups. You need confidence that the broader ecosystem will recognise your new location and that App Views will index your content at the new provider.
Current statistics reveal ecosystem concentration. Approximately 11.7 million accounts use Bluesky-hosted PDS instances compared to roughly 59,000 on independent servers across 2,200 data stores. This 99.5% concentration on Bluesky-hosted infrastructure shows that while portability is architecturally possible, ecosystem incentives haven’t yet driven broad adoption of independent hosting.
For organisations considering implementing PDS infrastructure, the key question isn’t whether portability works technically—the cryptographic design is sound—but whether rotation key management aligns with your operational requirements and whether the independent PDS ecosystem is mature enough to provide practical alternatives to Bluesky’s hosting.
What are relays in the AT Protocol and what role do they play?
Relays are network indexers that aggregate data updates from all known Personal Data Servers into a single comprehensive stream called the firehose. It’s available in binary format or JSON (Jetstream) for developer accessibility.
This aggregation lets App Views access complete network data without querying thousands of individual PDS instances. That solves the scalability problem inherent in fully distributed architectures. However, relays create a significant centralisation concern. Currently only Bluesky operates a full-network relay, establishing a de facto monopoly over this infrastructure layer.
The technical function is straightforward. PDS instances broadcast repository updates over HTTP and WebSockets whenever users create posts, likes, follows, or other records. Relays subscribe to these update streams from all known PDS instances across the network, aggregate them into a unified chronological stream, and republish this firehose for consumption by App Views and other services. The firehose provides comprehensive network visibility—every public action by every user flows through this stream. This technical foundation enables AT Protocol’s architecture to influence engagement quality by supporting custom algorithms and discovery mechanisms.
Two firehose formats serve different use cases. The binary format optimises for efficiency for high-throughput applications processing millions of events. Jetstream provides JSON representation optimised for developer accessibility, reducing bandwidth requirements and parsing complexity compared to the full binary stream. Developers building custom feeds, moderation tools, or analytics services can choose the format matching their performance and convenience requirements.
Infrastructure requirements for operating a full-network relay are substantial. Bryan Newbold’s detailed notes from running an independent relay demonstrate the resource demands. The deployment required a bare metal server with 12 vCPU processors, 32GB RAM, and 2×1.92TB NVMe drives. Monthly costs run around $150-$153 for infrastructure alone—excluding development, monitoring, and operational overhead. Relay operation is accessible to well-funded organisations but not casual hobbyists.
During initial backfill operations, the relay demonstrated high disk write rates—600-1800MB/sec—and PostgreSQL growth of approximately 14MB per second. After completing backfill, steady-state operations were more modest. CPU utilisation stayed under 2% and network traffic under 250KB/sec. Final PostgreSQL storage reached approximately 447GB, with production Bluesky relays using approximately 1TB for PostgreSQL and 1TB for CAR (Content Addressable aRchive) storage.
These infrastructure requirements, while not astronomical by enterprise standards, create barriers to relay operation. The initial capital investment, ongoing hosting costs, storage growth, and operational complexity discourage casual deployment. More problematic, relays have no clear revenue model. They provide infrastructure but generate no direct income. That creates an economic sustainability question that affects decentralisation viability.
The “speech vs reach” architectural philosophy justifies relay centralisation within AT Protocol’s design. The argument distinguishes between the “speech” layer—content publication rights—and “reach” layer—content amplification and discovery. PDS federation operates permissively, allowing anyone to publish content without centralised gatekeeping. Relay operation can be centralised because relays don’t control what gets published. They merely aggregate what’s already public. This separation means relay operators control reach—what content gets indexed and amplified—but not speech—what content can be published.
Critics like Chris Hartgerink question whether this distinction holds in practice. Without Bluesky’s relay, alternative App Views lack the data to function effectively. If Bluesky operates the only full-network relay, and major App Views depend on that relay for comprehensive data, does Bluesky effectively control both speech and reach despite the architectural separation? Can meaningful reach exist outside Bluesky’s infrastructure if alternative relays lack the resources or incentives to achieve comprehensive coverage?
This creates a single point of failure. If Bluesky’s relay experiences downtime, the entire network’s discovery and real-time features degrade, even though individual PDS instances continue operating.
Alternative relay architectures are technically possible but economically questionable. An organisation could operate topic-specific relays indexing only relevant PDS instances—for example, a research relay indexing only academic users. Regional relays could focus on geographic areas. However, many App View features require comprehensive network data. Global search needs complete indexing, follower counts require tracking all follow relationships, trending topics need visibility into entire network activity. Topic-specific or regional relays can’t provide these features, limiting their utility for general-purpose social applications.
The current reality is stark. Bluesky operates a monopoly relay that processes all network activity, creating a single point of architectural control despite the protocol’s decentralised design. This concentration creates dependency risk—what happens if Bluesky’s relay fails? It creates governance risk—can Bluesky use relay control to advantage its own App View? And it creates sustainability risk—will independent relays ever emerge with viable economic models?
For technical decision-makers evaluating AT Protocol, relay architecture represents the protocol’s most significant centralisation compromise. The design trades decentralised relay operation for scalability and comprehensive network features. Whether this trade-off is acceptable depends on your priorities. If global search and metrics are necessary, relay aggregation solves real problems. If genuine decentralisation is paramount, relay centralisation undermines the broader architecture.
What are lexicons and how do they prevent vendor lock-in?
Lexicons are AT Protocol’s global schema network defining standardised data structures, behaviours, and API contracts across all implementations. They create a shared vocabulary allowing different server implementations to understand each other’s data without vendor-specific translations.
Core com.atproto.* lexicons define repository syncing, authentication, and identity management. Application lexicons like app.bsky.* define social features such as posts, follows, and likes. Third parties can develop new lexicons for custom features while maintaining interoperability with the broader ecosystem.
Here’s what that means in practice. When you publish a post on Bluesky, your PDS stores it as an app.bsky.feed.post record with standardised fields—text (max 300 chars), createdAt timestamp, reply references. Any client or server implementing this lexicon understands exactly what those fields mean and how to process them. These standardised schemas are called Lexicons.
Think of Lexicons as protocol-level API specifications or contract definitions. When a server implements the app.bsky.feed.post lexicon, it commits to understanding the exact structure of post records. Which fields are required, what data types they accept, how timestamps are formatted, and what behaviours are expected. Any client or service speaking the same lexicon can confidently exchange post data regardless of who developed the underlying software.
The Lexicon specification language builds on JSON Schema and OpenAPI patterns while incorporating AT Protocol-specific features. The specification defines five primary types: query operations, procedures, subscriptions, stored records, and authentication tokens. The specification includes AT Protocol-specific string formats like at-identifier (DIDs or handles), cid (Content Identifiers), and datetime (timestamps).
Lexicons support constrained string formats tailored to AT Protocol primitives: at-identifier (DIDs or handles), at-uri (AT Protocol URIs), cid (Content Identifiers), datetime (timestamps), did (Decentralised Identifiers), handle (domain-based usernames), nsid (Namespaced IDs), tid (Timestamp IDs), record-key (repository record keys), uri (generic URIs), and language (ISO codes). These constrained formats enable validation and type safety across implementations.
Schema evolution follows compatibility rules designed to prevent breaking changes. New fields must remain optional, allowing older implementations to ignore unknown fields. Types cannot change—a string field can’t become an integer. Fields cannot be renamed without creating a new lexicon. Non-optional fields must persist (though deprecation is recommended for unused fields). Breaking changes require publishing new lexicon namespaces, ensuring implementations can continue supporting older versions while adopting newer schemas.
Lexicon authority derives from DNS domain control, similar to how reverse DNS naming works in Java packages or Android apps. The organisation controlling the domain can define lexicons under that namespace. Bluesky controls the app.bsky.* namespace. Independent developers can create lexicons under domains they control. Lexicons are published as AT Protocol repository records using the com.atproto.lexicon.schema type, making schema definitions themselves part of the federated data layer.
This architecture prevents vendor lock-in through several mechanisms:
Data portability: Because your data conforms to standardised lexicons rather than proprietary formats, you can export your repositories and import them into alternative services without conversion or data loss.
Client choice: Multiple client applications can implement the same lexicons, allowing you to switch between apps without changing servers or losing functionality.
Server interoperability: Different PDS implementations—Bluesky’s official PDS, independent implementations—can host users on the same network because they speak the same lexicon language.
Feature innovation: Developers can build alternative App Views, feed generators, or moderation services implementing standard lexicons while differentiating on user experience, performance, or algorithmic approaches.
Migration assurance: Even if your PDS provider disappears, your data remains usable by any service implementing the relevant lexicons.
The theoretical benefits are compelling, but practical ecosystem maturity determines real-world effectiveness. How many independent lexicon namespaces exist beyond com.atproto.* and app.bsky.*? Have third-party lexicons achieved meaningful adoption? Does lexicon governance allow genuinely independent evolution, or does Bluesky’s architectural control extend to schema standardisation?
Current evidence suggests limited third-party lexicon adoption. The ecosystem remains dominated by Bluesky-defined schemas, with independent lexicon development still nascent. This concentration doesn’t necessarily indicate architectural failure—early ecosystems often consolidate around first-mover standards during their first 1-2 years—but it does mean vendor lock-in prevention remains theoretical rather than demonstrated.
For enterprise evaluation, lexicons represent solid architectural thinking about interoperability and data portability. The specification is technically sound, the compatibility rules are sensible, and the standardisation approach mirrors successful patterns from other domains. However, the proof requires ecosystem diversity—multiple implementations, multiple lexicon publishers, and migration evidence demonstrating that portability works in practice, not just in protocol specifications.
How does AT Protocol achieve federation between servers?
Federation works through repository synchronisation. Personal Data Servers broadcast updates to relays via HTTP and WebSockets, relays aggregate these into a network-wide firehose, and App Views consume the firehose for indexing and features. This differs from ActivityPub’s server-to-server message passing. AT Protocol uses a centralised aggregation layer rather than point-to-point communication. The architecture achieves technical federation—data distributed across independent servers—but with an architectural centralisation trade-off in the relay layer.
The account-based federation model stores user data on servers rather than implementing peer-to-peer distribution between end devices. This choice prioritises convenience and reliability over pure decentralisation. You don’t need your devices online for your content to remain accessible. The PDS hosting your data handles availability. This mirrors traditional web hosting more than blockchain or peer-to-peer architectures.
The synchronisation process follows three steps. When you create content through your client application, the request goes to your PDS. The PDS validates the request, adds a signed record to your repository, and broadcasts the update over HTTP POST or WebSocket streams. Relays subscribing to that PDS receive the update notification, fetch the new record if needed, validate the cryptographic signature against your DID, and add the update to their aggregated firehose stream. App Views consuming the firehose receive the update and process it according to their indexing and filtering logic.
Note that only public content flows through this federation mechanism. Private messages use direct PDS-to-PDS communication outside the relay infrastructure.
This architecture contrasts sharply with ActivityPub’s federation model. In ActivityPub, servers communicate directly with each other using server-to-server protocols. When a Mastodon user follows someone on a different instance, their server establishes a subscription relationship with the other server and receives updates directly. There’s no central aggregation point. Federation happens through server-to-server message passing. This provides genuine decentralisation but creates challenges for features requiring global network data.
AT Protocol’s relay aggregation enables comprehensive features that ActivityPub struggles to provide. Accurate follower counts across the entire network—not just instances your server knows about. Full-text search covering all content—not just content your server has seen. Trending topics based on complete activity data—not partial visibility. And comprehensive user directories. These features require network-wide visibility that relay aggregation provides but point-to-point federation makes difficult.
The trade-off is architectural centralisation. While PDS federation is distributed—anyone can operate a PDS and host user data—relay operation concentrates around organisations with resources to aggregate the entire network. Currently Bluesky operates the only full-network relay, though the protocol doesn’t technically prevent alternative relays from emerging.
Current federation statistics illustrate the ecosystem’s maturity. Approximately 11.7 million accounts use Bluesky-hosted PDS instances compared to roughly 59,000 on independent servers across 2,200 data stores. This 99.5% concentration on Bluesky-hosted infrastructure reveals that while federation is architecturally possible, economic and operational realities favour consolidation. Users can choose independent PDS providers, but most don’t—whether due to convenience, reliability concerns, or simple unfamiliarity with alternatives.
The protocol enables federation. The ecosystem incentivises centralisation. Understanding this distinction matters for technical decision-makers. AT Protocol isn’t preventing independent PDS operation or alternative relay development. But it also isn’t creating compelling economic incentives for such independence. The result is federation in design with centralisation in deployment.
Federation benefits include provider choice—you can select PDS hosting based on trust, performance, or features. Data portability—signed repositories enable migration between providers. And censorship resistance—distributed hosting makes comprehensive takedowns difficult.
Federation limitations include relay dependency—comprehensive features require relay infrastructure. PDS concentration—the ecosystem consolidates around Bluesky hosting. And governance questions—who controls protocol evolution if one organisation dominates infrastructure?
For strategic evaluation, AT Protocol clearly achieves federation at the technical level. Data is distributed, account portability works, multiple PDS instances interoperate. However, ecosystem concentration around Bluesky’s infrastructure—99.5% of users—means federation remains architectural potential rather than operational reality for most participants. Whether you value the architecture’s capability to support future decentralisation or require current ecosystem diversity determines how you assess this trade-off.
What is the difference between speech and reach in AT Protocol’s moderation model?
The “speech” layer refers to content publication rights where permissive PDS federation allows broad participation without centralised gatekeeping. The “reach” layer refers to content amplification where App Views, feed generators, and labelers control visibility and discovery. This architectural separation allows you to publish content freely while communities and services independently moderate what gets amplified. It creates a spectrum of moderation approaches rather than a single platform policy.
The philosophical foundation distinguishes between the right to speak—publish content—and entitlement to audience—have content amplified. Traditional platforms conflate these concerns. Content moderation decisions simultaneously determine whether you can publish and whether others will see your publication. AT Protocol separates them architecturally, implementing different technical mechanisms for each layer.
In practice, this works like this. A controversial political commentator can run their own PDS—or find a provider—and publish freely. That’s the speech layer. But whether their content appears in trending topics, gets recommended to new users, or surfaces in search results depends on App View and feed generator policies. That’s the reach layer. The PDS can’t be prevented from publishing, but amplification isn’t guaranteed.
The speech layer operates at the PDS level. Anyone can run a PDS or find a provider willing to host their account. PDS operators have minimal filtering responsibilities—they store and distribute whatever signed records their users publish. The permissive federation model means even controversial or marginal viewpoints can find hosting, similar to how anyone can operate a website regardless of content, subject to local laws and hosting provider terms.
The reach layer operates at the App View, feed generator, and labeler level. App Views decide what content to index and how to rank it. Feed generators implement algorithmic choices about what content surfaces in discovery feeds. Labelers apply content labels that App Views and clients can use for filtering—marking content as adult, spam, misleading, or violating specific policies. You configure which labelers you trust and how aggressively to filter labeled content.
This creates several moderation possibilities impossible in traditional platforms:
Competing moderation standards: Different App Views can implement different moderation policies. A family-friendly App View might filter aggressively. A free-speech-oriented App View might filter minimally. You choose your App View based on preferred moderation approach.
User-configurable moderation: You select which labelers to trust and how to handle labeled content. One user might hide all content labeled “political,” while another welcomes such content. Same network, different experiences.
Independent labeler services: Third parties can operate labeling services implementing their community’s standards. A professional community might run a labeler marking off-topic content. A fact-checking organisation might label misleading claims. You subscribe to labelers matching your preferences.
Separation of concerns: PDS operators aren’t responsible for content moderation beyond local legal requirements. App View operators moderate reach but can’t prevent publication. Labelers provide information but don’t enforce decisions—you control filtering configuration.
Some labels might be mandatory based on App View policies—for example, content deemed illegal in the App View operator’s jurisdiction or violating their terms of service—while others are user-configurable (content preferences).
The criticism is that if most users access the network through Bluesky’s App View—which currently dominates—and that App View implements specific moderation policies, the speech/reach distinction becomes theoretical rather than practical. You technically have publication rights, but without reach through the primary App View, your content remains effectively invisible to the mainstream network. Alternative App Views would need significant user adoption to provide meaningful reach outside Bluesky’s ecosystem.
The labeler system demonstrates the reach layer’s distributed potential. Independent labelers can apply content labels according to their criteria—community standards, topic relevance, fact-checking, content warnings. Client applications and App Views enforce these labels according to user configuration. The architecture enables moderation diversity without requiring consensus on specific policies.
Feed generators extend the reach layer’s flexibility to algorithmic discovery. Instead of a single “For You” algorithm controlled by the platform, you can subscribe to multiple feed generators implementing different discovery approaches—chronological feeds, topic-specific feeds, algorithmic recommendations, community-curated feeds, or custom filters. Feed generators operate independently from content storage, separating algorithmic choice from data hosting.
This architectural justification for relay centralisation mirrors the arguments made in the relay section above. Control over aggregation and discovery isn’t the same as control over publication. However, the same practical concerns apply—concentration creates power regardless of architectural intentions.
For technical leaders evaluating moderation requirements, the speech/reach model offers real benefits. Reduced platform liability—PDS operators aren’t responsible for moderating all content. User choice in moderation approaches—select labelers and App Views matching your preferences. And innovation in moderation techniques—independent labelers can experiment with different approaches. However, these benefits depend on ecosystem diversity—multiple App Views, active labeler adoption, and user understanding of moderation configuration.
What are the main components of AT Protocol architecture?
The core architecture consists of Personal Data Servers hosting user data and identity, Relays aggregating updates into firehose streams, and App Views providing application features by consuming firehose data. Supporting services include Feed Generators creating custom content algorithms and Labelers applying independent moderation labels. All components coordinate through DID-based identity and Lexicon-based schemas, with some components centralised (Relay, App View) and others distributed (PDS, generators, labelers).
Personal Data Server (PDS) serves as your home in the cloud. It hosts your signed data repository containing posts, likes, follows, and other records. It manages your DID-based identity, orchestrating authentication and authorisation. It distributes your content by broadcasting updates to relays and responding to requests from other services.
You can self-host a PDS for complete data sovereignty or choose a provider based on trust, features, or cost. The official PDS implementation has low computational requirements. Individuals can run single-user instances on modest VPS hosting—2GB RAM, 20GB storage. Multi-user deployments scale resources with user count.
Relay functions as the network’s core indexer. It crawls the network by subscribing to repository updates from all known PDS instances, aggregates these updates into comprehensive streams, and republishes the firehose for consumption by App Views and other services.
Relays can theoretically index all or part of the network. Topic-specific relays could focus on relevant PDS instances. But most App View features require comprehensive coverage. Infrastructure requirements are substantial. Bluesky’s production relays use approximately 1TB for PostgreSQL and 1TB for CAR storage, with servers requiring fast disks, significant bandwidth, and continuous operation. The relay provides two output formats: binary firehose for high-throughput applications and Jetstream (JSON) for developer accessibility.
App View serves as the application layer transforming firehose data into user-facing features. It consumes the relay’s firehose stream, processes updates according to its indexing logic, and provides APIs for client applications.
App Views support large-scale metrics—follower counts, like counts, engagement data. Content discovery through algorithmic feeds. User search across the entire network. And relationship graphs—who follows whom, block lists, mute lists. Different App Views can implement varying approaches to these features—different ranking algorithms, different search relevance models, different privacy policies—while operating from the same underlying firehose data.
This architecture reduces computational load compared to traditional platforms. App Views don’t store repositories, only indices. And it prevents vendor lock-in—you can switch App Views while retaining your content.
Feed Generator provides independent algorithmic content discovery. Rather than accepting a single platform-controlled algorithm, you can subscribe to multiple feeds implementing different discovery approaches.
A feed generator queries App View data, applies its algorithmic logic—chronological sorting, topic filtering, engagement ranking, machine learning recommendations—and returns content for your consumption. Feed generators operate as independent services routable by the PDS based on client configuration. This enables third-party innovation in discovery algorithms without modifying core infrastructure.
Labeler implements distributed moderation through content and account labeling. Independent labeler services apply labels based on their criteria—community standards, topic categorisation, content warnings, fact-checking, spam detection.
Client applications and App Views enforce these labels according to user configuration. One user might hide all content labeled “politics” while another welcomes such content. Some labels might be mandatory based on App View policies—illegal content. Others remain user-configurable. The labeler system enables competing moderation standards and user choice in content filtering.
The identity layer provides account portability across all components. You have permanent Decentralised Identifiers (DIDs) containing references to your current PDS and cryptographic keys—signing key for data validation, rotation key for identity updates. Because identity is cryptographic rather than namespace-based, you can migrate between PDS providers by updating your DID document and moving your signed repository. Domain-based handles—like @username.bsky.social or @company.com—map to DIDs through DNS or HTTPS verification, providing human-readable usernames while maintaining cryptographic identity.
The data layer ensures integrity and portability. Your data is stored in signed repositories—Git-like structures containing collections of records. Each record—post, like, follow—is cryptographically signed and timestamped, enabling verification independent of the hosting provider. Repositories use Merkle search trees to organise records chronologically based on Timestamp IDs (TIDs), providing efficient syncing and verification. The signed repository model enables migration between PDS providers with complete data integrity.
The schema layer prevents vendor lock-in through Lexicon standardisation. Core com.atproto.* lexicons define repository syncing, authentication, and identity. Application app.bsky.* lexicons define social features. Third parties can develop custom lexicons under their DNS domains. Standardised schemas ensure different implementations understand each other’s data without vendor-specific translations.
Component interaction follows this data flow: Your client app → Your PDS (stores your post) → Relay (aggregates with others’ posts) → Firehose (comprehensive network stream) → App View (indexes and ranks) → Feed Generators & Labelers (custom algorithms/moderation) → Other users’ clients (see your content).
From an infrastructure perspective, the components show dramatic cost disparity. PDS instances are cheap to operate—$5-20/month for single users. Relays are expensive—$150+ baseline, thousands at scale. And App Views fall between depending on feature scope and user base.
Infrastructure reality shows concentration despite architectural distribution. Bluesky operates the dominant relay, primary App View, most PDS instances—hosting 99.5% of accounts—and PLC (Public Ledger of Credentials) identity registry. Independent PDS instances serve approximately 59,000 accounts across 2,200 data stores. Independent labelers and feed generators exist but remain a small fraction of ecosystem activity. The protocol permits decentralisation. The ecosystem demonstrates centralisation.
For technical decision-makers evaluating architecture, the component design shows thoughtful separation of concerns. Data hosting (PDS) separates from aggregation (Relay) separates from application features (App View). Supporting services—feed generators, labelers—integrate cleanly without requiring core infrastructure changes. The cryptographic identity and signed repository mechanisms provide solid foundations for portability and verification.
However, operational reality differs from architectural potential. Running components requires resources, expertise, and ongoing maintenance. Economic incentives favour consolidation around well-resourced operators. Network effects concentrate users where others are active. The result is an architecture enabling distribution implemented with centralisation.
FAQ
What is the difference between AT Protocol and ActivityPub?
AT Protocol exchanges schematic data with standardised schemas (Lexicons), while ActivityPub exchanges JSON-LD documents with flexible schemas. AT Protocol uses relay-based aggregation for network-wide data access. ActivityPub uses server-to-server message passing. AT Protocol optimises for global features—search, metrics, comprehensive feeds—at cost of relay centralisation. ActivityPub prioritises decentralisation but struggles with cross-server discovery and features requiring global data. Different architectural philosophies addressing federation challenges through contrasting approaches. AT Protocol accepts relay centralisation for scalability. ActivityPub maintains point-to-point federation at cost of global feature difficulty.
Is AT Protocol actually decentralised or is that just marketing?
Mixed reality reflecting gap between architectural capability and ecosystem deployment. Protocol design enables decentralisation through portable accounts (DIDs with rotation keys), independent PDS hosting, and theoretically open relay operation. Current implementation shows significant centralisation. Bluesky operates monopoly relay, dominant App View, PLC identity registry, and hosts 99.5% of PDS instances—11.7M accounts vs 59K on independent servers. Infrastructure economics favour centralisation. Relay operation costs thousands monthly with unclear revenue model. Network effects concentrate users where others are active. Protocol permits decentralisation. Ecosystem incentives work against it. Genuine decentralisation requires economic sustainability models for independent operators and cultural shift toward valuing data sovereignty over convenience.
How much does it cost to run a full-network AT Protocol relay?
Infrastructure requirements are substantial based on operational experience. Bryan Newbold’s relay deployment required bare metal server with 12 vCPU processors, 32GB RAM, 2×1.92TB NVMe drives at monthly cost approximately $150-$153. Initial backfill operations demonstrated high resource usage—disk write rates 600-1800MB/sec, PostgreSQL growth 14MB/sec. Steady-state operations more modest—CPU under 2%, network traffic under 250KB/sec. Final storage reached 447GB PostgreSQL. Production Bluesky relays use approximately 1TB PostgreSQL + 1TB CAR storage. Cloud storage options (AWS EBS) prove expensive compared to bare metal with large local disks. Total monthly costs likely thousands of dollars for comprehensive relay at scale, depending on optimisation and infrastructure provider. Economic model unclear. Relay operators have costs but no obvious revenue source, contributing to centralisation concerns.
Can I migrate my account between Personal Data Servers without permission?
Theoretically yes, if you control your rotation key—the cryptographic key authorising DID document updates. Migration process involves using rotation key to update DID document pointing to new PDS, uploading signed repository backup to new PDS, and optionally updating domain handle. New PDS broadcasts updates through relay network. Your account appears at new location with complete history. The caveat: many users don’t control rotation keys. PDS providers manage them for operational convenience, limiting true portability. Self-custody rotation keys—paper key, hardware key, user device—enable genuine migration without provider cooperation. Provider-managed rotation keys require provider permission or cooperation. Account portability claim depends on cryptographic key control, not just protocol capability. Evaluate rotation key management model before assuming migration capability.
Where can I find the official AT Protocol specification?
Official documentation available at atproto.com provides comprehensive protocol specifications, developer guides, and implementation details. Primary specifications include Authenticated Transfer Protocol (core federation), DIDs and Handles (identity layer), Repository and Data Model (data structure), Lexicon (schema definition), and HTTP API/Event Streams (communication protocols). Lexicon specification at atproto.com/specs/lexicon defines schema language. Additional technical resources: Bryan Newbold’s relay infrastructure documentation, AT Protocol GitHub repositories (github.com/bluesky-social), Bluesky developer documentation. IETF standardisation in progress. Portions submitted to Internet Engineering Task Force as Birds of a Feather proposal August 2025, signaling commitment to neutral multi-stakeholder governance. Specifications currently Bluesky-controlled. IETF process aims to establish vendor-neutral standards body.
What infrastructure do I need to run my own Personal Data Server?
Minimal PDS deployment requires server with persistent storage, domain name for identity verification, HTTPS certificate for secure communication, and network connectivity. Software: official PDS implementation from Bluesky (open source) or compatible alternative implementations. Resource requirements scale with user count. Single-user instances run on modest VPS—2GB RAM, 20GB storage starting point. Multi-user hosting requires resources proportional to user count and activity. Operational requirements include backup strategy for signed repositories, security update processes, monitoring and alerting, and relay connectivity configuration. Deployment complexity moderate for developers familiar with server administration. Challenging for non-technical users. Self-hosting provides data ownership and sovereignty but accepts ongoing maintenance responsibility and operational risks. Provider-hosted PDS offers convenience at cost of reduced data control.
How does account portability work technically in AT Protocol?
Account identity uses Decentralised Identifier (DID) containing signing key (validates user data) and rotation key (controls identity updates). Your data stored in signed repository—Git-like structure with cryptographically signed records: posts, likes, follows. Migration process: use rotation key to update DID document pointing to new PDS location, upload repository backup to new PDS, update domain handle verification if desired. New PDS validates repository signatures against DID signing key, confirms cryptographic integrity, broadcasts updates through relay network. Your account appears at new location with complete verifiable history. No opportunity for old PDS to modify history or new PDS to fabricate records. Cryptographic signature chain provides tamper-proof verification. Portability effectiveness depends on rotation key custody—user-controlled enables genuine migration, provider-controlled requires cooperation—and repository backup availability. Continuous syncing to user device or third-party mirror recommended.
Why would anyone run a relay if there’s no revenue model?
This is an unsolved question affecting decentralisation viability. Potential motivations include infrastructure provider marketing—demonstrate technical capability and scale. Research/academic interest—studying decentralised systems. Ideological commitment to decentralisation—supporting protocol independence. Cross-subsidy from other services—relay operation subsidised by App View revenue or PDS hosting fees. Current relay monopoly suggests economics don’t support widespread independent operation. Possible future revenue models: subscription services requiring real-time firehose access, premium App View features consuming relay data, aggregate data licensing to researchers or analytics services, grant funding from protocol foundations or consortia. Until sustainable economics emerge, relay operation likely remains limited to well-funded organisations or ideological operators willing to sustain losses for strategic positioning.
What are the security implications of DID-based identity for enterprise use?
Cryptographic identity provides security benefits. Account ownership independent of provider prevents vendor lock-in risks. Verifiable data integrity through signed repositories ensures content authenticity. Migration capability enables business continuity if provider fails. Security considerations include rotation key custody model—user device storage, hardware security modules, provider-managed escrow. Signing key compromise risks—requires key revocation and rotation procedures. DID registry dependency—PLC currently Bluesky-centralised creating single point of control. Key recovery mechanisms—balance security with usability for credential loss. Enterprise deployment requires key management policies defining custody and rotation procedures, backup and recovery processes for keys and repositories, identity federation integration with existing systems (SSO, LDAP, directory services), and audit trails for compliance requirements. Maturity assessment: protocol relatively new with limited enterprise deployment examples. Enterprise-grade tooling and operational patterns still developing. Production deployment requires comprehensive risk evaluation and key management planning.
Can AT Protocol integrate with existing identity systems (SSO, LDAP)?
Yes, through hybrid architecture. Enterprises can operate internal PDS instances with SSO/LDAP authentication controlling access, while the PDS manages DID-based federation externally on users’ behalf. Technical pattern: internal auth verifies user identity and authorises PDS access. PDS manages DID and signing keys on user’s behalf. Users interact with broader AT Protocol network through federated identity. Complexity involves maintaining cryptographic key custody while integrating enterprise identity management systems—reconciling centralised enterprise identity with decentralised protocol identity. Use case dependent: internal-only deployment (enterprise social network) simpler than federated external access (employees interacting with broader AT Protocol network). OAuth procedures grant applications temporary write permissions following standard patterns. Implementation examples currently limited. Enterprise adoption remains early stage. Integration requires careful consideration of authentication flows, key management responsibility, and compliance requirements.
How does AT Protocol handle spam and abuse across federated servers?
Layered approach combining speech/reach separation with independent moderation services. PDS federation operates permissively (speech layer)—low barriers to content publication without centralised gatekeeping. App Views and labelers control visibility (reach layer)—filtering and ranking decisions independent from publication rights. Labeler services apply content and account labels based on their criteria: spam detection, policy violations, content warnings, community standards. Some labels potentially mandatory—illegal content based on jurisdiction. Others user-configurable—content preferences, sensitivity filters. Clients and App Views enforce labels according to configuration. You choose which labelers to trust and how aggressively to filter. Network-wide visibility through relay enables cross-server abuse detection. Patterns visible across entire network rather than limited to single server’s view. Criticism: centralised App View creates moderation choke point despite architectural distribution. Effectiveness depends on labeler ecosystem maturity—currently limited—client implementation quality—label enforcement support—and user sophistication—understanding labeler configuration.
What happens if the main Bluesky relay goes down?
Current architecture creates single point of failure. Bluesky operates only full-network relay. Impact of relay failure includes App Views losing real-time updates—stale data for metrics and discovery. Discovery features degraded—trending topics, recommendations cease updating. Cross-server visibility impaired—new content doesn’t propagate. And network-wide search outdated—indices stop updating. PDS instances continue operating. You can publish content, repositories remain accessible. But content reaches limited audience without relay aggregation. Direct PDS-to-PDS communication theoretically possible but not implemented in practice. Ecosystem depends on relay-mediated discovery. Account portability unaffected—DID-based identity operates independently. Mitigation strategies include relay redundancy—multiple relay operators consuming same PDS updates—and client-side fallback—degraded functionality during relay outage. However, alternative relays currently non-existent due to economic and operational barriers. Architectural centralisation risk: protocol permits relay distribution, reality concentrates dependency on single operator. Business continuity requires confidence in Bluesky’s relay reliability or emergence of alternative relay operators.
Wrapping it all up
AT Protocol represents thoughtful architectural thinking about decentralised social infrastructure. The cryptographic identity mechanisms enable genuine account portability. The lexicon standardisation provides solid foundations for interoperability. The speech/reach separation offers innovative approaches to content moderation. The component architecture cleanly separates concerns between data hosting, aggregation, and application features.
However, architectural capability differs from ecosystem reality. Bluesky operates monopoly relay infrastructure, dominant App View, most PDS hosting, and PLC identity registry. Independent operators serve less than 1% of accounts. Economic incentives favour consolidation rather than distribution. Network effects concentrate users where others are active. The protocol permits decentralisation. The implementation demonstrates centralisation.
For technical leaders evaluating AT Protocol for adoption, migration, or competitive positioning, the questions aren’t whether the architecture supports decentralisation theoretically—it does—but whether practical deployment aligns with your strategic requirements. Do you value federation as current operational reality or architectural potential for future development? Does cryptographic portability matter if 99.5% of users accept Bluesky hosting? Can meaningful reach exist outside Bluesky’s infrastructure given current ecosystem concentration?
The answers depend on your priorities. If you need global social features—comprehensive search, accurate metrics, trending topics—AT Protocol’s relay aggregation solves real scalability challenges that pure peer-to-peer models struggle with. If you require genuine decentralisation with no single points of control, current AT Protocol deployment falls short despite architectural capabilities. If you seek vendor lock-in protection through cryptographic identity and standardised schemas, the protocol provides solid technical foundations. But ecosystem maturity will determine practical effectiveness.
AT Protocol deserves evaluation based on what it is—a thoughtfully designed federation architecture with real portability mechanisms and genuine centralisation trade-offs—not what its marketing claims or critics assert. Your strategic context, risk tolerance, and timeline determine whether its current ecosystem concentration is a fatal flaw or an acceptable bet on future decentralisation potential. For a comprehensive framework to evaluate these trade-offs, see our guide on deciding between centralised and decentralised architectures.
