Rhyzome: An idea for identity sovereignty

Disclaimer: This is an early AI assisted draft document, but I felt it important to publish both for provenance and to start spreading the idea.

Mission

Rhyzome is a sovereign identity infrastructure project built on the conviction that digital identity should belong to the person it describes. Every major identity system today — Google, Facebook, government platforms, even decentralized protocols like ATProto's did:plc — places identity in someone else's hands. Rhyzome is the missing layer: terrain-first identity, owned by the user, portable across any infrastructure.

The name comes from the fungal rhizome — a decentralized, rootless network with no center to attack. It is deliberately misspelled, and the misspelling stays.

The Problem

Every time a user logs in with Google, Google learns about another service they use. Platforms build detailed maps of their users' digital lives not from reading messages but from watching logins. Centralized identity is surveillance infrastructure by default. When platforms comply with authoritarian pressure — and they do, because they have no choice — user identity goes with them.

ATProto solved data sovereignty. It did not solve identity sovereignty. did:plc identities are controlled by Bluesky's PLC directory. did:web identities depend on DNS and web hosting. Neither is genuinely sovereign.

Rhyzome solves the half of the problem ATProto left open.

The Architecture

did:rns — A Sovereign DID Method

Rhyzome introduces did:rns, a new DID method built on the Reticulum network stack. Reticulum addresses are generated from cryptographic keypairs, making collisions exceedingly rare by construction. The address is the identity — no registration, no namespace authority, no collision resolution. The DID exists the moment the keypair is generated.

Each did:rns identity is served by a personal identity server. The identity server owns the DID document. Resolution routes through the Reticulum network to the identity server, which serves the document authoritatively. No third party can alter or revoke it.

Reticulum announces are augmented to carry did:key identifiers, abstracting over multiple encryption schemes and enabling algorithm agility without protocol changes. The did:rns identity is derived from the same public key, cryptographically linking the two.

The Personal Identity Server

The personal identity server is a containerized application — the fundamental unit of Rhyzome's architecture. The container is the DID document authority. Moving it from managed hosting to personal hardware is a sovereignty transfer: the same artifact, running in a different place.

The server is built in Rust for memory safety, minimal footprint, and predictability on modest hardware. A Python Reticulum sidecar handles network communication initially, replaced by a Rust Reticulum implementation when complete.

The Reticulum Network

Reticulum is a cryptographic network stack designed for resilience and infrastructure independence. It runs over any available medium — IP, LoRa, packet radio, or whatever is available. Rhyzome uses Reticulum-over-IP initially, with the network becoming progressively more resilient as physical nodes proliferate. The identity is transport-agnostic by construction. IP dependency is a bootstrapping convenience, not a structural requirement.

OIDC Bridge

Rhyzome provides an OIDC-compliant bridge, making did:rns identities usable as login credentials anywhere that accepts "Sign in with Rhyzome." Enterprises integrate via standard OIDC — no new protocols to learn. The Reticulum backbone is internal architecture. The user sees one button. The enterprise sees one integration.

The Claims System

Rhyzome introduces a general-purpose sovereign claims system for making verifiable assertions about identity. The design is deliberately expressive — the protocol does not specify which claims are valid. Any claim a user wants to make about themselves is supported.

Each claim consists of:

• source — a DID identifying who attested the input
• encrypted_input — a public blob, encrypted by the source with the user's public key and signed by the source, so the signature is publicly verifiable without revealing the contents
• output — the result of the computation
• circuit — an AT URI referencing a circuit record in the ATProto ecosystem, specifying the arithmetization method via record type
• proof — a self-describing blob prefixed with the proof system identifier, interpreted without external resolution, similar to did:key

The ZK proof proves that the circuit was executed correctly on the encrypted input, that the source's signature verified, that decryption was correct, and that the computation produced the claimed output — all without revealing the decrypted input to anyone. The source encrypts and signs the input. The identity server decrypts inside the circuit. The verifier sees only public inputs and the proof.

Input trust is established by the source signature, verified inside the circuit itself. The verifier resolves the source DID to obtain the public key — governments use did:web since they already have domains. The protocol is agnostic to source trust decisions; verifiers and resources make those judgments independently.

Claims and proofs are stored as records on the user's ATProto PDS, reusable across subsequent authentications. Generating a proof is computationally expensive; storing and reusing it is free. Three lexicon namespaces cover the ecosystem:

• com.rhyzome.circuit.<arithmetization> — circuit definitions, stored on ATProto PDSes, discovered via AppViews
• com.rhyzome.proof.<proof-system> — stored proof records
• com.rhyzome.claim — complete reusable claim records

Capability Trees Integration

Rhyzome runs the first Capability Trees verifier service for ATProto. Capability Trees governs permission sovereignty — what applications are authorized to do with user data. The claims system governs identity attribute sovereignty — what applications are authorized to know about users. They are complementary authorization layers.

A resource's Capability Trees policy can require a specific circuit and source for a given claim, expressing compliance requirements as protocol-level policy. The resource's liability reduces to policy specification. They never touch identity documents. They never store sensitive data. The verifier enforces everything else.

The ATProto PDS with Address Book Abstraction

Rhyzome forks BlackSky's Rust PDS implementation, adding an address book abstraction that decouples internal data references from external DIDs. Identity migration becomes a pointer update rather than a data migration.

During migration to the address book PDS, every DID found in existing data is scanned. If it resolves with alsoKnownAs, the address book maps the old DID to the new one automatically. If it resolves without alsoKnownAs, a transparent self-mapping entry is created as a future-proof placeholder. If resolution fails, the entry is flagged for manual review with a retry option. Manual address book editing is always available as an escape hatch.

This creates a natural forcing function for ecosystem adoption. When a user migrates to did:rns, links break for friends on non-address-book PDSes. Those friends migrate to address book PDSes to restore them, scanning alsoKnownAs declarations to reconstruct the mappings. The wave propagates through the social graph until address book adoption is universal — at which point Bluesky adopts it for everyone else, assisted by a Rhyzome PR.

The Sovereignty Journey

A user achieves full sovereignty in three steps, each independently valuable:

1. Migrate to Rhyzome's PDS — data sovereignty, migration-ready infrastructure, existing DID still works
2. Migrate to did:rns — identity sovereignty, no platform dependency, data history continuous via address book
3. Acquire and set up the personal identity server kit — full sovereignty, Rhyzome becomes a bridge

After step three, Rhyzome only knows when the user logs in. That's it. The kit is plug-in, power-on hardware running a Rust-only identity server — the Python sidecar is never shipped on the kit. The managed service validates the Rust implementation in production before it ever reaches hardware.

Bridges are fungible. The protocol is open. The identity lives on hardware the user owns. Leaving Rhyzome does not mean losing the identity.

The Business Model

Rhyzome has three revenue streams that reinforce each other:

Managed hosting — a subscription service for users who want sovereignty without immediate hardware. Each user's identity server runs in an isolated container. The managed service is a funnel and onboarding experience, not a retention target. Churn to the kit is a success metric.

Personal identity server kit — plug-in hardware with the full Rust identity server. Sold after the Rust rewrite is complete and production-validated. Kit owners graduate from managed hosting, reducing the managed service's infrastructure burden naturally. The managed service never needs to scale indefinitely.

Enterprise OIDC bridge — B2B SaaS for organizations adopting "Log in with Rhyzome." Each user exists in the system once, on their own hardware. Enterprises get OIDC compliance, liability reduction, and a compliance story reducible to policy specification. The more regulatory pressure increases, the more valuable the service becomes, and the more revenue flows to Rhyzome.

Enterprise revenue is invested in strengthening the Reticulum network. The more the regulatory environment tightens, the more resources Rhyzome has to build infrastructure that resists it. The more the Reticulum network strengthens, the more resilient did:rns resolution becomes. The more users join, the stronger the enterprise pitch. Every flywheel points in the same direction.

As enterprise revenue grows, user costs go down. This is a commitment, not a marketing statement.

The Philosophical Foundation

Rhyzome is the applied implementation of Cartography theory — the recognition that map supremacy, the mistake of treating abstractions as reality, is the root of much that goes wrong in human systems.

Centralized identity systems are map supremacy applied to personhood. Google, Facebook, and governments define users through their schemas, their databases, their categories. The identifier exists in their map. They can redraw it, erase it, or hand it to whoever asks.

did:rns is terrain-first identity. The identity exists because the user exists cryptographically. No one drew them into a map. The identity is self-certifying.

Rhyzome is Katocratic infrastructure — enforcement lives in the protocol, not the application. Authority flows downward, accountability flows upward. The structure serves what generated it.

The fungal lineage is intentional: Rust and Reticulum were named after fungal things by coincidence. The pattern was noticed and followed. Rhyzome — the rootless, decentralized, damage-resistant underground network — was chosen deliberately. Fungi have no center. You cannot cut off the head because there is no head.

Current Status

Idea stage. Initial build targets the Reticulum community with a Docker image — Python sidecar included, since that community already runs Reticulum. The Matrix room is the first audience. The managed service follows, funded by early subscribers. Enterprise revenue follows the managed service. The kit follows the Rust rewrite. Each phase funds and validates the next.

The founder is a Gen Z software engineering graduate building bootstrapped, hiring Gen Z first, with open source contributors always having first dibs on positions. The mission is the filter. The results are the arbiter.

Rhyzome. ATProto solved data sovereignty. We solve the other half.