On-demand encryption-state probe heals rooms refusing under the state-synced guard #68
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Follow-up to #66 (D34): rooms with membership but no state-synced marker fail closed until the next state-complete sync delta. Sliding sync heals at next connect (pos reset); a quiet v2 room may refuse plaintext sends for a long time. Add an on-demand repair: on EncryptionStateUnknown with membership present, fetch GET /_matrix/client/v3/rooms/{roomId}/state/m.room.encryption (404 => known-unencrypted), commit the result plus the marker through a non-sync repair write path (must not touch the sync cursor, §3.2/CR-1). Acceptance: §10.4.2 guard semantics unchanged (fail closed until commit); repair path never writes a cursor; e2e covers 404 and 200 cases.
Scope update after D34 addendum 3: the transmit-time probe now confirms fact-absence with the server before any plaintext leaves and discovers late encryption (memoized per session), which covers the leak-safety half of this issue. What remains for #68 is the UX half: rooms REFUSING with EncryptionStateUnknown (marker absent — e.g. quiet v2 rooms) could heal eagerly via the same GET instead of failing the send. The probe helper in SendQueue (confirmedEncryptionContent) is reusable for that.