Abstract and scope

Specification status

SOP/1 is implementable and stable enough to build against, but it is not yet a ratified production protocol: promotion depends on the ten decision gates on the status page. Where a gate has not passed, treat the corresponding text as a design commitment rather than a shipped guarantee.

SOP/1 is the upper of the two Sovereign Mesh layers. It depends on SSP/1 for node identity, pairing, trust policy, data scope, hybrid logical clocks, the mutable-table merge semantics it deliberately does not restate, and the asynchronous mailbox. Read SOVM/1 first if you have not.

Abstract

This document specifies the Sovereign Object Plane (SOP/1), a content-addressed immutable-object data plane layered alongside the host Sovereign Synchronization Protocol (SSP/1).

The principal data-plane decision: high-volume append-only and append-and-delete datasets are replicated as immutable Parquet objects rather than as one SSP change event per row, while small genuinely mutable datasets remain under SSP/1’s deterministic row-level merge semantics.

Each design decision is stated in the section that makes it; this document carries no separate decision index.

SOP/1 deliberately specifies no bespoke fleet group-key protocol and no bespoke whole-object encryption envelope. Instead:

• SSP defines identity, trust policy, pairing/vouching policy, data scope, and authorization decisions.
• Messaging Layer Security (MLS), as specified by RFC 9420 and implemented initially using OpenMLS, manages cryptographic group membership, membership epochs, removal, forward-secret control messaging, and exporter secrets.
• Cryptographic scope is represented by a small number of MLS domain groups, not by one universal fleet content key and not by one group per table.
• Each domain has an independently random application KEK. MLS distributes the KEK to authorized members; routine MLS epoch changes do not rotate it. Domain KEK generations change only on membership-security transitions such as removal, compromise response, or an addition that must not gain history.
• COSE (RFC 9052/9053) is the normative container for access/wrapped-DEK records, immutable producer manifests, durable control records, and historical key-history packages.
• DEK rewrapping is entitlement-aware: an AccessRecord is never created under a KEK generation whose holders include a node not entitled to the underlying object.
• Parquet Modular Encryption (PME) is the canonical encryption mechanism for SOP analytical data objects.
• Each Parquet object uses a random per-object data encryption key (DEK).
• The DEK is referenced by an opaque key reference and wrapped outside the Parquet file under the current application domain KEK.
• The canonical storage identity is defined to be the exact iroh-blobs 32-byte BLAKE3 root hash of the encrypted Parquet bytes; SOP does not compute or maintain a second content hash.
• Iroh transports opaque MLS messages and encrypted SOP objects; iroh-blobs is the preferred large-object transfer mechanism.
• The existing SSP store-and-forward mailbox remains distinct from an iroh relay and remains necessary for peers that are never online simultaneously.
• DuckDB is the preferred local analytical engine, but remains a materializer and query engine rather than the unit of replication.
• Delta Lake is the decided lakehouse interoperability target; the projection remains derived and never becomes the source of truth for mesh history.

The resulting system deliberately minimizes bespoke cryptographic protocol. SOVM retains product-specific authorization and data-model semantics while delegating generic group key establishment and Parquet encryption to standardized mechanisms.

OpenMLS mobile support, secure-element integration, MLS fork/orchestration behavior, PME performance, and encrypted key-store behavior require implementation gates before this design becomes normative for production.

Conventions

The requirement keywords and the encoding rules are the specification’s conventions. Durable signed records in this part follow the SOP/1 COSE profile over the substrate’s container, and the registry indexes every content type and label.

Terminology

SOP/1 shares its vocabulary with the rest of the specification: node, mesh, trust authority, site_id, mesh_id, HLC and mailbox mean here exactly what SSP/1 terminology says they mean. Where a word means something different in each layer — tombstone, purge, scope, domain, generation — terminology holds the distinction.