Abstract and scope

Extension status

This is a hand-authored extension specification to SOP/1. It changes nothing in SOP/1: it defines a second object kind and a second encrypted-object format through the extension points SOP/1 itself reserves. It is not implemented anywhere, and its own decision gates (section 5) are all open. Where this document and SOP/1 disagree about the base plane, SOP/1 is correct.

Abstract

This document extends the Sovereign Object Plane (SOP/1) to unstructured data: photos, video, audio, documents, and any other large binary asset that is not naturally a table of rows.

SOP/1 defines a content-addressed immutable-object data plane whose canonical object is an encrypted Parquet file. Almost none of its machinery is specific to Parquet. Storage identity and verified transfer (SOP/1 section 11.7), the per-object DEK wrapped in a COSE AccessRecord under a domain KEK (section 7), the producer-signed ObjectManifest (section 12.2), blind replicas and placement tiering (section 16), permanent identity tombstones (section 14), and Padmé size padding all operate on opaque encrypted bytes. Only the payload profile — Parquet Modular Encryption — assumes tabular content.

This extension therefore adds exactly two things:

1. a new manifest object_kind, blob, with its own manifest field profile (manifest profile); and
2. a new encrypted-object format, SOP-BLOB-1 (object format): a chunked AEAD stream whose chunk boundaries align with the transfer layer’s verification granularity, so that a byte range of a large asset can be fetched from a blind replica, verified, and decrypted without touching the rest of the object.

Everything else — keys, access records, manifest signing, acceptance rules, domains, placement, transport, the mailbox — is reused from SOP/1 unchanged.

1. Extension basis

SOP/1 reserves the extension points this document uses:

• Section 2.4: the canonical object is “an encrypted Parquet file or another explicitly approved encrypted object format”. SOP-BLOB-1 is such an approval.
• Section 11.1: PME is canonical for data objects “unless a future object type explicitly specifies another format”. Blob objects are that future object type.
• Section 12.2: the ObjectManifest carries object_kind. This extension registers the value blob and defines which manifest fields accompany it.

Because SOP/1 Revision 8 is frozen and requires a successor document for design change, this extension deliberately makes no change to SOP/1 text or semantics. A conforming SOP/1 implementation that does not implement this extension MUST fail closed on object_kind = blob — which is already the required behavior for an unknown object kind.

2. The model in one page

A logical asset — one photo, one video — is stored as one or more blob objects:

• the original: the asset’s bytes, encrypted as one SOP-BLOB-1 object;
• zero or more derivatives: thumbnail, poster frame, transcode — each an independent SOP-BLOB-1 object referencing its source.

Every blob object has its own random DEK, its own AccessRecord, its own producer-signed manifest, and a storage_id that is the transfer-layer hash of its exact encrypted bytes — all exactly as for a Parquet object.

Queryable facts about assets — capture time, location, camera, dimensions, duration, tags, and which storage_ids hold the bytes — do not live in the blob plane at all. They are rows in ordinary SOP/1 APPEND_DELETE Parquet tables (assets and metadata). The blob plane stays a dumb, blind, content-addressed byte plane; all indexing and query lives in the tabular plane SOP/1 already specifies. The discipline is one sentence: the index references blobs; blobs never reference the index.

Deleting an asset is an ordinary equality delete of its asset_id in the governing metadata table. The permanent-tombstone semantics of SOP/1 section 14 then make every object carrying that asset_id — original and derivatives — eligible for garbage collection (lifecycle).

3. Why not an existing file-sync system

Prior art was surveyed before this design was written — Ente, Perkeep, Tahoe-LAFS, WNFS, Peergos, Signal attachments, Syncthing’s untrusted-device mode — and the constructions chosen here are theirs, not novel (security considerations records the borrowings).

Adopting one of those systems whole was rejected for a structural reason: each brings its own identity, membership, and placement authority. A mesh running SOP/1 for tables and a second system for media would hold two trust models, two membership states, and two catalogs for one fleet — and the second system’s authority would not be the mesh’s MLS domains. The blind replica property, the single encrypted catalog, and the single admission ceremony do not survive that split. The data plane is the part SOP/1 already has; the part worth importing from prior art is the object format, and that is what SOP-BLOB-1 does.

4. Non-goals

This extension does not attempt to provide:

• filesystem semantics — no directories, no paths, no rename, no partial overwrite; an asset is immutable and whole;
• multi-writer mutation of an asset — a corrected asset is a new asset;
• plaintext-level deduplication — a keyed logical fingerprint remains possible under SOP/1 section 11.9 and is not required here;
• a streaming or transcoding protocol — derivatives are produced by applications; the plane only stores and transfers them;
• content search over media — indexing derived features (labels, embeddings, OCR text) is application work that lands in ordinary tables.