Decision: Wave 0A is a prerequisite for both the A0 object-envelope experiment and the A1 MLS experiment. Do not choose exact packages or make Profile A an implementation baseline until authority topology, device authenticity, canonical envelope binding, compromise policy, and migration seams are explicit.
The earlier streams correctly separated encryption, authorization, discovery, availability, and evidence. They left one dependency implicit: a recipient envelope and an MLS credential are meaningful only if TalkCo has decided which device key is authorized to act for which logical identity, in which context and epoch, under which recovery and fork rules.
#Authority topology and conflict semantics
Automerge demonstrates that replica convergence does not define semantic authorization: a CRDT can converge while same-property conflicts are resolved arbitrarily. Matrix is a useful reference for the opposite boundary: signed, hash-linked events, explicit authorization events, causal references, and deterministic state resolution independent of arrival order. Automerge conflict and convergence behavior, Matrix room events and state resolution
The smallest viable TalkCo model is one logical authority per context with explicitly delegated writer capabilities. This does not require one online server. The authority can be represented by signed local-first events and replicated across peers, but every context needs one unambiguous authority root or authority epoch for deciding which writers may perform which actions.
Each moderation or membership event should identify the context, target object, writer device, authority epoch, causal parent set, capability or role granting permission, canonical event hash, and signature. Invalid or unauthorized events remain observable evidence but never affect materialized state. Concurrent authorized events remain available for review. Conflicting same-writer sequence positions or successors produce equivocation evidence and quarantine the affected branch. Wall-clock time may be displayed but must not decide authority; causal order plus a deterministic tie-breaker should do that.
The first mode remains open: delegated authority from one context owner, moderator quorum, multi-root authority, or single-writer proposals with separate review events. Wave 0A must choose one mode and encode it in each authority event.
#Device enrollment and key authenticity
MLS requires an Authentication Service to bind identities to signing keys and leaves credential successor, expiry, revocation, and membership policy to the application. Signal Sesame is a useful failure-case reference for deleted devices, rollback, unsynchronized clocks, and reordered, duplicated, delayed, or forged messages. WebAuthn attestation can add an authenticator-integrity signal but is not automatically proof that a key belongs to the intended TalkCo user. RFC 9420, Signal Sesame, WebAuthn Level 3
The minimum device record contains:
- logical user identifier and unique device identifier;
- signing and encryption/KEM public keys with key-purpose and algorithm identifiers;
- enrollment authority and authority epoch;
- validity/revocation status and optional superseded-device reference;
- signed enrollment and revocation events;
- key-directory version or transparency checkpoint.
A relay or directory listing must not be sufficient to trust a new device. Enrollment needs a user-root signature, approval from an already verified device, an out-of-band ceremony, or a future recovery quorum. A restored backup must prove continuity against a current checkpoint or enroll as a new device. A revoked device key may remain available for historical verification but cannot authorize new events past the revocation frontier.
Key transparency is a candidate for detecting directory substitution or split views through append-only logs, inclusion/consistency proofs, monitors, witnesses, or peer comparison. The current IETF key-transparency documents are drafts, so the first implementation should use a scoped adapter and explicit freshness/checkpoint behavior rather than making a global transparency service a prerequisite. Key Transparency architecture draft, Key Transparency protocol draft
#HPKE envelope contract
HPKE supplies confidentiality and sender authentication only in its authenticated modes. It does not provide application replay or downgrade protection, does not hide plaintext length, and does not provide recipient-compromise forward secrecy. info participates in the key schedule; AEAD associated data authenticates application metadata; the application must define encoding, ordering, and replay behavior. RFC 9180 security properties and encoding
The outer signed object should bind at least:
- envelope version and canonical serialization;
- context identifier, object identifier, object content hash, and parent/reference hash;
- authority epoch and grant/capability digest;
- recipient logical user, device identifier, key fingerprint, and key-directory version;
- HPKE suite identifiers, encapsulated key, defined
info, and defined AEAD associated data; - envelope nonce or replay identifier and ciphertext commitment.
The contract must define sign/encrypt ordering, unique identifiers, nonce generation and reuse behavior, suite negotiation and downgrade rejection, replay detection, missing/duplicated/reordered/stale envelopes, and recipient-key compromise plus re-encryption policy. The signed TalkCo event authenticates author and authority independently of HPKE; HPKE Base mode is not an author-authentication mechanism.
Static recipient encryption keys can expose historical ciphertext after recipient-device compromise. That is a product decision: accept historical exposure, periodically re-encrypt, or use a ratcheting design for the relevant object class. Long-lived content also needs a migration seam for KEM and signature algorithms.
#MLS application binding
MLS assumes an Authentication Service, an untrusted Delivery Service, application-defined identity/reference validation, and application policy for credential replacement, expiry, revocation, and membership. Exported values are bound to the epoch and should use unique purpose labels and contexts; exported values should be refreshed after commits. RFC 9420 protocol and exporter sections
The A1 experiment needs a separate signed TalkCo binding event containing the TalkCo context, MLS group identifier, TalkCo authority epoch, MLS epoch, ciphersuite, tree hash, confirmed transcript hash, accepted membership/device digest, and application-policy version. The client accepts an MLS epoch only when this binding is valid under current TalkCo authority state.
If an exporter derives object-wrapping material, its context must include a TalkCo domain separator, purpose, object identifier, audience/context identifier, authority epoch, MLS group and epoch, and binding-event hash. A1 must choose exactly one mechanism—MLS application messages carrying object keys or exporter-derived wrapping material—and must not conflate it with direct MLS application encryption. A per-post or per-comment MLS group remains a rejected default.
#PQ and hybrid migration
NIST has standardized ML-KEM, ML-DSA, and SLH-DSA. Long-lived encrypted posts and comments are exposed to harvest-now-decrypt-later concerns. Hybrid HPKE extensions and MLS PQ ciphersuites remain a migration area, and the MLS PQ ciphersuite work is not yet a completed standard. FIPS 203, FIPS 204, FIPS 205, NIST PQC migration guidance, RFC 9958, MLS PQ ciphersuite draft
Wave 0A should not choose a PQ package yet. It should require algorithm and version identifiers, downgrade rejection, versioned key-directory records, dual-wrapped content keys during migration, and re-encryption or re-signing without changing object identity. Confidentiality migration and historical-authenticity migration are separate problems.
#Minimum Wave 0A contract
The machine-checkable contract should cover:
- Authority mode and root.
- Context and authority epochs.
- Canonical event serialization and hash.
- Parent/causal references.
- Per-writer sequence and equivocation detection.
- Writer capabilities and moderation authorization.
- Deterministic materialization of concurrent authorized events.
- Device enrollment, replacement, revocation, and recovery.
- Key-directory versioning and split-view behavior.
- Backup restoration.
- Envelope fields,
info, AAD, suite identifiers, replay IDs, and downgrade policy. - Recipient-compromise and re-encryption policy.
- MLS binding fields and exporter context rules for A1.
- Algorithm agility and PQ migration fields.
#Smallest falsifying set
Before A0/A1, test concurrent authorized moderation in different delivery orders; unauthorized device insertion; conflicting same-writer sequence positions; malicious or split-view key-directory updates; revoked/expired device events; stale backup restoration; HPKE replay, cross-context substitution, recipient substitution, downgrade, and nonce reuse; recipient-key compromise; MLS commits without valid TalkCo binding; exporter domain separation and stale epoch values; delivery-service withholding/reordering; and future envelope/signature versions without downgrade or object-identity breakage.
The Wave 0A conclusion is high confidence on boundaries and medium confidence on the final topology. The unresolved choices are root versus quorum authority, moderation precedence, account/device recovery, historical exposure after compromise, anonymous device enrollment, and whether PQ protection is required at launch or only through migration agility.