#Aims and reasoning
#Conversations are the second primitive
A conversation is something you say to someone; a channel is something you publish. Both are first-class in TalkCo. A bounded conversation supports replies, acknowledgments, and negotiations that would create different pressures in a broadcast audience. The publishing primitive is defined in §04.
Group conversations remain personal-scale. A shared space that needs persistent channels, membership policy, stewarded permissions, norm facilitation, a labeler, or continuity beyond its participants belongs to the community model in §09. Group volume is handled by the recipient's rate-aware rules in §07.
#Conversation settings are negotiated, not imposed
A channel has an owner and an audience; a conversation has participants. People should be able to express “I prefer no read receipts,” “I am invisible right now,” or “I would like this conversation to disappear after a week” without pretending to control another person's device. Local choices, preferences, proposals, and notices must remain distinguishable.
The product should describe what cooperating clients do. It cannot establish that another device erased a decrypted message or obeyed an interface preference. Useful customization belongs in the default client so ordinary choices do not require modified software.
#Read receipts, reframed as a tool for the reader
The feature should help a reader organize their response, without making opening a message an obligation to answer. No automatic read-state is transmitted by default. A private reply-later flag helps the reader remember; a deliberate acknowledgment such as “got it, will reply” communicates when they choose.
Mutual or delayed receipts remain opt-in candidates for close pairs. The request, decline, delay, and withdrawal controls must avoid pressure. Existing receipt controls and communication-pressure research support testing those choices separately (AppleMessagesReadReceipts, WhatsAppReadReceipts, Gegenhuber2024, BarberSantuzzi2015).
#Presence should be scarce and scoped
Online status and “last seen” are absent or off by default. Typing indicators are off unless participants opt in or a later active-conversation prototype demonstrates sufficient benefit. Invisible mode can apply globally or to selected contexts: availability is the person's choice, not a conclusion the service should publish from their activity (Gegenhuber2024, AppleFocus).
#Reactions as lightweight replies
A conversation reaction is visible to that small conversation. Labeled Yes/No/Maybe/Got it-style reactions may notify when they replace a short answer; other emoji need not notify by default. Labels and icons require validation because generic emoji are not precise semantic acknowledgments (SlackReactions, Tardelli2025, Morstatter2017). Broadcast reactions remain author-private and silent in §06.
#Message priority is a property of the message
A sender may mark normal, high, or emergency priority while composing. It is a hint. Recipient control, visible markers, and the consequences of repeated overuse belong to §07, including operating-system notification controls.
#Disappearing conversations
Disappearing content lowers the stakes of ordinary talk. It is a negotiated retention preference, not a promise that recipients cannot record it. Avoid permanent log entries that make temporary sharing unusually conspicuous; explain actual retention and backup behavior where the person makes the choice (Bayer2016, ChoiWilliamsKim2020, Kreling2022, Kim2024BeReal).
#Edits and deletion are requests, not magic
Once plaintext reaches another device, a sender cannot guarantee deletion of copies, screenshots, previews, or modified-client caches. TalkCo can accurately say “Person A requested deletion,” show that a message changed, or remove it from the default view. A correction should not silently rewrite the context of another person's reply.
#Conversation artifacts need consent
Preserving a useful conversation should be an intentional act. Meaningful participants agree to the selected material, intended audience, retention, and permitted provenance disclosure before it becomes a shared memory or channel post. A private pin is only a local reference; it does not enlarge the audience.
The artifact can be a bounded photobook, a shared memory page, or a channel post. None makes the entire conversation into publishing material. A deliberate attestation to the new artifact also need not prove who originally said each private sentence. The lifecycle research owns that distinction.
#Protocol and architecture
#Keep local attention state out of the conversation stream
An acknowledgment is a chosen message; a transport acknowledgment means only what that delivery layer actually observed. Neither proves a person read, understood, or was available. Private preferences may later sync between the owner's devices as encrypted user state, without becoming remote presence signals.
| Act | Candidate protocol behavior | Authority limit |
|---|---|---|
| Reply-later flag, invisible mode, notification mode | Device-local state; optional encrypted own-device sync | Does not grant the sender access to local state |
| Receipt preference or retention preference | Versioned preference or proposal with explicit acceptance where mutual behavior is requested | A modified recipient can still retain data or decline disclosure |
| Acknowledgment or short-answer reaction | Authenticated conversation item referring to the target revision | Recipient decides interruption; no broadcast engagement counter |
| Edit or withdrawal | Authenticated revision/notice referring to the prior item | Default-client overlay, not proof of remote erasure |
| Membership or device change | Authorized control transition under the accepted context policy | Transport delivery order and a newly presented device key do not establish authority |
| Promotion request and agreement | Separate scoped artifact workflow | Does not export conversation keys or default to a transferable personal transcript signature |
These are semantic categories, not finalized message names or wire formats.
#Variation — Pairwise sessions for asynchronous conversation
The leading 1:1 experiment uses Signal's PQXDH and ratchet specifications through a version-pinned adapter. libsignal is a gated reuse candidate: its maintainer documents external use as unsupported and APIs as changeable. Reusing a cryptographic library does not provide access to Signal's service or settle the separate bridge strategy in §10.
Private session authenticity must not be undone by an added personal signature over each message, ciphertext hash, upload request, or consent receipt. The encryption research defines the evidence questions; the protocol name alone does not establish complete deniability.
#Variation — OpenMLS for evolving multi-party groups
MLS can maintain group key epochs, but the application must define who may add a member, how concurrent commits are accepted, what late joiners learn, and how a device rejoins after recovery. A group epoch is not independently a TalkCo permission grant. OpenMLS provides group APIs and pluggable crypto/storage components; its current platform documentation distinguishes tested targets from mobile/WASM builds that are not equally supported (OpenMLS Book).
This option needs a group-authentication evidence profile. MLS messages contain signatures; encryption alone does not make those signatures non-transferable. Per-recipient authenticated change batches, contextual signing keys with separately analyzed personal bindings, and late-reader checkpoints remain alternatives in the encryption research. A two-party MLS variant must earn its complexity against the pairwise baseline.
#Promotion crosses a new consent and key boundary
Missing required evidence leaves publication pending. Concurrent withdrawal and publication require an explicit causal policy; a partition cannot provide instant knowledge of another participant's new withdrawal. A later recipient receives a newly authorized artifact, not the original conversation's session secret. Exact promotion and history semantics belong to lifecycle research.
#Likely components and their limits
| Component from the technology inventory | Local job | Status / decisive test |
|---|---|---|
| Rust + Tokio | Own persistent conversation/session tasks and delivery cancellation | Working candidate; suspend/resume and backpressure |
| SQLite / rusqlite | Outbox, local projections, preferences, and accepted state | First-slice candidate; crash-safe state/outbox transitions without reusing cryptographic state |
| libsignal adapter | Pairwise session establishment and evolving message keys | Gated reuse; target bindings, API/license policy, recovery, and evidence export |
| OpenMLS adapter | Multi-party epochs and group-protected application data | Gated group prototype; concurrent commits, late joins, mobile persistence, and credential binding |
| Object AEAD + protected recipient descriptors | Durable attachments and consented artifacts independent of session history | Protocol candidate; object/context binding, key retention, and no exported session secrets |
| p2panda-sync or a smaller reconciliation adapter | Transfer authorized history or opaque queued records | Research comparison; no accidental public author feed or second authority model |
| Automerge / Yjs | Optional jointly edited artifact draft before publication | Bounded draft candidate; history and actor leakage, selected snapshot consent, and dependency-safe authorization |
One component owns each accepted state machine. A collaboration library can own a draft's merge semantics when those semantics are deliberately adopted; the client must not maintain a competing custom “truth” above it. None of these packages has been integrated or security-tested by this documentation change.
#Open questions and validation
- Receipt and typing prototypes (OT-05-001, OT-05-002): test optional mutual/delayed receipts, decline language, and active-conversation indicators against communication pressure and metadata leakage.
- Short-answer reactions (OT-05-003): test labels, icons, and custom sets; notify only when a reaction acts as a reply.
- Session and group admission: test two devices, offline membership changes, duplicate delivery, stale snapshots, revocation, and resumed clients under both candidate variants.
- Consent and private evidence: define meaningful participants by artifact type, concurrency with withdrawal, and deliberate attestation without converting all private history into transferable proof (#3, #5).
- Voice/video calls: scope and delivery remain a later go-to-market gate in §12.