Disposition: MLS is a strong group-key-management candidate for sphere-shaped audiences and selected post/comment contexts. It is not, by itself, TalkCo application authorization, parent/child relationship privacy, or a private directory. TACo is a conditional threshold-release candidate for exceptional policies, not the default key path for ordinary posts and comments. Recipient-held keys plus signed TalkCo grants remain the baseline to falsify first.
#What MLS actually gives TalkCo
RFC 9420 defines an asynchronous group key-establishment protocol for groups from two to thousands, with forward secrecy and post-compromise security. Groups evolve through epochs; proposals and commits change membership; welcomes initialize new members; private messages encrypt application data. A removal commit adds fresh entropy to the new epoch so the removed member does not learn the current epoch secret. RFC 9420
That maps well to:
- a private sphere with changing membership;
- a post whose audience is the current sphere at publication time;
- comments authored by current members of that audience;
- group-wide moderation or authorisation transitions that need an authenticated epoch;
- multi-device membership, provided each device is a distinct MLS client and TalkCo owns the device lifecycle.
It does not automatically solve:
- whether a post is addressed to the whole sphere, a subset, or one role;
- whether a comment inherits the parent audience or has a narrower audience;
- how an application hides parent references, author timing, sizes, or membership from relays;
- how a removed member's already-decrypted history is recalled;
- how a local-first replica chooses between conflicting application authority and MLS state;
- how a post/comment is discovered without exposing a group or object directory.
The MLS specification explicitly says that group ID, epoch, message frequency, and some message lengths can be exposed to the delivery service, and that the distribution service affects what group properties observers can infer. That makes MLS a cryptographic group layer, not a metadata-resistance layer. RFC 9420, external metadata
OpenMLS adds an implementation-specific gate. Its current changelog records storage-provider behavior, persistence fixes affecting secret-tree forward secrecy, a current MSRV of Rust 1.91 in the unreleased line, and active changes around draft extensions, provider dependencies, WASM, and PQ support. The first harness must therefore pin an exact release/commit and provider rather than treating “OpenMLS” as a stable unit. OpenMLS changelog
#Object-by-object fit
| TalkCo object | MLS fit | Competing baseline | Research gate |
|---|---|---|---|
| Private post to a stable sphere | Good if the sphere already has a group epoch; the post can use an epoch-derived content key or a separately derived per-object key | Per-recipient HPKE or a compact broadcast envelope for small fixed audiences | Compare group reuse against per-object fanout, late join behavior, metadata, and revocation |
| Post to a one-off fixed audience | Often excessive; creates group state for an object with no future membership operation | HPKE-wrapped random content key, signed audience grant | Measure envelope size, offline delivery, recipient churn, and key deletion |
| Comment in the same sphere | Good when comment audience is exactly the current epoch; parent reference still belongs to TalkCo's encrypted event model | Per-comment key wrapped to the post audience or current sphere | Test comments created offline across epoch changes and concurrent removals |
| Comment to author/moderators only | Poor fit for the full sphere; a smaller group or recipient envelope is simpler | HPKE or a moderator sub-group | Test moderation transitions and accidental audience widening |
| Large attachment | Use MLS only to deliver or authorize a random content key; never route bulk ciphertext through group state by default | Padded ciphertext blob plus per-recipient/epoch key envelope | Test resend, shard repair, key rotation, and storage-provider observations |
| Membership/invitation | Strong fit for authenticated group transitions, but TalkCo must authorize the application transition | TalkCo authority event plus MLS commit | Fail closed on policy/MLS disagreement; never resolve by arrival order |
The working hypothesis is therefore MLS for group-shaped key evolution, not MLS for every object. The first experiment should compare a sphere-level group, a per-post group, and no-MLS per-recipient envelopes under the same event and audience fixtures.
#TACo and threshold access control
TACo encrypts data client-side and distributes shares of a decryption key among a cohort. A threshold of nodes evaluates access conditions and returns decryption fragments to the requester; the documentation describes conditions based on on-chain state, RPC/API state, time, or application logic. The usual practical pattern is to threshold-protect a symmetric content key rather than bulk content. TACo access control, TACo conditions
This is valuable when TalkCo needs a release service that can enforce a condition without giving any one service the key. It is not automatically better than recipient-held keys:
- the requester must reach enough nodes at read time;
- conditions can depend on blockchain or HTTP/RPC availability;
- the cohort, cohort administration, condition references, request timing, and requester authentication create new metadata and governance surfaces;
- threshold decryption changes the failure model from “recipient has the key” to “recipient and enough independent nodes can complete release”;
- a threshold can reduce single-node trust without eliminating collusion, censorship, stale state, or policy-owner authority.
TACo's own documentation requires a developer-specific cohort for production access and describes a cohort administrator with control over cohort parameters. Its testnet documentation explicitly says testnets are unsuitable for production and have weaker trust assumptions. This makes TACo a serious later experiment, but not a dependency to place beneath every post and comment. TACo mainnet access, TACo testnets
#Proxy re-encryption and other release mechanisms
Proxy re-encryption can let a proxy transform a ciphertext or wrapped content key for a recipient without learning the plaintext. That can reduce sender-to-recipient fanout or let an archive mediate delegated access. It does not remove the proxy's visibility into requests, timing, object identifiers, or policy metadata, and revocation generally still requires a new key epoch, ciphertext update, short-lived re-encryption capability, or an online policy check.
For TalkCo the correct comparison is not “MLS versus PRE.” It is:
- recipient-held HPKE-wrapped content key;
- MLS-derived group key wrapping for a current audience;
- proxy transformation of a key envelope for a delegated recipient;
- threshold release of a key under an external condition.
Each option must be tested against the same revocation and availability cases. PRE should advance only if it removes a measured fanout, storage, or delegation problem that recipient-held envelopes cannot solve without exposing a larger graph. TACo should advance only if threshold release is required for a condition or recovery workflow that local signed grants cannot express.
#Preliminary Wave 1 recommendation
The first cryptographic profile to falsify is:
TalkCo authority event
→ random per-object content key
→ ciphertext post/comment/attachment
→ key envelope for current audience
→ optional MLS-derived wrapping key for sphere-shaped audiences
→ signed TalkCo grant and encrypted local projectionUse MLS where the audience is a real evolving group. Use HPKE or a compact envelope for one-off or sharply narrower audiences. Keep membership, revocation, object identity, and parent-reference semantics in TalkCo events. Treat TACo and PRE as optional key-release adapters with explicit online, metadata, collusion, and migration costs.
#Falsifiers for the next stream runs
- Audience churn: compare 10, 100, and 1,000-member spheres with per-post groups, sphere-level epochs, and per-recipient envelopes.
- Offline comments: create comments while members are offline, then add/remove devices and deliver events out of order.
- Revocation: remove a member, publish a new post and comment, resend old attachments, and verify exactly which historical and future objects remain decryptable.
- Authority disagreement: corrupt or delay an MLS commit while TalkCo's signed membership event disagrees. The result must be quarantine or repair, never arrival-order acceptance.
- Release-service outage: compare recipient-held keys, PRE, and threshold release during provider/node/chain/RPC failures.
- Metadata exposure: run each profile through the normalized trace harness and record group ID, epoch, message size, membership, request timing, key-envelope fanout, and storage access surfaces.
The next dependency is a precise TalkCo identity/device and audience taxonomy. Without it, “member,” “recipient,” “eligible requester,” and “recovered device” are not stable enough to compare MLS, TACo, or PRE.