Messages stay "encrypted" after verifying someone until you leave and reopen the room #16

New issue

Open

opened 2026-10-05 17:55:35 +00:00 by robocub · 0 comments

robocub commented

2026-10-05 17:55:35 +00:00

Owner

Report

After cross-signing (verifying) a user, their DM keeps showing the messages as encrypted / unable to decrypt. Clicking to another room and back makes them decrypt and display.

What it suggests

Verification makes new keys available (key sharing between your devices, or key backup once trusted), and the Matrix SDK can then decrypt the events. But the open room's timeline doesn't re-render those events until the room is reopened. Likely candidates:

The decrypted events don't reach the timeline as a change, or the timeline entries don't re-evaluate their type. TimelineViewEntry caches its display type in loadState and only recomputes it on update(), which only runs for events the list was told changed.
Or nothing asks the SDK to retry decrypting already-loaded events when verification finishes or new room keys arrive.

Plan

Reproduce: unverified DM with undecryptable messages; verify the other user (or your other device) with the room open; check logs for room-key arrival and decryption.
When room keys arrive or a verification completes, retry decryption for the open timeline's undecrypted events and emit onChange for each one that now decrypts, so the entries rebuild.
Make sure an entry that changes from encrypted to message re-computes its display type.

Acceptance

With the DM open, completing verification turns the "encrypted" placeholders into the real messages within a few seconds, without leaving the room.

Filed with LLM assistance. This is a fork-only issue; never refile it on Commet's tracker.

## Report After cross-signing (verifying) a user, their DM keeps showing the messages as encrypted / unable to decrypt. Clicking to another room and back makes them decrypt and display. ## What it suggests Verification makes new keys available (key sharing between your devices, or key backup once trusted), and the Matrix SDK can then decrypt the events. But the open room's timeline doesn't re-render those events until the room is reopened. Likely candidates: - The decrypted events don't reach the timeline as a change, or the timeline entries don't re-evaluate their type. `TimelineViewEntry` caches its display type in `loadState` and only recomputes it on `update()`, which only runs for events the list was told changed. - Or nothing asks the SDK to retry decrypting already-loaded events when verification finishes or new room keys arrive. ## Plan 1. Reproduce: unverified DM with undecryptable messages; verify the other user (or your other device) with the room open; check logs for room-key arrival and decryption. 2. When room keys arrive or a verification completes, retry decryption for the open timeline's undecrypted events and emit `onChange` for each one that now decrypts, so the entries rebuild. 3. Make sure an entry that changes from encrypted to message re-computes its display type. ## Acceptance With the DM open, completing verification turns the "encrypted" placeholders into the real messages within a few seconds, without leaving the room. --- _Filed with LLM assistance. This is a fork-only issue; never refile it on Commet's tracker._

robocub added the

bug

effort: small

labels

2026-10-05 17:55:35 +00:00

robocub referenced this issue

2026-10-05 19:03:38 +00:00

Ask for the recovery key at sign-in; failed decryptions stay failed #32