From private message to distributed publication

TalkCo is not choosing between “a messaging system” and “a publishing system.” The product idea is a controlled transition: a private message can be pinned or upgraded into a published post, and replies can become the thread below that post without discarding their causal history or silently changing their audience. That transition makes key exchange, access control, moderation, and local-first conflict semantics one connected research problem.

This round will research the smallest architecture that can support that transition while keeping content end-to-end encrypted, authority explicit, discovery replaceable, and distribution broader than one server without confusing “distributed” with “decentralized.” It will also decide what can replace or supplement Trust On First Use (TOFU) for users, devices, groups, and publishing contexts.

#Decision boundary

The research must answer:

• how a message, post, reply, attachment, moderation action, and promotion event should be represented and linked;
• whether promotion changes the ciphertext, audience, key envelope, object identifier, or only the publication state;
• which key-exchange layers can replace plain TOFU for first contact, device addition, key rotation, offline recovery, and group membership;
• whether key transparency, cross-signing, witnesses, gossip, out-of-band verification, WebAuthn, social recovery, or threshold approval should be combined;
• how authorization distinguishes authoring, reading, replying, editing, moderating, pinning, promoting, and re-sharing;
• how local-first replicas resolve concurrent publication, moderation, removal, and audience changes without arrival-order authority;
• which MLS, HPKE, capability, CRDT, event-log, transport, discovery, and storage libraries are useful as adapters or benchmarks;
• how the product can be distributed across independent nodes while keeping application authority, private keys, and metadata boundaries explicit;
• which approaches deserve the first vertical-slice experiment and which should remain research-only.

#Shared object and state model

Every stream must evaluate the same lifecycle rather than comparing protocols in isolation:

private message
  → pinned message (local reference)
  → promotion proposal
  → authorized promotion event
  → published post projection
  → replies/comments as linked encrypted events
  → moderation, edit, tombstone, or audience-transition events

The first hypothesis is that promotion creates a new publication projection and audience/key grant while retaining a signed causal link to the source message. It must not silently make a private message public. A reply may be visible in the private conversation, the published thread, or both only when the reply's own audience and grant permit it.

The shared object matrix is:

#Alternatives to plain TOFU

TOFU is a useful bootstrap but a poor universal trust model. It detects a change only if the user remembers the old key, and it does not solve malicious first contact, device insertion, directory split views, recovery, or group membership by itself.

The research will compare a layered model rather than searching for one replacement:

1. Authenticated invitation: QR, local exchange, signed link, or an existing verified device introduces a context and initial device key.
2. Device-root and cross-signing: a logical user root or verified device set signs new device keys and records replacements/revocations.
3. Scoped key directory: a context-specific directory returns signed key records with version/checkpoint, freshness, and proof of consistency.
4. Transparency and witnesses: monitors, gossip, or independent witnesses detect equivocation or split views; they do not establish human identity by themselves.
5. User-visible verification: safety numbers, QR fingerprints, short authentication strings, or hardware-backed enrollment provide a high-assurance ceremony for sensitive contexts.
6. Recovery and quorum: social recovery, threshold approval, or steward quorum handles account/device loss without silently resurrecting revoked keys.

The key decision is which layers are required for ordinary messaging, private spheres, published contexts, and high-risk contexts. Key transparency is not a substitute for application authorization; cross-signing is not a substitute for an auditable directory; WebAuthn attestation is not automatically proof of a user's identity.

#Dependency-ordered research waves

#Wave 0 — product transition and authority boundary

Freeze the message→post transition, object identifiers, source/parent references, audience classes, device model, authority topology, moderation roles, revocation semantics, and observer threat model.

Exit gate: two independent implementations would agree on whether a promotion, reply, edit, tombstone, or moderation event is valid without trusting arrival order.

#Wave 1 — key exchange and TOFU alternatives

Compare invitation-bound keys, device roots/cross-signing, key transparency, witnesses/gossip, scoped key directories, safety-number/QR ceremonies, WebAuthn/passkeys, social recovery, threshold approval, and capability-bound device records.

Test malicious device insertion, directory split view, stale checkpoints, offline enrollment, device loss, backup restoration, key rotation, context separation, user-visible verification, and metadata leakage.

Exit gate: select an A0 trust ladder for ordinary messaging and publishing, with stronger verification profiles for sensitive contexts and explicit recovery behavior.

#Wave 2 — shared messaging/publishing event fabric

Compare Matrix-style signed state events, MLS/Marmot group epochs, p2panda-like signed event graphs, Automerge/Yjs/CRDT projections, Secure Scuttlebutt/Hypercore feeds, and Nostr-like public event relays.

Test promotion, inherited versus independent audience, comment fanout, offline replies, concurrent moderation, edits/tombstones, re-sharing, and publication rollback.

Exit gate: define the canonical TalkCo event model and a message→post state machine independent of any transport or CRDT library.

#Wave 3 — encryption and distributed access control

Compare object-level AEAD/HPKE envelopes, MLS group epochs, signed capabilities, UCAN/Biscuit/Macaroon-style delegation, broadcast/attribute encryption, PRE, threshold release, and key transparency evidence.

Test author versus reader versus moderator authority, promotion to a larger audience, removal, late join, device compromise, offline grants, re-encryption, provider compromise, and key-release outages.

Exit gate: choose the default object-envelope and grant contract; any PRE/threshold system must have a named requirement that recipient-held keys cannot satisfy.

#Wave 4 — local-first persistence, discovery, and edge distribution

Compare local databases/sync layers and transport fabrics for persistence, recovery, conflict semantics, peer discovery, metadata, and ciphertext custody. Evaluate Automerge, Yjs, RxDB, ElectricSQL, cr-sqlite, PouchDB/CouchDB, p2panda, iroh, libp2p, Hypercore/Hyperswarm, Matrix, and trusted-peer storage adapters.

Exit gate: the selected vertical-slice seams can survive ordinary disconnection, duplicate/out-of-order events, peer replacement, relay failure, and ciphertext repair without making a substrate identity into TalkCo identity.

#Wave 5 — adversarial integration and approach selection

Synthesize no more than three core approaches:

1. A0 local-first signed event fabric: object-level E2EE, layered key verification, selective group security, replaceable transport, bounded edge custody.
2. A1 sphere-epoch publishing: A0 plus MLS for stable private publishing contexts and explicit promotion/reply audience rules.
3. C conditional distributed release: A0 plus PRE/threshold/ZK/contract adapters for one named external-condition or recovery requirement.

Admission proofs, metadata transports, storage backends, and verification UX are adapters tested across the core approaches rather than separate architectures.

Exit gate: recommend the smallest approach that passes the shared harness and publish the tradeoffs, rejected alternatives, and remaining blockers.

#Shared falsifying harness

• Promote a private message with a larger audience and verify that the original conversation does not become readable to new readers without a new grant or re-encryption decision.
• Deliver promotion and reply events in different orders, with missing parents and duplicate events; verify deterministic quarantine and eventual repair.
• Add a device through a malicious directory, stale checkpoint, backup restore, or compromised existing device; verify the same acceptance decision across replicas.
• Rotate a device key and publish a new post while the old device is offline; verify future access, historical access, and cached-key limits.
• Create concurrent moderation events from authorized and unauthorized writers; retain evidence while materializing the same valid state on every replica.
• Compare inherited post audience, explicit reply audience, moderator-only evidence, and re-share grants without allowing a signed grant to override possession of a broader group key.
• Run A0/A1/C through relay, discovery, storage, threshold, and chain outages; record which local operations remain available.
• Correlate access-network, rendezvous, relay, storage, and publishing traces; state the accepted metadata leakage for each profile.
• Restore old CRDT/event state, replay grants, roll back manifests, and submit stale transparency checkpoints; fail closed at the authority boundary.
• Measure fanout, persistence, battery, proof size, verification cost, repair time, and recovery time at audience sizes 10/100/1,000/10,000.

#Engaging HTML page brief

The page should answer a reader's questions in this order:

1. What is the product transition? Show the message→published-thread flow as a visible state diagram.
2. Which trust problem are we solving? Explain TOFU's limits before presenting alternatives.
3. What are the three approaches? Use a comparison table with audience, encryption, verification, distribution, moderation, cost, and failure mode.
4. What should TalkCo use first? Keep the A0 recommendation visible and separate from experimental A1/C branches.
5. What does each approach give up? Put detailed protocol/library tradeoffs in labeled disclosure blocks.
6. What would falsify the recommendation? Keep the test gates visible near the decision.

The page is Markdown-mastered and generated into the site's styling layer. It should use one flow diagram, one approach comparison table, one trust-ladder diagram, and disclosure blocks for source notes, rejected options, and implementation details. All diagrams need accessible text equivalents and must render in light/dark themes and narrow widths.

#Current non-goals

This round will not deploy a key-transparency service, create a threshold committee, choose a blockchain, implement a new ratchet, or select a final library solely from feature count. It will not claim that a distributed directory proves human identity, that MLS solves publishing ACLs, or that encrypted storage removes metadata.

The orchestration ledger is round-5.ledger.json. The prior object/key boundary remains in round-4/content-access-synthesis.md.