TalkCo — Application Spec · Table of Contents

#Aims and reasoning

#What this document is

TalkCo combines private conversations with contextual publishing. This living specification explains the human aims, the reasoning behind them, and candidate ways to build them. It is written for people designing, reviewing and implementing the project. Product intent, research evidence and adopted protocol decisions have different authority.

#How to read it

Read §01, §02 and §02b for the product and evidence, then the relevant feature chapter. Each chapter's Aims and reasoning section comes before Protocol and architecture. Diagrams explain mechanics; nearby prose explains the remaining assumptions and tradeoffs.

Question	Start here	Continue with
What are we trying to make possible?	Overview	Principles, evidence
How could we build it?	Architecture variations	Feature chapters below, then profiles and tests
Which technologies are most plausible?	Master research table	The comprehensive catalogue and its dated source notes
What is actually decided?	File-level Decided / open lines	Roadmap, existing issue lanes
How do I compare alternatives?	Consecutive Variation — … sections	Tabs in the generated review; all variants remain visible in Markdown and print

#Certainty is part of the specification

Label	Meaning
Product commitment	User-visible behavior or constraint owned by the numbered specification
Working direction / leading experiment	Favored implementation hypothesis, revisable against named evidence
Adapter / comparator	A bounded component or alternative, not a whole-stack adoption
Gated	A requirement, security, platform, license or operational question must be resolved
Adopted mechanism	Accepted by an explicit architecture/protocol decision and its evidence; a page edit does not supply that evidence

The older Session/TACo/Signal direction and newer Rust/DXOS/object-profile research are reconciled as explicit alternatives in §10. A library can own accepted semantics; no diagram requires a redundant custom engine. A protocol implementation still cannot guarantee copy prevention, erased recipient memories, universal anonymity or unreviewed deniability.

#Protocol and architecture

#File manifest

Chapter	Aims and reasoning	Architecture focus and leading candidates
01 · Overview	Conversations and contextual publishing	Shared foundation; native core and integrated workspace
02 · Principles	Audience, context and qualitative feedback	Scoped disclosure, local views, recipient-addressed feedback
02b · Evidence	Mechanisms, experiments and limits	Mesa/NetworkX hypotheses; separate protocol fixtures
03 · Identity	Appropriate presence without context collapse	Context keys, introductions, devices, recovery and scoped witnesses
04 · Channels	Nested, followed publication spaces	AEAD/HPKE objects and optional OpenMLS epoch delivery
05 · Messaging	Deliberate conversation and consent	Ratchets/groups, local outbox, consented promotion and recipient descriptors
06 · Feeds	Finite discovery without amplification	Local SQLite/FTS5 projections, bounded frontier and reply audiences
07 · Attention	Recipient control and low interruption	Local policy, opaque platform wakeups or pull adapters
08 · Safety	Protection, repair and bounded consequences	Local blocks, scoped reports, overlays and evidence boundaries
09 · Community	Kaupapa, do-ocracy and optional shared memory	Shared records, scoped grants, optional sensitive-operation approvals
10 · Architecture	Local agency and privacy across operators	State ownership, components, profiles, routes and custody seams
11 · Hosting	Sustainable capacity without reading rights	ERIS/Kapla, iroh-blobs, Tahoe/ZKAP or smaller replica/coding services
12 · Roadmap	Preserve product scope and resolve uncertainty	Common fixture, decision gates, protocol handoff and launch conditions

#Research and options

The research hub supplies the reading map and evidence vocabulary. Its master table is the only comprehensive candidate inventory.

Research page	Protocol responsibility
Content lifecycle	Logical objects, revisions, consent, descriptors, shared history and checkpoints
Encryption and keys	Private authentication, retained keys, group security and conditional release
Trust and discovery	Introductions, identity continuity, device succession and recovery
Access and moderation	Action authority, concurrent removal, scoped evidence and library ownership
Distribution and storage	Ciphertext representation, delivery, leases, repair, quotas and metadata
Tools and libraries	Candidate roles, boundaries, source dates and adoption gates
Architecture profiles	Independent design axes and a common falsification fixture
Matrix P2P / Tachyon	Bounded group-engine, embedded-homeserver and carrier comparisons

#Supporting references

References defines citation keys; glossary defines terms; issue lanes routes decision work; changelog records integration changes. Dated workbench studies remain evidence and history, not competing live specifications.

#Conventions

Markdown is the master source. Architecture variants use ordinary same-level headings; reusable presentation lives in the generated-site layer. See the writing guide for source structure, evidence discipline and diagram conventions.

Build with the repository's pinned dependencies, then run the documentation build, HTML/source synchronization and diagram checks. The generated section map below must be refreshed whenever headings change. A rendered page is a review surface, not a second source of truth.

#Open Threads

This index owns navigation, not design decisions. Unresolved choices remain with their feature/research chapter and §12.

Full generated section map

#Section map

Generated by node scripts/build-html.js --refresh-section-map. Use this map to navigate the application-spec sections and their local headings.