Abstract and scope

Specification status

This is the frozen architecture baseline for SOP/1. It is implementable and stable enough to build against, but it is not yet a ratified production protocol: promotion depends on the ten decision gates in section 27. 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 the protocol family first if you have not.

Abstract

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

The revision preserves the principal data-plane decision of the earlier proposal: 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.

Revision 3 tightened the cryptographic and operational architecture; Revision 4 closed four design gaps identified in review (entitlement-aware rewrapping, unique KEK generator, supersession verification, sequencer state rules); Revision 5 resolved the open questions into recorded decisions (Section 28), selected Delta Lake as the lakehouse target, and fixed the credential, authorization-artifact, KEK-retirement, key_ref, domain-taxonomy, and group-recovery policies.

Revision 6 applied external review, correcting seven points around APPEND_DELETE semantics, supersession GC, sequencer equivocation, domain migration, recovery durability, row-identity filtering, and authorization history.

Revision 7 closed four remaining structural issues:

• The former mutable “descriptor” is split into an immutable producer-signed ObjectManifest and independently replaceable, access-authority-signed AccessRecord objects. Rewraps and table-to-domain migration therefore change access records without altering producer provenance.
• Permanent identity tombstones are made genuinely permanent logical knowledge. Delete objects MAY be compacted, but the tombstone identity set MUST remain represented for as long as the table’s identity namespace can accept late data; expected-offline-time is no longer a correctness bound.
• Blind-sequencer state-loss recovery uses retained signed receipt-chain evidence plus MLS-state attestation. Divergent valid receipt histories fail closed as proof of prior equivocation; absence of usable receipts falls back to domain genesis reset.
• Recovery no longer depends on an iroh-local tag. A SOVM RecoveryRoot record names the catalog checkpoint and its bootstrap access record; iroh tags may pin it locally but are not protocol state.

Revision 8 freezes the architecture as the implementation baseline for Phase 0. It makes three final corrections from closing review and no further design changes:

• Gate G4 tests receipt-based sequencer state-loss recovery (fail-closed on divergent chains, genesis-reset fallback), replacing the obsolete member-re-attestation wording.
• entitlement_class in the AccessRecord is defined: it records the Section 8 historical-entitlement mode under which the access grant was issued, and participates in the Section 7.6 entitlement check.
• The AccessRecord carries issued_hlc for audit ordering, and the issuer-authority argument is stated explicitly: encryption under K_domain_generation proves domain membership at that generation, which anchors issuing authority in the domain’s security history more strongly than any claimed timestamp.

Subsequent changes to this document require a new RFC, not a revision: architecture review has reached diminishing returns, and the two remaining open items (O1, O2) are implementation-time decisions gated in Phases 4 and 5 respectively.

SOP/1 no longer proposes a bespoke fleet group-key protocol or a bespoke whole-object encryption envelope as the preferred production design. 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 (deferred to Phase 5); 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.

This memo proposes; it does not decide. 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 and terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY and OPTIONAL in this specification are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in capitals.

SOP/1 shares its vocabulary with SSP/1: node, mesh, trust authority, site_id, mesh_id, HLC and mailbox mean here exactly what they mean there. Durable signed records across both layers follow one COSE discipline — the family registry indexes every content type and label, and section 7.10 defines this layer’s profile.