Sealed group rosters (§8.9b), and the two claims around them #6

2026-08-31T15:27:29Z

paulhitt commented

2026-08-31 15:27:29 +00:00

(Migrated from gitlab.com)

Closes #1
Closes #2

§8.9b was written and never committed. Two corrections come with it, pointing in
opposite directions — which is the point.

§22.4 read as though nothing had changed

It had. There is no gid -> user_id row left to read, and a stolen or subpoenaed
database does not reveal your groups.

But §22 is not about that. It is about what a running relay can observe, and
every word of it still holds: envelopes are addressed to devices, so membership is
reconstructible by correlation whether or not a table exists to read.

"Not stored" and "not observable" sound alike, and only the first is true. A
reader who takes §8.9b as closing §22 has been misled, and so has one who takes
§22 as meaning §8.9b bought nothing.

Both sections stay; the paragraph now says why.

§15 was wrong about Android, in the safe direction

	was	now
§13 PQ ratchet	no	built (`98342dd`, 16 tests), not yet cross-engine
§14 sealed sender	no	wired, run not recorded

Neither becomes . This table records runs, and no Android cross-engine
run has happened. Understating is the opposite of the failure §10 warns about,
but it is corrected the same way — by establishing what was run, not by flipping
a symbol because the code looks present.

The membership-trust claim now carries its evidence

Rather than asserting it, §8.9b records that on both apps the group list prefers
the sealed roster and the receive gate resolves from the blob — each covered by a
test watched to fail with the change reverted (iOS e90ba1b, Android
0006d82).

Follow-on

Resources/Views/spec.leaf in the relay is generated from this file via a sibling
checkout, so the public page needs the generator re-run and a deploy. Separate MR.

Closes #1 Closes #2 §8.9b was written and never committed. Two corrections come with it, pointing in **opposite directions** — which is the point. ### §22.4 read as though nothing had changed It had. There is no `gid -> user_id` row left to read, and a stolen or subpoenaed database does not reveal your groups. But §22 is not about that. It is about what a **running** relay can *observe*, and every word of it still holds: envelopes are addressed to devices, so membership is reconstructible by correlation whether or not a table exists to read. > "Not stored" and "not observable" sound alike, and only the first is true. A > reader who takes §8.9b as closing §22 has been misled, and so has one who takes > §22 as meaning §8.9b bought nothing. Both sections stay; the paragraph now says why. ### §15 was wrong about Android, in the safe direction | | was | now | |---|---|---| | §13 PQ ratchet | no | built (`98342dd`, 16 tests), not yet cross-engine | | §14 sealed sender | no | wired, run not recorded | **Neither becomes .** This table records *runs*, and no Android cross-engine run has happened. Understating is the opposite of the failure §10 warns about, but it is corrected the same way — by establishing what was run, not by flipping a symbol because the code looks present. ### The membership-trust claim now carries its evidence Rather than asserting it, §8.9b records that on both apps the group list prefers the sealed roster and the receive gate resolves from the blob — each covered by a test **watched to fail with the change reverted** (iOS `e90ba1b`, Android `0006d82`). ### Follow-on `Resources/Views/spec.leaf` in the relay is generated from this file via a sibling checkout, so the public page needs the generator re-run and a deploy. Separate MR.

paulhitt commented

2026-08-31 15:28:41 +00:00

(Migrated from gitlab.com)

mentioned in merge request flamenet-relay!5

paulhitt commented

2026-08-31 15:43:41 +00:00

(Migrated from gitlab.com)

mentioned in commit 8ace350a56

mentioned in commit 8ace350a568093ac7dcd18dd45e858723df2f3b2

paulhitt (Migrated from gitlab.com) merged commit 8ace350a56 into main

2026-08-31 15:43:41 +00:00

paulhitt commented

2026-09-09 18:59:50 +00:00

(Migrated from gitlab.com)

changed the description

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-e2e#6