The unresolved problem is narrower than “which decentralized stack should TalkCo use.” A post, a comment, an attachment, a membership transition, and a peer-discovery record have different audiences, lifetimes, revocation needs, and metadata. Applying one group protocol or one access-control network to all of them would make the wrong layer authoritative.
This round will decide the smallest set of cryptographic and distribution seams that can support private posts and comments while preserving local-first operation, context-scoped identity, transport replacement, edge custody, and metadata accounting.
#Decision boundary
The research must answer:
- whether MLS is appropriate for post and comment encryption, access control, both, or only selected group-shaped contexts;
- when to use per-recipient HPKE or broadcast encryption instead of an MLS epoch;
- whether proxy re-encryption or threshold access control such as TACo adds value that signed grants and recipient-held keys cannot provide;
- how peers discover one another without creating a global identity, relationship, or content index;
- what metadata resistance is feasible for a local-first social application, and what latency, availability, and battery costs it imposes;
- whether smart contracts should coordinate only commitments, leases, committees, or revocation evidence, while content authority remains off-chain;
- whether simple zero-knowledge proofs can demonstrate eligibility, membership, possession, or non-revocation without exposing a stable graph;
- how ciphertext can be sharded across trusted peers with simple quotas, bounded repair, declared failure domains, and no plaintext custody;
- which parts belong in the first falsifying harness and which remain research-only.
#Research ordering after the first evidence pass
The dependency is not “encryption first, privacy later.” Authority topology and device-key authenticity precede both encryption and network discovery. The first encryption and access-control decisions then determine the audience, identifier lifetime, revocation event, and object fanout that every metadata and discovery design must protect. The order is therefore:
- freeze object, audience, observer, identity, and revocation semantics;
- freeze authority topology, device enrollment/authentication, recovery, fork semantics, and the canonical envelope contract;
- compare MLS, per-recipient HPKE, broadcast encryption, and signed grants for posts, comments, and attachments;
- compare distributed access-control mechanisms against the same authority and revocation model;
- derive peer-discovery and metadata profiles from the selected audience and identifier shapes;
- derive edge-shard manifests, quotas, repair, and failure domains from the selected ciphertext/key model;
- investigate ZK proofs and smart contracts only where the preceding waves expose a concrete coordination or abuse-control gap;
- run the same falsifying vectors through three core profiles, with admission proofs, metadata transports, and storage backends treated as adapters.
The metadata stream has now established a working minimum policy: opaque context-scoped identifiers, fixed-size control blocks, bucketed object sizes, invitation-based rendezvous, compartmentalized queues/providers, modest batching and jitter, and ciphertext-only edge custody. This is a measurable baseline, not a claim of global anonymity. See metadata-resistance-research.md.
The first Wave 1 evidence pass is provisional until Wave 0A freezes device and envelope semantics. Its cryptographic hypothesis is: use MLS for evolving sphere-shaped groups and selected group-shaped post/comment audiences; use HPKE or a compact recipient envelope for one-off or sharply narrower audiences; keep application membership, object identity, revocation, and parent references in TalkCo events. Treat TACo threshold release and proxy re-encryption as optional adapters for an identified conditional-release or delegation gap. See wave-0a-authority-device-envelope-evidence.md and wave-1-initial-evidence.md.
#Object and access matrix
Every stream must evaluate the same object classes and access patterns.
| Object | Audience shape | Mutability | Revocation question | Candidate control plane |
|---|---|---|---|---|
| Private post | Fixed recipients, sphere, or role-defined audience | Append-only after publication | Can a removed member lose future access without rewriting history? | MLS, per-recipient HPKE, broadcast encryption, signed grant |
| Comment/reply | Post audience plus author/editor exceptions | Append-only, possibly moderated | Can a comment be hidden or revoked without changing parent authorization? | Post epoch, per-comment envelope, author key, signed moderation transition |
| Attachment | Same audience as parent object, often large | Immutable bytes, mutable logical reference | Can storage and key revocation be separated? | HPKE-wrapped content key, manifest grant, proxy or threshold release |
| Membership/invitation | Small authorized set or steward group | Ordered transitions | How are joins, removals, device loss, and late joins represented? | TalkCo authority event, MLS commit, scoped transparency evidence |
| Peer rendezvous | Context-scoped and short-lived | Expiring | Can discovery occur without a permanent public identifier? | Invitation, rendezvous token, private relay, local exchange |
| Shard manifest | Storage operators or trusted peers | Signed succession | Can repair occur without granting plaintext authority? | Signed manifest, lease, possession/integrity evidence |
| Admission proof | Verifier sees only eligibility result | One-shot or short-lived | Can proof use be prevented from becoming a tracking identifier? | Privacy Pass, anonymous credentials, ZK membership/non-revocation proof |
The shared test patterns are: fixed and changing audiences, large and small groups, offline late joiners, concurrent comments, device addition/removal, compromised relay, compromised storage peer, stale replica, revoked grant, recovery import, and cross-context correlation.
#Dependency-ordered waves
#Wave 0 — boundary and threat model
Freeze the object matrix, audience types, device model, revocation semantics, privacy observers, edge-peer trust assumptions, and any requirement for public verifiability. This wave owns the vocabulary. It must distinguish encryption, authorization, discovery, availability, and evidence.
Exit gate: every later stream can state what it protects, who may authorize it, what a revoked party can still learn, and which metadata each observer can see.
#Wave 0A — authority topology, device authenticity, and envelope contract
Decide whether each context has one logical authority with delegated capabilities, a moderator quorum, a multi-root authority, or a proposal/review model. Define deterministic event ordering, equivocation evidence, fork recovery, reinitialization, and the treatment of unauthorized events.
Define the person/device/key-directory model: user root, app installation, device signing key, device encryption/KEM key, enrollment and revocation events, key-purpose and algorithm identifiers, expiry, backup restoration, and scoped transparency/checkpoint behavior. A directory or relay must not be able to authorize a new device by assertion alone.
Define the versioned object envelope: canonical serialization; sign/encrypt ordering; visible and encrypted fields; context/object/parent/authority/grant/device/suite bindings; HPKE info and AEAD AAD; nonce and replay identifiers; downgrade policy; recipient-key compromise; history and re-encryption behavior; and PQ/hybrid algorithm-agility fields. For A1, define the TalkCo binding between context authority state and MLS group/epoch/transcript state, including exporter domain separation if exporters are used.
Exit gate: two independent implementations reject the same malicious device insertion, stale or replayed grant, cross-context envelope substitution, conflicting authority event, invalid MLS binding, backup resurrection, and downgrade. This is a protocol contract, not a package selection.
#Wave 1 — content encryption and access-control primitives
Run the MLS/post-comment stream and the distributed access-control stream in parallel after Wave 0A. Their first outputs remain hypotheses until they pass the Wave 0A envelope and authority contract.
The MLS stream compares group epochs, sender keys, late joins, removals, offline comments, per-post groups, per-sphere groups, attachments, moderation, and multi-device operation. It must explicitly test where MLS stops being a good fit and where HPKE, broadcast encryption, or signed grants are simpler.
Its first decision is not “can MLS encrypt a post?” MLS can provide asynchronous group key establishment and epoch-scoped application encryption. The decision is whether the post's audience is a durable evolving group, a one-off recipient set, or a narrower role subset, and whether the exposed group/epoch/message metadata is acceptable for that object. The stream must compare sphere-level MLS, per-post MLS, and no-MLS recipient envelopes under identical offline and revocation vectors.
The access-control stream compares TACo/threshold networks, proxy re-encryption, broadcast encryption, attribute-based encryption, capabilities, and application-signed grants. It must separate who authorizes access, who transforms or releases keys, who pays for availability, and who can revoke or censor.
TACo advances only if threshold release solves a concrete condition or recovery problem that recipient-held keys and signed grants cannot solve. Proxy re-encryption advances only if its delegation or fanout benefit survives tests for request metadata, revocation, proxy collusion, online availability, and migration. Neither may become the implicit authority for ordinary posts or comments merely because it can express programmable conditions.
Exit gate: produce candidate profiles for static audience, dynamic audience, large audience, role/attribute audience, offline audience, and revoked audience. No profile may use a key server, threshold committee, MLS transcript, or smart contract as TalkCo’s sole application authority without an explicit failure model.
#Wave 2 — peer discovery, metadata resistance, and edge custody
Run peer-discovery, metadata-resistance, and edge-storage streams after Wave 0A and Wave 1 using the audience profiles and identifier lifetimes that those waves produce. Device-key authenticity is not deferred to network discovery.
Discovery research compares invitations, rendezvous tokens, iroh-style discovery, private DHTs, local exchange, queue relays, mix or onion paths, and scoped transparency. It must distinguish finding a peer, authenticating a peer, selecting a transport, and learning a relationship.
Metadata research models local, relay, discovery, storage, colluding-provider, group-member, and global observers. It compares padding, batching, delayed delivery, queue rotation, relay indirection, and mixnet-style designs against latency, battery, availability, and abuse costs.
Edge-storage research compares trusted-peer replication, erasure-coded shards, quotas, leases, repair, challenge proofs, and failure domains. It must test whether “trusted peers” are trusted for custody only or also for authorization, and must keep repair ciphertext-only.
Exit gate: each candidate distribution profile has a normalized observer trace, a peer-discovery lifecycle, a storage failure matrix, a quota/repair policy, and a statement of what remains linkable.
The metadata stream must compare four bounded profiles rather than search for one universal privacy layer:
- opaque local-first transport with fixed blocks and size buckets;
- onion/queue privacy with context-compartmentalized routes and rotation;
- mixnet-sensitive delivery with fixed-size packets, batching, delay, and cover traffic;
- PIR/ORAM adjuncts for narrowly defined provider-index or read-heavy queries.
The default profile must be tested against local process/OS, access network, relay, discovery service, storage provider, group member, colluding providers, and global passive observers. It must record what is directly visible, inferable, bounded, or unavailable. No candidate may claim protection against a compromised unlocked client or a global observer without measuring the anonymity set, timing, bandwidth, battery, availability, and abuse costs.
#Wave 3 — ZK proofs and smart-contract control planes
Begin only after Waves 1 and 2 identify a concrete proof or coordination gap. Research minimal ZK proofs for eligibility, membership, possession, non-revocation, and rate-limit/admission tokens. Research efficient contract roles such as commitment anchoring, lease accounting, committee rotation, dispute evidence, or payment—not storing posts, comments, identities, or plaintext access policy by default.
Compare whether the same property can be achieved with signed offline evidence, threshold authorization, scoped transparency, or a local capability. Measure proof size, verification cost, linkability, state growth, chain dependency, censorship, upgradeability, and recovery.
Exit gate: every proposed on-chain or ZK component has a precise statement, verifier, witness, revocation/freshness model, privacy leakage, failure mode, and off-chain fallback. “More decentralized” is not an acceptance criterion by itself.
This wave is blocked until the earlier waves identify a property that signed offline evidence, encrypted manifests, threshold authorization, scoped transparency, or a private rendezvous cannot provide. A contract must not become a public index for posts, comments, recipients, peer identity, or shard placement merely because it can verify a commitment cheaply.
#Wave 4 — synthesis and falsifying profiles
Synthesize the streams into three core profiles and composable adapters:
- A0 object-envelope baseline: signed TalkCo events, per-object AEAD/HPKE grants, no MLS/PRE/ZK/contract critical path.
- A1 stable-sphere MLS experiment: A0 plus one specified whole-sphere MLS wrapping mechanism.
- C conditional-release experiment: A0 plus one named PRE/threshold/contract condition.
Privacy Pass/Semaphore/RLN, metadata transports, discovery providers, and storage backends are adapters tested against these profiles, not separate content-encryption architectures.
Each profile must run the same vectors for authorization disagreement, revocation, offline comments, recovery, discovery correlation, storage compromise, repair, and contract unavailability. Select the smallest profile that passes; retain the others as explicitly bounded experiments.
#Research-stream return contract
Each stream must return:
- a decision question and bounded scope;
- current primary sources and exact source locations;
- supported, contradicted, inferred, and unknown claims;
- at least one disqualifying counterexample;
- a comparison matrix against the shared object/access patterns;
- an adoption profile, rejection boundary, and smallest falsifying experiment;
- implementation, license, maturity, migration, and failure-domain constraints;
- one dependency for the next wave.
No stream may select a package merely because it combines encryption, discovery, storage, and governance. Combination is a hypothesis to test against the shared authority and metadata boundaries.
#Current non-goals
This round will not deploy a blockchain, run a threshold committee, implement a new ratchet, install production packages, or decide final platform targets. It will not treat a ZK proof as privacy-preserving until its public inputs, verifier state, witness lifecycle, replay behavior, and correlation surface are specified.
The canonical orchestration ledger is round-4.ledger.json. The previous architecture boundary remains the baseline in architecture-exhaustion.md.