The metadata page said sealed rosters were not built #66

2026-08-31T13:41:42Z

paulhitt commented

2026-08-31 13:41:42 +00:00

(Migrated from gitlab.com)

Closes #1

/metadata told people the encrypted-roster design is not built. It shipped
in 4c21698 / c832b1c and deployed today, so the page was stale on a privacy
claim — on the one page people open specifically to find out what is stored.

Why this is not just "flip it to built"

The opposite overclaim was the easier mistake to make. What is actually true:


Relay can hold a sealed roster	built, deployed, verified in prod schema
Any client creates one	none
Production groups sealed	0 of 4 — 7 `group_members` rows still in the clear

A page that answered the correction by announcing the capability would leave
every reader better protected in their head than in fact.

What the row says now

The list is held in the clear today, for every group on the server.
The encrypted path exists — no account ids in any group table, members known
only by opaque tokens — and nothing is using it yet.
What it will and will not buy once something does: it defeats a stolen or
subpoenaed database; it does not hide groups from the operator, because
fan-out is per device and watching who receives a group's traffic still
gives the group away.

the promise this earns is "a dump of this database does not reveal your
groups", and not "the server cannot see who you talk to"

Verification

Structure balanced: 17/17 <tr>, 36/36 <td>, 17/17 <strong>
The staging gate renders all 19 public pages, /metadata among them, before
prod is touched

Not in this MR

spec.leaf is generated from flamenet-e2e/docs/SPEC.md, which carries the
same stale framing and now contradicts its own §8.9b. Filed separately.

Closes #1 `/metadata` told people the encrypted-roster design **is not built**. It shipped in 4c21698 / c832b1c and deployed today, so the page was stale on a privacy claim — on the one page people open specifically to find out what is stored. ### Why this is not just "flip it to built" The opposite overclaim was the easier mistake to make. What is actually true: | | | |---|---| | Relay can hold a sealed roster | built, deployed, verified in prod schema | | Any client creates one | none | | Production groups sealed | **0 of 4** — 7 `group_members` rows still in the clear | A page that answered the correction by announcing the capability would leave every reader better protected in their head than in fact. ### What the row says now 1. The list is held **in the clear today**, for every group on the server. 2. The encrypted path exists — no account ids in any group table, members known only by opaque tokens — and **nothing is using it yet**. 3. What it will and will not buy once something does: it defeats a stolen or subpoenaed database; it does not hide groups from the operator, because fan-out is per device and watching who receives a group's traffic still gives the group away. > the promise this earns is "a dump of this database does not reveal your > groups", and not "the server cannot see who you talk to" ### Verification - Structure balanced: 17/17 `<tr>`, 36/36 `<td>`, 17/17 `<strong>` - The staging gate renders all 19 public pages, `/metadata` among them, before prod is touched ### Not in this MR `spec.leaf` is generated from `flamenet-e2e/docs/SPEC.md`, which carries the same stale framing and now contradicts its own §8.9b. Filed separately.

paulhitt commented

2026-08-31 13:49:13 +00:00

(Migrated from gitlab.com)

mentioned in commit fc787b8ce1

mentioned in commit fc787b8ce1a846f830e733c180700e3771437a99

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

2026-08-31 13:49:13 +00:00

paulhitt commented

2026-09-09 18:59:27 +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-relay#66