Production is 4 groups, 4 plaintext, 0 sealed #2

New Issue

2026-08-31T13:43:28Z

paulhitt commented

2026-08-31 13:43:28 +00:00

(Migrated from gitlab.com)

SealGroupRosters is deployed and additive by design — existing rows keep their
plaintext membership until a client upgrades them. Nothing has.

select count(*) filter (where roster_blob is null)     as plaintext,  -- 4
       count(*) filter (where roster_blob is not null) as sealed,     -- 0
       count(*) as total from groups;                                 -- 4
select count(*) from group_members;                                   -- 7

The relay already supports upgrading a group in place, owner-only, deleting the
GroupMember rows in the same transaction (c832b1c). What is missing is a
client that calls it — paulhitt/flamenet-messenger-ios#1.

Done when

A client offers/performs the upgrade for groups it owns
group_members reaches 0 rows, or the remainder is understood and recorded
/metadata updated once this is no longer "nothing is using it yet" (#1)

`SealGroupRosters` is deployed and additive by design — existing rows keep their plaintext membership until a client upgrades them. Nothing has. ```sql select count(*) filter (where roster_blob is null) as plaintext, -- 4 count(*) filter (where roster_blob is not null) as sealed, -- 0 count(*) as total from groups; -- 4 select count(*) from group_members; -- 7 ``` The relay already supports upgrading a group in place, owner-only, deleting the `GroupMember` rows in the same transaction (c832b1c). What is missing is a client that calls it — paulhitt/flamenet-messenger-ios#1. ### Done when - [ ] A client offers/performs the upgrade for groups it owns - [ ] `group_members` reaches 0 rows, or the remainder is understood and recorded - [ ] `/metadata` updated once this is no longer "nothing is using it yet" (#1)

paulhitt commented

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

(Migrated from gitlab.com)

mentioned in issue #5

paulhitt commented

2026-08-31 14:57:07 +00:00

(Migrated from gitlab.com)

mentioned in merge request flamenet-messenger-ios!43

paulhitt commented

2026-08-31 15:09:38 +00:00

(Migrated from gitlab.com)

mentioned in issue flamenet-messenger-android#3

paulhitt commented

2026-08-31 15:10:49 +00:00

(Migrated from gitlab.com)

mentioned in merge request flamenet-messenger-android!1

paulhitt commented

2026-08-31 15:23:40 +00:00

(Migrated from gitlab.com)

mentioned in merge request flamenet-messenger-android!3

paulhitt commented

2026-09-04 22:17:46 +00:00

(Migrated from gitlab.com)

Closed — every box is ticked, measured with this issue's own query on 2026-09-04.

plaintext | sealed | total
----------+--------+-------
        0 |      2 |     2

group_members
-------------
            0

Against the 4 plaintext / 0 sealed / 7 member-rows recorded when this was filed.

✅ A client performs the upgrade — both live groups carry a roster_blob at roster_version 1.
✅ group_members reaches 0 rows.
✅ /metadata updated — done today under relay#18, and it needed doing: the page still said "every group that exists right now is still the old kind, held in the clear", which stopped being true when the apps caught up and nobody re-measured.

⚠️ The count went 4 → 2, so two of the original groups were deleted rather than upgraded. That is worth stating rather than reading 0-plaintext as proof that four upgrades happened; two did, and the other two went away.

⚠️ And the plaintext those 7 member rows held outlived the delete. group_members was holding 9 dead tuples when I looked — deleted from the live table, still in the heap. Cleared under relay#17, along with a weekly VACUUM FULL and per-table autovacuum thresholds so it does not silently rebuild. Autovacuum's default never fires on a table this small, which is why nobody had seen it.

This property is now re-measured weekly by messenger-privacy-check — a group roster losing its seal, or group_members gaining a row, mails on the state change.

**Closed — every box is ticked, measured with this issue's own query on 2026-09-04.** plaintext | sealed | total ----------+--------+------- 0 | 2 | 2 group_members ------------- 0 Against the 4 plaintext / 0 sealed / 7 member-rows recorded when this was filed. - ✅ A client performs the upgrade — both live groups carry a `roster_blob` at `roster_version 1`. - ✅ `group_members` reaches 0 rows. - ✅ `/metadata` updated — done today under relay#18, and it needed doing: the page still said *"every group that exists right now is still the old kind, held in the clear"*, which stopped being true when the apps caught up and nobody re-measured. ⚠️ **The count went 4 → 2, so two of the original groups were deleted rather than upgraded.** That is worth stating rather than reading 0-plaintext as proof that four upgrades happened; two did, and the other two went away. ⚠️ And the plaintext those 7 member rows held **outlived the delete**. `group_members` was holding 9 dead tuples when I looked — deleted from the live table, still in the heap. Cleared under relay#17, along with a weekly `VACUUM FULL` and per-table autovacuum thresholds so it does not silently rebuild. Autovacuum's default never fires on a table this small, which is why nobody had seen it. This property is now re-measured weekly by `messenger-privacy-check` — a group roster losing its seal, or `group_members` gaining a row, mails on the state change.

paulhitt (Migrated from gitlab.com) closed this issue

2026-09-04 22:17:47 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-relay#2