The content key is not the access authority

The central architectural risk is treating encryption, authorization, discovery, availability, and public evidence as one problem. They are not one problem. A post may be visible to a stable sphere, a comment may be authored by one member but moderated by another, an attachment may outlive the device that created it, and a storage peer may need to repair ciphertext without learning either the audience or the key. A single protocol can cover some of these transitions while being the wrong authority for the rest.

The current research therefore selects boundaries before packages. MLS, proxy re-encryption, threshold access control, private discovery, edge sharding, ZK proofs, and smart contracts are evaluated as replaceable adapters behind those boundaries.

#Current recommendation

Build the first encrypted content path around this composition:

TalkCo signed authority event
  → random per-object content-encryption key (CEK)
  → AEAD-encrypted post, comment, or attachment chunks
  → signed grant bound to context, object, action, audience, and validity
  → HPKE-wrapped CEK for each authorized device
  → A1 experiment: one precisely specified whole-sphere MLS wrapping path
  → opaque rendezvous and ciphertext-only edge custody

The rules are:

• MLS is a group key-evolution mechanism, not TalkCo's ACL, moderation system, object-ordering system, discovery layer, or revocation authority. Use it for durable, evolving sphere-shaped audiences; do not create an MLS group per post or comment by default. The MLS architecture separates the group protocol from application policy, and RFC 9420 defines the protocol's group and epoch semantics. RFC 9420, MLS architecture
• A random object CEK plus per-device HPKE envelopes is the default hypothesis for one-off posts, narrow audiences, comments, and attachments. HPKE Base mode does not authenticate the sender and does not supply replay, downgrade, ordering, or recipient-compromise policy by itself. The signed envelope must bind context, object, grant digest, recipient device, suite/version, and ciphertext commitment through authenticated metadata and HPKE info/AAD before this becomes an implementation contract. HPKE
• The MLS branch is deliberately underspecified until Wave 0A chooses one mechanism: an MLS application message carrying a CEK, an MLS-Exporter-derived wrapping key, or direct MLS application encryption. Those choices have different persistence, replay, history, and compromise behavior. A sphere MLS key cannot cryptographically narrow a grant to a smaller audience; use it only where the cryptographic audience is exactly the sphere epoch.
• Comments are separate signed encrypted objects that reference a parent through a causal or opaque reference. MLS may protect the current group envelope, but it does not decide comment order, moderation, or whether an arriving event is authoritative.
• A removed member loses access to future keys or grants; the system does not promise to erase plaintext, cached ciphertext with a known key, screenshots, or keys already delivered. Historical access and future access must be specified separately.
• Proxy re-encryption and threshold release are conditional adapters. They advance only when an experiment shows a real need for delegated transformation, unknown future recipients, author-offline release, recovery, or an external condition that recipient-held keys cannot satisfy. TACo access-control concepts
• Peer discovery starts with an out-of-band invitation, a short-lived context-scoped rendezvous handle, application authentication, and then a replaceable transport. An iroh endpoint or DHT record may help locate a known endpoint; it must not become TalkCo identity or a public relationship directory. iroh FAQ, libp2p rendezvous
• Trusted edge peers are trusted for bounded ciphertext custody only. Two- or three-way replication is an initial parameter to benchmark against peer availability, repair delay, correlated-failure probability, and the required durability target; it is not a universal constant. Larger immutable attachments may use erasure-coded chunks after encryption. Repair receives ciphertext and manifests, not plaintext authority or decryption keys.
• ZK proofs and contracts are deferred to concrete gaps. The initial candidates are anonymous admission or rate limiting, scoped non-revocation evidence, batch commitments, committee/lease accounting, and disputes. Privacy Pass proves an issuer-issued authorization token; it is not inherently proof of personhood or group membership. Posts, comments, recipients, and shard placement do not go on-chain by default. Privacy Pass, Semaphore, RLN formal specification

This is a working recommendation, not a claim that every mechanism has passed production benchmarks. The next decision is whether the profile survives the same falsifying vectors across audiences of different sizes, device churn, offline delivery, metadata observers, storage faults, and release-service outages.

#Why this order is binding

The dependency order is:

1. Freeze authority and object semantics. Define identities, devices, audience types, object lifetimes, parent references, moderation, joins, removals, recovery, and the exact meaning of revocation.
2. Freeze authority topology and device-key authenticity. Decide whether authority is single-owner, steward-quorum, delegated, or multi-writer. Define device enrollment, key-directory or scoped-transparency behavior, malicious insertion, split views, expiry, backup restoration, and fork recovery. This precedes both HPKE and MLS.
3. Freeze compromise and the canonical envelope contract. Define sign/encrypt ordering, visible versus encrypted metadata, AAD/info bindings, nonce rules, suite/version negotiation, replay IDs, grant freshness, revocation frontiers, backup behavior, and migration. Define whether old content survives recipient compromise and whether late joiners receive history.
4. Choose the object key and grant model. Falsify random CEKs, signed grants, HPKE envelopes, and the minimum envelope fanout for posts, comments, and attachments.
5. Test selective MLS. Compare sphere-level MLS, per-post MLS, and no-MLS recipient envelopes under the same late-join, device-removal, offline, and concurrent-comment cases. The first MLS experiment must choose either application-message or exporter-based wrapping.
6. Derive discovery and metadata protections. Device-key authenticity is handled in Wave 0A; network discovery is evaluated here. The minimum policy is opaque context-scoped identifiers, fixed-size control blocks, size buckets, invitation rendezvous, compartmentalized providers, modest batching/jitter, and optional onion or mixnet profiles. Metadata evidence
7. Derive edge custody and repair. Storage cannot be evaluated until the ciphertext/key model establishes chunk size, manifest authority, replication parameters, erasure-coding thresholds, repair semantics, and tombstone behavior. Edge-storage evidence
8. Research ZK and contracts only against a named gap. A proof or contract must have a precise statement, verifier, freshness and revocation model, failure mode, privacy leakage, and off-chain fallback. ZK and contract evidence
9. Run a common falsifying harness. Select the smallest profile that passes; retain more distributed profiles as bounded experiments rather than allowing optional infrastructure to become mandatory architecture.

The order prevents a common failure mode: adopting a sophisticated coordination layer to compensate for an undefined authority model. MLS cannot resolve an application authorization disagreement. A threshold network cannot decide whether an event is a valid moderation transition. A smart contract cannot make a public recipient graph private. A mixnet cannot repair an edge shard. Each can be useful at its own boundary.

#Object-to-primitive matrix

#The profiles and adapters worth building or falsifying

The synthesis keeps three core profiles—A0, A1, and C—and treats anonymous admission as an adapter that can be composed with any of them. More independent profiles would turn the research into an unbounded menu; fewer would hide the exact trade-off between local-first operation and distributed conditional release.

#Profile A0 — local-first object-envelope baseline (recommended first experiment)

TalkCo signs authority and membership events locally. Each post, comment, and attachment receives a random CEK. The CEK is wrapped to authenticated authorized devices with HPKE. There is no MLS, PRE, ZK, contract, or erasure-coding dependency in the critical path. Delivery, discovery, and storage are replaceable. Edge peers may hold bounded ciphertext replicas under quotas and leases. Metadata protection uses opaque context handles, fixed or bucketed control traffic, queue rotation, modest batching, and independent providers.

This is a research baseline, not yet a safe vertical slice. It must first pass malicious device insertion, envelope substitution, replay, downgrade, key-compromise, backup restoration, authority conflict, and offline causal-order tests. Its expected costs are recipient-envelope fanout, explicit device lifecycle handling, and limited revocation: keys already delivered cannot be recalled.

#Profile A1 — stable-sphere MLS experiment

A1 keeps the A0 object model but adds exactly one stable whole-sphere current-epoch MLS mechanism. The experiment must state whether the CEK is carried as an MLS application message, wrapped with an exporter-derived key, or represented as a direct MLS application message. A1 must not use an MLS grant to narrow access below the sphere membership that already holds the MLS key.

The MLS branch advances only after A0 defines device authentication, authority binding, persistence, exporter domain separation if applicable, and reinitialization. It is a comparative branch, not a premise of the first slice.

#Profile B — anonymous-admission adapter

Profile B is an adapter that can be added to A0, A1, or C when the product needs an action to be rate-limited or authorized without revealing a stable identity. Privacy Pass is the first admission experiment; Semaphore or RLN are candidates when group membership or rate limits need a ZK-backed nullifier; AnonCreds is a candidate when a richer external credential model is required. These proofs do not encrypt content, discover peers, or release a CEK.

It advances only after the product names the issuer or root, verifier, public inputs, nullifier lifetime, replay behavior, rotation, recovery path, and linkability budget. Privacy Pass proves token authorization from its issuer; the application must define what that issuer attests.

#Profile C — distributed conditional-release experiment

Profile C keeps the A0 object model but adds a generic ConditionalKeyRelease adapter. A PRE proxy may transform a key envelope; a threshold network may release a key only when a declared condition is satisfied; a narrow contract may anchor roots, account for leases or payments, rotate committees, or record disputes. The content remains encrypted before leaving the author device, and the release service is not the application authority.

Profile C is justified only by a requirement such as author-offline release, a recipient not known at publication time, threshold recovery, or a condition that must survive the author's unavailability. Its costs are online availability, request metadata, committee churn, collusion and censorship assumptions, migration complexity, and potentially irreversible key release. TACo is not a v0 dependency until a maintained implementation and operational posture are demonstrated; its current upstream posture should be treated as a rejection gate, not an assumption. TACo developer start, NuCypher/TACo repository

#Distributed is not automatically decentralized

Profile A0 is distributed when multiple nodes carry delivery, rendezvous, or ciphertext custody. That says where work happens, not who controls authority. It becomes decentralized for a particular property only when no single operator can unilaterally control that property's authorization, availability, censorship, or release outcome under the declared failure model. A threshold committee can distribute key shares while retaining a centralized administrator, and a global DHT can distribute lookup while exposing a public relationship index. The research therefore records distribution and decentralization as separate acceptance dimensions.

#Research waves and exit gates

#Wave 0 — authority, audience, and threat boundary

Freeze the identity/device model, post/comment/attachment object model, audience types, revocation semantics, observer classes, edge-peer trust assumptions, and public-verifiability requirements.

Exit: every later stream can state who may authorize an object, who may decrypt it, what a removed member retains, what each observer sees, and which failure is fail-closed.

#Wave 0A — authority topology, device authenticity, and envelope contract

Decide whether authority is single-owner, steward-quorum, delegated, or multi-writer. Specify deterministic event ordering, equivocation detection, fork recovery, and reinitialization. Define person, app installation, device key, restored backup, and scoped transparency/key-directory identities. Test malicious device insertion, directory split view, credential expiry, backup restoration, cross-device equivalence, and revocation-frontier freshness.

Then specify the canonical envelope: sign/encrypt ordering, visible and encrypted fields, context/object/grant/device/suite binding, AAD and HPKE info, nonce construction, suite/version negotiation, replay IDs, history and compromise policy, key rotation, tombstones, and migration. Every MLS commit must bind to the exact accepted TalkCo authority transition before the client merges it.

Exit: the authority and device contract is concrete enough that two independent implementations reject the same malicious key insertion, stale grant, conflicting commit, replay, downgrade, and backup resurrection.

#Wave 1A — object encryption and grants

Benchmark random CEK plus HPKE envelopes against compact signed grants, broadcast encryption, and any other recipient envelope under small, medium, and large audiences. Include multi-device enrollment, device loss, offline recipients, envelope replay, recovery import, and old-epoch compromise.

Exit: a versioned object envelope and grant contract exists, with explicit key rotation, recipient-device binding, revocation, tombstone, and migration semantics.

#Wave 1B — selective MLS

Test MLS at sphere level, per-post level, and as an envelope-wrapping adapter. Include late joins, removals, offline commits, concurrent comments, moderator disagreement, storage replay, multi-device state, crash before local persistence, and group sizes 10/100/1,000/10,000.

Exit: MLS is either accepted for a named audience class or rejected for that class with evidence. “MLS can encrypt it” is not sufficient.

#Wave 2A — discovery and peer authentication

Implement the lifecycle as four separate operations: find a candidate, authenticate the application key, select a transport, and learn or update the relationship. Compare out-of-band invitations, short-lived rendezvous, iroh-style known-key lookup, private DHT lookup, SimpleX-like queues, and local/offline exchange.

Exit: discovery never establishes membership by itself; an invitation is scoped, expiring, replay-resistant, transport-independent, and bound to a TalkCo authority event.

#Wave 2B — metadata resistance

Run the normalized trace harness against local, relay, discovery, storage, group-member, colluding-provider, and global observers. Record size, timing, routing, provider overlap, queue and shard lifetimes, retry behavior, cover traffic, CPU, battery, bandwidth, and availability.

Exit: the default profile states its accepted leakage and measurable budget. Stronger onion/mixnet profiles have explicit degraded modes. PIR and ORAM advance only for a narrow query or access pattern that the baseline fails.

#Wave 2C — trusted-peer edge custody

Benchmark replication factors as parameters for small objects and compare erasure coding for large immutable attachments. Derive the choice from peer availability, repair delay, correlated-failure probability, target durability, and quota economics. Test independent failure domains, corrupt/stale shards, withholding, repair races, leases, tombstones, quota exhaustion, quota Sybil attacks, peer replacement, collusion, coding-parameter mismatch, and ciphertext-only repair.

Exit: a signed manifest, quota and lease policy, repair protocol, evidence vocabulary, and omission/recovery behavior exist without giving a storage peer authorization or a decryption key.

#Wave 3 — ZK and contracts

Start from a failed Wave 1 or Wave 2 property. For every proof, define the statement, witness, public inputs, verifier, root/key freshness, nullifier/linkability, revocation, circuit migration, and offline fallback. For every contract, define the small state transition, chain failure behavior, reorg/censorship assumptions, upgrade authority, and why signed evidence is insufficient.

Exit: the feature is either a narrow adapter with a measured benefit or rejected from the core. No content, recipient, social graph, or plaintext policy is placed on a public chain.

#Wave 4 — adversarial integration

Run A0, A1, B, and C through one suite and record the first failing invariant. B is an adapter dimension rather than a competing encryption architecture. The integration review must prefer the smallest profile that passes the product's declared threat model, not the profile with the most distributed components.

Exit: a candidate is selected for a vertical slice; every deferred adapter has a trigger, a seam, and an explicit non-goal.

#Common falsifying harness

The harness should use the same events and observer traces for every profile:

1. Authority disagreement: deliver a valid-looking MLS commit, grant, or proof that conflicts with the signed TalkCo membership event. The client must quarantine or repair, never accept by arrival order.
2. Late join and history: add a member after publication, then test exactly which old posts, comments, and attachments are readable and which new objects are readable.
3. Removal and device loss: remove a device while it is offline, rotate future keys, restore from backup, and verify that the intended future boundary holds.
4. Concurrent comments: create offline comments and moderation transitions, deliver them in different orders, and verify deterministic causal resolution.
5. Fanout and churn: compare HPKE, sphere MLS, per-post MLS, broadcast, PRE, and threshold release for audience sizes 10, 100, 1,000, and 10,000.
6. Release outage: take the relay, PRE service, threshold node subset, rendezvous service, storage peers, and chain/RPC endpoint offline independently. Local operation must degrade according to the declared profile.
7. Metadata correlation: combine access-network, relay, discovery, and storage traces. Fail any profile whose stated privacy depends on non-collusion that it does not declare.
8. Identifier rotation: rotate context, queue, endpoint, object, and shard handles while offline comments, repair, recovery, and migration are active.
9. Storage faults: corrupt, withhold, replay, and race repairs for replicas and erasure-coded shards. Repair must remain ciphertext-only and preserve manifest authority.
10. Anonymous admission: replay proofs, reuse nullifiers across contexts, rotate roots, and simulate verifier or issuer outage. Fail if abuse control becomes a stable identity or permanently releases a content key.
11. Contract boundary: submit stale roots, reorganized transactions, censored updates, and incompatible committee rotations. No ordinary post or comment should become unreadable merely because the chain is unavailable unless Profile C explicitly requires that property.
12. Client compromise boundary: state what is visible to an unlocked client and treat any stronger claim as invalid unless the protocol provides a separate trusted execution or device boundary.
13. Device-key authenticity: insert a malicious device, fork a scoped key directory, restore a backup containing removed keys, and deliver equivalent-looking device certificates in different orders. Fail if clients accept inconsistent device sets or revive revoked keys.
14. Envelope binding: substitute context, object, grant, recipient-device, suite/version, parent-reference, and ciphertext-commitment fields; replay and downgrade envelopes; test nonce reuse and HPKE sender spoofing. Fail if decryption succeeds for a different security context or stale grant.
15. MLS state integrity: test delivery-service equivocation, concurrent commits, stale Welcome, missing proposal, external join, state loss, reinitialization, and exporter domain separation. Fail if clients merge incompatible state or reuse an exported value across contexts.
16. Grant freshness: replay grants against stale revocation frontiers, clock skew, and offline recovery. Fail if a client treats arrival time as authority or accepts a grant outside its declared validity.
17. Manifest and release integrity: test manifest rollback, shard poisoning, coding-parameter mismatch, threshold-node collusion, malicious condition providers, cohort-admin takeover, committee migration, and irreversible key release.

#Open decisions that still block implementation

The research has narrowed the architecture, but these inputs must be fixed before selecting exact libraries or protocol suites:

• What is the authority topology: one content owner, a steward quorum, delegated moderators, or multi-writer authority? How are equivocation, fork recovery, and deterministic ordering handled?
• How are devices enrolled and keys authenticated: invitation-contained keys, a scoped key directory, key transparency, or another mechanism? How are malicious insertion, split view, expiry, backup restoration, and cross-device equivalence handled?
• What is the canonical envelope contract: sign/encrypt ordering, visible fields, AAD/info bindings, nonce construction, replay IDs, suite/version negotiation, grant freshness, revocation frontier, and migration?
• What are the audience classes: one-off recipients, private spheres, public-but-pseudonymous posts, role-based subsets, and anonymous eligible readers?
• Are posts/comments immutable encrypted events with moderation overlays, or can an author rewrite ciphertext history? This determines tombstones, parent references, and key epochs.
• What is the compromise/history policy? Must old content survive a recipient-device compromise, do late joiners receive history, and can backups retain CEKs after removal?
• What metadata budget is acceptable for ordinary and sensitive contexts: latency, bytes per logical byte, battery, queue retention, provider overlap, and global-observer scope?
• Can trusted peers be assumed to remain independently operated, or must the edge profile tolerate correlated failure and collusion by default? What replication and erasure-coding parameters meet the target durability?
• Is there a real product requirement for recipient-unknown-at-publication, author-offline conditional release, anonymous admission, or public dispute evidence? If not, Profiles B and C remain experiments.
• Which implementation language/runtime and platform constraints determine whether OpenMLS, an HPKE implementation, a capabilities library, queue/relay adapters, and erasure coding can be pinned and audited without creating a large trusted computing base?

#Evidence map

The detailed evidence is split by decision so that this synthesis stays skimmable:

• Wave 1 MLS and access-control evidence
• Wave 0A authority, device, and envelope evidence
• Wave 1–2 integrated encryption, discovery, and edge-custody evidence
• Metadata-resistance report and claim case and metadata-resistance.case.json
• ZK and smart-contract control-plane evidence
• Dependency-ordered research plan
• Orchestration ledger

The claim-level synthesis case is maintained separately in content-access-synthesis.case.json. It records which claims are directly sourced, which are integrated proposals, what counterevidence was checked, and what remains unresolved.