What this section covers¶
For most of the social web's history, "social media" has meant a handful of companies each running one closed service. Federated (sometimes loosely called "decentralized") social networking is a different bet: independently operated servers, run by different people or organizations, speak a shared protocol so their users can follow, post to, and interact with everyone else on the network — without any single company owning the whole thing. Some networks push further than federation into genuine decentralization, where even the server layer is optional (Nostr) or identity is explicitly designed to be portable across hosts (AT Protocol).
This section is organized in two layers, plus a handful of practical guides that cut across both:
- Federated protocols — the actual wire protocols: what gets sent, how servers discover and authenticate each other, how identity and moderation are modeled. This is where the real architectural differences live.
- Fediverse apps — the applications people actually sign up for, each one built on top of one of the protocols above, each making its own product decisions the underlying protocol doesn't mandate.
- Guides — adoption numbers, getting started as a user, and linking a custom domain — practical pages that apply across more than one protocol or app at once.
Protocols¶
| Protocol | Model | Identity | Moderation |
|---|---|---|---|
| [[activitypub|ActivityPub]] | Server-federated — independent instances push activities to each other's inboxes | Tied to your instance (@[email protected]) |
Per-instance rules, plus all-or-nothing defederation between servers |
| [[at-protocol|AT Protocol]] | Account-federated — PDS/Relay/App View layering, with a global firehose | Portable DID, independent of hosting | Composable, user-subscribed labelers |
| [[nostr|Nostr]] | No servers at all — just relays relaying signed events, and clients | A bare keypair, with no registry | None built in — pushed entirely to relays and clients |
| [[matrix|Matrix]] | Server-federated, encrypted rooms with no single owning server | Tied to your homeserver (@you:homeserver.example), but delegatable to another host |
Per-room power levels, plus homeserver-level blocking |
Matrix solves a genuinely different problem from the other three — end-to-end-encrypted group and private messaging rather than public broadcast — so it's included here as an architectural sibling worth understanding, not a direct competitor to Mastodon or Bluesky.
Apps¶
| App | Built on | What it replaces |
|---|---|---|
| [[mastodon|Mastodon]] | ActivityPub | Twitter/X — the fediverse's most widely deployed app |
| [[bluesky|Bluesky]] | AT Protocol | Twitter/X — currently the largest active user base of any app here |
| [[threads|Threads]] | ActivityPub (partial, opt-in) | Twitter/X — a centralized app with the largest overall user base, only a slice of which is fediverse-reachable |
| [[other-fediverse-apps|Other fediverse apps]] | ActivityPub | Pixelfed (photos), PeerTube (video), Lemmy/Mbin (forums), WriteFreely (blogging), Funkwhale (audio), Owncast (streaming) |
Guides¶
- [[adoption-and-usage|Adoption & usage numbers]] — how big each network actually is, and why registered-account counts mislead
- [[getting-started|Getting started as a user]] — picking a platform and instance, and what migrating later actually involves
- [[linking-a-custom-domain|Linking a custom domain]] — using your own domain or subdomain as your identity on Bluesky, Mastodon, Nostr, and Matrix
- [[run-bluesky-pds|Running a Bluesky PDS]] and [[install-mastdon|Installing Mastodon]] — self-hosting notes
Why the protocol distinction matters¶
It's easy to conflate "Mastodon" with "ActivityPub" or "Bluesky" with "AT Protocol," but in every case the app is one product built on a shared, open protocol that other apps can and do build on too — the way Chrome is one browser built on HTTP. The protocol pages in this section describe what any compliant implementation must do; the app pages describe what one specific team chose to build on top of that, which is where most of the day-to-day user-facing differences actually come from.