Epic: Users should not see UTDs for messages they are not supposed to be able to read

[BillCarsonFr]

Abstract

There are cases when messages cannot be decrypted by a client, and it is expected/known that it can't.

Currently clients will display these messages, and display them as errors: unable to decrypt messages.

In some cases, these UTDs (Unable To Decrypt) can be resolved (decrypted) if the user performs some action.

The goal is to identify these type of UTDs and see if they could be hidden to the user until the action that could resolve them is performed.

Definition

A UTD is expected when a message which keys were not supposed to be (or couldn't be) shared with your current device is received.

When sending a message, the client checks for all devices in the room, then sends them the Megolm key to decrypt the message. Therefore, for example if the current device was not in the room at that point, it will create an expected UTD.

Notice that we are talking here about a device joining a room, not a user joining a room. Devices have their own life time, and is different from the user life time.

Scenarios creating avoidable UTDs:

• Expected UTDs: Hide device-relative historical UTDs #2313: You log in with a fresh session and open one of your existing rooms. All messages sent before this login existed will be in UTD, and it's expected. You need to get access to the backup first to fix them.

• Expected UTDs: Hide UTDs for messages sent while you were not in the room ("Pre-join UTDs") #2317: In a set-up where an e2e room has history_visibility set to shared or world_visible, the pre-invite/join history will be UTD for ever (at least until history sharing is implemented).

• If one of the recipient in the room has no device, the sender know that there is no chance ever for the recipient to read this messages

Expected UTDs can sometimes be fixed

• If you have enabled server side key backup, you will be able to recover history (since the point you joined/got invited to the room). If the backup has been fully imported, in best case the UTDs will be resolved (there are cases were the backup could be missing some keys).

• In e2e rooms that allows to access pre-join/pre-invite history, the UTD wont fix unless MSC3061 is supported by both the person that invited you, and your current device. It will also only work if you are invited, and not if you join by yourself (space restricted rooms)

• It is also possible that a user manually imports room keys from a file. This could fix any kind of UTDs (could be possible that an other users shares keys to you in that way)

Breakdown

### Tasks
- [ ] https://github.com/element-hq/element-meta/issues/2313
- [ ] https://github.com/element-hq/element-meta/issues/2317
- [ ] Expected UTDs: Handle UTDs due to a recipient not having any device to encrypt to

[BillCarsonFr]

I might heavily update this issue, as it looks like I end up writing every thing we know about that could cause UTD. Instead of things we know will be in UTD until the session has been properly verified.

Updated the issue

[richvdh]

Closing this, because the two sub-issues have been resolved