TalkCo supporting research

Wave 1–2 initial evidence: encryption, access, discovery, metadata, and edge custody

PARTIAL 12 sections

This checkpoint integrates the five independent Luna streams. It is a synthesis of evidence, not a production cryptographic design.

#Working baseline

TalkCo authority events
  → object-level AEAD ciphertext
  → signed application grant
  → HPKE envelope per recipient device
  → MLS envelope only for stable sphere-shaped membership
  → invitation-scoped discovery and replaceable delivery
  → opaque trusted-peer custody and ciphertext-only repair

The key distinction is now firm: encryption protects bytes, grants authorize application actions, MLS maintains evolving group secrets, discovery finds possible endpoints, and storage peers hold ciphertext. None of the external fabrics becomes the TalkCo membership or moderation authority.

#Wave 1: content and access control

#MLS is a selective group primitive

MLS is a good fit when a sphere or private community has a shared, evolving audience. It provides epochs, membership changes, sender authentication, and encrypted application messages. It does not define TalkCo roles, moderation, comment ordering, discovery, search, deletion, or application ACLs. RFC 9420, MLS architecture

The current candidate is:

  • one MLS group per stable sphere or community;
  • posts/comments addressed to the whole sphere carried as small application messages or key envelopes;
  • independent object keys for posts and attachments;
  • HPKE envelopes for narrow audiences, historical objects, and late joiners;
  • signed TalkCo moderation, authorship, visibility, and revocation transitions.

Do not create one MLS group per post by default. Late joiners still need historical object keys, and per-post groups multiply state, persistence, discovery, commit contention, and recovery. MLS does not provide a total order for concurrent comments. Removed members lose future epochs but retain historical plaintext and keys already obtained.

#The baseline access-control profile

The first profile should be recipient-held keys plus signed grants:

  • fresh per-object AEAD content key;
  • per-device HPKE envelope for each authorized recipient;
  • COSE/CBOR or equivalent signed grant bound to object/context, action, subject device, epoch, expiry, and revocation frontier;
  • offline deterministic validation;
  • local plaintext projections only;
  • no external key-release service in the critical path.

Capabilities can borrow attenuation and delegation invariants from UCAN, Biscuit, and object-capability systems without importing their full identity or policy ecosystem. A valid grant authorizes an operation; it does not imply possession of a decryption key.

#TACo, PRE, broadcast encryption, and ABE remain conditional branches

TACo-style threshold release is useful when the publisher is offline, the recipient is unknown at encryption time, or access depends on external state such as time, payment, or an oracle. It adds cohort liveness, policy, chain/API, request-metadata, collusion, upgrade, and maturity dependencies. TACo should sit behind a generic ConditionalKeyRelease seam, not define TalkCo membership or routine message encryption. TACo access control, TACo repository

Proxy re-encryption is worth an attachment/delegation experiment when the author cannot remain online or re-encrypting a large blob is expensive. It introduces proxy censorship, re-encryption-key leakage, metadata, online dependency, revocation complexity, and a separate cryptographic migration story.

Broadcast encryption is a specialist option for very large, mostly static, one-way audiences. Attribute-based encryption is a specialist option for cross-organization role/attribute policy. Both move substantial authority into enrollment or attribute issuers and should remain research branches unless the product requires them.

#Wave 2: discovery and metadata

#Discovery lifecycle

The operations must remain separate:

  1. An invitation or local exchange names a context-scoped application key and optional transport hints.
  2. A short-lived rendezvous, queue, local radio path, removable-media bundle, or transport ticket returns untrusted endpoint candidates.
  3. The transport authenticates the endpoint against the invitation.
  4. TalkCo validates and records the device/context membership transition.
  5. A transport handle is remembered only within that context and lifetime.

“Not found,” “stale,” “unreachable,” “not authorized,” and “revoked” are distinct states. Discovery failure must never become authorization failure.

The strongest first combination is:

QR/offline invitation
  → secret short-lived rendezvous or dumb relay
  → iroh-like transport
  → TalkCo application authentication and authority event

SimpleX-like queues are the strongest privacy/delivery reference. Briar-like QR and local exchange are the strongest disconnected-operation reference. libp2p rendezvous is a bounded experiment. Global Kademlia, public Nostr discovery, and network-wide Waku discovery should not locate private TalkCo people, relationships, audiences, or keys.

#Metadata baseline

The minimum practical policy should research:

  • opaque context-scoped identifiers rather than global lookups;
  • fixed-size or bucketed control traffic;
  • compartmentalized queues and storage providers;
  • modest batching and jitter;
  • queue/relay rotation;
  • selective cover traffic for high-risk actions;
  • stronger onion or mixnet routing only for selected traffic classes.

SimpleX provides a practical fixed-block and queue-rotation reference. Tor padding and Loopix-style mixes demonstrate the additional bandwidth, latency, and availability costs of stronger resistance. SimpleX protocol, Tor padding, Loopix

The next harness must emit a common trace for local, access-network, relay, discovery, storage, group-member, colluding-provider, and global-passive observers. It must record what is observed, inferred, unavailable, redacted, or padded.

#Edge custody

Use trusted peers for ciphertext custody only.

  • Small posts, comments, thumbnails, and event chunks: bounded full replication across two or three admitted peers and distinct failure domains.
  • Large immutable attachments: client-side authenticated encryption followed by optional erasure coding when enough independent failure domains exist.
  • Repair: signed manifest and repair capability, ciphertext-only.
  • Peer limits: total bytes, object count, shards per manifest/context, lease duration, concurrent uploads, repair bandwidth, pending repairs, and challenge frequency.
  • Evidence: possession, integrity, freshness, observed retrieval, repair, and tombstone records remain distinct.

Five peers in one household or under one operator are not five independent failure domains. A storage peer may withhold, corrupt, delete, or collude; it must not forge a manifest, authorize a recipient, revoke a member, or learn plaintext from ciphertext alone.

Tahoe-LAFS remains the semantic reference for capabilities, leases, repair, and failure-tolerant storage. S3 is the first compatibility baseline. Ceph/CRUSH, SeaweedFS, and Garage are self-hosted placement/repair benchmarks. Storj, Walrus, and IPFS Cluster are bounded external-control-plane comparisons, not private-core authorities.

#Falsifiers carried into the next wave

  • MLS, TalkCo policy, and any external authorization state disagree and arrival order silently chooses a winner.
  • A late joiner cannot receive authorized history without unsafe epoch-key retention or an object-key envelope.
  • A non-moderator’s valid MLS message changes moderation state.
  • A copied grant widens scope, crosses contexts, or replays after revocation.
  • A threshold/PRE node unilaterally releases a key or becomes unavailable below its declared liveness threshold.
  • Discovery lookup from a stable account identifier creates a public relationship graph.
  • A stale discovery record grants access or causes revocation.
  • Transport rotation creates a new application identity.
  • Size, timing, grant count, shard placement, or lease renewal leaks more relationship metadata than declared.
  • Storage repair requires plaintext, changes logical object identity, or resurrects a revoked generation.

#Dependency for the next stream

The ZK/smart-contract stream now has a bounded question: can privacy-preserving eligibility, non-revocation, commitment, lease, dispute, or threshold-coordination functions solve a demonstrated gap left by local grants, HPKE, selective MLS, scoped discovery, and opaque storage? It must not research blockchains or ZK systems as an end in themselves.