#Why another round is needed
The first round selected promising seams: a Rust core, local encrypted state, signed protocol objects, MLS/OpenMLS as a group prototype, opaque storage adapters, and privacy-focused validation. It did not yet establish what “local-first” means for each object, what must converge during a partition, or whether TalkCo is distributed in control and failure handling rather than merely decentralized in ownership.
The second round therefore researches four separate questions before choosing more packages.
#Material gaps
- State models are not assigned to object classes. Messages, channel posts, membership, key epochs, receipts, deletion requests, manifests, recovery records, and shard sets may need different authority and consistency rules.
- The identity wording is ambiguous between one private device-local ownership root and one protocol-visible identity. The latter would conflict with the requirement for separate sphere identifiers, keys, endpoints, storage namespaces, and recovery records.
- The Signal-fork strategy in the architecture document conflicts with the first-round Rust-core direction. Protocol compatibility, source reuse, UX reuse, network interoperability, crypto-library reuse, and licensing need separate decisions.
- “TACo commitment” should likely become “conditional-access seam, with TACo as one candidate implementation” until the project’s transition, governance, API, and license settle.
- Threshold steward signatures, threshold decryption, storage reconstruction, distributed key custody, and Byzantine quorum are different mechanisms and must not share one undifferentiated design label.
- Storage redundancy and repair constants are hypotheses, not TalkCo-specific evidence. They need churn, malicious-host, repair-storm, battery, bandwidth, metadata, and deletion simulations.
- A system can be decentralized in ownership while retaining one mandatory coordinator, indexer, gateway, issuer, repair scheduler, or consensus group. Distribution must be defined per control path.
#Research lane boundaries
#Local-first state
Compare append-only encrypted events, operation logs, CRDTs, local repositories, SQLite replication, and server-assisted sync. Evaluate encrypted local indexes, migrations, compaction, device replacement, recovery bundles, duplicate delivery, and selective replication. Do not let this lane decide DHT routing, threshold cryptography, or blob durability.
#Key exchange and access control
Compare hybrid and post-quantum key exchange, group security, key transparency, capability delegation, threshold cryptography, proxy re-encryption, attribute/policy systems, and revocation. Define the key hierarchy from device root through sphere, channel, community, content, recovery, and migration. Do not let this lane decide general replication or storage repair.
#Strong distributed systems
Compare replication, causal/eventual consistency, consensus, Byzantine/threshold coordination, DHTs, peer discovery, overlays, relays, and migration between coordinators. Separate crash faults, malicious hosts, Sybil attacks, censorship, equivocation, collusion, and compromised clients. Do not let this lane choose cryptographic constructions or storage encoding.
#Distributed file storage
Compare encrypted blobs, erasure coding, repair, mutable manifests over immutable objects, deletion/tombstones, metadata visibility, small-object behavior, self-hosted nodes, provider migration, and proofs of availability/repair. Do not let this lane define application event ordering or authorization policy.
#Constraints that remain hard gates
Reject systems that require global plaintext state, public people/content search, cross-sphere identifier reuse, central permanent identity or recovery authority, online centralized coordination for ordinary private reads, public DHT enumerability, exact reader histories, popularity metrics, default decryption rights for hosts, unversioned policy endpoints, or deletion claims beyond what replicated ciphertext makes possible.
Do not conflate threshold signatures, threshold decryption, storage reconstruction, and Byzantine consensus. Do not accept “decentralized” claims that leave one mandatory gateway, indexer, coordinator, or repair authority.
#Synthesis questions
The final architecture must answer:
- What are the canonical state objects, and who may write/read each one?
- Which objects are immutable, append-only, mutable-by-manifest, CRDT-merged, or consensus-authorized?
- What happens to each object during partitions, duplicate delivery, conflicting membership changes, and provider loss?
- What is the exact key hierarchy and what is the relationship between signing, encryption, recovery, migration, and authorization keys?
- Which access decisions are local, signed-claim-based, group-key-based, threshold-controlled, or coordinator-mediated?
- What metadata is visible to each participant in each operation?
- Which adapters can be swapped without changing encrypted object semantics?
- What is the smallest multi-client, multi-node prototype that can falsify the design?
The gap audit found no blocker to proceeding. It did find enough material uncertainty that the synthesis should produce explicit gates rather than a single unconditional package stack.