Host interface

SOP/1 is specified relative to a host that supplies identity, policy and delivery. SSP/1 is one such host, and this page states the contract precisely so that SOP/1 can also be implemented over a different one.

An implementation satisfying everything on this page is a conforming SOP/1 host, whether or not it implements the rest of SSP/1.

This separation is deliberate. The object plane’s data path — encryption, content addressing, manifests, placement, compaction — depends on none of SSP/1’s wire format, canonical encoding, cursors or merge algebra. It depends on four primitives. Naming them keeps the substitution possible instead of welding the two layers together by accident.

1. Node identity

A host MUST provide:

Primitive	Requirement
site_id	A stable 16-byte identifier, unique within the mesh, rendered as 32 lowercase hex characters. MUST NOT change for the life of the node’s identity key.
mesh_id	A stable 16-byte mesh identifier, identical on every node of the mesh.
Signing	The ability to produce an Ed25519 signature under the node’s root identity key over a caller-supplied pre-image.
Public-key resolution	Given a site_id known to the mesh, return its Ed25519 root identity public key, or report it as untrusted.

The signing interface MUST accept a pre-image and return a signature. It MUST NOT require the caller to hold the private key, and a host SHOULD implement it such that the private key is non-extractable — held in a secure element, TPM or platform keystore where available.

That shape is not incidental. SOP/1 binds its MLS credential to this identity, and if a host can only sign by handing out key bytes then the credential binding stops being an assertion about a protected key and becomes an assertion about a copy of one. A host that cannot keep the key non-extractable MUST surface that as an explicit posture rather than degrade silently.

2. Admission and removal

A host MUST express every admission and removal decision as a signed, hash-chained authorization record. SOP/1 defines the record’s contents and validation rules; the host’s obligation is to produce them, chain them, and make the chain available. In SSP/1 these are COSE_Sign1 records under the shared COSE profile, the same chained shape as role assignments.

Requirements:

• Each record MUST be signed by a node the mesh’s trust policy authorizes to make the decision, under its root identity key.
• Each record MUST carry a monotonic generation counter and the hash of its predecessor. A generation alone is insufficient: two authorized nodes can independently mint conflicting records at the same generation, and only an explicit predecessor hash makes the conflict visible without reference to whichever downstream operation happened to win.
• A host MUST surface, not silently reconcile, two records claiming the same predecessor.
• Validation MUST be self-contained: a consumer verifies the signature chain and generation monotonicity without requiring that its own policy replica has already converged. A host that requires policy convergence first creates an availability failure indistinguishable from an attack.

A host MUST NOT require the consumer to trust a transport, a relay or a server for any part of this. The chain is verifiable from the records alone.

3. Scope lookup

A host MUST answer, for a given node and a given table:

may_decrypt(site_id, table) -> yes | no

Requirements:

• The answer MUST be authoritative for the mesh, not advisory.
• A host MUST fail closed: absence of an affirmative answer is no.
• A consumer MUST be able to detect when a cryptographic group grants a node broader access than the scope lookup allows, and MUST treat that mismatch as an error rather than resolving it in favour of either side.

SSP/1’s own implementation of this is described in scope. A different host may derive the answer any way it likes, provided it is deterministic across nodes and fails closed.

4. Asynchronous mailbox

A host MUST provide a store-and-forward channel with these properties:

Property	Requirement
Opacity	The operator MUST NOT be able to read payload plaintext.
Addressing	Payloads are addressed to a site_id within the mesh.
Durability	A payload accepted for a currently-trusted recipient MUST be retained until delivered or until a stated retention bound elapses.
Retention bound	MUST be stated and finite.
Delivery	At-least-once. Duplicate delivery MUST be permitted, since consumers are required to be idempotent.
Ordering	None required. A consumer MUST NOT depend on mailbox ordering.

The mailbox exists because a live transport cannot serve peers that are never online simultaneously. It is not a substitute for a live transport and a live transport is not a substitute for it; SOP/1 requires both roles to exist.

The mailbox operator is inside the availability boundary and outside the confidentiality boundary

A mailbox operator can withhold, delay, reorder or drop payloads. Those are availability attacks and this contract does not prevent them; it requires only that the operator cannot read the payloads it is carrying.

A consumer MUST therefore treat mailbox silence as inconclusive rather than as evidence that no message was sent. Where a decision depends on having seen everything, the consumer needs its own evidence — SOP/1’s sequencing receipts are an example of exactly that pattern.

5. What the host does NOT have to provide

Stated so a prospective host knows where its obligation stops:

• No bulk object transfer. SOP/1 brings its own.
• No group key management. Where SOP/1 is deployed, MLS handles it.
• No canonical encoding, cursors, watermarks or merge algebra. Those are SSP/1’s internals, and SOP/1 does not touch them.
• No transport confidentiality beyond mailbox opacity.
• No specific pairing ceremony. The host must produce authorization records the consumer can verify; how a human authenticated the decision is the host’s business, subject to the properties in identity.

6. Conformance

A host claiming conformance MUST document:

1. how site_id and mesh_id are derived, and their stability guarantees;
2. whether the identity key is non-extractable, and on which platforms;
3. the authorization-record format and its chaining rule;
4. the scope-lookup semantics and its fail-closed behaviour;
5. the mailbox retention bound and the operator’s trust position.

An undocumented host is not a conforming host, because a consumer cannot reason about the guarantees it is inheriting.