10 · Architecture & Protocol

#Aims and reasoning

#Privacy should survive a change of host

A person should not lose their relationships, private records or ability to publish because an operator disappears. A community should keep useful shared memory without handing a service a map of its members or giving technical administrators authority over ordinary community life. These are the reasons for local state, portable objects, contextual identities and replaceable delivery and storage.

Privacy also has an insider boundary. A permitted reader can copy plaintext. An encrypted signature can become evidence when that reader reveals it. A provider that cannot decrypt may still observe who connects, when and how much. TalkCo therefore separates confidentiality, source authentication, authority, custody and traffic privacy. The authentication research owns the unresolved deniability construction.

#Reuse should remove work without importing the wrong social model

Conversations, channels and an optional community workspace can share device lifecycle, object access, persistence and synchronization while retaining different contexts and histories. The shared-core study supports one implementation foundation with independently deployable clients and hosts.

Each state machine needs one owner: a reviewed library or TalkCo code. A second log or permission engine is justified only by a responsibility the selected implementation does not already satisfy. Community kaupapa guides practice; it does not become an executable constitution because a framework offers roles and workflows (§09).

#Working directions remain visible until an adoption decision

Earlier versions called Session transport, TACo access control and a Signal bridge the chosen stack. Newer research reopened that composition. This page reconciles their status as working directions under evaluation, alongside newer candidates; it does not record a winning replacement. Architecture lane #1 owns the eventual retain, narrow or supersede decision.

The comparison is total implementation and maintenance cost while meeting the same product promises. A successful packet exchange, buildable library or diagram is insufficient adoption evidence.

#Protocol and architecture

#One contract, several possible implementations

Library ownership is accepted per contract, not inherited from a default account or database. The network may omit, reorder or replay data; neither a relay acknowledgement nor a local optimistic edit establishes permission. Recovery and freshness policy must be explicit wherever an operation releases a new key or broadens an audience.

This is a local shortlist. The master research table owns the comprehensive inventory, source dates and alternatives.

#Variation — Smaller native core

This path permits narrow substitutions and a small headless host, while leaving more lifecycle and interoperability work with TalkCo. If p2panda authorization or merge semantics pass the contract, that implementation can own the responsibility without a custom duplicate. Its current repository describes modular packages and warns that APIs and core types are not production-stable before v1 (primary source, checked 2026-10-24).

The UI submits commands. Optional Effect coordinates client tasks; persistent retries have one durable owner. TanStack DB needs a tested snapshot/delta boundary. These are client comparison gates, not a requirement to install every named UI library.

#Variation — Integrated workspace

This is a replacement composition where accepted library semantics remove substantial work. The contract constrains identity, shared history, synchronization and custody before any private data is admitted; it is not a second authoritative history above ECHO. The diagram states the required integration boundary, not that the package already exposes each adapter. The strongest open questions are context isolation, broad app/device access, transferable history evidence, local protection, export and exact source license. The dated DXOS evaluation records inherited findings; adoption must establish current terms and behavior.

Encrypting a signed history does not settle deniability. If the required private profile conflicts with the history or identity model, include the cost of changing that model or reject it for that surface.

#Variation — Client-owned recurring-group engine

The Matrix P2P study makes this a bounded group-engine countercandidate. The inspected Tachyon experiment uses Matrix delivery and separate room/epoch graphs; it does not demonstrate arbitrary cryptographic-fork convergence or TalkCo-compatible deniability. Neutrino's embedded-homeserver experiment is a different comparison. Combining them needs evidence of a distinct benefit.

#Encryption profiles vary independently of the client stack

The detailed variant diagrams and admission tests live in architecture profiles. A0 is a reference experiment, not a claim that a direct-network prototype is safe for every community. OpenMLS distinguishes tested targets from Android, iOS and WASM targets built but unsupported in CI; platform and recovery tests precede selection (OpenMLS book, checked 2026-10-24).

#Different evidence needs different authentication

HPKE encryption alone does not authenticate a person. A group key alone does not distinguish writers against insiders. A private signature hidden in ciphertext can still be revealed. The evidence review includes introductions, device bindings, checkpoints, reports and recovery because those records can recreate excluded proofs or links (authentication study).

Descriptor authentication also binds the exact encrypted representation, selected evidence profile and replay state. Its expected profile comes from trusted context state; an incoming field cannot choose a weaker verifier. The envelope contract owns the detailed binding requirements.

A context-scoped logical object ID, revision/dependency reference, authority state, encryption generation, storage locator and audience descriptor have different meanings. A ciphertext hash is a retrieval/integrity reference, not a universal social-object or author identifier. Deterministic CBOR/COSE and carrier-specific Protobuf/Postcard remain format candidates. Exact authenticated bytes, domains, unknown fields and downgrade rules need conformance vectors.

#The receiving boundary is part of the protocol

Checks must match the selected engine: dropping arbitrary CRDT updates can invalidate legitimate descendants. Arrival time and wall-clock timestamps are not authority. During partitions, useful local edits may continue while new disclosures wait for the freshness policy; convergence cannot undo a key already disclosed. Concurrent-removal and checkpoint rules remain lane #5 gates.

#Traffic classes obey an explicit privacy profile

p2panda may use iroh underneath its synchronization/network packages; they are not necessarily competing layers. Direct iroh connections expose peer IP addresses, and relays observe connection metadata. Context-specific endpoints reduce some links but do not hide timing or shared network paths (iroh privacy documentation, checked 2026-10-24).

Retained Session-style small-message routes, Lokinet richer-traffic routes and other private adapters must face the same observer model. Reticulum/Zenoh adaptation remains research where offline, low-bandwidth or local requirements justify it; no compatible TalkCo adapter is assumed. Lookup, rendezvous, push, polling, expiry and blob fetches belong to the same trace. No adapter may silently downgrade a private context to direct delivery.

#Custody receives bytes and obligations, not social authority

ERIS representation, iroh-blobs transfer and S3-compatible byte I/O are different jobs. ERIS can encode application ciphertext independently of a backend; iroh-blobs supplies verified blob/range transfer; a custody service adds finite leases, quotas, repair and expiry. Byte receipt or a live connection does not prove durable retention (ERIS specification, iroh-blobs). Variant diagrams and the repair contract live in §11 and storage research.

#How access control enforces the product

#The Signal-fork strategy: bridge, then independence

The older B→A proposal remains an adoption experiment: a compatibility leg to Signal followed by independent TalkCo operation. A bridge must visibly distinguish destination network and capabilities; it cannot silently carry a context into different audience, retention or evidence rules. Client source reuse, libsignal reuse and service access are separate decisions. Current libsignal explicitly describes use outside Signal as unsupported; API compilation is not a service commitment (libsignal README, checked 2026-10-24).

#Swappable abstraction, given TACo's transition

TACo remains a named conditional-release comparison. Ordinary close-friends membership, feed reads and coordination do not themselves establish a need for threshold release. Identify the condition, operators, failure/recovery model, retained-key limits and costs before adding it. Earlier relaunch dates are historical planning evidence, not a current availability guarantee. A release service cannot revoke keys already retained by readers.

#Decision gates and open threads

The roadmap sequences these outputs. This pass supplies implementation hypotheses and reviewable connections; documentation alone validates no cryptographic composition, network privacy guarantee or package selection.