This map constrains package research. TalkCo is currently a documentation-first specification, not an implemented client or service. The useful question is therefore not “which popular framework should we use?” but “which components preserve the design while reducing the hardest implementation risks?”
#What the application is
TalkCo is a decentralized, end-to-end-encrypted product combining private conversations with channel-based publishing. Its design rejects global feeds, public popularity signals, frictionless reposting, public follower graphs, and central identity recovery.
The primary workflows are:
- contextual identity and contact introduction through QR codes, invite links, exact usernames, or introductions, with local aliases and route-aware verification;
- private one-to-one and group conversations with reply-later state, deliberate acknowledgments, optional receipts, disappearing conversations, reactions as replies, and consent-based artifacts;
- text, image, video, and file publishing into nested personal or community channels with public, unlisted, or invite-only visibility;
- finite, relational feeds assembled from individually followed channels rather than a global ranked feed;
- recipient-controlled notifications with priority hints, context modes, batching, and dampening;
- silent personal blocking, local verification, layered moderation, and separate restorative and protective tracks;
- community membership, stewardship and facilitation roles, threshold custody, governance, fork, export, and exit;
- ciphertext-only storage using a friends-and-family mesh, erasure-coded redundancy, repair under churn, and reliable hot capacity.
Primary source sections: project overview, identity and contexts, messaging, feeds and discovery, architecture, and hosting and storage.
#What exists today
The repository currently contains a Markdown source collection and a static publication pipeline:
- Node.js scripts use CommonJS and built-in modules.
- npm is the package manager;
package.jsondeclares@mermaid-js/mermaid-clias the only direct development dependency. scripts/build-html.jsgenerates static HTML, JSON, CSS, and browser JavaScript from Markdown.- Forgejo Actions builds and deploys the generated
html/surface to Codeberg Pages. - The CI workflow uses Node 22; the scout observed Node 26.7.0 and npm 11.19.0 locally.
- Mermaid diagrams are checked with repository scripts.
There is not yet an application client, backend/API server, database schema, native project, cryptographic implementation, storage service, application test runner, linter, type checker, or production node topology.
The largest implementation gap is architectural commitment: target platforms, first-release scope, client language, backend language, persistence model, protocol schema, and transport/access-control adapters are all still open.
#Implementation surfaces
Research should treat these as separate seams:
| Surface | Core problem to solve | Package-selection constraint |
|---|---|---|
| Client | Local identity contexts, conversations, channels, notifications, recovery, and device pairing | Offline/local-first behavior, secure storage, background work, and mobile/desktop viability |
| Cryptographic access | Group keys, contextual identifiers, revocation, recovery, and conditional access | Swappable adapters; hostile clients remain in the threat model; no UI-only privacy claims |
| Transport | Store-and-forward control traffic and richer encrypted traffic | Preserve metadata minimization and avoid coupling the product to an unstable protocol revision |
| Application protocol | Versioned encrypted objects, membership grants, edits, deletion requests, receipts, and forks | Explicit schemas, migrations, capability negotiation, and interoperability tests |
| Storage | Ciphertext blobs, manifests, erasure coding, repair, hot caching, and host controls | Hosts must not gain decryption rights; churn and partial availability are normal |
| Community/governance | Signed manifests, role grants, threshold operations, consent, export, and exit | Auditable state transitions and key rotation rather than generic social features |
| Validation | Protocol behavior, privacy leakage, recovery, churn, and anti-virality properties | Property-based, fuzz, simulation, interoperability, and metadata-leakage testing |
| Documentation/tooling | Durable Markdown, diagrams, research queues, and generated review surfaces | Preserve Markdown as the source of truth and keep generated output disposable |
#Constraints that disqualify attractive packages
The following are architectural constraints, not optional product preferences:
- no global content index, people search, public graph endpoint, crawler-oriented surface, or popularity ranking;
- no phone-number identity or central password-reset identity;
- separate protocol-visible identifiers, keys, namespaces, endpoints, storage records, and recovery records for contextual profile spheres unless explicitly linked;
- encryption before shared infrastructure, with metadata treated as a separate privacy surface;
- forward-looking revocation, with no claim that already-decrypted plaintext can be erased;
- truthful conversation settings that express preferences and requests rather than remote device control;
- storage hosts holding ciphertext without automatic decryption rights;
- two-of-three technical-steward defaults for community root operations;
- legal and liability review before personal hosting or public launch.
The project also names Session lineage, TACo, Signal-lineage cryptographic concepts, symmetric/group keys, and a friends-and-family encrypted storage mesh as working technology directions. Their APIs, maturity, licensing, and migration risks remain research questions. TACo, Session Protocol V2, and Lokinet mobile support are explicitly transition-sensitive.
#Research boundary for downstream lanes
The stack lane should compare client runtimes, protocol/backend languages, schema and migration tooling, and integration seams for cryptography and transport. The domain lane should focus on E2EE groups, contextual identity, recovery, threshold access, signed community state, and key rotation. The data/integrations lane should compare local encrypted indexing, ciphertext storage, erasure coding, repair, notifications, and privacy-bounded automation; global search and engagement AI are out of scope. The quality/operations lane should cover cryptographic and protocol testing, privacy leakage, dependency and license review, reproducible builds, observability without plaintext or relationship graphs, and self-hosted-node delivery.
#Evidence and uncertainty
Observed facts come from the repository files listed above and the package/CI inspection recorded by the application scout. The conclusion that a local-first client is likely important is an inference from offline recipients, intermittent storage hosts, and device-held recovery; it is not yet a settled platform decision.
Open decisions that could change the shortlist include target platforms, v1 scope, whether to reuse or fork Signal-lineage code, exact Session/Lokinet/TACo integration APIs, storage and metadata models, launch jurisdictions, threat-model boundaries, package-license policy, and acceptable native dependencies.