12 · Open Questions & Roadmap

#Aims and reasoning

#What is settled

The stable spine — so reviewers know what is not up for casual revision:

• The diagnosis: social media's harms are structural — a publishing machine fused into influence, hierarchy, and identity machines (§02).
• The remedy axes: a small/known audience, context-fragmented identity, de-metricized feedback (§02).
• No global feed, relational discovery, no frictionless repost, author-private broadcast reactions, a finite feed (§06).
• Crawler, aggregator, and social-graph-analysis resistance is a core constraint, not an optional privacy enhancement (§01, §06).
• Two primitives — conversations and channels — not one undifferentiated stream (§04, §05).
• Contextual profiles, not one flattened "main" account; contexts, not quantified closeness (§03).
• No public popularity metrics, no votes/karma, no person-level reputation (§02, §06, §08).
• The existing Session/TACo/Signal-lineage stack remains a working assumption under explicit reconciliation, not an irreversible dependency decision. Architecture lane #1 must retain, narrow, or supersede those commitments together rather than by silent package substitution (§10).
• Community-scale work defaults to kaupapa, do-ocratic initiative, incomplete records, scoped technical custody, and lightweight shared memory rather than a mandatory governance workflow or scalar power hierarchy (§09).
• The discipline of omission — features are not added because they are possible (§02).

#Where decisions live

This is the canonical handoff for the collection. The numbered pages are the current application spec: they own user-visible behavior, social meaning, safety posture, and high-level constraints. The Research & Options hub and its available libraries, tools, and packages inventory preserve competing mechanisms, evidence, and missing-piece analysis; they are not dependency decisions. A future protocol specification must own exact wire formats, cryptographic domains and key hierarchies, migration and conformance rules, and final package or carrier choices.

The overlap is the shared invariant: when a product promise must survive across clients or carriers, this roadmap records it as protocol work without moving its social meaning out of the owning product chapter. Until a later protocol spec accepts the handoff, a named library, service, or standard remains a candidate with an explicit boundary and next gate.

#Protocol and architecture

#The smallest buildable comparison

The shared fixture contains a private conversation, consented publication, reply, shared record, checkpoint, attachment, two devices and recoverable ciphertext custody. It should be narrow enough to replace. It is not a request to build two complete products or to implement every candidate in the catalogue.

Privacy-sensitive deployment cannot inherit the direct-route prototype's defaults. Conversely, an exceptional threshold-release requirement does not justify adding that service to every feed read. The diagrams in §10 and architecture profiles keep those choices independent.

#Roadmap Buckets And Dependencies

The buckets separate work by the kind of answer that can close it.

#Roadmap buckets

These buckets assign deferred thread work to the phase that can actually close it. They are not section-local design decisions; each item names the next concrete output needed before source prose should change.

#Research and design queue

The distributed E2EE methodology work lives in the Research & Options hub. The current cross-cutting work is partitioned into thirteen GitHub decision lanes, while notification, channel, simulation and terminology work remains in the roadmap below. Research pages stay provisional until their named tests and decision gates are run.

The generated internal queue (npm run build:internal, then html/research-queue.html) carries the full packet prompts for active research, dialogue, and validation threads. The table maps those packets to their owning chapters. When a packet lands, the owning source section must mark the resulting local conclusion as a research-backed decision and cite the sources that justify it.

#Current application spec

• Channel model pass (OT-04-001, OT-04-002, OT-04-003, OT-04-004) — settle follow inheritance and override behavior, parent/sub-channel muting, ephemeral-vs-permanent scope, local tag-routing rules, and sub-channel audience inheritance together. Done when §04, §06, §07, and §10 no longer imply different channel semantics.
• Lazy attention controls (OT-06-004) — define how a person declares per-channel eagerness without upfront relationship taxonomy. Depends on the channel model and contextual-profile work.
• Sybil and invite-borne abuse fork (OT-08-009, OT-11-001) — compare phone-number, invite-scarcity, one-time payment, and tolerated-abuse models against the no-phone-number line, free-tier abuse risk, and invite accountability.
• Personal-safety parameters (OT-08-005, OT-08-006, OT-08-010) — narrow threshold, anti-brigading, restorative-prompt, escalation, and key-verification questions after the governance and verification research tasks report.

#Later protocol spec

• Hostile-fork economics and licensing (OT-02-006 narrowed) — the protocol boundary is now integrated: absence of global indexes and enumerable graph endpoints, metadata minimization, rate limits, and client-integrity limits are application/protocol commitments. Later work compares licensing, trademark, foundation governance, server-access policy, network-effect assumptions, and takeover game theory without treating them as privacy controls.
• Shared workspace objects and technical access — translate §09 into a portable object/access model without compiling kaupapa or ordinary coordination into law. Define only the technical grants, membership/key transitions, checkpoint/late-reader semantics, export/fork boundaries and sensitive custody operations that require interoperable enforcement. #2, #5, and #11 own the split.
• Access, transport, revocation, and storage contracts (OT-10-002, OT-10-003, OT-10-006, OT-11-002, OT-11-003) — reconcile the legacy Session/Lokinet/TACo assumptions with the authenticated-object profiles, compare the named carriers under explicit observer models, and choose custody/repair semantics only after the ERIS/Kapla, Tahoe/ZKAP and Rust comparison. Forward-only revocation remains an honest product limit; exact carriers, release services, quotas and redundancy constants remain gated by #1, #3, and #6–#9.

#Later go-to-market

• Launch definition (OT-12-001) — define v1, what is protocol-enforced at launch, what can begin as client policy, and which non-goals are release blockers.
• Calls and community sequencing (OT-05-006, OT-09-011) — decide whether voice/video and community-scale features are MVP, post-MVP, or explicit non-goals for first release.
• Storage purchase and sustainability (OT-11-006, OT-11-010) — make "buy more storage" ordinary-user safe, distinguish durable storage from hot hosting, hide wallet/token mechanics, and model how access control, transport, and hosting are covered without a growth engine.
• Launch gates for legal and safety work (OT-08-011, OT-11-009) — complete the illegal-content and encrypted-hosting liability workstream before any public launch plan.

#Legal launch gates

This source collection does not give legal advice. This section is the canonical launch-gate record: the product cannot publicly launch until the legal/safety workstream has counsel-reviewed answers for the whole stack.

Research-backed legal issue-spotting: Public launch is blocked until counsel has reviewed the service-role map, notice path, preservation plan, and object-level response design against the launch jurisdictions.

§08 and §11 define the incident and hosting implementation boundaries that feed this cross-cutting gate. The existing legal evidence is recorded under USC2258A, REPORTAct2024, DMCA512, CDA230, EUDigitalServicesAct, and UKOnlineSafetyGuide. These are source inputs for current jurisdiction-specific counsel review, not a claim that this editing pass revalidated every legal conclusion.

#Simulation and validation

• Stage 1 minimal ABM (OT-02B-001) — run the Stage 1 minimal agent-based model defined in §02b, testing whether attention stays distributed and homophily stays weak under TalkCo's structural rules.
• Chronological-ordering side effect (OT-02B-002, OT-06-005) — test whether the extremity-attention effect reported in prior simulations appears without a global feed, reposts, public popularity signals, or political-content emphasis.
• Signal-visibility contrast (OT-02B-005) — compare exact public counts, hidden counts with latent ranking, coarsened visible labels, author-private reactions, and no recipient-visible signal before committing to any metric surface.

#UX research and terminology

• Temporal-design scope (OT-02-001 narrowed) — the citation gaps are resolved. Decide whether ephemeral-vs-permanent behavior belongs at channel default, post-level override, or both.

#Spec sequence

The current collection is the application spec. It should keep enough architecture to make the application coherent, but avoid turning unfinished protocol or launch choices into premature product commitments.

• Now — application spec. Clarify the user-facing primitives, non-goals, safety posture, anti-virality mechanics, contextual identity, and architecture-level constraints.
• Next — protocol spec. Resolve encryption details, access-control abstractions, metadata minimization, crawler/aggregator resistance mechanics, migration/recovery, and hosting/storage contracts.
• Later — go-to-market plan. Decide adoption sequencing, channel-vs-messenger launch emphasis, compatibility bridges, public release gates, and organizational sustainability once something concrete exists to launch.
• Continuous — validation. Simulate the core ruleset where simulation can change a design decision.

#External dependencies to track

Earlier launch dates and maturity claims remain dated evidence in the research history, not current availability promises. The master research table owns candidate qualification; the linked issue lanes own decisions.

#Open Threads

Cross-cutting work is routed through the existing decision lanes and the product threads above. This reorganization closes no unexecuted protocol, legal, simulation or release gate.