Useful tools for implementing TalkCo

#Use the canonical inventory first

The complete overview is now maintained in the root tools page. It separates implementation packages, protocol and format standards, carriers, storage services, notification adapters, validation tools, bounded benchmarks, and grouped dead ends. Its compact columns are:

Job | Candidate | Role | Status | Boundary / stops at | Next gate

The page also has a decision-evidence bridge for the current Rust/Tokio, SQLite/FTS5, SQLCipher/keystore, Protobuf/Buf, COSE/CBOR, OpenMLS, Tauri/Flutter, iroh/libp2p, opaque custody, push, TACo, and validation/supply-chain gates. The round-7 remaining research register carries the detailed evidence and decisive checks; it is not a second inventory.

This workbench keeps the rationale that led to that structure, the adoption sequence, and the explicit refusals below. It intentionally does not repeat the candidate table.

#The first tool decision is an architectural boundary

TalkCo is still a documentation-first specification. The repository has a Node.js/npm publication pipeline, but it has no application client, backend, database schema, cryptographic implementation, or test runner yet. That makes a framework-first package installation premature.

The useful stack is the one that keeps private state local, makes cryptographic and transport dependencies replaceable, and lets the project test metadata leakage before it commits to a network topology. A tool implements a seam; it does not decide what a profile sphere, conversation, audience, consent receipt, or moderation action means.

#Current decision record

The current working direction is a bounded composition, not a dependency lock:

• Rust/Tokio for the replaceable core; SQLite/FTS5 for local state and search; SQLCipher and platform keystores only behind native-build and recovery gates.
• Protobuf/Buf for evolvable control messages; COSE with deterministic CBOR as the leading signed-event format candidate.
• OpenMLS for a disposable group-shaped prototype; object-level AEAD/HPKE remains the countercandidate for bounded audiences.
• Tauri 2 when a Rust-owned shell is the priority; Flutter remains the broad-platform comparison. Neither shell supplies protocol authority or recovery semantics.
• iroh plus a dumb-relay harness; libp2p, Session, SimpleX, Lokinet, Tor, and Katzenpost behind replaceable adapters and metadata tests.
• Opaque client-encrypted S3-compatible custody first, with Storj/Tahoe-LAFS and other storage systems as bounded benchmarks.
• Web Push, APNs, and FCM only as opaque wake adapters; TLA+/TLC, fault injection, packet traces, SBOMs, signatures, and provenance as release evidence.

The evidence dates, missing work, and next checks for each direction live on the canonical inventory and in the remaining decision register.

#What should not become a dependency yet

These are explicit refusals or gates, not maturity rankings:

• Direct libsignal reuse: Signal specifications remain useful design input, but external-use support, current API/bindings, licensing, and native build surface must pass a fresh review.
• TACo as routine membership or messaging infrastructure: Conditional release is relevant only for a named requirement that recipient-held envelopes cannot meet; current implementation, network, governance, and recovery facts remain transition-sensitive.
• Matrix, Nostr, ActivityPub, or similar systems as the application architecture: Their federation, public identifiers, relay/indexing surfaces, or operator histories are useful export/comparison material, not private-sphere authority.
• DID/VC, KERI, PGP web of trust, or WebAuthn as a universal identity layer: Each may fill a bounded local, recovery, interoperability, or key-continuity seam; none automatically prevents correlation or grants remote read authority.
• CRDT or hosted-sync authority for identity, membership, revocation, or governance: Automerge, Yjs/Yrs, PouchDB/CouchDB, ElectricSQL, PowerSync, Turso/libSQL, and Local-First Auth can inform projections and benchmarks, but convergence is not authorization or key rotation.
• Global search, engagement analytics, public social graphs, and server-side AI over plaintext private content: These conflict directly with the product's stated omissions.

The grouped dead-end notes retain the remaining names and one-sentence reasons without reprinting their full research context.

#Adoption order

#1. Resolve the platform gate

Choose whether the first production target is desktop, Android/iOS, browser, or a deliberately narrow prototype. The research cannot honestly select between Tauri, Flutter, Kotlin Multiplatform, or browser-first work until that decision exists.

#2. Build one disposable vertical slice

Use one context-scoped identity, one encrypted append-only event, one SQLite/SQLCipher migration, Protobuf encode/decode, mock carrier/storage/conditional-access adapters, and one native plus one browser/WASM compilation target. The gate is preservation of context boundaries across storage, serialization, migration, and adapter replacement.

#3. Validate group and signed state

Build a two-device Rust harness with OpenMLS and a minimal COSE/CBOR manifest layer. Exercise recipient-scoped introduction, offline delivery, add/update/remove membership, epoch rotation, two-of-three signed community manifests, and fork snapshots that exclude private history and live invitations.

#4. Add ciphertext-only storage and wake delivery

Run the same opaque-object interface against S3-compatible storage and Storj, with Tahoe-LAFS as a reference experiment. Record metadata traces, failure matrices, shard recovery, repair bandwidth, and cache behavior. Use Web Push/APNs/FCM only for bounded wake hints.

#5. Make privacy and supply-chain evidence release gates

Run Wycheproof, property/state-machine tests, TLA+/TLC, Testcontainers, Toxiproxy/tc-netem, TShark leakage checks, OSV-Scanner, Syft/Grype, signed digest-pinned artifacts, and allowlisted aggregate telemetry. Add continuous fuzzing, interoperability, migration fixtures, and independent reproducible builds before a real-world pilot.

#Open decisions

The shortlist remains subordinate to these decisions:

• target client platforms and whether browser parity is mandatory;
• v1 scope, especially calls, communities, personal hosting, and hot storage;
• whether TalkCo reuses or forks Signal-lineage code;
• exact Session, Lokinet, and TACo contracts and licenses;
• storage metadata visibility, durability thresholds, and repair policy;
• threat model for compromised devices, malicious hosts, traffic analysis, and recovery;
• license policy for AGPL/GPL dependencies and acceptable native toolchains.

#Evidence boundary

This workbench consolidates the 2026-08-19 shortlist and points to the 2026-09-07 remaining research register, which contains the current primary-source links, counterevidence, and decisive checks. Package/version, license, support, advisory, hosted-service, and API facts are time-sensitive and must be rechecked immediately before adoption. The canonical page records the candidate coverage; this file records why the adoption sequence and refusals are shaped as they are.