# Data, Consent & Privacy — the room's approach

> A chat room is being turned into a **queryable mind**. This document sets out,
> in plain terms, how the room handles the question that follows from that: *if
> what you say here feeds a model, on what terms?* It is distilled from the room's
> own discussion (April–June 2026) and written so that someone arriving cold can
> follow the whole argument.


## Part 0 · Orientation — read this first

*Skip to Part 1 if you already live in this material. This part builds the
scaffolding so the rest is legible to anyone.*

### What this document is

An **outline spec**: it states the shape of the room's approach and the
principles behind it, without yet freezing every implementation detail. It
records what the room has actually converged on, flags what is still open, and
gives the next builder a frame to harden.

### The 30-second version of "the world model"

The `#jar:matrix.org` room is read, day by day, by an ingestion pipeline. That
pipeline doesn't store the chat — it **distils** it: who spoke, what they
decided, which questions are open, which concepts keep recurring. The result is a
*world model* — a queryable picture of what the group knows and is arguing about,
browsable at [`/jar-world`](https://rw.zo.space/jar-world). Decent runs the same
machine over its own Monday calls; JAR is the first **external** group it runs over.
(Full mechanics: the *World Model Protocol — context excerpt* shared alongside this doc.)

So the room is two things at once: a place to talk, **and** the raw material for a
model. That double role is the entire reason consent is on the table.

### Three words we will keep using

| Word | Plain meaning | Why it matters here |
| --- | --- | --- |
| **Ingestion** | The act of reading the room and turning it into model data. | It happens automatically and continuously. It is the thing you are or aren't consenting to. |
| **Consent** | Agreeing, on known terms, that your contributions may feed the model. | The open question is *when* and *at what grain* you give it. |
| **Refusal** | Saying no — declining to be ingested or attributed. | The room's strongest principle is about what refusal must *never* cost you. |

### The cast (who shaped this)

- **rich** (`@monsieurbulb`) — building the ingestion + world-model surfaces; pushing
  the consent question and the "make this reusable for any community" goal.
- **Wei** (`@wei:pacna.org`) — Matrix/homeserver internals; framed a Matrix room as
  "a lite blockchain — a DAG of events."
- **Daniel / olanod** (`@olanod:virto.community`) — Virto/VOS private-comms lead;
  the room's sharpest privacy critic (metadata, SimpleX, MLS).
- **Tristan** (`@tristain`) — antitrust / market-structure lens; author of the
  *capability-preserving refusal* principle and a draft consent-cap proposal.
- **lu_bubba** — provenance and source-linking; temporal GraphRAG.


## Part 1 · The core question

> *"Should there be some consent agreement related to this room in particular with
> regard to surfacing the discussions into a higher-order model / queryable voice?
> …Should the ingestion path itself be protocolised — short terms agreed on join:
> 'welcome to JAR, your content will be ingested automatically, names anonymised'?"*
> — rich, 2026-06-03 / 06-08

This is the spine of the spec. Everything else is either a constraint on the
answer or a piece of the mechanism that delivers it. The root of the question is
older than the recent thread: when the `/jar-world` site shipped (2026-05-21),
rich flagged it openly — *"there's no terms / agreement currently for people
joining that they will end up with their opinions surfaced on the JAR-world site."*
The job now is to close that gap honestly.


## Part 2 · What the room ruled out (and why)

Two tempting-but-wrong answers were eliminated early. Recording them matters as
much as the principles, because they mark the edges.

### 2.1 · Per-message consent — incoherent on a public room

> *"That consent part sounds tricky to enforce… using the blockchain example, it's
> like an indexer having to ask for my consent for processing my transactions."*
> — Daniel, 2026-06-03

Once a Matrix message federates, it is in the shared event graph (the DAG) and
**cannot be retracted**. Asking permission per message is both unenforceable and
the wrong mental model. rich accepted this directly: *"Daniel's right that
per-message consent on a public room is incoherent."* → **Consent cannot live at
the message; it has to live at the boundary** (Part 3.1).

### 2.2 · Content encryption as "privacy" — solves the wrong leak

> *"If JAR ever writes messages into public state, e2ee on the body doesn't save
> you. Who↔who, when, from where is the actual leak. Meta doesn't mind it can't
> read WhatsApp."* — rich, 2026-06-05, building on Daniel

Encrypting the *body* of a message leaves the **metadata** — sender, device,
timestamps, membership, server domain — in the clear. For a public, ingestible
room that metadata is the sensitive part. → **The privacy axis that matters is
metadata, not content encryption** (Part 4.3).


## Part 3 · The principles the room converged on

Seven principles, each stated plainly, then grounded in the room's own words.

### 3.1 · Consent at the boundary, not per message

You consent **on entry** to a bounded space whose terms say "discussion here feeds
the world model" — exactly like agreeing to a Discord's terms on join, or the
passkey + consent-on-entrance already used for the Monday Chaos Sessions. You
don't approve each message; you accept the room's purpose once.

> *"The frame that survives is consent at the boundary, not per message… and it's
> mutual: you give context, the community owes you a stake/say in what it becomes.
> That's where the liability runs both ways too."* — rich, 2026-06-03

### 3.2 · Capability-preserving refusal (the room's hardest line)

This is Tristan's contribution and the principle the room treats as binding:
**saying no must never cost you anything unrelated.** Consent that you cannot
safely refuse is not consent — it is coercion wearing a checkbox.

> *"Consent is not meaningful if refusal destroys access to the substrate. For any
> consent-relevant operation O, there should exist a refusal path R such that
> invoking R does not require cooperation from the party benefiting from O, and does
> not remove the refusing agent's unrelated protocol capabilities."* — Tristan,
> consent-cap-semantics-v0, 2026-06-05/06

Tristan later sharpened this to a **refusal-liveness** claim: refusal need not
always be *accepted*, but an independent path to refuse must always *exist* — one
that doesn't depend on the party who benefits, and doesn't strip unrelated
capabilities. The threat model he names is **coercive dependency**: an optional
ingestion point quietly hardening into a dependency surface you can't opt out of.

> *"Binding principle: openness is desirable, but refusal must remain
> capability-preserving."* — Tristan, 2026-06-08

### 3.3 · Architectural orthogonality — consent is a market-structure primitive

Through Tristan's antitrust lens, consent is not only a user-permission toggle; it
is part of the **market structure**. The danger is collapse: if security,
governance, collateral, liquidity, fees and *narrative* all orbit one surface
(e.g. one token), then "refusing" a world-model claim can quietly cost you
routing, reputation or voice — and consent becomes nominal.

> *"An agent may formally consent, but if refusing means losing routing,
> reputation, liquidity, collateral access, or governance voice, then the protocol
> has created coercive dependence through architecture."* — Tristan, 2026-06-05

Practical corollary the room noted: keeping JAR **coinless** for now preserves this
orthogonality — it stops the consent surface from collapsing into a token surface
before the coordination problem is even understood.

### 3.4 · Per-surface separation — public feeds the model, private never does

The world model wants to read and connect *everything*; metadata-minimal messaging
wants *no one* — including us — to be able to. These pull in opposite directions.
The room's resolution is **not to reconcile them but to separate them by surface**.

> *"Consented public rooms feed the model, private DMs never get ingested. Keep the
> public tier on plain Matrix; treat SimpleX-style queues as the model for any
> private tier."* — rich, 2026-06-05. Daniel concurred: *"Ingesting data from a
> public chat works well with Matrix"* while his own focus is private comms via VOS.

### 3.5 · The user signs, not the host — Matrix is just transport

The integrity of a consent record should ride on the **user's own key** (a
Virto/Kreivo identity), not on whichever homeserver happens to host the room. Once
the user signs and the pipeline drops anything that doesn't verify, the homeserver
stops being a trust anchor at all.

> *"If the user signs and we drop anything that doesn't verify, then 2 and 3 collapse
> into one thing — the homeserver stops being the trust anchor… Matrix is basically
> just transport + ordering. We rebuild the consent timeline ourselves from the
> signed events. Self-hosting becomes a sovereignty call, not a requirement for this
> to be sound."* — rich, 2026-06-04, after Wei's steer that the user (not the
> server) should sign.

### 3.6 · Provenance and attribution are a *separate, later* layer

Consent is the **gate** (may we ingest you?). Attribution is a **later question**
(how much did your context contribute, and what stake does that earn you?). They
must not be conflated. Source-linking / "intelligence supply chain" provenance was
already the room's next ask back on 2026-05-21 (lu_bubba: *"when I see a distilled
fact and want to know more, I can't open it"*). Attribution proper is Kabocha
territory, downstream of the consent gate — not part of it.

### 3.7 · Tolerate noise over premature gatekeeping

A norm, not a mechanism, but the room holds it firmly: at this early stage, keep
channels fully open and tolerate even spam rather than import social/procedural
gatekeeping that could itself become a capture surface.

> *"The cost of openness is some noise; the cost of early exclusion is capture.
> Noise is not merely a defect — it can be read as part of a price signal, because
> its presence reflects the marginal cost of making it real."* — Tristan, 2026-06-08


## Part 4 · The mechanism (outline)

How the principles cash out technically. This is a sketch to harden, not a frozen
schema.

### 4.1 · The consent record

A **signed consent event**, carried in the same Matrix DAG as the chat, asserting
"this identity grants ingestion of this scope under these terms." Sketch:

```json
{
  "type": "org.decent.worldmodel.consent",
  "content": {
    "action": "grant",                         // or "revoke"
    "scope": "!dDGIfthCSazkdSmMFH:matrix.org",  // room or space
    "terms_version": "v1",
    "terms_uri": "https://decent.partners/consent/v1",
    "purpose": ["world-model-ingest", "attribution"],
    "subject": "@alice:matrix.org",
    "issued_at": 1733230000000,
    "sig": "<ed25519 over canonical content by the subject's own key>"
  }
}
```

### 4.2 · The ingestion rule

> Include message **M** from sender **S** in room **R** *iff* there exists a consent
> event **E** where `E.subject == S`, `E.scope` covers **R**, `E.action == "grant"`,
> `E.issued_at < M.origin_server_ts`, no later `revoke` supersedes it, and
> `terms_version` is one we accept.

- **Consent-as-of-message-time.** Because we ingest every event and rebuild the
  consent timeline ourselves from the signed records, we can ask "was there valid
  consent *at the moment this message was sent?*" — we don't depend on Matrix's own
  state resolution for our custom events.
- **Revocation is honest about the past.** A `revoke` event drops *future* context
  cleanly and flags past contributions for exclusion from the next training/build
  run. It cannot unpublish what already federated — and the spec says so plainly
  rather than pretending otherwise.
- **No consent → don't ingest** (or aggregate-only, never attributed).

### 4.3 · Privacy / metadata posture (per surface)

| Surface | Transport | Rationale |
| --- | --- | --- |
| **Public, ingested tier** | Matrix (matrix.org fine to start) | Weakest on metadata, but mature, and server-side history is what lets the ingestion bot backfill. This tier is *meant* to be read. |
| **Private member comms** | SimpleX-style (no accounts, rotatable pairwise queues, relays that delete on delivery); inspiration from Bison Relay's metadata-minimisation | Strongest metadata privacy. **Never ingested.** Maps onto our invite-graph model. |
| **Encryption standard** | MLS (RFC 9420) over Olm/Megolm | Daniel's and rich's shared preference. |

Because the graph and world model live in **our app layer on passkey identities,
not in the transport**, the transport is swappable — the choice above is a
starting point, not a lock-in.

### 4.4 · Identity binding

The signer is a portable **Virto Connect / Kreivo** identity, so the *same*
identities that will eventually **own** the model (the Pluralis end-state: the
community provides the data *and* the compute, and owns the result) are the ones
**consenting to feed** it. Ownership, governance and data-pledge all key off one
id. Rollout follows **"self-asserted now, signed-later"**: ship first with the
Matrix identity as signer, harden to the Kreivo key without re-asking everyone —
though, since the signature is doing the security work, the room leaned toward
pulling "signed" forward to now.


## Part 5 · Open questions

Honestly unresolved, carried forward:

- [ ] **Consent UI.** Wei: the DAG/custom-event approach is feasible but "there's no
  UI, one must be custom built." This is the actual build (rich's Tauri-on-Matrix
  client is the candidate).
- [ ] **State event vs message event** for the consent record (keyed by `state_key
  = mxid` so room state simply *shows* who's consented). Wei leans state event,
  unsure of gotchas.
- [ ] **Binding mxid → Kreivo identity** credibly, with the user's signature *inside*
  the event content.
- [ ] **Terms integrity:** hash the terms text so they can't be quietly changed;
  re-consent on a version bump. Align to an existing **MSC** rather than inventing
  `org.decent.*` if one fits.
- [ ] **Tristan's "physical truth" threat model** — refusal-liveness backed by
  independently replayable, hardware-attested substrate evidence. Acknowledged as
  ahead of what we're optimising for now; parked, not dismissed.
- [ ] **Is this room a *function of JAR's protocol* or merely an ingestion point?**
  rich's view: it's an optional ingestion point — refusal here must never gate
  JAR's protocol capabilities; anyone may stand up a consentless channel. Dominance,
  if it emerges, must come from gravity/network-effects, never from a chokepoint.


## Part 6 · Why this generalises

The point is not to govern one room. It is a **reusable join-terms primitive**:
short terms agreed on entry, a signed consent record, a consent-aware ingestion
rule, and a clean public/private surface split — that *any* community can adopt to
turn its own conversation into a world model it owns, without turning consent into
a dependency mechanism.

> *"This should develop into a generic protocol / system that any community can
> use."* — rich, 2026-06-08

That makes this document the **consent layer of the World Model Protocol** — the
terms on which the machine in the *World Model Protocol* (context excerpt alongside this doc) is allowed to read a room.