What sovm is
sovm (Sovereign Mesh) is a data plane for peer-to-peer data meshes. It replicates a dataset across a set of machines under one trust authority, in a form the machines holding it cannot read. Its preferred live transport substrate is iroh: public-key addressed, QUIC-based, direct where possible, NAT-traversing when needed, and relay-assisted when direct paths are unavailable.
This page is the ten-minute version. The normative details live in two specifications — SSP/1 for synchronization, identity and mutable state, and SOP/1 for the encrypted object plane. The protocol family explains the split.
What “sovereign” means here
Section titled “What “sovereign” means here”One authority holds the keys and sets the policy for a mesh. Everything else follows from that.
That authority is deliberately unspecified: a person with four devices, a household, a lab, a small team, an organization. sovm does not model who or how many. What it does model is a boundary, and it enforces the boundary cryptographically rather than administratively — so an operator running the hardware, a hosting provider, or a storage vendor is outside it by construction and cannot be brought inside by a configuration mistake.
The mesh is not a protocol for exchanging data between mutually distrusting parties. It replicates within one authority. That constraint is what makes the key hierarchy simple enough to reason about.
Privacy is the constraint, not a feature
Section titled “Privacy is the constraint, not a feature”It is worth being concrete about what “privacy is paramount” actually bought in the design, because it is visible in decisions that would otherwise have gone the easy way:
- Encryption is per object, with a fresh random key each time, rather than one key for the dataset.
- The Parquet footer is encrypted, so a holder cannot read the schema, column statistics, or row counts — not just the values.
- Identifiers on the wire are opaque. Domain names, table names, and schema names are protected metadata; a relay routing a message learns none of them.
- Object sizes are padded to a target-length function, so size alone leaks less about content.
- There is no vendor-held recovery key, which also means no third party can be compelled to produce one.
- Query planning uses an encrypted catalog, so the metadata that makes queries fast does not have to be exposed to make them fast.
Each of those costs something in complexity or performance. That is the trade the design makes on purpose.
The shape of the problem
Section titled “The shape of the problem”sovm targets datasets with an awkward combination of properties that existing tools each satisfy only partly.
- Mostly append-only. A recorded measurement does not change.
- Large relative to the machines holding it, and some of those machines are constrained — metered connections, limited storage, battery.
- Must survive any single machine failing, which means replicas.
- Those replicas should be cheap and untrusted — spare hardware, a home server, rented capacity.
- Producers are frequently offline and must keep collecting while disconnected.
- Access must be revocable: a decommissioned or stolen machine must lose future access.
File sync handles size and replication but treats the dataset as opaque files with no notion of who may decrypt what. A hosted database handles queries and revocation but requires trusting the host. Row-level replication protocols handle merge semantics correctly but pay a per-row cost that is absurd for a hundred million immutable append-only records.
Five ideas
Section titled “Five ideas”1. Use the cheapest correct replication primitive
Section titled “1. Use the cheapest correct replication primitive”Mutable data needs conflict resolution. Immutable data does not. sovm therefore
splits the work between its two layers: SOP/1 asks every table to declare
a mutation class — APPEND, APPEND_DELETE, or MUTABLE –
and the mutable class is handed down to SSP/1.
Append-only tables become immutable encrypted objects replicated by content address. Adding an object is commutative and idempotent, so there is no global sequence number and no coordination. Genuinely mutable state — configuration, entity records, catalog metadata — replicates as signed change events that merge deterministically, per column, ordered by a hybrid logical clock (SSP/1 semantics). The same state on every machine, and no coordinator in either path.
2. Ciphertext is the persistent object
Section titled “2. Ciphertext is the persistent object”The thing that exists on disk and on the wire is an encrypted Parquet file. Plaintext is transient computation state on an authorized machine. This is an architectural invariant rather than a deployment option, which is what makes the next idea possible.
3. Storing is not reading
Section titled “3. Storing is not reading”A machine that stores an object does not thereby gain the ability to decrypt it. SOP/1 keeps two formally distinct sets: the machines that hold ciphertext, and the machines that can decrypt it. Neither is inferred from the other.
That is what makes a blind replica a first-class participant rather than a workaround. An archive can carry the complete dataset and be cryptographically unable to read any of it.
4. Delegate the group cryptography
Section titled “4. Delegate the group cryptography”The hard part of a multi-machine system is not encrypting a file; it is tracking which machines currently hold which keys, and making revocation mean something. The family does not invent protocols for that. Admission itself is human-anchored in SSP/1 — a pairing ceremony or a vouch quorum, confirmed by a person, defaulting to deny. The cryptographic group state that follows uses MLS (RFC 9420) for cryptographic group membership and COSE (RFC 9052) as the container for keys, signatures, and durable records.
Machines are grouped into a small number of cryptographic domains, each with an application key that MLS distributes to its members. Removing a machine advances the group and mints a new key generation the removed machine never receives.
Crucially the key hierarchy is separate from the object encryption, so rotating a domain key does not rewrite a single data file — only the small access record carrying each object’s key is replaced.
5. Let the transport find the path
Section titled “5. Let the transport find the path”The mesh is not a VPN-shaped requirement for a flat, pre-arranged network. Its preferred live substrate is iroh: endpoints are addressed by cryptographic public keys, the transport runs over QUIC, and peers try the fastest direct path first. iroh hole-punches through NATs where it can and falls back to relay servers when a direct connection cannot be made.
That is the useful sense in which the network heals around the nodes — iroh
maintains the best available connection rather than making the application care
which route won. The relay carries encrypted traffic, never plaintext, and SSP/1
still owns delivery, retries and convergence on top of it. Object transfer rides
the same substrate: an object’s storage_id
is the iroh-blobs hash of its exact encrypted bytes, which is
where verified streaming, resumption and range transfer come from.
What this buys, concretely
Section titled “What this buys, concretely”| Requirement | How it is met |
|---|---|
| Cheap untrusted replicas | Blind replicas hold ciphertext with no domain key |
| Survives machine loss | Content-addressed objects on multiple replicas, plus catalog checkpoints and a recovery root |
| Works across real networks | iroh dials by endpoint identity, tries direct QUIC paths, hole-punches through NATs and falls back to encrypted relays; SSP/1 handles delivery and convergence |
| Works offline | Objects are formed locally and published on reconnect; no master node |
| Concurrent edits converge | Signed, clock-ordered events merged per column (SSP/1); the same state everywhere, whatever the delivery order |
| Revocation means something | One keyring removal kills the node’s events, vouches and connections (SSP/1); MLS removal rotates the domain key generation (SOP/1) |
| Queries stay local | Encrypted Parquet queried in place by a local engine, planned from an encrypted catalog |
| Rotation is cheap | Key rotation replaces access records, never the data objects |
Boundaries
Section titled “Boundaries”SOP/1 has an explicit non-goals list. The ones most likely to matter:
- One trust authority per mesh. No cross-party sharing, and no collaborative multi-writer editing semantics.
- No distributed transactions and no global commit order for data. Objects converge as a set; that is the entire consistency model for append data.
- No retroactive revocation. A machine that was authorized read what it read. Revocation is future-facing and the specification says so plainly.
- No traffic-analysis resistance. Sizes are padded and identifiers opaque, but a storage provider still sees that something arrived and roughly how large.
- No vendor recovery key. Nobody else can decrypt your data, which also means nobody else can restore it for you.
Where to go next
Section titled “Where to go next”For the mechanism, read how it works. For the normative text, start at the protocol family. For what actually exists today, read the implementation status — it is short, and more honest than the rest of this page implies.