Decentralized networks list: signal versus noise

This decentralized networks list sorts named networks into signal and noise. Signal means a mechanism difference you can read off the protocol. Noise means a slogan shared by systems that behave nothing alike.

The word "decentralized" fits at least four arrangements of machines, identities, and authority. A list that groups them together has grouped things that behave nothing alike.

An account on a volunteer's Mastodon server and a Nostr key you hold yourself share a slogan and almost nothing else. One leaves your posts in someone else's database. The other leaves them signed by you, on any relay willing to keep them.

The approach is the same one the community platform axes use, applied to machines rather than to rooms. This page classifies nine networks by mechanism, so a reader can predict behavior from the classification alone.

What to take away

Question one: where the data lives

On one of many independent servers. Federation. Mastodon, Lemmy, and PeerTube use it. A Mastodon handle says where the account lives: @you@example.social sits on that server, and copies of public posts travel only to servers that follow it.

On relays that hold nothing authoritative. Nostr works this way. Each note is signed by the author's key and sent to several relays the user picks. A relay can drop any note, and the note survives on the others.

On the participants' own devices. Peer to peer. Secure Scuttlebutt replicates a signed log between peers who follow each other. Briar sends messages over Tor and Bluetooth with no server at all. Availability depends on someone who holds the data being online.

In a shared, replicated ledger. Farcaster registers accounts in a contract on Optimism, and ENS registers names on Ethereum. Only a small part lives on chain, usually an identifier or a pointer. Posts and images sit on servers, hubs, or peers.

Record the answer for the network's default configuration, and note if the design allows more than one. Storing the observation rather than a bare value is the general habit for a platform record.

Question two: what the identity is bound to

A server. The handle includes the server's name, and the identity is the server's account. Mastodon's @you@example.social and Matrix's @you:matrix.org work this way. Moving servers means a new identity, possibly with a redirect from the old one, and the redirect depends on the old server cooperating. Mastodon requires an alias on both accounts before a move.

A domain you control. Bluesky separates the layers: a DID (did:plc) is the identity and the handle is a domain name, so you can point your own domain at the account and change hosting without changing identity. Self-hosting a data server takes a domain and a small virtual server, typically $5 to $20 a month.

A key you hold. Your identity is a public and private key pair, and anything you publish is signed with it. Nostr encodes keys as npub and nsec, and Secure Scuttlebutt uses Ed25519. Relays and servers are interchangeable; whoever holds the key is you. Losing the key is losing the identity, with no operator to appeal to.

A record in a shared ledger. ENS names on Ethereum and Farcaster IDs on Optimism are registered in a replicated structure. Resolution from identifier to current location goes through that structure rather than through a server.

This question decides what "portability" means for a network. It is the claim most often made and least often defined.

A server-bound identity like Mastodon's is portable only with the server's help. A key-bound one like Nostr's is portable by definition and unrecoverable by design. A niche social network's portability claim is one of the four claims worth checking before you trust it.

Question three: where the power to remove sits

With the server operator, over their own members. Federation's default, and it covers Mastodon, Lemmy, PeerTube, and Matrix. Your operator can suspend you; no one else's can, though they can refuse to receive from you.

With each server, over which other servers it will hear. Also federation. Mastodon instances publish their domain blocks at /about unless the admin hides the list. Whether a blocklist is public is worth recording. A server that is widely blocked is cut off without any single decision having been made.

With relays, over what they will carry. On Nostr a relay can refuse a note, and the same note usually sits on several others. Removal is local to each relay and never total.

With the reader, through labeling. Bluesky's Ozone lets independent parties publish labels, and each reader's app chooses which labelers to apply. Nothing is removed from the network; it is hidden from those who opted in to hiding it.

With no one. Secure Scuttlebutt and IPFS have no removal mechanism beyond individual blocking. Whether that is a feature is a matter of position; that it is a fact is not.

The classification table: nine networks by data, identity, and removal

Each row below reads across as the three answers: where the data lives, what identity is bound to, and where removal sits.

Three cells per entry. From them, a reader can answer the questions that matter without a single number. What happens when my server closes? Who can silence me, and how completely? What do I lose if I lose a credential? Can harassment aimed at me be stopped, or only hidden?

Reading the mechanism from the documentation

Each answer sits in the protocol specification or the reference software's own description, so this is an ordinary exercise in matching a claim to the document that settles it.

Find the section that describes how a message travels from author to reader and which machines hold it on the way. Then find how an identifier is resolved to a location. ActivityPub, the AT Protocol, Nostr's NIPs, the Matrix specification, and the Secure Scuttlebutt protocol guide each have such sections.

Look for the words "block", "defederate", "label", "mute", and "moderate", and read what each is allowed to do. Where the documentation is silent on removal, the answer is usually "no one". The entry should say the documentation is silent rather than guess.

The decentralized networks overview covers what these mechanisms do and do not change for the person using them; this page is the key for telling the mechanisms apart.

Common questions

A network claims to be decentralized but every account is on one large server. How is it classified?

By its mechanism, with a note. Mastodon's architecture is federated. A network where most members sit on one instance is concentrated in practice. Both are facts. The classification records the first, and the entry's notes record the second with the evidence, because concentration can change and architecture rarely does.

Do the three answers ever fail to predict behavior?

They predict what is structurally possible. What happens in practice also depends on operators, norms, and who is actually there, which are properties of a community rather than a network and belong in a different record.

Should the list name protocols?

It should name them and attach the classification. A specification is a document a reader can check; a protocol's name is a label that says less than its classification does. Nostr's NIP-01 settles how relays handle a note. The word "decentralized" settles nothing.

Where do bridges between networks go?

As a note on both entries, describing which direction messages flow and which side's removal power applies to bridged content. Matrix publishes bridges for IRC, Slack, and Discord, and each one carries its own moderation rules. A bridge is where two classifications meet, and the seam is where the surprises are.