Appendices

These appendices are non-normative. They illustrate the specification and carry no requirement of their own; where one appears to disagree with a numbered section, the section governs.

Appendix A. Responsibility matrix

Concern	Owner
Stable node identity	SSP
Human pairing policy	SSP
Vouching	SSP
Node roles	SSP
Table/domain scope	SSP
Admission decision	SSP
Removal decision	SSP
Group membership crypto	MLS / OpenMLS
Group epoch transition	MLS / OpenMLS
Control-message crypto	MLS PrivateMessage
Domain KEK distribution	MLS PrivateMessage + SOP application key
Historical key policy	SOVM SOP
COSE key/sign containers	RFC 9052/9053 + SOVM profile
Per-object DEK	SOVM SOP
Parquet encryption	PME
Encrypted object ID	iroh-blobs BLAKE3 hash (Section 11.7)
Object semantics	SOP
Mutable row convergence	SSP/1
Live transport	iroh
Large-object transport	iroh-blobs
Async mailbox	SSP mailbox
Local analytics	DuckDB / host engine
External lakehouse view	Delta Lake projection

The important boundary is:

SSP decides membership and scope.
MLS makes membership cryptographically real and securely distributes
application KEKs.
COSE standardizes SOP key/signature records.
PME makes stored analytical data cryptographically private.
iroh-blobs defines the canonical object hash and verified byte transfer.

Appendix B. Privacy invariants

A conforming production SOP implementation MUST preserve the following invariants.

1. Canonical SOP analytical objects are PME-encrypted.
2. PME encrypted-footer mode is used for SOP-PME-1.
3. All columns are encrypted in SOP-PME-1.
4. Every object receives a fresh random DEK.
5. Untrusted storage never receives an unkeyed plaintext content hash as the object identifier.
6. Semantic key names do not appear in PME key_metadata.
7. Every SOP-PME object is verified against its storage_id before any plaintext derived from it is released.
8. Wrapped DEKs and semantic object metadata are protected from untrusted storage.
9. Cryptographic domain membership does not exceed SSP-authorized scope.
10. Out-of-scope nodes do not receive applicable domain-group secrets.
11. Historical access for a newly added node is explicit.
12. Obsolete MLS protocol secrets are not retained merely for historical lake access.
13. Historical SOP keys are protected separately under node-local encrypted storage.
14. Iroh sees already-encrypted bulk object bytes.
15. The SSP relay sees opaque MLS/SOP ciphertext, not user plaintext.
16. Query and compaction paths do not intentionally persist plaintext scratch files.
17. Production debugging does not expose user plaintext or key material.
18. Node removal blocks future epoch secrets and future accepted publication.
19. The product does not claim retroactive forgetting by an already compromised authorized node.
20. Plaintext export to an incompatible external lakehouse is explicit user release, not transparent replication.
21. Full-disk encryption is defense in depth, not the sole protocol privacy guarantee.
22. Loss of all MLS protocol state is never data loss provided at least one recoverable copy exists of the SOP ciphertext, its immutable ObjectManifest plus applicable AccessRecord state, and the necessary application KEK history (Section 12.7); recovery is rooted by RecoveryRoot and, when MLS state itself is lost, completed by the domain genesis reset (Section 22.10).

---

Appendix C. Example lifecycle

Consider four nodes:

Symbol	Node
L	laptop
P	phone
H	home server
K	kitchen hub

SSP policy:

flowchart LR
  accTitle: Domain membership in the worked example
  accDescr: The control group holds all four nodes, the SENSOR domain holds the laptop and phone, and the LEDGER domain holds the laptop and home server.
  CONTROL --- L
  CONTROL --- P
  CONTROL --- H
  CONTROL --- K
  SENSOR --- L
  SENSOR --- P
  LEDGER --- L
  LEDGER --- H

C.1. Create an object

Phone P is a current SENSOR MLS member and holds SENSOR KEK generation 4.

It records 100,000 measurement rows.

flowchart TD
  accTitle: Creating an object on an authorized producer
  accDescr: Rows become Parquet, are encrypted under a fresh random data key, and the resulting object yields a content hash, a producer-signed manifest, an access record wrapping the data key under the current domain key generation, and an encrypted catalog entry.
  rows[rows] --> parquet[Parquet]
  parquet --> dek["random DEK D1"]
  dek --> enc[PME encrypt]
  enc --> obj["object O1"]
  obj --> sid["storage_id = iroh-blobs hash(O1)"]
  obj --> man["COSE_Sign1_producer(ObjectManifest)"]
  obj --> acc["COSE AccessRecord(D1, K_gen4)"]
  obj --> pub[encrypted catalog-entry publication]

O1 may be copied to L, H, or blind archive storage.

H may store O1 without receiving SENSOR decryption membership if policy allows blind storage.

C.2. Phone goes offline

P remains on an older SENSOR MLS state.

L and H continue operating.

If no membership-security transition occurs, P can reconnect, process ordinary MLS updates, confirm that SENSOR KEK generation 4 remains current, create publication wrappers for unpublished DEKs, and publish. Routine MLS epoch advancement does not create a new SENSOR KEK generation.

C.3. Phone is removed

While P is offline, the user removes P.

SSP authorizes removal.

L submits an MLS Remove/Commit for SENSOR through the blind Commit sequencer. Once the removal becomes canonical, L — as the accepted committer and therefore the unique generator (Section 7.3) — creates a fresh random SENSOR KEK generation 5 and distributes it over MLS.

flowchart LR
  accTitle: Key generation advance on node removal
  accDescr: Removing a node advances the domain key generation, so the removed node holds only the superseded generation.
  g4["KEK generation 4"] -->|"REMOVE P"| g5["KEK generation 5"]

Newly published objects use generation-5 COSE AccessRecords.

P never receives K_sensor_gen5.

When P reconnects, its newly introduced manifests/access records are rejected because the site has been removed, regardless of which MLS epoch or KEK generation they reference.

C.4. New phone joins

New node N passes SSP pairing, vouching, and human confirmation.

N is added to CONTROL and SENSOR.

If policy is FORWARD_ONLY, N receives current SENSOR access only.

If policy is FULL_HISTORY, an authorized existing member sends N a COSE-signed historical key package inside an authorized confidential channel containing the retained application KEKs needed to decrypt historical SENSOR objects.

MLS itself is not forced to retain old epoch protocol state for this purpose.

C.5. Compaction

L compactly rewrites 50 historical encrypted objects and their logical delete objects.

It decrypts authorized source modules, applies deletes, creates a new Parquet file, generates random DEK D2, PME-encrypts it, and publishes O2.

O2 receives a new ciphertext storage ID.

O2’s immutable producer manifest records the superseded source set; its access record independently grants current-domain decryption.

Only after retention, synchronization, purge, and the supersession verification-or-dispute-window precondition of Section 18.5 permit may the old ciphertext objects be garbage-collected. If H is a fully entitled second replica, its signed verification attestation of O2 satisfies the precondition early; otherwise the configured dispute window applies.