How this compares

If you already know a system like Unix, Erlang, REST, Nix, Plan 9, IPFS, Mastodon or Bluesky, this page places the entity system next to it. The short version: most of the pieces are not new, and we say so. What is unusual is the combination and the floor it sits on.

The entity system is several things at once — a substrate for distributed information, a programming model, and an operating system for your own machines — so it is compared per face rather than against one field. The papers do that in depth:

All four are in the paper corpus. Peer-to-peer is one form built on top of the rest, not the frame that contains them. This page is the quick orientation across all of it.

What we share with the field

Content addressing, identity rooted in keys, and immutable storage are prior art. They appear in IPFS, Hypercore, Nostr, Git, Nix and restic, and the entity system uses them the same way everyone else does.

What is worth noticing is how widely they appear. The same few structures keep being rediscovered by people solving unrelated problems:

A build system, a backup tool, a 1980s operating system, a telecoms language and a capability microkernel do not share a lineage. That they converge is the observation the corpus is built around — not a claim to have invented the structures, but evidence that they are found rather than designed.

The actor correspondence is the sharpest example, and Paper 2 states it as an observation rather than a design goal: an entity at a tree path with an inbox handler is structurally an actor — identity (peer + path), state (tree subtree), behavior (handler), mailbox (inbox) — and it was not designed as one. What distinguishes it is that open-dispatch systems elsewhere carry untyped messages (Erlang), external schemas (gRPC), or assigned identity (databases); here the dispatched data is typed, content-addressed and versioned.

Where it differs

Five things, stated plainly.

It is useful with nobody else on it. This is the deepest difference on the page, and it changes what the rest of the comparisons are even about.

The Fediverse, the AT Protocol and Nostr are network-first designs: their value is participation, so a client with no relays, an instance with no federation, or a repository no application view indexes is doing nothing much. That is not a flaw — it is what a social protocol is — but it means each of them carries a bootstrapping problem in its foundations, and every one of them has had to fight it.

In this design the network is additive. One person, one laptop, no connection to anyone is a complete use case: content-addressed storage, a tree you can verify, capability-controlled access, your own machines syncing with each other, an operating environment over your own fleet. None of that has a second party in it, and none of it is a degraded mode waiting for a network to arrive. Connect to other peers and you get more — publishing to a static host anyone can read, addressing peers directly, resolving names — and it is genuinely peer-to-peer rather than routed through anyone's servers. But that is a benefit added on top of something already worth running.

The practical consequence for a reader: adopting this does not require an adoption bet. You do not have to predict whether a network materialises, because the substrate pays for itself on your own hardware either way. Two honest limits on that. Scaling peer-to-peer to global size at low cost is a direction the architecture is built for and not a demonstrated result. And the application layer on top — the L5 data model that would make "run your own social feed" an off-the-shelf thing rather than a build — is the least settled part of the system, which Applications sets out with the maturity of each piece marked.

What it costs to leave, and who decides whether you take part. This is the axis a reader coming from the Fediverse or Bluesky will care about first, and the field splits on it more sharply than on anything technical.

ActivityPub, as deployed in Mastodon, federates servers: the unit of the network is the instance, not the person. Your handle is at your instance, your data is in its database, and it holds your keys and must stay online for you to exist on the network. That is a design choice with real benefits — a human-scale moderation unit, and someone accountable for it — but the cost is that one operator is load-bearing for your identity and your archive. Migration carries your followers and not your posts. The AT Protocol went furthest in the deployed field toward fixing exactly this, and deserves credit for it: a signed, content-addressed personal repository plus a portable identifier is genuinely the closest anyone has come to credible exit. Assessed honestly, that exit is more credible than anywhere else in the field and less credible than the marketing — the identifier directory nearly everyone uses is operated by one company, and though the protocol permits many relays and application views, few run at scale.

Nostr takes the shortest path of the three and, on this axis specifically, gets furthest. Identity is a bare keypair bound to no server, so you are the same identity on any relay and can walk away from any of them — the strongest identity portability in the field, and the design closest to this one in philosophy. Its relays are deliberately dumb store-and-forward with almost no logic in them, which is a good decision rather than an incomplete one, and the pattern is one this project learned from directly: our own relay modes name the same space. The cost is the mirror image of Mastodon's — nothing guarantees your content survives, is found, or is recoverable, because relays prune and come and go.

Here, the question is moved rather than answered. Your identity is your keypair, not an account somewhere. Publishing is commodity static hosting, so nobody has to grant you a place to put things and moving hosts changes nothing about who you are. And a name resolves through a registry you chose to pin, which means the load-bearing question stops being whose server am I on and becomes whose attestations do I choose to believe — answerable per name, and changeable without moving your data.

Against Nostr in particular the difference is not portability, which it already has, but persistence: signed content-addressed state sits on a passive host and stays verifiable with nobody online to keep it alive, so leaving is free and the archive is not staked on a relay continuing to carry it. That is the one place the two designs genuinely diverge, and it is a difference in what is being optimised rather than a correction.

None of which escapes the axis — it is a different position on it. Trust does not go away when hosting stops being scarce; it becomes explicit, and someone still has to do the work of deciding whom to believe. What changes is that the decision is the reader's and is revisable, rather than being settled by whoever holds the account. Federated groups and shared moderation are still perfectly buildable on this — they become a matter of whose attestations a community agrees to honour, rather than of which server everyone had to sign up to.

Authorization is a capability, not an access list. Most of the field sits at public-or-encrypt: Nostr's choice is "encrypt to a key" or "broadcast." Solid — which shares our goal of user-owned data almost exactly — chose ACLs. We use a four-dimension grant (handlers, operations, resources, peers) that attenuates and travels with the artifact, so authority is carried in the token rather than inferred from who is asking.

One model rather than several subsystems. iroh offers connections, blobs, documents and gossip as separate pieces; Nostr is events-only. Typed entities, a tree, capabilities and dispatch are one model here, and everything else is composition of it.

That is partly a bet on comprehensibility, and it is worth naming as one. A decentralised system asks a newcomer to hold a lot at once — instances and federation and relays and firehoses and application views and directories — and the size of that conceptual surface is a genuine cost, paid by every person who has to reason about the system before they can use it or build on it. Six primitives and one composition rule is a deliberate attempt to keep that surface small enough to hold in your head. Whether it succeeds is for readers to judge, and whether it matters for adoption is not something this page can claim: a favourable position is a reason a thing could be adopted, never evidence that it will be.

Posture is not fixed. Every deployed system in the field assumes one: the online seeder, the always-on server, the pinning node, the full validator. Because state is content-addressed, signed and capability-rooted wherever it sits, the same participant can be a live peer, park its state somewhere passive and go quiet, or work offline and reconcile later — and a static host serving signed entities is a first-class participant, not a dumb cache.

The floor, and why it is measured

The entity system is a small mandatory core plus an optional set above it. That structure is not new either: XMPP has run it for twenty-five years, with a small core and the XEP series above, and no requirement that anyone adopt the published extensions.

It is also the structure's known risk. XMPP's extensions are credited with its longevity and blamed for fragmentation — two clients can share a core and still fail to work together, because the useful behaviour lives in extensions they do not both implement.

Our answer is to measure the floor and publish the result. The core protocol has been re-derived across more than forty languages, and conformance is tracked per peer rather than claimed once. Each peer's verdict against the --profile core gate, the oracle commit it was measured at, and its known gaps are published in the conformance matrix rather than summarised as a badge — including the peers that do not pass, which are listed with a named defect. The claim is spec-forced convergence — one specification re-derived across languages — not that many separate codebases independently agree, since the generated peers share a generation lineage.

Almost nothing else in this field publishes a conformance suite. Nostr's bar for accepting an extension is that it is implemented in two clients and one relay.

What it does not do

Named here because a comparison that only lists strengths is not a comparison.

• No consensus. Peers converge by reconciling content-addressed history and surfacing conflicts as data. Strict linearizable agreement — one ordered log, bounded failover — is not provided, and content addressing does not buy Byzantine agreement. If you need trustless agreement among strangers, a blockchain solves a different problem better.
• No moderation layer. Nobody in this field has solved moderation in a decentralised system; Matrix has the most developed cooperative primitives and declined the strong form as incompatible with decentralisation and end-to-end encryption. We currently specify none.
• Not zero-knowledge, not confidential compute. Verification is re-running, which is the opposite of checking a proof cheaply. Capabilities gate access, not visibility during computation.
• No deployed user base where the social incumbents have tens of millions. The model is unproven at that scale.

Where to go next

• What the entity system is — the six primitives and the layer stack.
• The specification — the mandatory floor, in full.
• The architecture — the optional layer, and the design space above core.
• The papers — each face compared in depth; the table at the top of this page says which one to start with.