Are we federated yet?

What works today

Federation lets independently operated services exchange data. Email is a familiar example. This guide also covers related open tools.

Editorial assessments for twelve activities. Select an activity to read its approaches and limitations.
Activity	Grade	The practical picture
Publishing	A	Feeds connect independent publishers and readers.
Community chat	A−	Established networks; client features and migration vary.
Public social	A−	Public conversation works; discovery and exit depend on the app.
Email	B	Provider choice is established. Delivery and migration take care.
Private messaging	B	Encrypted options exist; compatibility needs checking.
Forums & events	B	Communities can connect; not every action travels.
Media hosting	B−	Independent video, audio, and photos need hosting resources.
Files & calendars	B−	Sync and sharing work; moving a whole workspace is harder.
Calls & meetings	C+	Open components exist; complete meeting workflows differ.
Identity	C+	Institutional federation is established; personal portability varies.
Code collaboration	C	Useful alternatives; collaboration across forges is still limited.
Discovery	D	Search, addressing, and bridges solve only parts of the problem.

Grades assess practical adoption within each category. They are editorial judgments, not measured scores or protocol rankings. How we assess them

How we assess these categories

Reading the guide

You already do this

An email address at one provider can contact an address at another. Other systems connect conversations, publications, files, or institutional services. Their rules for participation differ.

A useful exit needs more than an export

A move can preserve an address without preserving messages, permissions, or contacts. Domain control helps some services. Each application needs its own migration and recovery plan.

Grades describe a use case

Grades reflect available applications, adoption effort, and the limits of replacing the listed services. They do not measure protocol quality, privacy, or operator independence.

The grade scale — per category

A: Established alternatives for this activity, with practical hosted or client-based adoption.
B: Useful deployed alternatives, with significant limits in features, compatibility, or migration.
C: Useful components or narrower deployments. Replacing the full workflow requires substantial compromises.
D: Tools address parts of the activity. A broadly useful replacement remains incomplete.

Maturity tier — per approach

Ready: Established deployment and specifications, with supported implementations for the stated task.
Usable: Deployed and useful. Results depend on the selected applications, providers, and features.
Emerging: Draft, alpha, or experimental capabilities that need evaluation before routine use.

Starting effort — per approach

Effort describes the starting task on each card. Estimates are qualitative, not measured. Hosted adoption usually takes less work than independent operation. Running a service also requires updates, backups, support, and abuse handling.

Each card links to a primary source. The September 2026 research snapshot guides this assessment. Application support can differ from specification status.

Explore the approaches

ACategory grade

Publishing

Can I publish and be subscribed to?

Alternatives for Substack, Medium, Spotify podcasts

Feeds connect independent publishers and readers.

A website on a controlled domain provides a foundation for independent publishing. Feeds connect publishers to independent readers. Social protocols can add conversation and discovery.

Directories, paid access, recommendations, and analytics can remain specific to a platform. Moving a feed does not automatically move subscriptions or payment relationships.

Web feeds

Syndication from your own domain

Maturity: ready

Independent publications and subscriptions without a shared social account.

Limit: WebSub hubs support push delivery and introduce a service dependency. Feeds alone do not supply shared replies, moderation, or a social graph.

Start hereStarting effort: minutes

Install a reader that accepts feed URLs. Subscribe to a publication that you already read.

Technical details & sources

RSS and Atom let readers subscribe directly to a publication. WebSub adds push delivery. These mechanisms distribute entries without defining a shared social network.

Specification: RSS 2.0. Atom (RFC 4287). WebSub for push, a W3C Recommendation updated 2 June 2026
Publishing: WordPress, Ghost, Hugo, Eleventy, Jekyll, or a hand-written file
Readers: NetNewsWire, Feedbin, Miniflux, FreshRSS, Reeder
Stewardship: RSS Advisory Board. IETF for Atom. W3C for WebSub
Social layer: Syndication only. Shared replies, moderation, and ranking require other protocols or applications.
Moving out: Feed redirects can preserve subscriptions. OPML transfers subscription lists, but reading state depends on the application.
Operating needs: A simple feed needs little infrastructure. Push delivery adds a hub dependency.

Open podcasting

Feeds decoupled from listening apps

Maturity: ready

Audio publishing with a choice of hosts and listening applications.

Limit: Discovery, premium access, recommendations, and analytics can depend on platforms. Support for podcast extensions varies between hosts and applications.

Start hereStarting effort: minutes

Use a podcast app that accepts feed URLs. For publishing, choose a host with feed export and redirect support.

Technical details & sources

A podcast feed describes episodes and links to media. Listeners can choose an application independently of the publisher’s host. Extensions add optional features.

Specification: RSS plus the Podcasting 2.0 namespace, with defined stages for proposed and formalised tags
Hosting: A publisher-controlled feed and reachable media hosting
Apps: AntennaPod, Podverse, Fountain, Pocket Casts, Apple Podcasts
Stewardship: The Podcast Index community governs the namespace
Discovery: Podcast Index as an open directory alongside closed ones
Moving out: Feed redirects can preserve distribution. Paid subscriptions, payment relationships, and listening state need separate migration.
Operating needs: The publisher needs feed hosting and media delivery. Directories and paid access add separate service requirements.

IndieWeb

Interactions between independent sites

Maturity: usable

A personal or organizational website with independent publishing clients and responses from other sites.

Limit: Each standard covers a limited task. Discovery, moderation, hosting, and compatibility still depend on the selected tools.

Start hereStarting effort: an evening

Choose a website with Webmention or Micropub support. Add a feed for subscriptions.

Technical details & sources

Webmention notifies a site about a link to its content. Micropub lets clients create and edit posts. Feeds can supply subscriptions alongside these interactions.

Specification: Webmention and Micropub (both W3C Recommendations). IndieAuth for sign-in
Publishing: WordPress plugins, Micro.blog, Kirby, static-site setups
Clients: Compatible Micropub clients and website interfaces
Stewardship: IndieWeb community, with W3C Recommendations for Webmention and Micropub
Federation bridge: WordPress ActivityPub exposes blog and author actors. Ghost documents social-web distribution as Beta at the research cutoff.
Moving out: Domain control preserves addresses. Content and application state still need export and migration support.
Operating needs: The publisher maintains the site and selected endpoints. Incoming interactions also need moderation.

A−Category grade

Community chat

Can my community chat somewhere else?

Replacing Slack, Discord, Teams

Established networks; client features and migration vary.

Matrix replicates room events across participating homeservers. XMPP routes messages between domains. IRC links servers within a cooperating network. All three support established communities.

Replicated history does not establish account portability. Migration also needs identity, memberships, media, and encryption material. Support differs between applications.

Matrix

Replicated room state across homeservers

Maturity: ready

Persistent community or organizational rooms across administrative domains.

Limit: Independent server implementations differ in maturity, licenses, and features. Specification support does not guarantee interchangeable deployments.

Start hereStarting effort: an evening

Choose a hosted homeserver. Before inviting a group, check its client support, moderation policy, and recovery instructions.

Technical details & sources

Matrix replicates room events across participating homeservers. Servers reconcile room state rather than depending on one room host. User accounts still belong to homeservers.

Specification: Matrix v1.19, released 8 July 2026. Deployed client and server support needs separate checks.
Servers: Synapse (reference, Python). Continuwuity and Tuwunel (independent Rust servers)
Clients: Element, FluffyChat, Nheko, Cinny, NeoChat
Stewardship: The Matrix.org Foundation stewards the specification. Its elected Governing Board has an advisory role.
Encryption: Encrypted rooms use Olm/Megolm. Defaults and support depend on the client, room, and integration.
Moving out: Room replication does not move accounts. Recovery after server loss depends on surviving servers, devices, and keys.
Operating needs: Homeservers manage room state, history, media, synchronization, and upgrades. Public services also need continuing abuse handling.

XMPP

Inter-domain XML stanza routing

Maturity: ready

Messaging with a selected set of compatible extensions and clients.

Limit: The supported XEPs and their versions determine compatibility. A general claim of XMPP support does not establish a complete messaging experience.

Start hereStarting effort: an evening

Choose a provider and clients with a compatible feature profile. Check group chat, file transfer, and encryption support.

Technical details & sources

XMPP routes messages and presence between domains. Extensions add group chat and other features. Traditional group rooms depend on a room service.

Specification: IETF core RFCs 6120 and 6121, with XSF extensions for additional features
Servers: Prosody, ejabberd, Openfire, Tigase, Snikket (packaged deployment)
Clients: Conversations, Gajim, Dino, Monal, Movim
Stewardship: IETF core standards and the XMPP Standards Foundation. The reviewed compliance page identifies the 2023 suite.
Encryption: OMEMO (XEP-0384), version 0.9.1 dated 6 April 2026 — still labelled Experimental
Moving out: Account migration and data export depend on implementation support
Operating needs: Server requirements depend on the chosen extensions. Mobile delivery, history, files, and encryption need compatible client and server support.

IRC

Linked servers forming a named network

Maturity: ready

Lightweight text communities on an established IRC network.

Limit: Separate IRC networks do not automatically interoperate. Linking a server normally requires agreement from the network operators.

Start hereStarting effort: minutes

Join an existing IRC network through its recommended browser or desktop client.

Technical details & sources

IRC links cooperating servers into a named network. IRCv3 extends client behavior. Separate networks do not share a universal account or channel namespace.

Specification: Modern IRC documentation. IRCv3 adds SASL, message tags and history
Servers: Solanum, InspIRCd, UnrealIRCd, ergo
Clients: Halloy, Senpai, WeeChat, irssi, The Lounge
Stewardship: IRCv3 develops client extensions. Individual networks govern their server links.
Encryption: TLS protects connections to servers. Baseline IRC has no interoperable end-to-end encryption.
Moving out: Nicknames, accounts, and channels belong to a network. Another network does not automatically preserve them.
Operating needs: Running a server and joining a network are separate tasks. Server links require operator agreement, and retained history needs additional services.

BCategory grade

Can I leave a hosted mailbox behind?

Replacing Gmail, Outlook, hosted Exchange

Provider choice is established. Delivery and migration take care.

Email connects independently administered domains through open standards. Mail transfer, mailbox access, and domain authentication serve different purposes. Users can choose hosted providers or independent operation.

Protocol support does not guarantee inbox delivery. Receiver policies and reputation affect delivery. End-to-end encryption also requires compatible clients and key management.

Internet email

Store-and-forward mail between domains

Maturity: ready

Asynchronous correspondence and mailing lists across independent providers.

Limit: Reliable independent delivery requires DNS, authentication, reputation management, and continuing operations. Hosted use transfers much of this work to the provider.

Start hereStarting effort: an hour

Choose a hosted provider that supports your own domain. Plan a mailbox export and a future provider change.

Technical details & sources

SMTP transfers mail between domains. IMAP and JMAP provide mailbox access. A controlled domain can preserve addresses through a hosting change.

Protocol: SMTP transfer (RFC 5321). IMAP4rev2 (RFC 9051) and JMAP (RFC 8620) for mailbox access
Servers: Mail transfer and mailbox software include Postfix, Exim, Stalwart, Maddy, Cyrus, and Dovecot
Clients: Thunderbird, K-9 Mail, Apple Mail, Evolution, hundreds more
Stewardship: IETF specifications, independent domain operators, and receiver delivery policies
Authentication: SPF authorizes senders. DKIM signs messages for a domain. DMARC (RFC 9989) evaluates alignment and publishes policy.
Encryption: MTA-STS and DANE protect supported transport paths. OpenPGP and S/MIME provide content encryption with separate key-management requirements.
Moving out: Domain control preserves addresses during a provider change. Messages and provider-specific settings require migration.
Operating needs: Reliable public delivery needs authentication, DNS, reputation, spam handling, monitoring, and incident response. A managed provider absorbs much of this work.

BCategory grade

Private messaging

Can private messaging cross services?

Replacing WhatsApp, iMessage, Messenger

Encrypted options exist; compatibility needs checking.

Matrix and XMPP support encrypted conversations across compatible servers. MLS supplies group cryptography. MIMI drafts address additional layers for messaging between services.

Shared cryptography does not make applications interoperable. A bridge that decrypts messages becomes an endpoint with access to their contents.

Matrix encrypted rooms

E2EE over federated homeservers

Maturity: usable

Private conversations across homeservers with compatible Matrix clients.

Limit: Encryption depends on the room and integration. A working account alone does not guarantee access to encrypted history after device loss.

Start hereStarting effort: an evening

Choose compatible clients. Check device identities through the client instructions. Store the recovery material securely.

Technical details & sources

Encrypted Matrix rooms combine Olm/Megolm with device keys, verification, and key backup. Content protection does not hide all room metadata from participating servers.

Cryptography: Olm/Megolm, device verification, and key management. Specification features and deployed support require separate checks.
Servers: Synapse, Continuwuity, Tuwunel
Clients: Element, FluffyChat, Nheko
Metadata: Room membership and activity are visible to participating servers
Recovery: History recovery depends on available devices, encryption keys, and configured key backup.
Operating needs: Homeservers still manage room events and metadata. Users need device verification, recoverable keys, and a supported backup workflow.

XMPP with OMEMO

E2EE over inter-domain XMPP

Maturity: usable

Encrypted direct and group messaging within a compatible XMPP deployment.

Limit: OMEMO version differences and feature support can prevent interoperability. Encrypted media and group chat need checks with the selected clients.

Start hereStarting effort: an evening

Choose compatible clients and a server. Check the implemented OMEMO versions before relying on encrypted conversations.

Technical details & sources

OMEMO adds content encryption to XMPP’s domain federation. The report records XEP-0384 version 0.9.1 as Experimental. Actual compatibility depends on the selected clients.

Cryptography: OMEMO (XEP-0384) 0.9.1, Experimental status
Servers: Prosody, ejabberd, Snikket
Clients: Conversations, Dino, Monal, Gajim
Metadata: Presence and roster data held server-side
Recovery: Device keys and history recovery depend on the clients. Server-side message archives alone do not restore encryption keys.
Operating needs: The deployment needs compatible OMEMO versions, device support, and media handling. A modern XMPP server alone does not establish encrypted feature parity.

SimpleX

No global user identifier

Maturity: usable

Invitation-based private conversations without a global user identifier.

Limit: Invitation-based contact setup differs from an address directory. Device recovery and group behavior need evaluation for the intended use.

Start hereStarting effort: minutes

Install the app. Add a contact through its invitation workflow. Configure a backup before relying on it.

Technical details & sources

SimpleX keeps contacts and groups on devices instead of using a global user directory. Independently operated servers relay messages between participants.

Design: No global user identifier. Contacts and groups reside on devices.
Servers: Independently operated messaging relays, including self-hosted deployments
Clients: SimpleX Chat for iOS, Android and desktop
Metadata: No global user identifier. Metadata exposure still depends on the transport and deployment.
Recovery: Device-held state requires supported backup and recovery procedures.
Operating needs: Independent servers relay messages. Device-held contacts and groups make local state and recovery part of the service’s usability.

Delta Chat and chatmail

Encrypted chat over mail relays

Maturity: usable

Encrypted messaging with invitation-based contact setup over the email ecosystem.

Limit: Conventional email remains a separate workflow. The privacy and onboarding properties depend on the selected setup.

Start hereStarting effort: minutes

Install Delta Chat. Use its recommended chatmail setup. Establish an encrypted contact through an invitation.

Technical details & sources

Delta Chat recommends chatmail relays for its private-messaging workflow. Invitations or QR codes establish encrypted contacts. Ordinary unencrypted email is a separate case.

Design: Invitation-based encrypted contact establishment through QR codes or links
Servers: Independent chatmail relays for the recommended workflow. Conventional mail accounts have different assumptions.
Clients: Delta Chat on all major platforms
Metadata: The relay sees envelope data as any mail server would
Recovery: Use supported device transfer and backup procedures. Recovery depends on preserving the required local state.
Operating needs: Chatmail relays provide the recommended messaging infrastructure. Traditional mailbox deployments have different transport and onboarding assumptions.

Briar

Peer-to-peer synchronisation

Maturity: usable

Direct private communication with options for local connectivity during internet outages.

Limit: Direct synchronization changes availability and device requirements. Optional mailbox support addresses some offline delivery needs.

Start hereStarting effort: an hour

Install a supported client. Add a contact. Check availability with the devices and transports you intend to use.

Technical details & sources

Briar synchronizes encrypted data directly between contacts. It uses Tor online and local transports when internet access is unavailable. Optional mailbox support extends delivery.

Design: Direct encrypted synchronization, with optional mailbox support for asynchronous delivery
Servers: Optional Briar Mailbox for store-and-forward
Clients: Briar for Android and desktop
Metadata: Transport and device choices determine metadata exposure. There is no conventional central account service.
Recovery: Contacts and identity depend on device state. Evaluate supported recovery before relying on the deployment.
Operating needs: Availability depends on device connectivity and transport. Optional mailbox support changes delivery options when contacts are offline.

BCategory grade

Forums & events

Can forums, events, and interest communities federate?

Replacing Reddit, Facebook Groups, Eventbrite

Communities can connect; not every action travels.

Federated discussion can organize participation around communities and events. Specialized applications retain their own objects, permissions, and moderation rules.

An application can display a remote object without supporting every action. A surviving user account does not preserve a community after its host disappears.

Threadiverse

Communities as ActivityPub group actors

Maturity: usable

Community-centered discussion across compatible forum instances.

Limit: Communities depend on their hosts and moderators. Vote privacy and migration support differ between implementations.

Start hereStarting effort: minutes

Join a suitable instance. Check participation in a remote community and its moderation rules.

Technical details & sources

Lemmy represents communities as Group actors that receive contributions and announce them to followers. Related applications share discussion features with different voting and privacy behavior.

Specification: ActivityPub with application profiles. Lemmy documents communities as Group actors.
Servers: Lemmy, PieFed, Mbin
Clients: Web, Thunder, Voyager, Jerboa, Interstellar
Stewardship: Project maintainers define behavior. Instance and community moderators govern participation.
Voting: Semantics differ between implementations — PieFed exposes local and federated voting modes explicitly
Moving out: Account export and migration vary by application. Community ownership and moderator succession need explicit plans.
Operating needs: Communities need hosts, moderators, rules, and retained state. Operators also handle removal requests and incompatible voting or moderation behavior.

Mobilizon

Federated events and groups

Maturity: usable

Community events with participation across compatible instances.

Limit: Event display is only part of the workflow. Registration, attendance privacy, payments, and calendar updates need compatible application support.

Start hereStarting effort: an hour

Join a public instance. Create a trial event. Check registration and privacy from another compatible instance.

Technical details & sources

Mobilizon supports federated events and groups, multiple identities within an account, and participant roles. Its documented workflow includes registration across instances.

Specification: ActivityPub with event objects
Servers: Mobilizon instances with compatible event and registration support
Clients: Web interfaces. General fediverse applications can expose only part of an event workflow.
Stewardship: Project maintainers and instance operators
Federation: Registration works across instances where supported
Moving out: Event and group recovery need an explicit plan. A remote event listing does not preserve ownership or participant state.
Operating needs: Organizers manage attendance privacy, participant roles, notifications, and event changes. Payments and complex booking workflows need separate evaluation.

Specialist fediverse apps

Domain-specific social models

Maturity: usable

Domain-specific communities, such as reading records and book reviews.

Limit: Specialized objects need application-specific support. General social clients can display only part of the experience.

Start hereStarting effort: minutes

Join a BookWyrm server. Check reviews, reading lists, and export support before importing your collection.

Technical details & sources

BookWyrm combines reading tracking, reviews, and discovery. It federates with other BookWyrm communities and exposes social interactions to compatible ActivityPub services.

Specification: ActivityPub with application-specific extensions
Servers: BookWyrm is the reading-community example examined in the report.
Clients: Web, plus general fediverse clients for the social subset
Stewardship: Independent project teams
Federation: BookWyrm communities share specialized behavior. Other ActivityPub applications support a narrower social surface.
Moving out: Export and import support varies. Reviews, shelves, relationships, and identifiers need separate checks.
Operating needs: Operators maintain structured application data as well as social delivery. Specialized actions require compatible applications.

Usenet

Flood-fill distributed discussion

Maturity: usable

Distributed article exchange and discussion through participating news providers.

Limit: NNTP establishes article exchange and access. Provider retention, moderation, and community activity require separate assessment.

Start hereStarting effort: an hour

Choose a news provider and an NNTP client. Check the groups and retention that the provider offers.

Technical details & sources

NNTP supports article exchange between news servers and access by readers. Distributed copies provide resilience, subject to each server’s retention and peering policies.

Specification: NNTP (RFC 3977)
Servers: INN, Diablo, commercial providers
Clients: Thunderbird, slrn, tin
Stewardship: Convention and inter-operator agreement
Federation: Article exchange across participating news servers. Coverage depends on their peering and group policies.
Moving out: Replication and retention depend on participating news servers. A local archive provides a separate copy.
Operating needs: News servers select peers, groups, and retention policies. Useful access depends on provider coverage and the participating communities.

B−Category grade

Media hosting

Can video, music, and photos be hosted independently?

Replacing YouTube, Instagram, SoundCloud

Independent video, audio, and photos need hosting resources.

PeerTube, Funkwhale, and Pixelfed provide independent media services with federation. Social metadata and interactions travel separately from media storage and delivery.

Storage, transcoding, bandwidth, and moderation still require resources. Discovery, playlists, paid access, and creator income depend on the application and service.

PeerTube

Federated video hosting

Maturity: usable

Community video publishing under independent hosting and moderation.

Limit: Media hosting needs storage, bandwidth, backups, and moderation. Replication distributes costs but does not eliminate them.

Start hereStarting effort: an hour

Start with an existing instance. Before publishing, check upload access, storage limits, and moderation rules.

Technical details & sources

PeerTube federates video metadata and social interactions. Accounts and channels have distinct ActivityPub representations. Media storage and delivery remain separate from those activities.

Specification: ActivityPub representations for accounts, channels, and video metadata. Media delivery uses separate infrastructure.
Servers: PeerTube, maintained by Framasoft
Clients: Web, the PeerTube mobile app, third-party viewers
Stewardship: Framasoft, a French nonprofit
Federation: Channel and video federation. Comments and likes propagate
Moving out: Check account, channel, and media migration in the selected release. Federation alone does not preserve a complete media library.
Operating needs: Storage, transcoding, live delivery, bandwidth, backups, and moderation create substantial continuing costs.

Funkwhale

Federated audio libraries

Maturity: usable

Independent audio publication and libraries shared through compatible pods.

Limit: Audio federation has application-specific permissions and features. A general ActivityPub client cannot reproduce every library or listening function.

Start hereStarting effort: an hour

Choose a pod that accepts your intended use. Check library permissions and available client features.

Technical details & sources

Funkwhale publishes audio and manages libraries through independently hosted pods. ActivityPub shares content with compatible services, subject to its application and permission model.

Specification: ActivityPub with an audio-specific application and permission model
Servers: Funkwhale pods
Clients: Funkwhale interfaces and compatible audio clients. Library feature support varies.
Stewardship: Community project
Federation: Library sharing between pods, subject to permissions
Moving out: Audio files can remain under your control. Playlists, follows, and permissions need application-specific migration support.
Operating needs: Audio storage, delivery, permissions, and moderation remain operator responsibilities. Federation does not supply music distribution rights.

Pixelfed

Federated photo sharing

Maturity: usable

Photo-centered social publishing with an audience across compatible fediverse services.

Limit: Federation support is separate from albums, editing, accessibility, and migration. These features need evaluation in the chosen application.

Start hereStarting effort: minutes

Join an existing server. Check its upload limits, accessibility, moderation, and available clients.

Technical details & sources

Pixelfed provides an open-source photo-sharing application with federation. Uploads, albums, editing, and audience migration need evaluation separately from protocol compatibility.

Specification: ActivityPub
Servers: Pixelfed
Clients: Pixelfed interfaces and compatible clients. General fediverse clients expose only supported social actions.
Stewardship: Independent project
Federation: Posts and interactions reach Mastodon and its relatives
Moving out: Check export and import for media, audience, albums, and edits. Protocol support alone does not establish complete migration.
Operating needs: Instances manage uploads, media storage, accessibility features, moderation, and backups. Federation is only one part of the product.

B−Category grade

Files & calendars

Can calendars, contacts and files move?

Replacing Google Drive and Calendar, Dropbox, iCloud

Sync and sharing work; moving a whole workspace is harder.

CalDAV and CardDAV support independent clients and servers. Email carries cross-domain invitations. Federated file sharing and device synchronization address different collaboration needs.

File access does not transfer a complete workspace. Comments, live edits, permissions, tasks, and ownership need compatible application behavior.

CalDAV and CardDAV

Open calendar and contact access

Maturity: ready

Personal calendars and contacts with independent client and provider choices.

Limit: Shared calendars, delegation, recurrence, and resource booking need checks across products. Calendar invitations also depend on mail delivery.

Start hereStarting effort: an evening

Choose a compatible hosted service. Configure a CalDAV and CardDAV client on each device.

Technical details & sources

CalDAV provides calendar access, and CardDAV provides contact access. iMIP carries scheduling messages through email. Client synchronization and cross-domain invitations are separate layers.

Specification: CalDAV (RFC 4791), CardDAV (RFC 6352), iMIP for mail-borne invitations (RFC 6047)
Servers: Radicale, Baïkal, SabreDAV, Nextcloud, SOGo, Cyrus
Clients: Thunderbird, Apple Calendar and Contacts, DAVx5, Evolution
Stewardship: IETF. CalConnect for interoperability testing
Federation: CalDAV and CardDAV cover client access. IMIP carries calendar invitations through email.
Moving out: iCalendar and vCard support data transfer. Delegation, shared calendars, tasks, and provider-specific fields need separate checks.
Operating needs: Basic hosting is relatively approachable. Delegation, shared resources, recurrence, and scheduling policy require more care.

Open Cloud Mesh

Server-to-server file sharing

Maturity: usable

File shares between supported services across organizational boundaries.

Limit: Trust configuration sits outside OCM. Identity mapping, revocation, locking, and versioning need deployment-specific checks.

Start hereStarting effort: an hour

Use a hosted service with supported federated sharing. Check a share with the intended remote provider.

Technical details & sources

OCM specifies shares and invitations between file services. Existing protocols transfer the data. Nextcloud’s remote shares provide a concrete example of federated file access.

Specification: OCM 1.2.2 supplies an API specification and interoperability tests. IETF work is separate from a published RFC.
Servers: Compatible file services and CS3 deployments. The report separately documents Nextcloud-to-Nextcloud shares.
Clients: Desktop sync clients, mobile apps, web
Stewardship: The CS3 specification effort and a dedicated IETF working group
Federation: Share and invitation exchange, with trust established outside the protocol and data transfer through existing protocols
Moving out: Files can move without preserving remote shares. Comments, permissions, ownership, and live editing state need separate migration.
Operating needs: Operators configure trust and supported product combinations. Share acceptance, revocation, locking, versioning, and failure behavior need deployment checks.

Local-first sync

Devices instead of servers

Maturity: usable

Selected-device file synchronization or applications with offline editing and local copies.

Limit: Convergent edits do not define permissions, document meaning, or revocation. Offline replicas add further constraints.

Start hereStarting effort: an hour

Install Syncthing on two supported devices. Pair the devices and select a folder. Keep a separate backup.

Technical details & sources

Syncthing synchronizes files between paired devices. Automerge merges concurrent application changes. These solve different tasks and do not define a universal collaborative document format.

Specification: Syncthing’s file synchronization model and Automerge’s application synchronization engine
Servers: Depends on the application. Some deployments use discovery, relay, or synchronization services.
Clients: Syncthing and applications built with local-first synchronization engines
Stewardship: Independent projects
Federation: Selected peers and authorized datasets. Neither defines an unrestricted public collaboration network.
Moving out: Local replicas improve control. File formats, permissions, and application support still affect portability.
Operating needs: Devices need retained replicas and backups. Application authors must define schemas, permissions, transport, and revocation behavior.

Solid and Linked Web Storage

Apps separated from storage

Maturity: emerging

Experiments that separate application choice from data storage and permissions.

Limit: The Solid community specification and W3C standards work have different statuses. Application compatibility remains a separate requirement.

Start hereStarting effort: a weekend

For an experiment, use a Solid server and a compatible application. Evaluate access and migration with nonessential data.

Technical details & sources

Solid combines specifications for permissioned access to externally stored data. W3C Linked Web Storage pursues related standards work. The community protocol has a separate status.

Specification: Solid Protocol 0.11.0 is a Draft Community Group Report. W3C Linked Web Storage follows a separate standards process.
Servers: Community Solid Server, Enterprise Solid Server
Clients: A small ecosystem of pod-aware applications
Stewardship: The Solid Community Group and the W3C LWS working group
Federation: Storage independence rather than network federation
Moving out: Storage separation supports portability. Practical moves depend on compatible schemas, permissions, and applications.
Operating needs: A storage service needs compatible identity, access controls, and applications. Shared schemas determine whether another application can use the data.

C+Category grade

Calls & meetings

Can we hold a meeting across services?

Replacing Zoom, Teams, Google Meet

Open components exist; complete meeting workflows differ.

SIP supports inter-domain calling. WebRTC supplies media components. MatrixRTC connects calls through Matrix. Cross-product meeting workflows remain limited.

Shared media technology does not establish common invitations, permissions, recordings, or encryption behavior. Operators also need media capacity and support.

MatrixRTC

Conferencing signalled over Matrix

Maturity: usable

Voice and video conversations within compatible Matrix deployments.

Limit: Working Matrix calls do not establish compatibility with every open meeting application. Backend, client, and encryption support need evaluation.

Start hereStarting effort: an hour

Choose a Matrix service that supports Element Call. Check a call with users on another compatible homeserver.

Technical details & sources

Element Call implements conferencing with MatrixRTC signaling and a LiveKit backend. Matrix supplies room membership, while the media infrastructure carries the call.

Specification: MatrixRTC signaling and implementation support. A selective forwarding unit carries media.
Servers: A Matrix homeserver plus a LiveKit SFU
Clients: Element Call, standalone or embedded in Element
Federation: Cross-homeserver calls where operators deploy compatible backends
Encryption: Element Call documents end-to-end encrypted calls. Recording and gateway endpoints need separate consideration.
Cost: Media capacity, relay placement, and participant traffic determine operating costs.
Operating needs: Media requires bandwidth, NAT traversal, relays, and appropriate geographic capacity. The Element Call deployment includes a LiveKit backend.

SIP telephony

Inter-domain session signalling

Maturity: usable

Voice sessions between providers that permit the required inter-domain calls.

Limit: Provider policy can restrict inter-domain calling. Internal use of SIP does not establish open public connectivity.

Start hereStarting effort: an evening

Choose a SIP provider and compatible client. Check whether the provider permits calls to the intended domains.

Technical details & sources

SIP locates participants and negotiates sessions. Media uses additional protocols and infrastructure. Open signaling does not require providers to accept calls from every domain.

Specification: SIP (RFC 3261) for session signaling. Media transport and encryption require additional protocols.
Servers: Asterisk, FreeSWITCH, Kamailio
Clients: Linphone, Baresip, desk phones, softphones
Federation: Inter-domain signaling, subject to provider admission and routing policies
Encryption: SIP support alone does not establish end-to-end media encryption. Deployment and endpoints determine protection.
Cost: Voice and video require different media capacity. Relays and support add recurring costs.
Operating needs: Media transport, NAT traversal, relays, and provider policy sit alongside signaling. Two SIP products can remain operationally isolated.

Self-hosted meeting servers

Independent, not interconnected

Maturity: usable

Meetings controlled by an independent operator, with guests joining its application.

Limit: Self-hosting provides operational control. It does not establish a common meeting identity, invitation system, or cross-product room policy.

Start hereStarting effort: minutes

Try a hosted meeting service. Check guest access, accessibility, and encryption before choosing an independent deployment.

Technical details & sources

WebRTC supplies interoperable media components. An independently hosted meeting application still defines its own signaling, accounts, invitations, and room policies.

Specification: WebRTC media APIs and protocols. They do not define a universal meeting service.
Servers: Independent meeting applications. WHIP standardizes streaming ingestion, a separate use case.
Clients: Browser, plus native apps per project
Federation: Guest access through a meeting link does not establish interoperation between independent meeting services.
Encryption: Transport encryption and end-to-end encryption protect different paths. Recording, transcription, and gateways introduce additional endpoints.
Cost: Media capacity, relay placement, recordings, and support depend on the deployment.
Operating needs: Operators provide identity, admission, room policy, media capacity, and support. Recordings and transcription introduce additional access to content.

C+Category grade

Identity

Can I log in with an identity I own?

Replacing Sign in with Google, Sign in with Apple

Institutional federation is established; personal portability varies.

Institutional identity federation supports established deployments. OpenID Connect provides login assertions. OpenID Federation adds multilateral trust. Consumer account portability remains a separate problem.

Services choose which identity providers they accept. A federated login does not transfer the service account, its data, or its recovery authority.

OpenID Connect and Federation

Multilateral identity trust

Maturity: ready

Limit: A final specification does not establish support in every OIDC product. Membership, trust anchors, and service acceptance remain deployment choices.

Start hereStarting effort: a weekend

For an organization, identify accepted providers first. Then evaluate implementations for the required OIDC or Federation features.

Technical details & sources

OpenID Connect conveys authenticated identity information to services. OpenID Federation adds mechanisms for multilateral trust. Neither automatically makes service accounts portable.

Specification: OpenID Connect Core. OpenID Federation 1.0 became final on 17 February 2026
Implementations: OIDC providers and relying parties. OpenID Federation requires explicit support beyond ordinary OIDC compatibility.
Clients: Compatible relying parties. Federation trust processing needs additional implementation support.
Stewardship: The OpenID Foundation
Federation: Accepted identity assertions plus, where implemented, Federation trust chains and metadata policies
Moving out: A provider change does not automatically transfer service accounts or their stored data.
Operating needs: Deployment requires trust anchors, metadata policy, provider acceptance, and recovery procedures. OpenID Federation support needs explicit implementation checks.

eduGAIN

Interconnected institutional federations

Maturity: ready

Access to participating research and education services through an institutional identity.

Limit: Organized trust and membership make this federation useful. Participation depends on the institution and the receiving service.

Start hereStarting effort: minutes

Use your institutional login for participating services. Institutional operators manage federation membership.

Technical details & sources

eduGAIN interconnects research and education identity federations. Users authenticate through their home institutions. Organized membership and trust make access across institutions possible.

Specification: SAML 2.0 metadata exchange. Shibboleth and SimpleSAMLphp implementations
Operators: National identity federations, coordinated by GÉANT
Clients: Institutional web services and research infrastructure
Stewardship: GÉANT and member federations, with a formal policy framework
Federation: Multilateral trust through published metadata
Moving out: Institutional authentication does not guarantee account continuity after departure. Receiving services determine their own account and data policies.
Operating needs: Institutions establish membership, attribute policies, and trust relationships. Ordinary users rely on their institution’s supported service access.

DIDs and Verifiable Credentials

Self-managed identifiers and claims

Maturity: usable

Method-specific identifiers and issuer claims accepted by compatible verifiers.

Limit: A valid signature does not establish trust in a claim. Passkeys also serve a different purpose: authentication scoped to a relying party.

Start hereStarting effort: an evening

Start with an issuer and verifier that support the same credential workflow. Choose a compatible wallet.

Technical details & sources

DID Core defines an identifier framework. Verifiable Credentials defines an issuer–holder–verifier model for claims. Identifier control and claim acceptance require separate decisions.

Specification: DID Core and Verifiable Credentials 2.0, both W3C Recommendations
Implementations: Wallet and issuer software across several DID methods
Clients: Credential wallets and compatible verifier applications
Stewardship: W3C standards, with method-specific infrastructure and governance
Federation: Identifier resolution and credential verification are building blocks. Each deployment chooses trusted issuers and accepted methods.
Moving out: Control, resolution, and recovery depend on the DID method. Domain-based methods depend on continued domain control.
Operating needs: Deployments select DID methods, trusted issuers, credential formats, recovery, and revocation behavior. Standards alone do not settle these choices.

X-Road

Institutional data exchange

Maturity: usable

Data exchange between institutions within a managed trust framework.

Limit: X-Road combines distributed exchange with managed membership and central trust configuration. It serves institutional cooperation rather than unrestricted public participation.

Start hereStarting effort: ongoing

Identify the institutional trust framework and operator. Evaluate membership, schemas, access policy, and a trial data exchange.

Technical details & sources

X-Road exchanges data between organizations through security servers. Shared central services govern membership and trust configuration. Data can remain with independent organizations.

Specification: The X-Road architecture, with certification and timestamping authorities
Servers: X-Road security servers per member organisation
Clients: Institutional information systems
Stewardship: NIIS, jointly governed by member states
Federation: Distributed exchange with a central operator for trust configuration
Moving out: Institutional membership and agreements govern provider changes. Application data and relationships need a separate transition plan.
Operating needs: Member organizations operate security servers. Central services distribute membership and security configuration, with certification and timestamping authorities.

CCategory grade

Code collaboration

Can we build software across forges?

Replacing GitHub, GitLab.com

Useful alternatives; collaboration across forges is still limited.

Git distributes repository data. Forge workflows add issues, reviews, identities, permissions, automation, and packages. These need separate interoperability and migration support.

Forgejo labels federation experimental and disables it by default. Remote contributions also need explicit authorization before they trigger builds or access secrets.

Git over email

The federation that already works

Maturity: ready

Patch review between contributors who use independent Git and mail providers.

Limit: Email collaboration has substantial onboarding requirements. It does not reproduce every web-forge feature or remove mail delivery constraints.

Start hereStarting effort: an hour

Start with a project that accepts patches by email. Follow its contribution instructions and archive policy.

Technical details & sources

Git preserves repository objects across independent copies. Email can carry patches and review discussions. Together they support a workflow without a shared forge account.

Specification: Git repository formats and SMTP mail transport, with project-specific review conventions
Servers: Any Git host, plus a mailing list
Clients: Patch-capable mail tools such as git send-email. Project conventions determine compatible review workflows.
Stewardship: The Git project and IETF mail standards
Federation: Patches and review messages cross mail domains. Other forge functions require separate tools.
Moving out: Retained repositories and mail archives preserve separate parts of the workflow. Permissions, automation, and package publication need additional migration.
Operating needs: Projects maintain repositories, mail delivery, review conventions, and archives. Automation and publication require their own authorization boundaries.

ForgeFed

Forge federation over ActivityPub

Maturity: emerging

Pilots of collaboration between independently operated code forges.

Limit: A published specification does not establish implementation support. Useful assessment needs working issues, patches, permissions, and recovery across selected forges.

Start hereStarting effort: an evening

For routine hosting, choose a supported forge. For federation experiments, evaluate the documented workflows in a separate pilot.

Technical details & sources

ForgeFed extends ActivityPub for repositories, commits, issues, patches, and related collaboration. The report identifies Forgejo federation as experimental and disabled by default.

Specification: ForgeFed vocabulary and behaviour documents
Servers: Forgejo — federation appears in the admin config cheat sheet, labelled experimental and disabled by default
Clients: Forge web interfaces
Stewardship: The ForgeFed community, aligned with the fediverse
Federation: Specification scope includes cross-forge collaboration. Actual supported actions depend on the selected releases.
Moving out: Repository and collaboration exports depend on the forge. A complete move needs checks for reviews, identities, permissions, and automation.
Operating needs: Operators need supported workflows, abuse handling, and recovery. Remote contributions must not inherit permission to run builds or access secrets.

Radicle

Peer-to-peer forge

Maturity: usable

Peer-to-peer replication of repositories and associated collaboration data.

Limit: Peer replication changes workflow and availability assumptions. Teams need compatible tools and a plan for retained copies.

Start hereStarting effort: an evening

Try a nonessential repository with compatible Radicle tools. Check replication and recovery from another retained copy.

Technical details & sources

Radicle replicates Git repositories and collaboration artifacts through peers. Cryptographic identities and signed data support attribution. It uses a different architecture from ActivityPub forge federation.

Specification: The Radicle protocol: gossip, signed refs, cryptographic identities
Nodes: Self-hosted seed nodes
Clients: The rad CLI, web interfaces over seed nodes
Stewardship: The Radicle project
Federation: Replication between peers rather than between hosts
Moving out: Replicated repositories and collaboration data improve independence. Availability still depends on accessible copies.
Operating needs: Participants need reachable replicas and compatible tools. Seed availability and local workflow differ from an always-online forge service.

Tangled

Forge on AT Protocol

Maturity: emerging

Evaluation of code collaboration built on AT Protocol infrastructure.

Limit: Shared AT identity does not establish complete cross-forge compatibility. Reviews, permissions, automation, and application data need separate evaluation.

Start hereStarting effort: minutes

Evaluate a nonessential project. Check repository export and recovery of issues, reviews, and permissions.

Technical details & sources

Tangled demonstrates code collaboration in the AT Protocol ecosystem. Shared infrastructure does not establish compatible reviews, permissions, or automation across unrelated forges.

Specification: AT-based application data. The report does not establish a complete cross-forge compatibility profile.
Servers: Tangled knots plus a PDS for identity
Clients: Web
Stewardship: Independent project
Federation: AT infrastructure provides shared foundations. The report does not establish portable cross-forge workflows.
Moving out: AT identity continuity is separate from repository and collaboration recovery. Evaluate both in the selected deployment.
Operating needs: The report establishes its place in the AT ecosystem, but does not benchmark deployment, workflow completeness, or recovery.

DCategory grade

Discovery

Can anyone find any of this?

Replacing Google Search, platform recommendation feeds

Search, addressing, and bridges solve only parts of the problem.

Metasearch changes the search interface without necessarily replacing the underlying indexes. Independent discovery also needs indexing, ranking, spam control, and sustainable operation.

Few effective indexes can shape access to many independent publishers. Discovery must also respect permissions, corrections, and deletions. Public copies cannot guarantee erasure.

Open metasearch

Your interface, someone else's index

Maturity: usable

A choice of search interface that aggregates results from other services.

Limit: An open search interface does not establish an independent index. Sustainable indexing, ranking, and spam resistance remain substantial operational problems.

Start hereStarting effort: minutes

Choose a SearXNG instance. Review its operator policy and upstream engines before making it your default.

Technical details & sources

SearXNG aggregates results from other search services. It changes the user-facing search interface without automatically supplying an independently maintained web index.

Implementations: SearXNG, the metasearch implementation examined in the report
Hosting: Independent hosted instances or a self-hosted frontend
Clients: Browser search engine configuration
Stewardship: Independent projects
Federation: Query distribution, not a shared index
Moving out: A different interface can use different upstream services. Search preferences and stored state depend on the chosen application.
Operating needs: Operators maintain the frontend and its upstream integrations. Crawling and ranking remain dependencies of the selected search services.

Content addressing

Distribution by hash, not host

Maturity: usable

Peer distribution of public files and other retained datasets.

Limit: An identifier does not store content. Pinning and other retention services preserve bytes. Distribution alone does not settle consent or deletion.

Start hereStarting effort: an evening

Try a node with nonessential public data. Arrange retained copies before relying on it for durable publication.

Technical details & sources

IPFS supplies content addressing, routing, and transfer. BitTorrent distributes files among peers. Both support distribution without providing a complete social or collaboration network.

Specification: IPFS protocols for addressing, routing and transfer. BitTorrent BEP 3
Nodes: Kubo for IPFS and compatible BitTorrent clients
Clients: Gateways, native nodes, torrent clients
Stewardship: IPFS protocol and implementation communities. BitTorrent specification contributors.
Federation: Peer distribution. These protocols do not provide a complete social identity or permission system.
Moving out: Identifiers can reference the same content across hosts. Continued access requires retained, reachable copies.
Operating needs: Someone must store and serve the bytes. Pinning, gateways, and other retention services can become practical dependencies.

Cross-network bridges

Connecting networks that do not interoperate

Maturity: usable

Selected interactions across protocol boundaries, such as follows through Bridgy Fed.

Limit: Bridges add translation, availability, and policy dependencies. A bridge that decrypts chat content also becomes an endpoint in its security model.

Start hereStarting effort: minutes

Read the bridge instructions before enabling it. Check which content, identities, and interactions become visible on the other network.

Technical details & sources

Bridgy Fed connects ActivityPub, the web, and the AT ecosystem. It translates supported interactions rather than making these networks natively equivalent.

Implementations: Bridgy Fed for social interactions. Chat bridges have separate compatibility and encryption properties.
Hosting: Operated services, self-hostable in some cases
Clients: Native clients on each side
Stewardship: Independent operators
Federation: Translation, not native equivalence
Moving out: A bridge creates another identity and availability dependency. Native accounts and mapped representations need separate exit plans.
Operating needs: Bridge operators translate identities and content. They can store credentials and mediate edits, deletions, blocks, and availability.

What is still missing

The report identifies incomplete workflows, not proof that no implementation exists. Existing components often need common behavior, sustainable operation, or wider adoption.

Complete user and community exit
Partial support

Exports, account moves, identity cloning, and replicated rooms preserve different parts of an account. Complete recovery also needs relationships, permissions, media, and private state.
Payments
Existing foundations

Open Payments defines interfaces for payment accounts. Portable subscriptions, purchases, refunds, and access rights still need coordination between participating providers.
Marketplaces and delivery
Existing foundations

Beckn specifies commerce interactions across platforms. Dependable marketplaces also need reputation, fraud handling, fulfillment, dispute resolution, and support.
Live document collaboration
Partial support

File federation, editors, and CRDTs provide useful components. Broad cross-product collaboration still needs common document operations, permissions, comments, history, and recovery.
Encrypted messaging between services
Standards in progress

Matrix and XMPP support compatible encrypted conversations. MIMI addresses wider interoperability. Private contact discovery, introductions, recovery, and group policy remain difficult.
Independent discovery
Partial support

Feeds, public data streams, metasearch, and specialist indexes provide useful foundations. Sustainable discovery also needs quality, spam resistance, permissions, and portable preferences.
Sustainable operation and moderation
Continuing work

Memberships, commercial hosting, grants, and institutional support fund open services. Long-term resilience needs adequate maintenance, moderation, recovery, and more than one viable operator.

Choose a first step

These are independent options. Start with one useful change. Hosted services can reduce the operational burden. Before a larger move, check compatibility, export, and recovery for your actual workflow.

Subscribe to podcasts by feed

Install a podcast app that accepts feed URLs. Add a few existing subscriptions. Check access to any paid shows separately.

Minutes
Take a fediverse account on someone else's server

Choose a server with suitable policies. Mastodon moves followers where supported. Followed accounts require export and import, and posts remain behind.

Minutes
Buy a domain and put your email on it

Choose a hosted mail provider that supports your domain. Plan mailbox migration separately from the domain change.

An hour
Set your own domain as your social handle

Configure a domain handle in a supported AT Protocol application. Handle control is separate from PDS migration and account recovery.

An hour
Try one group conversation

Choose hosted Matrix or compatible XMPP clients. Invite a small group. Check encryption, notifications, and recovery before moving essential conversations.

An evening
Move calendars and contacts to CalDAV and CardDAV

Choose a compatible provider. Configure clients on each device. Android can require a sync adapter such as DAVx5.

An evening
Host your own files

For shared access, evaluate hosted or self-hosted Nextcloud. For selected devices, try Syncthing. Keep independent backups.

A weekend
Run something for other people

Start with a small community and a supported application. Plan updates, backups, moderation, support, and recovery before inviting users.

A weekend
Run your own mail server

Treat mail hosting as an ongoing service. Plan authentication, DNS, delivery monitoring, backups, and abuse handling before moving essential mail.

Ongoing

Yes, for many tasks.

Open transport, independent operation, and practical exit are separate achievements. Useful systems exist across all three. The remaining work includes compatible applications, dependable recovery, affordable discovery, accountable moderation, and sustainable hosting.

Corrections welcome

Grades are editorial assessments. Status claims reflect the research cutoff and can change. Corrections with implementation evidence are welcome in the issue tracker.

What works today

Reading the guide

You already do this

A useful exit needs more than an export

Grades describe a use case

The grade scale — per category

Maturity tier — per approach

Starting effort — per approach

What is still missing

Complete user and community exit

Payments

Marketplaces and delivery

Live document collaboration

Encrypted messaging between services

Independent discovery

Sustainable operation and moderation

Choose a first step

Subscribe to podcasts by feed

Take a fediverse account on someone else's server

Buy a domain and put your email on it

Set your own domain as your social handle

Try one group conversation

Move calendars and contacts to CalDAV and CardDAV

Host your own files

Run something for other people

Run your own mail server

Yes, for many tasks.

Corrections welcome