urgent and silent were not on /metadata. Both are things a sender
tells the relay so it can shape a push: urgent means ring now, silent means
this is housekeeping. Between them they let the relay tell a call from a
message — not who, not about what, but that this one is time-critical,
which is the single most informative thing a sender chooses to reveal.
Neither is stored, and the rows say so in those words. The issue
called this "an undocumented disclosure"; it is a disclosure, and it is
transient. silent and urgent are not columns on envelopes — they are
read to decide the push and gone with the request. Documenting them as
kept would have been its own inaccuracy.
The group-roster row said the opposite of the truth, and it was
true when it was written. It read "every group that exists right now is
still the old kind, held in the clear", waiting on the apps. The apps
caught up: both live groups carry a sealed roster_blob at roster_version 1, and the plaintext group_members table holds zero
live rows. Measured on production, not assumed.
That is the direction of error you want on a privacy page — it claimed
worse than reality — but a promise that has drifted is still wrong, and a
page nobody re-measures is how the drift goes the other way next time.
The nuance the row already made is kept intact, because it did not change:
a sealed roster earns "a dump of this database does not reveal your
groups", NOT "the server cannot see who you talk to". Messages are still
addressed per device, so watching who receives a group's traffic still
gives the group away.
Also measured while here: 46 of 58 queued envelopes are sealed sends
storing no sender at all, 12 are identified. The unsealed path is real
traffic, not a vestige.
**`urgent` and `silent` were not on `/metadata`.** Both are things a sender
tells the relay so it can shape a push: urgent means ring now, silent means
this is housekeeping. Between them they let the relay tell a call from a
message — not who, not about what, but that this one is time-critical,
which is the single most informative thing a sender chooses to reveal.
**Neither is stored, and the rows say so in those words.** The issue
called this "an undocumented disclosure"; it is a disclosure, and it is
transient. `silent` and `urgent` are not columns on `envelopes` — they are
read to decide the push and gone with the request. Documenting them as
kept would have been its own inaccuracy.
**The group-roster row said the opposite of the truth**, and it was
true when it was written. It read "every group that exists right now is
still the old kind, held in the clear", waiting on the apps. The apps
caught up: both live groups carry a sealed `roster_blob` at
`roster_version 1`, and the plaintext `group_members` table holds zero
live rows. Measured on production, not assumed.
That is the direction of error you want on a privacy page — it claimed
worse than reality — but a promise that has drifted is still wrong, and a
page nobody re-measures is how the drift goes the other way next time.
The nuance the row already made is kept intact, because it did not change:
a sealed roster earns "a dump of this database does not reveal your
groups", NOT "the server cannot see who you talk to". Messages are still
addressed per device, so watching who receives a group's traffic still
gives the group away.
Also measured while here: 46 of 58 queued envelopes are sealed sends
storing no sender at all, 12 are identified. The unsealed path is real
traffic, not a vestige.
659 tests pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
urgentandsilentwere not on/metadata. Both are things a sendertells the relay so it can shape a push: urgent means ring now, silent means
this is housekeeping. Between them they let the relay tell a call from a
message — not who, not about what, but that this one is time-critical,
which is the single most informative thing a sender chooses to reveal.
Neither is stored, and the rows say so in those words. The issue
called this "an undocumented disclosure"; it is a disclosure, and it is
transient.
silentandurgentare not columns onenvelopes— they areread to decide the push and gone with the request. Documenting them as
kept would have been its own inaccuracy.
The group-roster row said the opposite of the truth, and it was
true when it was written. It read "every group that exists right now is
still the old kind, held in the clear", waiting on the apps. The apps
caught up: both live groups carry a sealed
roster_blobatroster_version 1, and the plaintextgroup_memberstable holds zerolive rows. Measured on production, not assumed.
That is the direction of error you want on a privacy page — it claimed
worse than reality — but a promise that has drifted is still wrong, and a
page nobody re-measures is how the drift goes the other way next time.
The nuance the row already made is kept intact, because it did not change:
a sealed roster earns "a dump of this database does not reveal your
groups", NOT "the server cannot see who you talk to". Messages are still
addressed per device, so watching who receives a group's traffic still
gives the group away.
Also measured while here: 46 of 58 queued envelopes are sealed sends
storing no sender at all, 12 are identified. The unsealed path is real
traffic, not a vestige.
659 tests pass.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com
assigned to @paulhitt
mentioned in commit
a90943f807mentioned in issue #18
changed the description