No master node, no global sequence number, no agreement on the write path.

Machines produce data while disconnected and publish on reconnect. Gateway nodes on metered or unreliable links are a normal case rather than a degraded one, and there is no coordination tier anchoring a deployment to one region.

Scope and placement are separate concerns: which objects belong to a dataset is decided independently of which machines carry them, so capacity planning does not reopen access decisions.

iroh crosses the network you actually have

iroh dials by cryptographic endpoint identity, attempts direct QUIC connectivity, hole-punches through NATs where possible, and falls back to an encrypted relay when a direct path is unavailable.

Untrusted hops are a routing detail

Data can traverse an existing object store, a bucket in an account you do not administer, a message bus, a DMZ hop, or rented archival capacity. Relays are required not to have plaintext access — the encrypted object is what moves, not a plaintext representation.

Integrity survives the path

An object's identity is the hash of its encrypted bytes, so integrity is verifiable regardless of how many untrusted hops it took.

Revocation is an MLS membership operation

Removing a machine triggers an MLS epoch rotation. Subsequent objects are encrypted to the new epoch. The effect is cryptographic, not a policy promise.

Two planes, one transport. SSP/1 for mutable control state; SOP/1 for immutable objects.

SSP/1 handles everything that changes: who is a member, what the current key epoch is, what catalog metadata exists. It uses a Merkle-DAG structure that merges without coordination and applies deterministically on any node that has seen the same operations.

SOP/1 handles high-volume immutable data as content-addressed encrypted Parquet objects. Once written, an object is identified by the hash of its ciphertext and never changes under that identifier.

Both planes share iroh as the preferred transport. The transport is a binding choice — swapping iroh for another QUIC or relay implementation is possible by implementing the transport abstraction, without changing the protocol semantics.

SSP/1: mutable control state

Identity, trust, policy, catalog metadata, and entity records. Synchronizes as a Merkle-DAG; deterministic merge without coordination.

SOP/1: immutable object plane

High-volume encrypted Parquet. Content-addressed; once written, never changes. The encrypted catalog carries time ranges and value bounds for pre-decryption selection.

Transport independence

iroh is the preferred live transport. The abstraction layer can bind to another QUIC implementation or a relay substrate without touching protocol semantics.

One explicit export boundary

The interoperability projection is derived and never authoritative. Producing it is an export operation that must not happen as transparent background replication.

Objects are encrypted Parquet, so the analytics stack does not change.

Once decrypted on an authorized node, objects feed Arrow, polars, DuckDB and standard data loaders directly, with column pruning intact. There is no duplicate copy maintained for governance to lose track of.

The encrypted catalog carries time ranges and value bounds, so selection happens before decryption and only the matching objects are ever opened. An authorized compute node bootstraps from a directory of objects: verify the producer signature, check membership, decrypt.

Note — Evaluate against the spec, not a product

Neither layer has a released implementation. SOP/1 is a frozen architecture baseline with ten open decision gates; SSP/1's conformance corpus does not exist yet.

Note — Single trust authority

One authority holds the keys and sets policy. sovm does not provide cross-tenant sharing between mutually distrusting parties, nor collaborative multi-writer editing semantics.

Note — Operational metadata is observable

Storage providers still see object sizes and transfer timing.

Note — Fleet scale is unproven

The design targets a fleet of tens of machines. Membership latency is acceptable because membership changes are assumed rare; neither assumption has been validated for thousands of intermittently connected nodes.