What Is OpenFederation and Why We Chose ATProto

The Problem: Communities Are Trapped

Every online community today faces the same uncomfortable truth: they don't own their identity. A Discord server, a Slack workspace, a Facebook Group — none of them actually belong to the people who built them. The platform does. If the platform changes its rules, raises prices, or shuts down, the community loses everything: its members, its history, its reputation.

OpenFederation exists to fix that.

What OpenFederation Does

OpenFederation is a decentralized identity and data layer for communities. At its core, it gives every community a cryptographically portable identity — a Decentralized Identifier (DID) — and a Personal Data Server (PDS) that stores the community's membership, roles, and settings in a way that the community actually controls.

Think of it as owning your community's passport instead of renting a name badge from a landlord.

A community on OpenFederation can:

• Exist independently of any single hosting provider
• Move to another server at any time, taking all of its data with it
• Prove its identity cryptographically, without relying on a central authority
• Connect to applications — forums, chat platforms, games, governance tools — while maintaining a single source of truth for who its members are

The PDS is the authoritative home for a community's data. Applications read from it. If an application disappears, the community's identity and membership remain intact.

The Protocols: ATProto and ActivityPub

Two major open protocols compete for the future of decentralized social infrastructure: the AT Protocol (developed by Bluesky) and ActivityPub (the protocol behind Mastodon and the broader Fediverse). We use both — but in very different roles.

AT Protocol: The Foundation

The AT Protocol is OpenFederation's primary protocol. Every community identity, every membership record, and every role assignment is stored as an ATProto repository — a Merkle Search Tree (MST) of content-addressed, cryptographically signed records.

Here's why we chose it as the foundation:

1. True data ownership through cryptographic keys

ATProto was designed around a single idea: your data should be yours, provably. Every repository is signed by its owner's cryptographic key. When a community creates a did:plc identity on OpenFederation, it receives a primary rotation key — a secret that only the community holds. Even the server operator cannot impersonate the community or prevent it from leaving, because the community holds the master key.

This isn't a policy promise. It's a mathematical guarantee.

2. Portable repositories

An ATProto repository is a self-contained, exportable data structure. A community can call com.atproto.sync.getRepo and receive a complete CAR (Content Addressable aRchive) file containing every record, every block, every signed commit. That file can be imported into any other ATProto-compatible PDS. The community updates its DID document to point to the new server, and it's done. No migration negotiations, no data loss, no downtime bargaining.

This "free to go" principle is not an afterthought — it's the core architectural constraint that shapes everything else.

3. Verifiable data integrity

Every record in an ATProto repository is stored in a Merkle Search Tree. This means any third party can verify that a record exists, hasn't been tampered with, and was committed by the repository owner — without trusting the server. The tree's root hash, signed by the community's key, is a compact proof of the entire repository's state at any point in time.

For community identity, this matters enormously. A membership attestation isn't just a database row that an admin could quietly edit. It's a signed, content-addressed record in a verifiable data structure.

4. Structured data with Lexicon schemas

ATProto uses Lexicon, a schema language for defining record types and API methods. OpenFederation defines its own Lexicon schemas under the net.openfederation namespace:

• net.openfederation.community.profile — the community's public identity
• net.openfederation.community.member — membership records
• net.openfederation.community.role — role definitions
• net.openfederation.community.settings — governance configuration
• net.openfederation.community.attestation — verifiable claims

These schemas are standardized. Any application that speaks ATProto can read and understand OpenFederation community data without custom integration work.

5. DID flexibility

OpenFederation supports two DID methods, and lets communities choose:

• did:plc — a hosted DID method where the PDS manages key operations. The community receives its primary rotation key; the server holds a lower-priority recovery key (encrypted at rest with AES-256-GCM). This is the easy path: communities get full portability without managing their own infrastructure.

• did:web — a domain-based DID method where the community hosts its own did.json file. The PDS holds no keys at all. This is the sovereignty path: communities that want complete independence can control their identity at the DNS level.

Both methods produce the same result — a portable, verifiable identity — but they serve different trust models.

ActivityPub: The Bridge

ActivityPub is the protocol that powers the Fediverse: Mastodon, GoToSocial, Lemmy, PeerTube, and hundreds of other applications. It's the largest deployed federation network in the world.

We don't ignore it. We bridge to it.

OpenFederation implements what we call Scenario A: identity-only bridging. This means:

• Communities can be discovered by ActivityPub applications. An OpenFederation community appears as an AP Group actor with a public key, profile information, and links to its connected applications.
• WebFinger returns AP-compatible actor URLs alongside ATProto service endpoints, so Fediverse tools can find OpenFederation communities through standard discovery.
• NodeInfo endpoints advertise the PDS as a federation node, making it visible to Fediverse crawlers and directories.

What we deliberately do not do:

• No inbox or outbox processing. The PDS does not receive or send ActivityPub messages. It doesn't manage follows, boosts, or replies.
• No content federation. Posts, discussions, and media stay in whatever application the community uses. Only identity crosses the protocol boundary.
• No AP-native data storage. All data remains in ATProto repositories. The AP layer is a read-only projection.

This is a conscious architectural choice, not a limitation.

Why Not ActivityPub as the Foundation?

ActivityPub is a proven protocol with a large ecosystem. So why not build on it directly?

The answer comes down to what each protocol optimizes for.

ActivityPub optimizes for message passing. It's an excellent protocol for social networking: following accounts, delivering posts, forwarding replies. Its actor model maps naturally to users and groups exchanging content. The Fediverse proves this works at scale.

But ActivityPub was not designed for portable, verifiable data ownership. Consider what happens when a Mastodon instance shuts down:

• User identities (tied to the instance domain) become invalid
• Post history is lost unless individually backed up
• Followers on other instances see a dead link
• There is no cryptographic proof that the account ever existed

The instance is the identity. There is no separation between the hosting provider and the data it holds.

ATProto optimizes for data sovereignty. It was designed from the ground up so that a user's identity and data can survive the death of any single server. DIDs are not tied to domains. Repositories are self-contained and exportable. Signed commits create an auditable history. The protocol assumes that servers will come and go, and builds accordingly.

For OpenFederation's mission — giving communities portable, self-sovereign identity — ATProto's design assumptions align directly with our requirements. We would have had to build most of these properties on top of ActivityPub. With ATProto, we get them from the protocol layer.

ActivityPub's ecosystem is its strength. Millions of users, thousands of instances, a rich application landscape. We want OpenFederation communities to be visible in that ecosystem. But we want their identity foundation to be built on something that guarantees portability by design, not by convention.

That's why ATProto is the foundation and ActivityPub is the bridge.

How It Works in Practice

Here's a concrete example of how the pieces fit together:

1. A gaming community creates an identity on an OpenFederation PDS. It gets a did:plc identifier and a repository containing its profile, settings, and an initial membership record for its founder.

1. Members join. Each new member gets their own DID and a membership record is written to the community's repository — a signed, verifiable entry in the Merkle Search Tree.

1. The community links applications. It connects a forum (powered by Lemmy, speaking ActivityPub) and a leaderboard service. Both applications read membership data from the PDS to verify who belongs to the community.

1. The community becomes discoverable. Fediverse users can find the community via WebFinger and see it as an ActivityPub Group actor. The actor includes links to the connected applications.

1. Years later, the PDS host goes out of business. The community exports its repository as a CAR file, sets up a new PDS (or joins another OpenFederation host), imports the data, and updates its DID document to point to the new server. Every membership record, every role, every attestation survives the move — cryptographically intact.

No platform lock-in. No data loss. No permission needed.

The Architecture

OpenFederation's PDS is a modular system:

• Identity Manager — creates and resolves DIDs (did:plc and did:web), manages cryptographic keys, validates domains
• Repository Engine — wraps ATProto's MST implementation for signed commits, record storage, and CAR export
• XRPC Server — serves the AT Protocol API (standard ATProto methods plus OpenFederation extensions)
• ActivityPub Layer — optional, read-only projection of community identity into the Fediverse
• Authentication — JWT access tokens with refresh token rotation and reuse detection
• Partner API — allows trusted third-party applications to register users directly

The server is written in TypeScript, runs on Node.js, and stores data in PostgreSQL. Cryptographic keys are encrypted at rest using AES-256-GCM with PBKDF2-derived encryption keys.

Third-party applications integrate via the @openfederation/sdk, a zero-dependency JavaScript library that handles registration, authentication, and session management. It's available as an npm package or as a 2.5KB browser bundle served directly from the PDS. See the SDK integration guide for details.

What's Next

OpenFederation is in active development. The source code is available on GitHub. The identity layer, community management, partner API, ATProto federation endpoints, and ActivityPub bridge are all functional. The roadmap includes:

• Blob storage for community avatars and media
• Email verification for account recovery
• Expanded federation with peer PDS discovery for cross-server community visibility
• Governance integrations for communities that want on-chain or structured decision-making

The core commitment remains the same: communities should own their identity, control their data, and be free to leave any hosting provider at any time. Everything else is built on top of that principle.