#Aims and reasoning
TalkCo needs useful local work, contextual relationships and portable shared objects without turning a private life into a public evidence trail. Research is useful when it removes implementation work while preserving those aims. A framework's default account, authority or history model is therefore part of its suitability, not a neutral detail.
The numbered specification owns the human and product commitments. This research surface owns implementation hypotheses, counterexamples and tests. A named candidate advances only when its contract, failure/recovery behavior, context isolation and maintenance cost are understood. A library can own an accepted state machine; a duplicate custom engine is not required for architectural purity.
#How to read a research claim
Use explicit categories: user-directed product constraint; working direction; research/prototype candidate; benchmark/reference; rejected for the current requirement; and adopted mechanism supported by a recorded decision. A named package is not a dependency approval.
Separate inherited research, new source inspection, executed code, formal-model output and independent security review. Default-branch URLs, draft identifiers, release dates, audits, licenses and platform support are not timeless evidence. Do not infer maturity or confidentiality from a project name.
#What stays in the core specification
The numbered pages own conversations, channels, spheres, consent, recipient-controlled attention, personal safety, ordinary community practice and hosting intent. They must not promise copy prevention, remote erasure, universal anonymity or deniability beyond a validated threat model.
Legacy Session/TACo/Signal-fork commitments require explicit reconciliation through #1. Reopening their implementation status is not an accepted replacement stack. Community technical custody does not supply general social authority; kaupapa is guidance, not executable law.
#What stays in this research surface
Exact formats, encryption suites, context-key hierarchy, group-history and revocation semantics, carrier selection, ERIS codecs, custody/accounting extensions, package versions and fork plans remain here until evidence supports a protocol ADR. Product meaning does not move into a library by implication.
Evidence and provenance
Earlier evidence remains in round five, its synthesis, adversarial review and ledger. Round-seven material remains available as a historical workbench.
The September 21 integration combines the supplied conversation/snapshots with live repository baseline bbfb7c8a304ba201a236d4271bfdf7d194f3b780. It does not claim all external sources were refreshed or any crypto/storage/network composition passed tests. User instructions are a design basis, not empirical studies.
#Protocol and architecture
#Start with the decision boundary
Core ownership, group security, carrier privacy and storage representation are independent axes. OpenMLS or a bounded Tachyon-style engine can serve a recurring-group seam without owning every publication or shared record. p2panda may use iroh beneath its synchronization components. ERIS is a representation, not an operator network. §10 connects these boundaries in concrete variations.
#Research map
| Page | Owns | Decision lanes |
|---|---|---|
| Content lifecycle | Objects, revisions, promotion, consent, replies, views and checkpoints | #2, #3, #5 |
| Encryption and key management | Confidentiality, recipient authentication, evidence transfer, retained keys and conditional release | #3, #4 |
| Trust and discovery | Local trust, introductions, context identities, device continuity and recovery | #4, #9 |
| Access and moderation | Technical grants, concurrent authority, evidence and scoped consequences | #5, #8, #12 |
| Distribution and storage | ERIS, custody, leases, repair, quotas, transport and observation boundaries | #6–#9 |
| Master research table | The sole comprehensive candidate overview and next gates | #1–#13 |
| Profiles and decision tests | A0/A1/conditional profiles and the shared fixture | #1, #13 |
| Issue-lane map | Scope, interfaces, parallel work and existing-thread routing | #1–#13 |
| Round-seven register | Earlier P0/P1 evidence and unresolved implementation boundaries | Historical input to current lanes |
The master research table remains the only comprehensive catalogue. Supporting workbench notes preserve detailed evidence, not competing live status tables. GitHub issue state is not mirrored as a second mutable ledger in Markdown.
#Dated integration studies
- Local-first tool evaluation — 2026-09-18 — DXOS, Jazz generations, LiveStore, Effect/TanStack DB, Fireproof, OrbitDB, UCAN, verified retrieval and backend-shaped sync.
- Social filesystem and deniable authentication — 2026-09-19 — portable private objects, recipient-local authentication, shared history, custody and evidence transfer.
- Shared-core integration — 2026-09-21 — one implementation foundation for TalkCo and the optional community workspace.
- Collaborative spreadsheet and decentralized authority — 2026-09-21 — Mog, p2panda, Willow/Meadowcap, Le-Space, Mindoo, NextGraph and spreadsheet-specific concurrency.
- Community practice and permission models — 2026-09-21 — do-ocracy, kaupapa, scoped roles, p2panda-auth, Keyhive, Radicle, labels and the limit of governance-as-code.
- Open Local First / FOSDEM 2026 project scan — 2026-09-22 — conference-wide reconciliation covering Willow, Keyhive, NextGraph, p2panda, Radicle, Seed, Teamtype/CEP, Spritely, Yjs production cases, Teleportal, SQLRooms, Flec/VeriFx and the remaining scheduled projects.
- Matrix P2P and Tachyon — 2026-09-24 — client-owned room authority, Neutrino/Iroh source corrections, contextual identity and private evidence conflicts, adapter boundaries, computational models and falsification tests. This is a research comparison, not a replacement stack ADR.
#Focused implementation comparison
The smaller-core candidate remains Rust/Tokio with SQLite and a replaceable client. Effect and TanStack DB are focused TypeScript integration experiments. DXOS/ECHO/Composer is the substantial workspace countercandidate. Fireproof, OrbitDB and Classic Jazz merit bounded data/identity tests, not simultaneous complete implementations.
ERIS is a leading immutable-representation experiment, not a finished custody system. Compare Kapla/ERIS, Tahoe/ZKAP and a small Rust custody service with the same encrypted workload. Quotas, repair, key retention, traffic privacy and incident handling remain independent gates. No large fork is justified before the comparison establishes what it saves.
The September tool evaluation records important version, license and trust-model distinctions. Those claims retain their evidence dates and must be refreshed at implementation time.
#Private social files and evidence boundaries
Open formats can make posts, records and shared files independent of apps and hosts without creating a public everything-folder. A local view, read capability, edit grant, source authenticator and custody lease are distinct.
Private content authentication is not universally a transferable author signature. The proposed composition stores one application-encrypted payload and distributes separately authenticated recipient descriptors. Pairwise keys, HPKE Auth, ratchets, designated-verifier constructions and deniable contextual-key bindings have different limits. The September authentication note preserves that distinction; the complete construction is still open.
A shared key cannot identify individual writers against malicious insiders. Late readers may receive current checkpoint endorsement rather than original historical proof. Recovery, introductions, signed roots and storage receipts must not quietly reconstruct evidence or cross-context links the private profile meant to avoid.
#Open questions
Use #1–#13 for active decision work. Preserve existing unrelated notification, channel, simulation and terminology threads in §12. Do not duplicate or silently close them when importing research.