#Why this split exists
The application specification answers what TalkCo is: conversations and channels, consentful conversation artifacts, bounded comments, contextual identity, safety principles, hosting intent, and the current high-level architecture direction. The research surface answers how competing technologies might implement those behaviors. Mixing them makes a candidate library look like a product decision and makes a provisional architecture look settled.
#Research pages and reader questions
| Page | First question | Primary visual job |
|---|---|---|
| Hub | What is being researched, what is provisional, and where should I start? | Research map and decision-status flow |
| Content lifecycle | What exactly happens when a message becomes a post? | State machine plus consent/provenance sequence |
| Encryption and key management | Which cryptographic mechanism fits each content and audience shape? | Method decision tree and key lifecycle |
| Trust, discovery, and TOFU | How do first contact, device change, recovery, and peer discovery work? | Trust ladder, split-view diagram, discovery topology |
| Access control and moderation | Who can read, publish, reply, moderate, or release content? | Authority matrix and evidence flow |
| Distribution, storage, and metadata | What does “more distributed” mean operationally? | Layered topology, custody/repair, observer map |
| Tools, libraries, and adapters | Which packages are candidates, and where do they fit? | Adapter architecture and maturity matrix |
| Architecture profiles | How do A0, A1, and conditional release differ, and what would falsify them? | Profile comparison and falsification matrix |
#Dependency order
product transition
→ cryptographic jobs
→ trust and discovery
→ authority and moderation
→ distribution, storage, and metadata
→ tools and library seams
→ architecture profiles and tests#Classification vocabulary
Every research page must label claims as one of:
- Settled application behavior — already owned by the core specification.
- Working direction — currently favored, but still revisable.
- Research candidate — plausible mechanism requiring a spike.
- Benchmark candidate — useful comparison point, not an adoption proposal.
- Rejected for current scope — explicitly outside the first critical path.
- Provisional recommendation — current integration choice pending named tests.
#Boundaries
The research pages do not define final wire formats, cryptographic domains, exact package versions, legal policy, or the canonical §10 stack. Those belong in a future protocol specification or an explicit core-spec decision. Round-five evidence reports and Sol's review remain provenance artifacts under docs/research/round-5/.
#Acceptance gates
- The numbered core navigation contains product pages only; research leaf pages appear under a separate Research & Options group.
- Each page answers one reader question and links to adjacent pages instead of duplicating their comparison tables.
- Every diagram has a declared job and nearby prose equivalent.
- Every candidate is separated into facts, inference, recommendation, tradeoff, and unresolved test.
- The A0/A1/conditional-release comparison remains provisional.
- Generated HTML has no unintended cross-page Markdown links, stale page-13 references, or missing research cards.
#Open Threads
- Decide whether a future protocol-spec site should inherit the research pages or link to them as historical rationale.
- Keep package versions, licenses, security advisories, and platform support dated at implementation time.