open::federation
← All updates
update 2026-03-28

OpenFederation Whitepaper: A Personal Data Server & Federated Identity System

OpenFederation

Personal Data Server & Federated Identity System

White Paper

Version 3.0 - March 2026

Architecture, Identity, Governance, Deployment & Cross-Network Interoperability

Executive Summary

OpenFederation is a decentralised community platform built on the AT Protocol. It provides every community with a self-sovereign, portable identity -- stored on a Personal Data Server (PDS) it controls -- together with structured membership, custom roles with granular permissions, verifiable attestations, cross-network identity bridging, and a modular governance layer.

The system is designed around three principles: portability (a community may migrate its entire dataset to any compatible PDS without permission from the incumbent host), verifiability (every record is cryptographically signed and stored in a Merkle Search Tree, making the full history independently auditable), and modularity (governance is decoupled from identity and can be upgraded -- from simple admin control to community voting to on-chain governance -- without touching the underlying data model).

This white paper covers the full technical stack: identity layer, data schemas, repository structure, application architecture, governance modes, security model, deployment options, cross-network interoperability, and the operational procedures communities need to maintain control of their data.

1. Introduction

1.1 The Problem

Traditional community platforms centralise identity and data. A community's membership list, roles, and history are held by the platform provider, which can restrict access, export data in proprietary formats, or shut down service without warning. There is no portable, machine-verifiable record of a community's existence that the community itself controls.

1.2 The Solution

OpenFederation gives each community a dedicated repository -- hosted on a PDS that the community chooses -- and a Decentralised Identifier (DID) that anchors its cryptographic identity. Because both the DID and the data repository are portable, the community can move to a different PDS at any time, preserving its entire history.

1.3 AT Protocol Foundation

The system is built on the AT Protocol (Authenticated Transfer Protocol), an open standard originally developed for the Bluesky social network. AT Protocol provides:

  • A content-addressed, Merkle-tree repository format (CAR / blockstore)
  • Standardised XRPC API methods for reading and writing records
  • Two well-specified DID methods: did:plc and did:web
  • A Lexicon schema system for defining custom record types under namespaced identifiers

OpenFederation extends AT Protocol with community-specific Lexicon schemas under the net.openfederation namespace, adds governance gating logic, and wraps everything in a deployment-ready server implementation.

2. Identity Layer

2.1 DID Method Selection

At the moment of community creation, the founding member selects one of two Decentralised Identifier methods. This choice is permanent for the life of the DID, though the PDS hosting the community's data can be changed at any time regardless of the method chosen.

| Aspect | did:plc (Default) | did:web (Optional) |
|--------|-------------------|-------------------|
| Identifier format | Cryptographic hash (e.g. did:plc:z72i7hdynmk6r22z27h6tvur) | Domain name (e.g. did:web:manutd.com) |
| Control mechanism | Rotation keys held by community | Domain name ownership |
| PDS portability | Fully portable; DID is permanent | Fully portable; DID is tied to domain |
| Trust model | Cryptography + PLC directory | DNS + domain owner security |
| Recovery options | OpenFederation secondary key (optional) | Community manages domain & server |
| Best suited for | New communities, maximum decentralisation | Established brands with strong domain control |

2.2 did:plc -- Cryptographic Identity

A did:plc identifier is derived from a cryptographic hash of its genesis operation. It is not tied to any domain or service, making it the most resilient option for long-term community identity.

Control of the DID is exercised through rotation keys. OpenFederation implements a hybrid key model with two tiers:

Primary Rotation Key (Community Control)

Generated during community creation and returned to the community. OpenFederation does not retain a copy. Possession of this key grants full, unilateral authority to migrate the PDS, update verification methods, or rotate to a new key set.

Secondary Rotation Key (OpenFederation Recovery)

OpenFederation holds a lower-priority secondary rotation key whose sole purpose is to assist in account recovery when a community has lost its primary key. The trust boundary is made explicit: the cryptographic protocol enforces ownership; OpenFederation enforces reduced misuse risk through operational controls:

  • Multi-party approval for rotation operations (2-of-3 or equivalent)
  • Hardware-backed key custody (HSM / KMS) with strict access policies
  • Immutable audit logs and rotation event transparency
  • Documented recovery ceremonies requiring explicit community consent

2.3 did:web -- Domain-Based Identity

A did:web identifier uses a domain name already controlled by the community. The DID document is hosted at a well-known URI on the community's web server:

https://manutd.com/.well-known/did.json

OpenFederation holds no keys for did:web communities and has no control over the identity. Migration is straightforward: update the atproto_pds service endpoint in the did.json file to point at the new PDS. The tradeoff is that the identity's security inherits whatever protections the community applies to its DNS and web infrastructure.

3. Data Model

3.1 Lexicon Namespaces

All community records are defined under the net.openfederation namespace, preventing conflicts with core AT Protocol schemas or future protocol extensions. Each record type maps to an XRPC-queryable collection within the community's repository.

| NSID | Purpose | Key Type | Cardinality |
|------|---------|----------|-------------|
| net.openfederation.community.profile | Public profile, display name, avatar, website | self | 1 per community |
| net.openfederation.community.settings | DID method, governance model, governance config | self | 1 per community |
| net.openfederation.community.member | Membership record binding a user DID to a role | tid | 1 per member |
| net.openfederation.community.role | Named role with associated permissions array | tid | 1 per role |
| net.openfederation.community.attestation | Verifiable claim about a member or community | tid | Variable |
| net.openfederation.community.proposal | Governance proposal for protected collection changes | tid | Variable |
| net.openfederation.community.delegation | Vote delegation record (proxy voting) | tid | 1 per delegator |
| net.openfederation.identity.externalKey | Cross-network identity key (Ed25519, X25519, etc.) | user-chosen | Variable |

3.2 Record Key Strategy

The choice of record key determines storage consistency and protocol compatibility. OpenFederation uses three key types:

self -- Singleton Records

Used for profile and settings collections. Exactly one record can exist under this key. Writes to an existing self record replace it in the repository commit graph.

tid -- Timestamp Identifier

Used for member, role, attestation, proposal, and delegation collections. A TID is timestamp-based, guarantees uniqueness, maintains chronological ordering, and avoids encoding issues that would occur if DIDs were used directly as keys.

user-chosen -- External Key Identifiers

Used for the identity.externalKey collection. Users choose meaningful identifiers like meshtastic-relay-1 or nostr-primary. Must be 1-512 characters, alphanumeric with hyphens.

3.3 Core Schema Highlights

Profile

Contains displayName (required, max 64 chars), optional description (max 256 chars), blob fields for avatar (max 1 MB) and banner (max 3 MB), an optional website URI, and a createdAt timestamp.

Member

Links a member DID (did format) to a role reference (the rkey / tid of a role record), with a joinedAt timestamp. The roleRkey field is a reference rather than an embedded object, ensuring that role metadata is updated in one place.

Role

Defines a named role with an optional description and a permissions array of strings. Permissions follow the pattern community.<collection-short>.<action> (e.g., community.attestation.write, community.member.delete). The owner role is a regular role record with all permissions; it cannot have community.role.write or community.settings.write removed (lockout protection). Default roles (owner, moderator, member) are created during community creation. Communities can create custom roles with arbitrary permission sets.

Attestation

A verifiable claim with a subject DID, a type string (membership, role, or credential), an untyped claim object, an issuedAt timestamp, and an optional expiresAt timestamp. Revocation is performed by deleting the attestation record. The signed MST deletion commit serves as cryptographic proof of revocation. The audit log captures who revoked the attestation, when, and the reason.

Settings

Stores the immutable didMethod selection (plc or web) and the mutable governanceModel (benevolent-dictator, simple-majority, or on-chain), plus a governanceConfig object for model-specific parameters such as quorum, voter role, proposal TTL, protected collections list, and blockchain contract address.

Proposal

A governance proposal targeting a protected collection. Contains the target collection and rkey, the proposed action (write or delete), the proposed record content, the proposer's DID, vote arrays (votesFor, votesAgainst), status (open, approved, rejected, expired), timestamps, and an amendments array preserving the full amendment history.

External Key

An auxiliary cryptographic public key for cross-network identity bridging. Contains a key type (ed25519, x25519, secp256k1, p256), a purpose string (meshtastic, nostr, wireguard, ssh, device, etc.), the public key in did:key multibase format, and an optional human-readable label. Trust derives from the ATProto repo signing chain -- no cross-algorithm signatures needed.

4. Repository Structure

4.1 AT Protocol Repository Semantics

A community's entire dataset lives in a single AT Protocol repository, identified by its DID. The repository is an append-only Merkle Search Tree (MST) persisted as content-addressed blocks (CAR / blockstore format). SQL indexes may be maintained for fast lookup, but they are derived views; the blockstore is the authoritative source of truth.

Because the repository is content-addressed and every commit is deterministically derived from its contents, the full history is independently verifiable by any party holding the CAR file. This makes the data truly portable: importing a CAR file into a new PDS produces bit-identical blocks.

4.2 Collection Layout

Records are addressed using the path format <collection_nsid>/<record_key>. A representative repository looks like this:

/net.openfederation.community.profile/self
/net.openfederation.community.settings/self
/net.openfederation.community.role/3k-abc-123...
/net.openfederation.community.role/3k-def-456...
/net.openfederation.community.member/3k-ghi-789...
/net.openfederation.community.member/3k-jkl-012...
/net.openfederation.community.attestation/3k-pqr-678...
/net.openfederation.community.proposal/3k-stu-901...
/net.openfederation.community.delegation/3k-vwx-234...

4.3 Append-Only Discipline

Direct record deletion is used only for revocation (attestations) and cleanup operations. The preferred patterns are:

  • Revocation: delete the attestation record. The signed MST commit is cryptographic proof of revocation. The audit log preserves the reason.
  • Role changes: update the member record's roleRkey reference to point to a different role record.
  • Settings changes: overwrite the self-keyed settings record (replacement is the intended use for singleton records).

Governance layers additionally restrict which actors can write to protected collections, enforcing that changes only happen via the approved path (e.g., proposal voting in simple-majority mode, or the Oracle service in on-chain governance mode).

5. Technical Architecture

5.1 Component Overview

The OpenFederation PDS is a specialised AT Protocol implementation composed of four primary layers:

| Component | Responsibility |
|-----------|---------------|
| XRPC Server | Public-facing API endpoint exposing standard com.atproto.* methods and all net.openfederation.* custom methods (70+ endpoints) |
| Repository Engine | Manages the community's MST, signs commits, persists blockstore, maintains SQL indexes for fast lookup |
| Identity Manager | Handles DID creation ceremonies, hybrid key storage for did:plc, guided setup instructions for did:web |
| Blob Store | Stores binary assets (avatars, banners) referenced by profile records. Dual-backend: local filesystem or S3-compatible storage |

5.2 Identity Manager -- Dual DID Support

The Identity Manager is the component most significantly extended from a stock AT Protocol PDS. For did:plc communities it orchestrates the key generation ceremony, stores the secondary recovery key in encrypted form (AES-256-GCM), and returns the primary rotation key to the community. For did:web communities it generates the required did.json document and provides DNS configuration instructions -- but holds no keys at all.

5.3 Application Layer

Applications interact with the PDS exclusively through XRPC calls. Multiple clients are provided:

Web Dashboard (Admin UI)

A Next.js 15 application (shadcn/ui, React Query v5, Zustand, kbar) that gives administrators a graphical interface for community management, user approval, invite generation, audit log inspection, and moderation actions.

Command-Line Interface (ofc)

A comprehensive CLI with 65+ commands covering authentication, server management, community operations, attestations, external identity keys, roles, governance proposals/voting, profiles, partner keys, and audit logs. Supports both human-readable and JSON output for scripting.

JavaScript SDK (@openfederation/sdk)

A zero-dependency browser library (2.5KB gzipped) for third-party application integration. Supports registration, login, session management, auto-refresh tokens, and ATProto OAuth redirect. Available as an IIFE bundle served by the PDS at /sdk/v1.js and via npm.

Federated Service Bridges

External services such as Matrix can be integrated through a bridge service that polls the PDS for membership changes and updates their internal permission systems accordingly. A reference Matrix bridge implementation (bridges/matrix/) supports three deployment modes:

  • Public Matrix: Users link existing Matrix IDs via their PDS profile
  • Self-hosted: Bridge auto-provisions Matrix accounts from PDS handles via the homeserver admin API
  • Partner-hosted: A partner operates Matrix infrastructure for multiple communities, eliminating per-community ops burden

The bridge syncs membership and roles (mapped to Matrix power levels) from the PDS to Matrix Spaces. Channel structure and per-channel permissions remain Matrix-native. One-way sync: PDS is source of truth.

Cross-Network Identity Bridge

The net.openfederation.identity.externalKey collection enables cross-network identity bridging without any AT Protocol changes. Users store auxiliary cryptographic public keys in their ATProto repo (Ed25519, X25519, secp256k1, P256 in did:key multibase format). External systems read these keys to derive network-specific identities:

  • Meshtastic: SHA-256(Ed25519_pubkey)[:16] mesh identity hash
  • Nostr: secp256k1 key converted to npub
  • WireGuard: X25519 peer public key for tunnel config
  • SSH: Ed25519 authorized key
  • Hardware devices: device attestation and authentication

A reverse-lookup endpoint (resolveByKey) allows bridge services to resolve any external public key back to its ATProto identity.

5.4 Governance Layer

The governance layer is entirely optional and defined by the governanceModel field in the community settings record. Three models are supported:

| Model | Write Authority | Trust Placed In | Upgrade Path |
|-------|----------------|-----------------|-------------|
| benevolent-dictator (default) | Permission-based (role permissions determine who can write) | Community admin(s) | Can upgrade to simple-majority or on-chain at any time |
| simple-majority | Proposals require majority vote from designated voter-role members | Community process | Can upgrade to on-chain |
| on-chain | Oracle service relaying results of smart-contract votes | Smart contract logic and blockchain consensus | Irreversible without community vote |

Governance enforcement intercepts all writes to protected collections. Protected collections are configurable per-community via governanceConfig.protectedCollections. Default: settings, role, member, profile, attestation. community.settings and community.role are always protected (cannot be removed) to prevent governance bypass.

In simple-majority mode:

  • Any member with the community.governance.write permission can create proposals targeting protected collections
  • The proposer auto-casts a "for" vote. Other voter-role members vote for or against
  • When the vote count reaches the configured quorum and a majority exists, the proposed change is automatically applied to the community repo via a signed MST commit
  • Proposals can be amended (resets votes, extends expiration, preserves full amendment history)
  • Vote delegation (proxy voting) is supported: members can delegate their vote to another voter-role member. Direct votes override delegations

5.5 On-Chain Governance Data Flow

When governanceModel is set to on-chain, the PDS enforces a protected-collections write policy. The flow is:

  1. Community members cast votes on a blockchain smart contract
  2. The contract emits an event on successful vote resolution
  3. An Oracle service listens for these events
  4. The Oracle authenticates to the PDS and submits an XRPC call with a governance proof / receipt
  5. The PDS validates the receipt and commits the change to the repository

Direct writes from any actor other than the Oracle are rejected for protected collections.

Implementation status: The PDS-side enforcement is fully implemented. The on-chain mode blocks all direct writes to protected collections and returns a GovernanceRequired error. The Oracle service, smart contract specification, and blockchain integration are not yet built.

6. Security Model

6.1 Authentication and Session Management

The PDS issues short-lived JWT access tokens with configurable TTL and longer-lived refresh tokens. Refresh token rotation is implemented with reuse detection: presenting a previously-rotated refresh token invalidates the entire session, providing protection against token theft.

ATProto OAuth 2.0 is supported as an authorization server (PAR, DPoP, PKCE) and as a client for "Sign in with ATProto" external user login.

6.2 Key Management at Rest

Recovery keys and signing keys are encrypted at rest using AES-256-GCM, keyed with the KEY_ENCRYPTION_SECRET environment variable. The primary rotation key for did:plc communities is returned to the community at creation time and never stored by the server thereafter. Communities are solely responsible for backing up this key.

6.3 Account and Community Lifecycle

All registration, approval, moderation, and security-relevant actions are written to an immutable audit log. The account status lifecycle provides seven states: pending, approved, rejected, disabled, suspended, takendown, and deactivated. The AT Protocol composable moderation model is implemented with two community states: suspended (reversible, community data remains readable by the owner for export) and taken-down (requires a prior export to have been performed).

6.4 Password and Handle Policy

Passwords must be 10-128 characters and satisfy at least three of four complexity categories (lowercase, uppercase, digit, special character). Handles must be 3-30 characters consisting of lowercase letters, numbers, and hyphens, with no leading or trailing hyphens and no consecutive hyphens. A reserved-names list blocks handles such as admin, root, and system.

6.5 Rate Limiting

| Scope | Limit |
|-------|-------|
| Global | 120 requests / minute per IP |
| Authentication | 20 attempts per 15 minutes per IP |
| Registration | 5 per hour per IP |
| Community creation | 10 per hour per IP |
| Discovery (public read endpoints) | 60 per minute per IP |

6.6 AT Protocol 'Free to Go' Principle

The PDS enforces the AT Protocol portability guarantee. Community owners can always export their full repository as a CAR archive via com.atproto.sync.getRepo or net.openfederation.community.export. Suspended communities remain readable for export. Takedown requires a prior export to have been performed. The transfer endpoint generates a migration package with instructions for updating the DID document to point at the destination PDS.

Automated scheduled exports with configurable intervals (daily/weekly/monthly) and retention policies are supported via the export scheduler. Snapshots are stored in blob storage (local or S3) with integrity verification.

7. Migration and Portability

7.1 Exporting a Community

Any community owner or admin can request a full export at any time using the net.openfederation.community.export endpoint (or the standard com.atproto.sync.getRepo method). The result is a CAR file containing every block in the repository's commit graph -- a complete, self-contained, verifiable snapshot of the community's data.

7.2 Migrating to a New PDS

The migration process is four steps, independent of the DID method:

  1. Export the repository from the current PDS as a CAR file
  2. Import the CAR file into the destination PDS via net.openfederation.admin.importRepo
  3. Update the DID document's atproto_pds service endpoint: - For did:plc: sign a PLC update operation with the primary rotation key - For did:web: edit the did.json file on the community's domain server
  4. Verify that the DID now resolves to the new PDS

7.3 PDS Failure Recovery

If the current PDS becomes unreachable, the community DID continues to exist and may still resolve (particularly for did:plc). Recovery requires:

  • A previously exported CAR snapshot (communities should export regularly, or use the automated export scheduler)
  • Control of the primary rotation key (or engagement of the OpenFederation recovery process for secondary-key-assisted recovery in the did:plc case)

The destination PDS must support both com.atproto.sync.getRepo for export and the net.openfederation.admin.importRepo endpoint for restoring a repository from a CAR file.

8. API Reference

All endpoints are XRPC methods served at /xrpc/{nsid}. Formal Lexicon definitions are in src/lexicon/. The table below lists the major endpoint groups.

| Group | Key Methods | Auth Required |
|-------|-------------|---------------|
| AT Protocol Sessions | createSession, refreshSession, getSession, deleteSession | No (create/get), Yes (others) |
| Account Management | register, listPending, list, approve, reject, updateRoles, changePassword, export | None (register); Admin / Mod (management) |
| Invite Codes | invite.create, invite.list | Admin / Mod |
| Community -- Core | create, get, listAll, listMine, update, delete | Approved user or Owner |
| Community -- Membership | join, leave, listMembers, listJoinRequests, resolveJoinRequest, removeMember, updateMemberRole | Approved user or Member |
| Community -- Roles | createRole, updateRole, deleteRole, listRoles | Owner (write); Public (read) |
| Community -- Attestations | issueAttestation, deleteAttestation, listAttestations, verifyAttestation | Owner/Mod (write); Public (read, supports remote PDS) |
| Community -- Governance | setGovernanceModel, createProposal, amendProposal, voteOnProposal, listProposals, getProposal | Owner (model); Voter role (proposals) |
| Community -- Delegation | setDelegation, revokeDelegation, getDelegation | Voter role (write); Public (read) |
| Community -- Moderation | suspend, unsuspend, takedown | PDS Admin |
| Community -- Portability | export, transfer | Owner / Admin |
| Identity Bridge | setExternalKey, listExternalKeys, getExternalKey, deleteExternalKey, resolveByKey | Yes (write); Public (read) |
| User Profiles | updateProfile, getProfile | Yes (write); Public (read) |
| Partner API | partner.register, partner.createKey, partner.listKeys, partner.revokeKey | X-Partner-Key (register); Admin (key management) |
| Repository Operations | getRecord, putRecord, createRecord, deleteRecord, describeRepo, listRecords, uploadBlob | Varies |
| Federation | sync.getRepo, admin.importRepo | Public (export); Admin (import) |
| Export Scheduler | admin.createExportSchedule, listExportSchedules, deleteExportSchedule, listExportSnapshots | PDS Admin |
| Administration | audit.list, server.getConfig | PDS Admin |

8.1 Example: Create a Community

curl -X POST http://localhost:8080/xrpc/net.openfederation.community.create \
  -H "Authorization: Bearer <accessJwt>" \
  -H "Content-Type: application/json" \
  -d '{"handle":"my-community","didMethod":"plc","displayName":"My Community"}'

8.2 Example: Export a Community

curl "http://localhost:8080/xrpc/com.atproto.sync.getRepo?did=did:plc:abc123" \
  -H "Authorization: Bearer <accessJwt>" \
  --output community.car

9. Deployment

9.1 Prerequisites

The PDS requires Node.js 18+ and PostgreSQL 15+. It is not suitable for serverless platforms (Vercel, Netlify Functions) because it requires persistent database connections and long-running processes. Recommended hosting options are Railway, Render, Fly.io, or any VPS / containerised environment.

9.2 Required Environment Variables

| Variable | Required In | Description |
|----------|------------|-------------|
| AUTH_JWT_SECRET | Production | Random string, minimum 32 characters. Server refuses to start without it. |
| KEY_ENCRYPTION_SECRET | Production | Encrypts recovery / signing keys at rest. Must be set before creating communities. |
| DB_HOST / DB_PORT / DB_NAME / DB_USER / DB_PASSWORD | All | PostgreSQL connection parameters. |
| DB_SSL | Production | Set to true to enable SSL connections to PostgreSQL. |
| CORS_ORIGINS | Production | Web UI URL (e.g. https://your-web-ui.up.railway.app). |
| PDS_HOSTNAME / PDS_SERVICE_URL | All | Publicly reachable hostname and full HTTPS URL of the PDS. |
| INVITE_REQUIRED | All | true (default) enforces invite-only registration. |
| BOOTSTRAP_ADMIN_EMAIL / HANDLE / PASSWORD | First run | Creates an admin account on startup; remove after verified. |
| BLOB_STORAGE | All | `local` (default) or `s3` for S3-compatible storage. |
| BLOB_S3_BUCKET / BLOB_S3_REGION / BLOB_S3_ENDPOINT | If s3 | S3 bucket configuration. |
| EXPORT_SCHEDULER_ENABLED | Production | Set to `true` to enable automated community backups. |

9.3 Docker Compose Quick Start

The recommended path for self-hosted deployment is Docker Compose with two services: postgres (postgres:15-alpine) and pds (node:22-alpine). The schema is initialised from src/db/schema.sql at first boot.

9.4 Railway Deployment

For faster deployment, we recommend Railway for managed deployment targets. The project deploys as three services from the same repository: the PDS API (Express.js, root directory), the Web UI (Next.js, web-interface/ directory), and the PLC Directory. Railway handles TLS termination and port assignment automatically. Full instructions are in RAILWAY.md.

9.5 Production Checklist

  • Set strong DB_PASSWORD (Railway auto-generates)
  • Set AUTH_JWT_SECRET and KEY_ENCRYPTION_SECRET (64-character random hex each)
  • Configure PDS_HOSTNAME, PDS_SERVICE_URL, and CORS_ORIGINS
  • Initialise database schema (npm run db:init or scripts/init-db.sh)
  • Configure bootstrap admin and verify login
  • Set up SSL / TLS (Railway provides free SSL)
  • Configure PostgreSQL backups
  • Enable export scheduler for automated community backups
  • Set up monitoring and alerting
  • Remove BOOTSTRAP_ADMIN_* variables after first login

9.6 Health Check

After deployment, verify the application is running with GET /health. A healthy response includes status: ok and database: connected with a UTC timestamp.

10. Implementation Status

Phase 1 -- Core PDS & DID Choice: COMPLETE

Community creation with did:plc / did:web selection, secure key generation and storage, guided did:web setup, real MST repository engine, ATProto repo endpoints, CAR export/import, blob storage (local + S3), Docker Compose, auto-schema migration, PLC directory service, partner registration API, JavaScript SDK, Web Dashboard, CLI.

Phase 2 -- Governance Layer: COMPLETE (except on-chain)

Custom roles with 12 granular permissions, permission-based authorization guards, governance enforcement with configurable per-collection protection, benevolent-dictator mode, simple-majority mode with proposals/voting/auto-commit, proposal amendments with history, vote delegation (proxy voting), governance model switching. On-chain mode enforcement is built (PDS rejects writes), but Oracle service and smart contract infrastructure are deferred.

Phase 3 -- Federation & Interoperability: MOSTLY COMPLETE

Cross-PDS attestation verification with remote DID resolution. Cross-network identity bridge for Meshtastic, Nostr, WireGuard, SSH, and hardware devices. Reference Matrix bridge with three deployment modes (public, self-hosted, partner-hosted). ActivityPub identity layer with nodeinfo and actor endpoints. Lexicon schema publication pending schema stabilisation.

Phase 4 -- Ecosystem & Tooling: COMPLETE

Comprehensive CLI (65+ commands across 12 command groups). Scheduled snapshot exports with configurable intervals and retention policies. JavaScript SDK with full documentation. Partner API for third-party integration.

Remaining

  • On-chain governance: Oracle service, smart contract specification, blockchain integration
  • Lexicon schema public registry
  • Full cryptographic verification of remote repo CAR imports (currently trusts remote PDS getRecord responses)

11. Conclusion

OpenFederation provides a complete, production-ready foundation for community identity that is portable by design, verifiable by any third party, and incrementally governable without migration penalties. Communities start with a simple administrative model and graduate to community voting or decentralised on-chain governance as their needs evolve -- all without changing their DID or moving their data unless they choose to.

By building on the AT Protocol's open standards, OpenFederation ensures long-term compatibility with the broader federated ecosystem and avoids platform lock-in at every level of the stack. The hybrid key model for did:plc gives communities true ownership of their identity while preserving a recovery path -- a balance that pure self-sovereign systems typically sacrifice for the sake of decentralisation.

The cross-network identity bridge enables communities to span multiple protocols -- ATProto for identity, Matrix for communication, Meshtastic for mesh networking, Nostr for announcements -- all anchored to a single, verifiable cryptographic identity. This is not protocol convergence; it is protocol coexistence with a shared identity layer.

The result is a system in which communities own their data, control their governance, bridge their identities across networks, and retain the right to leave -- unconditionally.

2026 OpenFederation - Version 3.0

Follow the work

Occasional, meaningful updates only.