/metadata says sealed rosters are not built. They are — and nobody is using them #1

New Issue

2026-08-31T13:40:34Z

paulhitt commented

2026-08-31 13:40:34 +00:00

(Migrated from gitlab.com)

/metadata tells people the encrypted-roster design is not built:

The server holds the list of members, and this is the largest single thing it
knows about you. It is not encrypted and there is no setting that hides it.
The design that would fix it is written up in the specification, and the
honest reason it is not built is that it would not deliver what it looks like
it delivers.

Sealed rosters shipped in 4c21698 / c832b1c and deployed today. The relay
now stores owner_key / roster_blob / roster_version, and group_tags
holds one opaque token per member with no account id in any group table.

So the page is out of date on a privacy claim, which is the worst place to be
out of date. It is live now.

The correction has to go both ways

Saying "it is built" would be its own overclaim. What is actually true:

The relay can hold a sealed roster. Built, deployed, verified.
No client creates one. Production is 4 groups, 4 plaintext, 0 sealed,
and 7 group_members rows still in the clear.
Even once clients catch up, it defeats a stolen or subpoenaed database,
not the operator watching live traffic — fan-out is per device, so who
receives a group's messages still reveals the group.

The claim this earns is "a dump of this database does not reveal your groups"
— not "the server cannot see who you talk to".

Done when

The group-membership row says what is stored today (plaintext), not what is possible
It says the sealed path exists without implying anyone is protected by it yet
It names the limit that survives even after clients catch up
No new claim that outruns the code

Follow-on work is tracked separately: clients do not create sealed groups, and
the membership check still trusts the relay.

`/metadata` tells people the encrypted-roster design **is not built**: > The server holds the list of members, and this is the largest single thing it > knows about you. It is not encrypted and there is no setting that hides it. > The design that would fix it is written up in the specification, and the > honest reason it is not built is that it would not deliver what it looks like > it delivers. Sealed rosters shipped in `4c21698` / `c832b1c` and deployed today. The relay now stores `owner_key` / `roster_blob` / `roster_version`, and `group_tags` holds one opaque token per member with **no account id in any group table**. So the page is out of date on a privacy claim, which is the worst place to be out of date. It is live now. ### The correction has to go both ways Saying "it is built" would be its own overclaim. What is actually true: - The relay can hold a sealed roster. Built, deployed, verified. - **No client creates one.** Production is 4 groups, 4 plaintext, 0 sealed, and 7 `group_members` rows still in the clear. - Even once clients catch up, it defeats a **stolen or subpoenaed database**, not the operator watching live traffic — fan-out is per device, so who receives a group's messages still reveals the group. The claim this earns is *"a dump of this database does not reveal your groups"* — not *"the server cannot see who you talk to"*. ### Done when - [ ] The group-membership row says what is stored **today** (plaintext), not what is possible - [ ] It says the sealed path exists without implying anyone is protected by it yet - [ ] It names the limit that survives even after clients catch up - [ ] No new claim that outruns the code Follow-on work is tracked separately: clients do not create sealed groups, and the membership check still trusts the relay.

paulhitt commented

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

(Migrated from gitlab.com)

mentioned in commit 7f5df8298c

mentioned in commit 7f5df8298c18f3223dff3fab16df68feb40dc68f

paulhitt commented

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

(Migrated from gitlab.com)

mentioned in merge request !3