Goals, principles and architecture

1. Goals and Non-Goals

1.1. Goals

SOP/1 Revision 8 aims to provide:

1. Efficient synchronization for a workload dominated by append-only data.
2. Efficient logical deletion without requiring immediate large-file rewrites.
3. Preservation of SSP/1 semantics for small mutable datasets.
4. Fleet-private data both in transit and at rest.
5. Cryptographic enforcement of data scope, not only sender-side policy.
6. Removal of as much bespoke cryptographic protocol as practical.
7. Offline-first data production without a master data node.
8. Efficient local analytical queries over encrypted Parquet.
9. Storage-engine independence at the synchronization layer.
10. Compatibility projection to standard analytical lakehouse formats.

1.2. Non-goals

SOP/1 does not attempt to provide:

• general distributed transactions;
• synchronous consensus for ordinary data writes;
• a global commit DAG for data objects;
• arbitrary concurrent schema editing;
• multi-user collaborative group semantics;
• ORAM or complete traffic-analysis resistance;
• guaranteed erasure from a previously compromised authorized node;
• synchronization of DuckDB database files or WALs;
• replacement of SSP/1’s mutable row conflict semantics;
• a SOVM-specific replacement for MLS;
• a SOVM-specific replacement for Parquet encryption.

2. Architectural Principles

2.1. Use the cheapest correct replication primitive

The dominant workload is append-only.

The system MUST NOT pay mutable-row synchronization costs for immutable analytical data.

The default high-volume write path is:

flowchart TD
  accTitle: The default high-volume write path
  accDescr: Rows are encoded to Parquet, encrypted with Parquet Modular Encryption, become an immutable encrypted object, and are replicated by content address.
  rows[rows] --> parquet[Parquet]
  parquet --> pme[PME encryption]
  pme --> obj[immutable encrypted object]
  obj --> repl[content-addressed replication]

2.2. Keep SSP where semantic conflict actually exists

SSP/1 remains the correct mechanism for state that can be concurrently edited on multiple nodes and must converge under deterministic semantic rules.

2.3. Standards before bespoke cryptography

Where an established protocol solves the cryptographic problem, SOP SHOULD use it instead of defining a parallel custom primitive.

In particular:

• MLS owns cryptographic group state.
• PME owns Parquet data and metadata encryption.
• Existing cryptographic libraries own primitive implementations.
• SOVM owns policy, identity binding, object semantics, and authorization.

2.4. Ciphertext is the persistent object

Plaintext user data is transient computation state.

The canonical SOP object MUST be an encrypted Parquet file or another explicitly approved encrypted object format.

2.5. Membership coordination is acceptable; data-write coordination is not

MLS maintains an ordered group epoch history.

SOP accepts that coordination cost because fleet and scope membership changes are rare and security-sensitive.

Ordinary data writes MUST NOT require MLS Commit operations.

2.6. Authorization precedes cryptography

MLS does not determine whether a node should be trusted.

SSP trust policy determines admission and scope.

MLS executes the resulting cryptographic membership state.

2.7. Historical readability is an application concern

MLS protocol state is intentionally forward-secret and disposable.

Historical SOP access keys required for long-term data access MUST therefore be managed as application key material distinct from retained MLS protocol state.

2.8. MLS transports application keys; it does not define their lifetime

The domain KEK is an independently random SOVM application key distributed over the authenticated MLS channel.

Routine MLS Updates and other non-membership epoch changes MUST NOT automatically create a new SOP KEK generation.

This decouples long-lived data access from the internal cadence of MLS epochs while retaining MLS as the membership truth and secure group channel.

2.9. Reuse standard CBOR security containers

SOP MUST use COSE rather than bespoke binary cryptographic wrappers for wrapped keys and durable signatures.

SOP CBOR payloads covered by signatures SHOULD use deterministic CBOR encoding as specified by the SOVM COSE profile.

3. System Architecture

The system is divided into five responsibilities:

flowchart TD
  accTitle: The five responsibilities of a sovm node
  accDescr: Application queries reach a local engine, which reads both mutable SSP state and the SOP object plane. Both sit above SSP policy and identity, which drives MLS group membership, which in turn uses either the asynchronous SSP mailbox or iroh for live transport.
  app[Application / Query] --> engine[DuckDB / local engine]
  engine --> msp[SSP state<br/>mutable semantics]
  engine --> mop[SOP object plane<br/>append / delete<br/>encrypted PME]
  msp --> policy[SSP policy / identity<br/>pairing / scope / roles]
  mop --> policy
  policy --> mls[MLS / OpenMLS<br/>group membership<br/>epochs / exporters<br/>control encryption]
  mls --> mailbox[SSP mailbox<br/>asynchronous]
  mls --> iroh[iroh / iroh-blobs<br/>live transport]

The architectural shorthand is:

Layer	Role
SSP	who and what
MLS	which members hold which current group secrets
PME	how analytical objects are encrypted
SOP	what immutable objects mean
iroh	how bytes move
DuckDB	how local analytical computation runs
Delta	how data is projected outward