#Why the boundary matters
TalkCo already says what the boundary should be. The table of contents calls the numbered collection an application spec and sends deeper protocol work later (00-table-of-contents.md#what-this-document-is). The roadmap repeats the sequence: clarify product behavior now, resolve wire-level and cryptographic choices in a later protocol spec (12-open-questions-and-roadmap.md#spec-sequence). The problem is not an absent decision. It is that several chapters answer what should people experience?, what must implementations enforce?, and which mechanism might we use? in the same visual and rhetorical register.
That mixing creates two opposite reading failures:
- A newcomer can mistake a candidate library, threshold setting, or transport for a product promise.
- A protocol reviewer can miss a social or client-side promise because it is presented as if access control alone could enforce it.
The proposal is therefore a disclosure and ownership change, not a new architecture decision. Keep product meaning visible, state the cross-layer invariant beside it, and move exact protocol mechanics behind a named protocol boundary. Preserve nuance by making the destination and enforcement limit explicit rather than by repeating the same explanation in every chapter.
#The four-layer contract
Use one recurring model everywhere a product decision meets implementation detail. The second layer is a seam and a test obligation, not another competing specification.
| Layer | First reader question | Owns | Does not own |
|---|---|---|---|
| 1. Product/application design | What should people experience, and what does the behavior mean socially? | User-visible concepts, audience semantics, affordances, defaults, non-goals, social and governance meaning, and the reasons for the design. | Exact wire formats, cryptographic parameters, carrier selection, or guarantees against a modified client. |
| 2. Shared invariants | Which product promises must remain true across the UX and every conforming implementation? | The small set of cross-layer rules that need both product tests and protocol tests: audience ceilings, meaningful consent, context-scoped artifacts, no first-class global index, forward-only revocation, and ciphertext custody without read authority. | A complete UI specification or a choice between candidate libraries. |
| 3. Application protocol | Which objects, authorities, and state transitions are versioned and enforceable? | Versioned objects, signatures, grants and revocation, encryption/key domains, metadata limits, authority rules, replay/conflict handling, migration, and the evidence needed to validate them. | Human-facing copy, social legitimacy, notification tone, or the operating system's notification policy. |
| 4. Transport contract and carriers/adapters | How are protocol objects and requests moved, and can the carrier be replaced? | Traffic classes, context-scoped addressing, expiry, delivery and storage-fetch semantics, carrier conformance, and adapter boundaries. | Audience meaning, who is authorized, or whether a community decision is legitimate. |
The application protocol is not the application spec. The current numbered collection is the application spec; a future protocol spec can define the exact records and conformance tests without replacing the product rationale. A transport carrier is a mechanism such as Session, Lokinet, iroh, or libp2p. The TalkCo transport contract sits above those carriers and states what delivery must mean. Calling all three “the protocol” hides the seam the reader needs.
#A quick ownership test
For a sentence or decision, ask these questions in order:
- Would a person see, choose, or experience this? It belongs in product/application design.
- Must every conforming implementation preserve it for the product claim to remain true? Record it as a shared invariant and a protocol test.
- Is it a signed object, authority, key domain, metadata rule, state transition, or migration rule? It belongs in the application protocol.
- Could the carrier change without changing the object's meaning or authority? Put it behind the transport contract and adapter seam.
This test also names the limit. A default client can make a notification mode, local alias, feed ordering, or profile reveal feel ordinary, but a hostile or modified client can ignore that policy after it has decrypted data. The protocol can constrain what is authorized, represented, or exposed; it cannot force a device to forget plaintext or preserve an interface. Product defaults, protocol checks, carrier limits, governance, and legal controls are defense in depth, not interchangeable enforcement.
#The shared seam should borrow the product's object vocabulary
The seam should use nouns readers already understand, then add the protocol obligation without pretending the nouns themselves solve it. This is the bridge between a product contributor and a protocol contributor.
| Shared object vocabulary | Product meaning | Protocol question at the seam |
|---|---|---|
| Profile sphere | A contextual face with its own visible profile material and channel defaults. | Which identifiers, keys, endpoints, grants, storage records, and recovery references remain sphere-scoped, and how is an intentional recipient-scoped link represented? |
| Channel | A place to publish, with an audience, register, and follow/mute behavior. | Which manifest, audience grant, policy epoch, key domain, and update/revocation events define the channel without creating a global index? |
| Conversation | A bounded exchange in which receipts, reactions, presence, and retention have different social meaning from a broadcast. | Which ratcheted events, participant state, preference messages, and retention notices are authenticated, replay-safe, and honest about their limits? |
| Post or conversation artifact | An intentional object that may remain private, be shared with a bounded audience, or become a channel post. | What new object, consent evidence, audience ceiling, recipient envelope, and provenance relation are created at promotion? |
| Grant | A visible reveal, membership, permission, or access decision. | Who signed the scoped grant, what object and audience does it cover, when does it expire or revoke, and can it widen an existing ceiling? |
| Membership or role | A person's standing in a community and the social meaning of stewardship or facilitation. | Which signed membership/role grant authorizes an operation, and which threshold is technical custody rather than a claim of social legitimacy? |
| Moderation overlay | A local block, contextual label, restorative route, or protective action. | What evidence and authority can be signed and shared, what remains local, and which consequence is selected by each subscriber rather than by a global score? |
| Storage object | An item that is available, backed up, or kept hot without making hosting a social rank. | Which ciphertext manifest, shard, policy epoch, repair state, and legal-control pointer can be observed by a host without granting read authority or exposing a social graph? |
The object vocabulary is shared; the claims are not. A grant is not automatically a social consent decision, and a threshold signature is not automatically governance. Product prose should say what a person can expect. Protocol prose should say what is authenticated and enforced. Adapter prose should say which candidate can perform the job and what remains to be tested.
#Reader-question map
The collection has five useful reading paths. They should converge on the same boundary vocabulary without forcing every reader through the same technical detail.
| Reader path | Primary question | First destination | Secondary detail or handoff |
|---|---|---|---|
| Newcomer | What is TalkCo, why does it refuse common social-media mechanics, and where do I start? | 01 → 02 → 02b from 00-table-of-contents.md#how-to-read-it | A short boundary legend in 00; skip protocol candidates on the first pass. |
| Product contributor | What should a person be able to do, what should it mean, and which promises are social rather than cryptographic? | 03–09 product mechanics, with paired Product promise / Shared invariant labels | §10 boundary section; client-policy examples in §05 and §07; no wire-format work required. |
| Protocol expert | Which objects, authorities, metadata, and state transitions must be specified and tested? | Proposed §10 four-layer contract and shared-seam sections | Future protocol spec; existing non-canonical research pages for cryptography, access control, discovery, storage, and architecture profiles. |
| Safety, governance, or legal reviewer | Which actions are unilateral and private, which are consequential and accountable, and what can the system know or do? | §08, §09, and §11 local boundaries | Shared invariant table, legal launch gates in §12#legal-launch-gates, and the storage/legal-control split. |
| Maintainer or implementation agent | Where is the canonical source, what is provisional, and what build/navigation work is safe to change? | 00, 10, 12, glossary.md, and scripts/build-html.js | This audit and the round-6 research-surface plan are proposals; the generated HTML remains a review surface. |
#What the source already supports
The boundary recommendation is grounded in the current repository, not inferred from terminology alone.
| Source inspected | Verified observation | Disclosure implication |
|---|---|---|
00-table-of-contents.md#what-this-document-is, #how-to-read-it, and the file manifest | The collection calls itself an application spec, sends deeper protocol work later, and gives newcomers a product-first reading order. | Make that promise visible before any stack diagram; add reader routes rather than changing the collection's scope. |
12-open-questions-and-roadmap.md#current-application-spec, #later-protocol-spec, and #spec-sequence | The roadmap already separates application behavior from later encryption, access-control, metadata, migration, and hosting contracts. | Promote this from a roadmap note to the canonical boundary and link each mixed chapter back to it. |
WRITING_STYLE_AND_TONE.md#the-current-document-structure, #the-spine-controls-local-edits, and #markdown-conventions | Markdown is canonical, the spine controls local edits, and disclosures are available for supporting detail. | Keep required decisions visible, move candidates and caveats into labeled details, and do not patch generated HTML. |
§07#priority-is-a-senders-hint-the-recipient-always-wins and §05#conversation-settings-are-negotiated-not-imposed | These sections already distinguish sender hints, recipient-dominant client policy, preferences, proposals, notices, and the limits of remote enforcement. | Reuse this client-policy language as a precedent instead of inventing a new enforcement vocabulary. |
§09#a-community-is-a-shared-space-not-a-bigger-group-chat | The chapter already separates protocol object, product surface, and governance template. | Reuse this three-part pattern at the wider app/protocol boundary, while adding transport and client-policy distinctions. |
§03#the-boundary-that-actually-separates-spheres and §10#transport-is-a-carrier-not-the-product-protocol | The collection already warns that device-local roots, protocol-visible sphere artifacts, transport identifiers, and product promises are not the same thing. | Turn the warnings into a recurring paired statement and a shared seam table. |
§10#how-access-control-enforces-the-product, §06#the-hostile-fork-guard, and §11#ciphertext-hosting-still-needs-legal-design | Access control, anti-enumeration, client integrity, carrier behavior, storage, and legal routing are all present, but the prose can read as if one access-control layer explains them all. | Correct the over-broad equivalence: some promises are access facts, some are protocol shape, some are client policy, and some are governance or legal controls. |
scripts/build-html.js (coreSourceFiles, globalNav, and indexGroups) | The public build has a flat core navigation and one “Infrastructure and Roadmap” index group; research is separated, but application/protocol routes are not. | Plan a navigation grouping change in the build layer; do not add this proposal to the canonical public source list before it is accepted. |
#Hierarchy and confusion audit
The highest-value edit is a small boundary legend in §10, then lightweight paired labels in mixed chapters. The table below names the local answer that should remain first and the detail that should move behind a clear handoff.
| Area | Current reader stumble | Primary content to keep visible | Secondary/reference treatment | Priority |
|---|---|---|---|---|
| §03 identity, profiles, and contexts | “One cryptographic identity” and “each sphere has its own identifiers and keys” can sound contradictory; the product view, anti-correlation claim, recovery bundle, and namespace checklist share one lane. | Contextual profiles, cold-contact minimal disclosure, intentional reveal/link semantics, and the honest bounded anti-correlation promise. | Pair with a protocol obligation for sphere-scoped artifacts; move key hierarchy, endpoint herd privacy, timing, recovery-record, and migration detail to the future protocol spec/research surface. State that a private device root may join spheres locally but is not a protocol-visible global account root. | High |
| §04 channels and content | Channel visibility, retention, tags, cross-posting, erasure coding, and storage constraints can read as one “channel protocol.” | Channel as publishing primitive; audience, register, follow/mute, local routing, and “cross-posting is filing, not amplification.” | Point visibility to the access obligation; point durability and shard behavior to §11/protocol research. Keep the user-facing health states, not Reed–Solomon constants. | High |
| §05 messaging and conversations | Social semantics of receipts, preferences, deletion, and consentful artifacts sit beside message types and new grants. | Conversation-versus-channel meaning; negotiated settings; explicit consent before a conversation-born artifact; honest forward-only deletion language. | Add a shared invariant for explicit consent and audience ceilings; move event schemas, envelope binding, ratchet/key choices, and promotion state transitions to the protocol spec. | High |
| §06 feeds, discovery, and anti-virality | No global feed, no global index, rate limits, client integrity, robots/terms, and hostile forks can appear to be one privacy guarantee. | No global feed, relational discovery, no boost, author-private broadcast reactions, finite feed, and declared ordering. | State “no first-class global index” as the protocol obligation; put rate limits, metadata, attestation, and external aggregators under defense in depth. Make clear that an authorized or modified client can copy visible plaintext. | High |
| §07 notifications and attention | The chapter is mostly clear, but context defaults can be confused with access or availability authority. | Recipient-dominant interruption policy, low-by-default pull behavior, visible priority hints, and local modes. | Reuse the existing local/preference/proposal/notice distinction; protocol detail is limited to truthful event types or optional encrypted sync, never remote availability control. This is a precedent, not a major restructure. | Medium |
| §08 safety and moderation | Silent blocking, forward-only revocation, threshold corroboration, and threshold cryptography use similar words while describing different jobs. | Personal block/mute, restorative/protective tracks, contextual labels, reporter protection, and the legal launch boundary. | Label threshold-before-consequence as social evidence/governance; label threshold authority as cryptographic operation control; keep the two explicit. Put signed overlays, evidence fields, and key rotation in protocol detail. | High |
| §09 community and governance | Governance meaning, technical stewardship, signed role grants, consent, and two-of-three custody are adjacent enough to imply that quorum proves legitimacy. | Community account as a shared space; separate stewardship/facilitation; consent, role scope, review dates, exit, and fork meaning. | Reuse the existing protocol-object/product-surface/governance-template pattern. Protocol defines scoped authority and signed records; governance decides whether a role or rule is legitimate; threshold custody only executes a permitted operation. | High |
| §10 architecture and protocol | The chapter is simultaneously a product stack, transport explainer, dependency strategy, encryption direction, access-control mapping, and protocol refusal list. | A short statement of what TalkCo invents, why the layers exist, the B→A strategy, and the product-to-protocol boundary. | Add the four-layer legend, shared-seam table, client-policy limits, and a separate mechanism/adapters handoff. Keep exact candidates and wire-format work in research/future protocol pages. | Highest |
| §11 hosting, storage, and funding | User-facing storage gifting, erasure-coded durability, hot availability, metadata, legal controls, and token abstraction compete for the same explanation. | Hosting is a user-facing capacity gift/purchase; hosts store ciphertext and do not automatically read; cold durability, hot availability, and legal routing are different jobs. | Move shard families, repair bands, placement correlation, billing metadata, and carrier/storage contracts to protocol research. Keep legal warnings and launch gates visible; “ciphertext-only” is not a liability conclusion. | High |
#Primary, secondary, and reference content
Use priority as a disclosure decision, not as a value judgment about technical detail.
| Priority | Reader sees first | Examples in TalkCo | Destination rule |
|---|---|---|---|
| Primary | The product promise, its rationale, and any warning or non-negotiable boundary needed to interpret it. | Contextual profiles; no global feed; consentful artifacts; silent forward-only blocking; recipient-dominant notifications; community exit; hosting is not reading. | Keep in the owning numbered chapter and give it a stable anchor. |
| Secondary | The shared invariant and a concise explanation of what a conforming implementation must preserve. | Audience ceiling; context-scoped identifiers; no first-class global index; explicit consent event; signed role grant; ciphertext without read authority. | Put immediately beside the primary claim or in the proposed §10 boundary section; do not make readers infer it from a library choice. |
| Reference | Exact mechanisms, options, derivations, examples, evidence, and implementation gates. | TACo/PRE, MLS, ratchets, endpoint herd privacy, K-of-N candidates, carrier maturity, legal source notes, and falsification tests. | Use ::: details with a predictive label or link to the non-canonical research surface/future protocol spec. Never hide a prerequisite, warning, decision, or required action. |
The current research surface is a good reference precedent: it keeps candidate methodologies and falsification tests separate from product behavior (distributed-e2ee-research-surface-plan.md). The same progressive disclosure should now apply inside the numbered chapters where a product sentence needs a protocol handoff.
#Recurring classification lens
For each cross-layer decision, use this table rather than repeating an undifferentiated paragraph. The Client policy column must state what a modified or offline client can bypass. The Validation column names the test that would change confidence.
Maintainer and protocol-reviewer classification table
| Decision | Product promise | Protocol obligation | Client policy | Adapter/dependency | Validation |
|---|---|---|---|---|---|
| Profile sphere and reveal | A person can show different contextual faces; cold contacts see little; an intentional link can merge two revealed spheres for one recipient. | Scope identifiers, keys, endpoints, artifacts, storage records, and recovery references per sphere; represent recipient-scoped link/reveal grants; do not publish a shared root. | Present one ordinary contact card; do not announce a second reveal; local aliases and trust labels stay local. | Key store, recovery bundle, discovery/routing adapter, and any future sphere-key hierarchy. | UX reveal/link tests; protocol correlation/timing review; hostile-client metadata audit; migration/recovery tests. |
| Channel visibility and retention | Public, unlisted, and invite-only channels have understandable audiences; ephemeral and permanent registers feel different without claiming capture prevention. | Bind channel manifests, audience grants, policy epochs, encryption domains, revocation, and retention notices; preserve scope ceilings. | Show plain visibility/retention labels; allow follow/mute and local filters; show availability as health, not cryptographic detail. | Symmetric/group-key path, TACo for conditional access, possible MLS sphere adapter, storage mesh and hot tier. | Audience/access matrix; membership-change and revocation tests; retention honesty tests; outage/repair tests. |
| Conversation-born artifact | Nothing becomes a shared artifact or channel post without meaningful participant consent and a bounded audience choice. | Create a new signed object with consent evidence, provenance, recipient envelopes, and an audience ceiling no wider than permitted; do not auto-promote plaintext. | Guide selection and consent copy; show who agreed and what audience was chosen; explain that decrypted copies cannot be recalled. | Ratchet/group messaging, object AEAD/HPKE or another envelope adapter, local artifact store. | Multi-party consent UX; state-machine tests; reply/promotion scope-ceiling tests; replay and rollback tests. |
| Blocking and revocation | A personal block is silent, immediate, reversible locally, and stops future access without pretending to erase prior plaintext. | Revoke or rotate future decryption authority; bind policy epochs and notices; never claim to un-retrieve old plaintext. | Hide locally, suppress notifications, and avoid a “you were blocked” signal; modified clients can retain prior plaintext. | Access-control interface, group-key rotation, TACo/PRE where justified, local keyring. | Forward-revocation tests; old-device/offline-client tests; copy/screenshot expectation review. |
| No global feed / anti-enumeration | Discovery is relational; no global feed, popularity scoreboard, frictionless boost, or infinite feed. | No first-class global index or enumerable graph endpoints; use scoped addressing, bounded cursors/page sizes, metadata minimization, and endpoint-local budgets. | Default client omits ranking, counts, and re-engagement nudges; an authorized or modified client may copy visible material. | Session-style carrier, Lokinet/SNApps candidate, direct fetch adapter, optional abuse/friction signals. | Crawl and graph-walk simulations; endpoint/metadata review; hostile-client and external-aggregator threat tests; ABM for attention effects. |
| Notification and presence modes | Broadcast is pull-only by default; the recipient controls interruption; priority is a visible sender hint, not a command. | Use explicit preference, notice, request, and acknowledgment objects where synchronization is needed; do not encode remote availability authority. | Local mode, OS controls, batching, reply-later flags, and feed ordering decide interruption; a client can ignore the default UI. | OS push, encrypted state sync, conversation transport, and local notification store. | Leakage and missed-obligation UX tests; delivery-without-notification tests; mode/override state tests. |
| Community custody and governance | Stewardship, facilitation, consent, role scope, review, fork, and exit are social arrangements without public rank. | Sign scoped membership/role grants and decision records; require configured threshold authority for root operations; preserve fork/export boundaries. | Show authority by domain and expiry; show local audit; do not rank people or imply quorum proves legitimacy. | TACo/threshold capability adapter, community key manager, signed manifest/export tooling. | Capture and absent-steward scenarios; consent/objection tests; fork membership/key isolation; role-expiry tests. |
| Ciphertext hosting | People can offer or buy capacity; a host stores ciphertext without automatically becoming a reader; hosting is not risk-free legal immunity. | Encrypt before placement; bind object/shard manifests, policy epoch, minimal metadata, repair state, and legal-control pointers without granting decryption. | Turnkey host setup/stop/drain controls; show “well backed up” or “hot hosting,” not shard constants or token plumbing. | Erasure coding, storage coordinator, seed/cache hosts, paid-storage broker, transport fetch adapter. | Churn/repair/retrieval tests; metadata minimization; host stop/drain; object-level legal-response feasibility. |
| Transport selection | The app remains usable when a carrier changes; users need not understand the network substrate. | Define object addressing, traffic classes, expiry, batching, metadata, and storage boundaries above any carrier. | Select or fall back to carriers transparently; expose only useful availability and error states. | Session-lineage, Lokinet, iroh, libp2p, direct host fetch, and future adapters. | Conformance suite across carriers; delivery/expiry tests; correlation and outage measurements; migration compatibility. |
#Terminology guardrails
The following terms should be added to the glossary or linked from the boundary legend. Existing glossary terms such as profile sphere, link grant, bounded anti-correlation, transport contract, and policy epoch should be retained and sharpened rather than redefined in multiple chapters (glossary.md).
| Term | Use it for | Do not use it as a substitute for |
|---|---|---|
| Application design | User-visible behavior, social meaning, defaults, non-goals, and UX decisions. | A wire-format or library plan. |
| Application spec | The current numbered collection that explains product behavior and high-level architecture. | The future application protocol specification. |
| Application protocol | Versioned objects, signatures, authority, grants, encryption, metadata, revocation, migration, and conformance rules. | The entire product or every client behavior. |
| Shared invariant | A promise that must be expressed in product terms and tested in protocol terms. | A vague value statement or a complete implementation design. |
| Transport contract | TalkCo's carrier-independent requirements for moving objects and requests. | Session, Lokinet, or any one network. |
| Carrier | A replaceable network or storage transport that carries protocol traffic. | The application protocol or access-control authority. |
| Client implementation | Code, runtime, persistence, UI, and integration architecture. | A user-facing policy or a protocol guarantee. |
| Client policy | A local/default rule for presentation, interruption, ordering, filtering, or disclosure. | Access authorization or remote-device control. |
| Access control | Who may decrypt or perform a specifically authorized operation. | Product promises such as consent, non-ranking, notification feel, social legitimacy, or legal role classification. |
| Governance meaning | Who should decide, what a role means socially, and how consent, repair, and exit work. | Cryptographic threshold authority. |
| Threshold authority | The technical quorum or condition required to execute a protected operation. | Threshold-before-consequence corroboration or community legitimacy. |
| No global feed | A product refusal of global ranked attention and infinite discovery. | A claim that no client can copy visible data. |
| No first-class global index | A protocol shape that does not expose a convenient enumerable graph/content index. | A promise that external aggregation or authorized crawling is impossible. |
#Diagram and disclosure register
No new diagrams are rendered by this proposal. The register names the job each existing or proposed visual must perform and gives a non-visual equivalent so that meaning survives a failed renderer, narrow viewport, dark theme, or assistive technology.
| ID / proposed destination | Visual job | Exact reader question | Accessible alternative | Proposed treatment |
|---|---|---|---|---|
D1 — §10#the-four-layer-contract (proposed; relates to §10#the-layered-stack) | Layered relationship and ownership | Which layer owns this decision, and where must the product and protocol agree? | The four-layer table plus the four-question ownership test in this audit, repeated in concise form in §10. | Add the ownership visual before the current dependency-shaped stack, and retain that stack as a separate implementation/dependency view with a clarifying caption; do not imply that arrows alone enforce semantics. |
D2 — §03#the-boundary-that-actually-separates-spheres | Relationship and privacy boundary | What does the private device root know, and what may the protocol-visible world learn about two spheres? | A sentence-by-sentence statement: device-local root may join spheres; sphere IDs/keys/endpoints/artifacts/storage stay scoped; a recipient-scoped link grant is the deliberate exception. | Retain the visual and its caption; add the product promise/protocol obligation pair and keep the correlation caveats in a labeled disclosure. |
D3 — §05#conversation-artifacts-need-consent | Sequence and state transition | What must happen before conversation material can become a shared artifact or channel post? | Numbered sequence: select material → meaningful participants consent → choose bounded artifact audience → create a new object/grant; otherwise it stays in the conversation. | Retain; add the audience ceiling and new-object obligation without putting envelope mechanics in the main flow. |
D4 — §06#the-hostile-fork-guard and proposed §10#defense-in-depth | Comparison of defense layers | What does the protocol refuse, what does the default client discourage, and what remains possible to a hostile client? | A three-column matrix: protocol shape (no global index), client policy (no ranking/counts), residual limits (copying, graph walking, external indexes). | Split the current anti-enumeration caveat into product refusal, shared invariant, protocol obligation, and client/organizational defense. |
D5 — §09#governance-surface-map and proposed §09#governance-and-technical-authority | Relationship and comparison | What does a community decide socially, and what can a steward quorum execute technically? | Paired table: governance meaning / signed record / threshold operation / client presentation. | Retain the governance map; add a visual or table that prevents quorum authority from reading as legitimacy or rank. |
D6 — §11#ciphertext-hosting-still-needs-legal-design | Separation of planes | Who stores ciphertext, who can read it, and who can route or act on a legal notice? | Two-plane prose/table: storage plane (ciphertext, stop/drain) and legal-control plane (minimal object metadata, route, counsel-reviewed response). | Retain; keep “ciphertext-only is not a liability conclusion” visible and put source-specific legal detail in the existing disclosure. |
D7 — proposed §10#shared-object-seam | Sequence/relationship from product object to protocol object to carrier | How does a user-visible channel, grant, or artifact become a versioned protocol object and then move over a replaceable carrier? | The shared object-vocabulary table in this audit, with one worked example for a conversation-born artifact. | Add only if the table is not enough; prefer the table when it is clearer than a diagram. |
#Disclosure labels
Labels must tell readers what is hidden before they open a details block. Required decisions, warnings, and prerequisites stay in the visible paragraph.
| Label | Visible statement | Supporting content allowed inside |
|---|---|---|
| Protocol obligation | One sentence stating the invariant or enforceable fact. | Object fields, signatures, epochs, key hierarchy, replay handling, migration, and conformance detail. |
| Client policy and enforcement limit | One sentence stating the default behavior and what it cannot force on another device. | OS notification behavior, local state, modified-client behavior, copy/screenshot limits, and UX variants. |
| Mechanism candidates and tests | One sentence naming the product job and the fact that the mechanism is provisional. | TACo/PRE, MLS, ratchets, HPKE, carriers, storage families, package maturity, benchmarks, and falsifiers. |
| Operational and legal boundary | One sentence naming who can act and the launch gate. | Host controls, metadata needed for routing, jurisdiction-specific evidence, counsel questions, and fallback hosting. |
| Open choice | The unresolved fork, its impact, and the owner or next check. | Competing options, rejected alternatives, evidence gaps, and roadmap dependencies. |
#Preserved meaning and removed duplication
The goal is to remove repeated explanations, not to remove nuance. Apply this plan only after the boundary vocabulary is accepted.
| Preserve in the owning chapter | Pair or point to | Collapse or remove | Why |
|---|---|---|---|
Contextual identity, reveal/link meaning, cold-contact behavior, and bounded anti-correlation in §03. | One concise sphere-scoping obligation in §10; exact namespace/key/recovery mechanics in the future protocol spec. | Repeated full lists of IDs, endpoints, profile artifacts, storage records, and recovery caveats in several chapters. | Keeps the human promise local while making the technical boundary findable once. |
Channel audience, register, local tags, and filing-not-amplification in §04; anti-virality meaning in §06. | Access/grant mapping in §10; storage durability in §11 and the storage research page. | Repeated visibility/retention explanations and protocol storage constants in product chapters. | A reader can distinguish “who should see it” from “how it is kept available.” |
Consentful promotion, negotiated settings, and honest edit/delete semantics in §05. | Consent/audience-ceiling invariant and object transition in §10/future protocol spec. | Generic claims that a “new grant” alone makes promotion consensual. | Product consent is a social condition; a grant is its technical representation, not its replacement. |
No global feed, relational discovery, finite feed, and no boost in §06. | No first-class global index and scoped addressing in §10; client-integrity/rate-limit caveats in one defense-in-depth disclosure. | Multiple full lists of forbidden global endpoints and repeated “not impossible” caveats. | Separates product refusal, protocol shape, and residual hostile-client risk. |
Silent personal blocking and the restorative/protective split in §08; role and consent meaning in §09. | Forward-revocation and signed overlay obligations in the future protocol spec. | Any phrasing that treats threshold corroboration and threshold cryptography as the same mechanism. | Similar words must not erase the different authority and harm models. |
§07 recipient-dominant modes and §09 protocol object/product surface/governance template. | Use both as local precedents for the new legend. | New parallel terminology for preference, proposal, notice, role grant, or authority. | Existing patterns are clearer and reduce vocabulary drift. |
Hosting gift/purchase, host stop controls, “hosting is not reading,” and legal launch gate in §11. | Storage object/repair metadata in the protocol research surface; legal-control plane in §11/§12. | Shard constants, repair bands, payment substrate, and legal source exposition in the main user-facing flow. | Keeps product and legal warnings visible while making operational detail retrievable. |
§12 current/next/later sequencing and external dependencies. | New canonical boundary subsection linked from 00, §10, and mixed chapters. | Cross-file claims that silently redefine whether a decision is application or protocol work. | One roadmap owner prevents local chapters from settling future wire decisions by implication. |
#Proposed destinations and edit candidates
This is a destination map, not authorization to edit the numbered source pages.
| Destination | Proposed change | Scope guard |
|---|---|---|
00-table-of-contents.md | Add a short Reader routes block and a visible application-spec / protocol-spec / research distinction near “How to read it.” Consider grouping the manifest by spine, product mechanics, architecture boundary, research/options, and reference. | Do not put protocol candidates into the newcomer path. Refresh the generated section map only through the build script. |
10-architecture-and-protocol.md | Add an explicit legend and subsections for the four-layer contract, the shared object seam, client policy/enforcement limits, and the adapter handoff. Keep existing anchors where possible. | Do not choose exact wire formats, key hierarchies, TACo/MLS split, or carrier versions in this edit. |
03–09 and 11-hosting-storage-and-funding.md | Add small recurring labels or paired statements: Product promise, Shared invariant, Protocol obligation, Client policy, and Mechanism candidate. Keep local meaning first. | Do not add a full protocol chapter to every product page or duplicate the classification table. |
12-open-questions-and-roadmap.md | Add a canonical boundary subsection before or alongside Spec sequence, naming what belongs now, next, later, and continuously validated. Link all boundary decisions here. | Preserve the existing roadmap buckets; narrow open questions rather than closing them by prose. |
glossary.md | Add or sharpen application design/spec, application protocol, shared invariant, carrier, client policy, and threshold-authority terms; link the on-ramp from 00 and §10. | Reuse existing definitions for profile sphere, link grant, bounded anti-correlation, transport contract, and policy epoch. |
scripts/build-html.js | Rework indexGroups so product mechanics, architecture/protocol, research/options, and reference have distinct labels; consider grouped internal navigation for audit/workbench pages. | Keep proposal artifacts out of coreSourceFiles and public HTML until accepted. Preserve the separate research group. |
html/ generated surface | Rebuild only after source edits; inspect new grouping and disclosure behavior in light/dark and narrow layouts. | No direct HTML edits; this audit performed no render or accessibility check. |
#Unresolved factual and design choices
These are the choices the boundary makes visible; the audit does not settle them.
| ID | Question | Impact | Suggested owner and next check |
|---|---|---|---|
| U1 | Is “shared invariants” a durable named layer in the future protocol spec, a test register shared by product and protocol documents, or only a recurring label? | Material: the wrong choice either duplicates prose or hides cross-layer obligations. | Maintainers and protocol/product leads; decide after reviewing the proposed §10 legend and one mixed-chapter example. |
| U2 | Where should the future protocol spec live, and which document owns versioning, status, and migration from the research surface? | Material: destination affects links, generated navigation, and authority over wire decisions. | Maintainers; choose a canonical location before adding protocol anchors to 00 or 12. |
| U3 | What exact sphere-scoping model supports contextual identity without exposing a device-local global root through endpoints, timing, storage, recovery, or migration? | Material privacy and interoperability risk. | Protocol/identity agent; write a candidate namespace/key matrix and run correlation and recovery tests. |
| U4 | What consent receipt and audience-ceiling record is required when conversation material becomes a private artifact, bounded share, or channel post? | Material safety and trust risk. | Product/protocol pair; prototype the multi-party state machine and test replay, refusal, and audience narrowing. |
| U5 | Which access mechanism belongs behind each object path: ratchet, symmetric/group key, MLS sphere, TACo/PRE, or a later conditional adapter? | Material performance, revocation, and dependency risk. | Protocol agent; benchmark fanout/churn and write explicit admission tests before selecting a library. |
| U6 | Which transport contract is stable across Session-style small traffic, richer IP-style traffic, direct storage fetches, and future carriers? | Material metadata, reliability, and migration risk. | Transport agent; define traffic classes, addressing, expiry, metadata, and carrier conformance tests. |
| U7 | Which anti-enumeration claims are protocol obligations, and which are client, governance, legal, or operational defenses against authorized crawling and hostile forks? | Material privacy and product-honesty risk. | Safety/protocol maintainers; threat-model a conforming hostile client, an authorized crawler, and an external aggregator separately. |
| U8 | Which notification, local alias, feed-order, and reveal decisions may be encrypted state synchronization, and which must remain purely local client policy? | Material UX and expectation risk, but not a reason to grant remote control. | Product/client agent; map each state to device-only, user-synced, or protocol-visible data and test OS-level behavior. |
| U9 | How should signed role grants and threshold root operations express technical authority without implying governance legitimacy or public rank? | Material capture, accountability, and social meaning risk. | Governance/protocol pair; test absent-steward, emergency, consent objection, fork, and export scenarios. |
| U10 | Can friends-and-family ciphertext hosting ship with an object-level legal-control plane, or must launch use foundation-run/contracted hosting? | Launch-blocking legal and operational risk. | Legal/safety owner; obtain counsel-reviewed role classification, report routing, preservation, response, and jurisdiction gates. |
#Phased next action
The smallest complete sequence keeps the current application spec readable while creating a clean upgrade seam.
| Phase | Work | Done when |
|---|---|---|
| 0 — Boundary approval | Confirm the four layer names, the “application spec ≠ application protocol” sentence, object vocabulary, and terminology guardrails. | Product, protocol, safety/governance, and maintainer reviewers agree on the labels or record a narrower alternative. |
| 1 — Reader orientation | Add 00 reader routes, the boundary on-ramp, and glossary terms. Split the generated index grouping in scripts/build-html.js; keep this audit non-canonical. | A newcomer can choose a product path, and a protocol reviewer can find the future-protocol handoff without reading §10 first. |
| 2 — Canonical boundary | Add the four-layer legend, shared seam, and client-policy limits to §10; add the single canonical boundary and sequence to §12. | A reader can classify an example without consulting a scout note or inferring ownership from a dependency name. |
| 3 — Local pairings and deduplication | Add concise paired statements in the highest-mixing chapters, starting with §03, §05, §06, §08, §09, and §11; point repeated mechanism detail to one destination. | Each mixed topic has one primary promise, one shared invariant/protocol handoff, and one reference destination; anchors and meaning are preserved. |
| 4 — Protocol and research handoff | Turn the shared invariant rows into protocol-spec work units and conformance tests; keep candidate mechanisms in the research/options surface until evidence changes a decision. | Exact object schemas, authority rules, metadata boundaries, migration, and carrier adapters have named owners and tests. |
| 5 — Render and accessibility QA | Rebuild HTML from Markdown, refresh the section map, and inspect realistic pages in light/dark themes, narrow widths, disclosure behavior, contrast, overflow, link anchors, and accessible diagram alternatives. | Required visual and accessibility checks pass; no generated HTML or source anchors drift. |
Do not use the boundary edit to settle exact key hierarchies, shard constants, package versions, carrier selection, legal conclusions, or a public protocol launch date. Those are the work items the boundary is meant to make legible.
#Evidence and validation status
- Source inspection: completed for the canonical anchors, chapter headers, glossary, research-surface convention, and
scripts/build-html.jsgroupings listed above. - Proposal scope: no numbered Markdown, glossary, build script, or generated HTML file was changed by this artifact.
- Content-collaboration contract: the companion JSON passes
validate_content_collaboration.py. - Markdown/build validation: pending the owner's decision to apply the proposed source edits; this proposal is not added to the public build input.
- Rendering and accessibility: not performed and intentionally marked not applicable for this proposal-only artifact. They are required in Phase 5 after source and generated-surface changes.
#Open Threads
- Boundary vocabulary and shared-invariant status — U1.
- Canonical future protocol destination and ownership — U2.
- Sphere, promotion, access, transport, anti-enumeration, client-policy, governance, and hosting gates — U3–U10.