#Aims and reasoning
#Why the architecture is already safer
Removing global reach, frictionless amplification, and public popularity signals reduces convenient routes to pile-ons and context collapse (§06). It does not eliminate abusive contacts, coordinated invitations, stalking, impersonation, or the risk of an authorized recipient leaking content. Those problems need direct controls and a realistic account of what each control can achieve.
#Blocking is silent by construction
A person may block or mute immediately, without a reason, approval, public event, or notification to the other person. Personal self-protection is unilateral and unaudited. The application should not make someone enter a moderation process merely to stop contact.
No explicit block signal is different from guaranteed secrecy about exclusion. Shared-group state, another account, delivery behavior, and previously visible content can permit inference. Forward access narrowing cannot erase already delivered keys, plaintext, or screenshots. Shared spaces also have their own authority: a personal block does not silently remove the other person from a community.
#A layered model
| Layer | Purpose | Consequence boundary |
|---|---|---|
| Personal block or mute | Immediate private self-protection | Local choice; no reason or shared audit required. |
| Inherited judgment, opt-in | Borrow a chosen source's deliberately shared recommendations | Depth one, locally overridable, attributable to the source for the subscriber, and reviewed or decayed. |
| Community labeler, opt-in | Offer contextual claims about content or behavior | Scoped evidence and process; the subscriber chooses warn, hide, or no action. |
A personal block never becomes a label automatically. Borrowed recommendations do not recursively import their sources' inherited lists, expose private block lists, or turn into a portable person score. The inherited-block entry should show source, category, time, and review date to its recipient. Personal blocks do not expire merely because an inherited recommendation does.
New labeler subscriptions default to warnings. Hiding or exclusion requires an explicitly chosen protective policy or a relevant protective-action grant; an arbitrary labeler cannot acquire community authority by publishing a label. These designs draw on stackable moderation while retaining local choice (BlueskyStackableModeration, ATProtoLabels, FediverseBlocklists2025).
#Two tracks
Restorative work addresses repairable friction in an ongoing relationship when participation is voluntary and immediate separation is unnecessary. A harmed person can choose no contact, represented contact, a written account, or protection instead. Protective work addresses credible threats, stalking, predation, targeted harassment, coordinated abuse, and safety-relevant impersonation without requiring dialogue with the source of harm. §09 owns scoped facilitation.
Ordinary labeler consequences require corroboration or a facilitator's confirmation. A first corroborated norm concern can lead to a private repair prompt; repetition or refusal may support a contextual label. Immediate danger takes the protective path. Corroboration is not a mathematical proof of independence, and social review is not interchangeable with a cryptographic quorum.
#No person-level reputation — and why
A label describes behavior in a context, with time, review, and possible resolution. It does not sum into a person score. Subscribers may reach different conclusions. Old and resolved labels should decay according to declared policy rather than becoming permanent public dossiers.
Facilitation requires labor. Bounded roles, review, and separate technical stewardship help keep that labor from becoming a prestige hierarchy (§09).
#Verification is not reputation
“Verified directly”, “introduced by Ana”, and “key changed” describe local evidence about a relationship, not standing in a network. Trust-on-introduction can help with impersonation without creating a public web-of-trust score; §03 owns verification and identity boundaries.
#Illegal content is not ordinary moderation
Some reports need category-specific legal/safety handling rather than a restorative prompt or a community label. The existing launch gate remains: counsel-reviewed service roles, incident routing, preservation, jurisdiction, and technically possible object-level responses must be resolved before public launch. §12 owns the legal assessment and current sources.
Encryption does not establish that hosts have no obligations. Client hiding does not remove a stored object, and withdrawing future access cannot recall plaintext. Incident handling must describe what each responsible actor can actually do.
#Protocol and architecture
#Personal controls and disclosed reports take separate paths
No shared report is created by the personal path. Self-device synchronization, if offered, must encrypt personal controls separately from community state. In an existing shared group, a block can suppress local contact but cannot cryptographically prevent another authorized group member reading group messages. A new narrower conversation or an authorized membership change is a separate action.
| Seam | Likely candidate and disposition | Required boundary |
|---|---|---|
| Personal policies, report workflow, local label views | SQLite / rusqlite; provisional baseline | Separate audiences and retention; protect local files and backups. |
| Report confidentiality | AEAD object plus HPKE recipient envelopes; prototype direction | Selected reviewers only; reporter disclosure must be deliberate and minimized. |
| Action and reviewer grants | TalkCo grant model; Biscuit/UCAN comparison | Resource, action, context, expiry, delegation, and accepted policy state. |
| Group removal where authorized | OpenMLS or the selected group adapter | Match the actual TalkCo membership decision; no assumed plaintext recall. |
| Optional label distribution | Replaceable scoped event delivery | Authenticate the issuer and scope without creating a universal reputation graph. |
These are candidate connections from the tools inventory. HPKE does not choose reviewers or authenticate a report's social interpretation. Biscuit's implementation explicitly leaves revocation to external state management; a valid token is not proof of fresh authority.
#A label is an input to a scoped decision
The reported person should not receive the reporter's identity by default. Facilitators need enough access to assess coordinated reports, with explicit retention and access limits. Reports from a common invite cluster, burst, or correlated source can be treated as one signal pending review, but the product must not claim it can reliably identify all Sybils or build a global relationship map to do so.
Outcome authentication follows the context's evidence profile. A transferable signature over a private transcript or its hash can undermine authorship deniability even when the bundle was encrypted in transit. A reported experience, a designated-reviewer proof, and a public attestation are different evidence classes; access-control research owns that comparison. Without universal decryption, moderators cannot proactively inspect every private object.
#Revocation changes future authority under an explicit history rule
Accepted policy changes determine future envelopes, group membership, and allowed actions. Concurrent removal and content updates need a declared causal rule, not last-arrival wins. A late revoked-device backup must not restore authority. Missing or incompatible authorization history can require deferring sensitive disclosure while ordinary already-authorized work remains available offline.
Local hiding, withholding future keys, deleting a cooperative host's ciphertext, and retaining a narrowly scoped incident record are separate operations. The implementation must keep them distinguishable in both API and product copy.
#Incident routing preserves the legal/safety boundary
A ciphertext-only host may know a locator and lease without knowing content. The incident schema must accept that limited report without demanding universal decryption. Response and preservation can have different actors and permissions; neither should silently grant community facilitators access to unrelated private material.
#Open Threads
- Labeler consequence parameters (OT-08-005). Set corroboration, review windows, decay, resolution, and appeal rules; test coordinated reports without collecting a global graph.
- Restorative prompt design (OT-08-006). Test voluntary participation, practical repair, and protective escalation under §09.
- Sybil and invite-borne abuse (OT-08-009). Measure scoped admission controls and false positives; avoid portable trust scores.
- Key verification and evidence (OT-08-010). Test introduction proofs and report authentication without reintroducing transferable private-source signatures.
- Illegal-content launch gate (OT-08-011). Keep current legal classification and incident evidence work in §12.
- Blocking and revocation test. Trace shared-group, multi-device, stale-policy, and alternate-account observations; claim only the privacy actually provided.