#Aims and reasoning
#Technical permission is narrower than social authority
A person may help with a task, contribute a record, or facilitate a disagreement without acquiring every digital power in that context. Conversely, permission to edit an inventory does not authorize taking the physical item. Product meaning comes from §08 and §09; this page studies the parts software can enforce.
Roles may bundle scoped technical powers when useful. Descriptive responsibility, labels, credentials, personal preferences, and hard grants remain distinguishable. No numeric hierarchy or automated interpretation of kaupapa is required.
#Accountability needs an evidence boundary
Personal blocks are local and unaudited. A report deliberately discloses selected evidence to selected reviewers. An outcome may be shared more widely than its case record, but a coordination feed must not become a permanent dossier.
A deniable transcript can support a person's account without proving that only the alleged author could have produced it. Missing transferable proof is not evidence of dishonesty; a valid technical artifact does not settle every social interpretation. Reported history, current endorsement, and original-source authentication are different claims for later readers.
#Convergence cannot reverse a disclosure
Arrival order must not decide legitimate authority. Yet a common accepted state is not a promise that every local governance question has one universal answer. A design can retain permitted local variants or incompatible histories explicitly.
Departure, suspension, malicious-edit correction, and compromised-device revocation may need different historical treatment. Even perfect eventual convergence cannot make someone forget a key released before the conflict was discovered. Freshness requirements for sensitive disclosure must therefore be designed separately from ordinary offline editing.
#Protocol and architecture
#Authority matrix
| Relationship or authority | May establish | Must not imply |
|---|---|---|
| Contributor | An in-scope content change or proposal | Universal ownership, moderation, or additional readers. |
| Reader | Permitted plaintext access | Individual writer identity merely by knowing the read key. |
| Shared controller | Selected future-access or resource transitions | A tenant root over unrelated spaces. |
| Technical steward | Named enrollment, key, or recovery work | General power to interpret norms or govern real-world activity. |
| Facilitator or moderator | Scoped reports and outcomes | Every content key or authority in other communities. |
| Label or attestation issuer | A contextual claim | Automatic permission, reputation, or collective agreement. |
| Storage custodian | Ciphertext retention under finite terms | Reading, social authority, or unlimited retention. |
| Repair worker | Bounded ciphertext reconstruction | New recipients, content revisions, or governance state. |
#Grant, capability, and envelope are different
A valid action grant need not contain a read key, and a read key does not confer publish or moderation rights. An ERIS capability over application ciphertext can allow reconstruction without application decryption. A descriptor's source-authentication mechanism is selected separately; encryption alone is not a personally attributable authorship proof.
Grant validation must bind the resource, action, relevant recipient/context, policy state, expiry where applicable, attenuation, replay rules, and accepted delegation chain. A byte allowance in a token is not a cumulative spending meter; #8 owns accounting. Quorum authorization counts accepted distinct authorities, not arbitrary device keys.
#Candidate components and ownership
| Seam | Candidate and status | Work that must remain explicit |
|---|---|---|
| Local accepted state | SQLite / rusqlite; provisional smaller-core baseline | Transactional persistence, replay, causal validation, and migration. |
| Scoped delegation | Biscuit, UCAN, Meadowcap; bounded comparisons | Authority establishment, namespace mapping, freshness, revocation, and key delivery. |
| Concurrent membership | p2panda-auth; candidate validation owner | Adopt its semantics deliberately; test control-evidence leakage and content dependency repair. |
| Private object access | AEAD plus HPKE; prototype composition | Audience ceiling, source-authentication profile, device state, and retention. |
| Recurring group state | OpenMLS; gated alternative | Credential binding, accepted membership changes, and historical access. |
| Shared approvals | Separate approval records; FROST only when threshold signing is required | Exact operation binding, identity/quorum policy, recovery, and evidence profile. |
The tools inventory remains the comprehensive comparison. These roles are proposed integrations, not package adoption. A library can own validation if its semantics satisfy the contract; maintaining a second competing reducer is not inherently safer.
#Variation — Explicit grant validation in the smaller core
This composition makes the contract visible but leaves substantial security work to TalkCo. Biscuit or UCAN can reduce token and delegation work; they do not choose the community's root or solve concurrent revocation. Biscuit explicitly identifies revocation as externally managed state. The exact capability format, authentication, and conflict policy need interoperable vectors before implementation is treated as reliable.
#Variation — Adopt a library's authorization semantics
The documented p2panda design includes cumulative Pull, Read, Write, and Manage levels and a configurable conflict resolver. Its strong-removal rule can invalidate dependent operations; mutual manager removal can freeze management. These are concrete semantics to evaluate, not a generic “CRDT solves permissions” claim. TalkCo must map them to named scoped powers, avoid unwanted inheritance, and test whether signed control operations fit the selected evidence profile (design source).
A rejected binary CRDT update may be a dependency of later legitimate edits. Compare semantic corrections, dependency closure, authorized checkpoints, and rebase instead of assuming deletion of the update repairs the document. An integrated workspace candidate must pass the same tests with its own validation owner.
#Revocation and conflict
This fixture distinguishes eventual authority from irreversible disclosure. A high-risk operation may require fresh agreement or a narrower release authority even where content editing is available offline. The protocol must state what happens when required evidence is unavailable, including partitions, stale checkpoints, restored backups, and irreconcilable histories. It must not silently elect a winner by arrival time or a manager by seniority.
#Moderation evidence flow
The report should not expose the reporter to the reported person by default. A summary may communicate an outcome without publishing the original conversation or association graph. Outcome authentication follows the declared evidence profile; a personally linked signature over private content or its hash can reintroduce transferable proof.
Evidence mechanisms requiring a named need
Hecate studies asymmetric message franking for reporting abuse to a moderator while retaining other privacy and deniability properties under its model. NOTRY studies retroactive avowal of a prior conversation. They are distinct research references, not selected libraries or a universal moderation solution. Normal consented publication may instead authenticate a new artifact now without proving the old conversation's original authorship. #3 owns the complete evidence chain and collusion model.
#Conditional access methods
| Method | Named reason to consider it | Additional gate |
|---|---|---|
| Scoped grant and recipient envelope | A known recipient can hold the key | Device lifecycle, fanout, replay, and future-grant rules. |
| MLS or session epoch | A recurring changing group justifies group state | Credentials, offline recovery, history, and application policy. |
| PRE | A specifically authorized ciphertext transformation is needed | Delegation, compromise, misuse, and revocation. |
| Threshold release / TACo candidate | No single party should release a protected key | Committee liveness, collusion, recovery, and metadata. |
| Attribute/broadcast encryption | A measured audience shape defeats simpler envelopes | Policy leakage, key management, and maturity. |
| ZK eligibility | A specific predicate must be proved privately | Issuer/nullifier correlation; proof is not key delivery. |
| Public control plane | A necessary public commitment or settlement | Public metadata, availability, and governance dependencies. |
TACo remains conditional on a named requirement and current review. No threshold service establishes social legitimacy, and no later policy change recalls a previously delivered key.
#Falsification tests
| Fixture | Required result |
|---|---|
| Unauthorized writer, moderator, or restored revoked device | Cannot change accepted protected state. |
| Action token without content key; read key without writer proof | Neither substitutes for the missing authority. |
| Concurrent removal, delegation, and prior key release | Explicit future/history result; no false recall claim. |
| Removed CRDT dependency with legitimate descendants | Defined repair/checkpoint behavior without silent corruption. |
| Private block, report, or case in export and coordination feed | No unintended disclosure. |
| Late-reader history | Distinguishes original authentication, current endorsement, and report. |
| Custody allowance, expired lease, or repair grant | Cannot add readers or create unlimited retention. |
| Same admissible events delivered in another order | Same policy outcome, or explicitly represented allowed disagreement. |
#Research links
Continue to lifecycle, encryption, trust, storage, and profiles. Earlier evidence remains in Wave 3. Package descriptions checked against the linked primary sources on 2026-10-24 do not establish a deployment-ready version or audit.
#Open questions
- #5: authorization owner, concurrent changes, malicious writers, and history repair.
- #3: source/control evidence profiles and signature leakage.
- #8: service delegation, private allowances, and replay/accounting.
- #11: useful roles and coordination without mandatory administration.
- #12: incident evidence, disclosure, retention, and launch gates.