GM Dear Nostr,
I need your help. I need all the arguments you can think of, why it would be a terrible idea to build public infrastructure based on ActvityPub and/or atproto instead of Nostr.
There is...
## Identity
ActivityPub identities are constitutively bound to a domain: @[email protected]. The domain is not an address but part of the identity itself. In a federal system where each state runs its own instance, identity is therefore state-bound — and it ends when the state stops operating. Mastodon's Move migrates followers but not content, and requires the origin instance to still be running and cooperating.
The more serious issue is reference integrity. If state A cites resources from state B in collections, curriculum mappings or learning paths, and B shuts down its instance, it is not only accounts that break but every reference to them. In an infrastructure built for cross-state reuse, that is a structural defect rather than an operational risk.
In Nostr the key is the identity. Domains still appear via NIP-05, but as a revocable, replaceable attribute rather than a foundation. A state can shut down its relay without breaking a single identity or reference; the events remain verifiable on any other relay. Responsibility for operations is thus decoupled from responsibility for identity — a far better fit for federal reality than a model in which one state's exit devalues everyone else's data.
## atproto: portability (but with a directory caveat)
The AT Protocol addresses this. Identity there is a DID, not a domain; the handle is merely an alias proven via DNS or HTTP and can be changed without breaking the identity. Migrating between Personal Data Servers is supported, and repositories can be exported and re-imported elsewhere. Rotation keys even let an identity survive loss of the signing key — but only because in normal operation the PDS operator holds such a key in trust. Recoverability is solved organisationally, not cryptographically: whoever can rescue the identity can also alter it. The tie to an operator is loosened, not removed.
The second caveat concerns resolution itself. `did:plc`, the method used almost exclusively in practice, is not a self-certifying identifier but points to a central directory, so far operated by Bluesky PBC. It is auditable, but its failure interrupts identity resolution network-wide, and its operator can change without the federation having any say. For public education infrastructure planned in decades, this merely relocates the dependency: from a state domain to a commercially operated registry in another jurisdiction. The alternative, `did:web`, avoids that but reintroduces exactly the domain binding we set out to escape.
## The Eurosky case
The obvious rejoinder is that sovereign European atproto infrastructure already exists. Eurosky (https://eurosky.tech/), a project of the Dutch Stichting Modal, runs its own Personal Data Server: data sits in Hetzner facilities in Falkenstein, Eurosky operates the service itself, the contract is held by the foundation, and the service falls under European law including GDPR and DSA. That is substantial and relevant for public bodies.
But it concerns the hosting layer, which was never the problem: that anyone may run a PDS is an explicit design feature and permissionless by intent. **The identity layer is untouched: a Eurosky account still carries a did:plc identity resolved against the same central directory**. Data held in Germany, identity resolved through a registry in foreign hands — for an argument resting on digital sovereignty, that is a solution at one layer, not throughout. The rotation-key trust relationship likewise only shifts, from Bluesky PBC to a Dutch foundation: still operator-mediated.
There is also the protocol's practical shape. atproto is built around a few large aggregators processing the whole network's traffic; as of early 2026, Bluesky PBC still ran the only full-network AppView. That suits a platform, less so a landscape of sixteen states, media centres and other bodies each running small nodes and exchanging selectively.
## Key loss
The obvious objection to key-based identity: what happens when a key is lost, and who is responsible in an administrative context? It must be addressed, but it is solvable.
For individual users, FROSTR and pomegranate offer approaches based on FROST signatures, standardised as RFC 9591: the key is split into shares, and signing requires k of n.
The contrast with the atproto model is therefore precise: there, one party must be able to act alone for recovery to work at all. Here, participation is possible without sole authority.
ActivityPub identities are constitutively bound to a domain: @[email protected]. The domain is not an address but part of the identity itself. In a federal system where each state runs its own instance, identity is therefore state-bound — and it ends when the state stops operating. Mastodon's Move migrates followers but not content, and requires the origin instance to still be running and cooperating.
The more serious issue is reference integrity. If state A cites resources from state B in collections, curriculum mappings or learning paths, and B shuts down its instance, it is not only accounts that break but every reference to them. In an infrastructure built for cross-state reuse, that is a structural defect rather than an operational risk.
In Nostr the key is the identity. Domains still appear via NIP-05, but as a revocable, replaceable attribute rather than a foundation. A state can shut down its relay without breaking a single identity or reference; the events remain verifiable on any other relay. Responsibility for operations is thus decoupled from responsibility for identity — a far better fit for federal reality than a model in which one state's exit devalues everyone else's data.
## atproto: portability (but with a directory caveat)
The AT Protocol addresses this. Identity there is a DID, not a domain; the handle is merely an alias proven via DNS or HTTP and can be changed without breaking the identity. Migrating between Personal Data Servers is supported, and repositories can be exported and re-imported elsewhere. Rotation keys even let an identity survive loss of the signing key — but only because in normal operation the PDS operator holds such a key in trust. Recoverability is solved organisationally, not cryptographically: whoever can rescue the identity can also alter it. The tie to an operator is loosened, not removed.
The second caveat concerns resolution itself. `did:plc`, the method used almost exclusively in practice, is not a self-certifying identifier but points to a central directory, so far operated by Bluesky PBC. It is auditable, but its failure interrupts identity resolution network-wide, and its operator can change without the federation having any say. For public education infrastructure planned in decades, this merely relocates the dependency: from a state domain to a commercially operated registry in another jurisdiction. The alternative, `did:web`, avoids that but reintroduces exactly the domain binding we set out to escape.
## The Eurosky case
The obvious rejoinder is that sovereign European atproto infrastructure already exists. Eurosky (https://eurosky.tech/), a project of the Dutch Stichting Modal, runs its own Personal Data Server: data sits in Hetzner facilities in Falkenstein, Eurosky operates the service itself, the contract is held by the foundation, and the service falls under European law including GDPR and DSA. That is substantial and relevant for public bodies.
But it concerns the hosting layer, which was never the problem: that anyone may run a PDS is an explicit design feature and permissionless by intent. **The identity layer is untouched: a Eurosky account still carries a did:plc identity resolved against the same central directory**. Data held in Germany, identity resolved through a registry in foreign hands — for an argument resting on digital sovereignty, that is a solution at one layer, not throughout. The rotation-key trust relationship likewise only shifts, from Bluesky PBC to a Dutch foundation: still operator-mediated.
There is also the protocol's practical shape. atproto is built around a few large aggregators processing the whole network's traffic; as of early 2026, Bluesky PBC still ran the only full-network AppView. That suits a platform, less so a landscape of sixteen states, media centres and other bodies each running small nodes and exchanging selectively.
## Key loss
The obvious objection to key-based identity: what happens when a key is lost, and who is responsible in an administrative context? It must be addressed, but it is solvable.
For individual users, FROSTR and pomegranate offer approaches based on FROST signatures, standardised as RFC 9591: the key is split into shares, and signing requires k of n.
The contrast with the atproto model is therefore precise: there, one party must be able to act alone for recovery to work at all. Here, participation is possible without sole authority.
32❤️1💯1🚀1🤙1
