Target user (Element) gets "unable to decrypt message" even though my sending client (Nheko) is still online, in a situation where arguably the keys to decrypt should just automatically be retransmitted

[ell1e]

Describe the bug

I've just a target user (Element) get "unable to decrypt message" even though my sending client (Nheko) is still online and they're not using any sort of new device. The message is also from hours ago, so there is no real reason in the interest of plausible deniability why in such a short time frame, my sending client shouldn't allow a receiving client to re-request the necessary keys if the same trust level is still present, which it should be with no new device or no device fingerprint change or anything having had happened.

To Reproduce

1. Use Nheko to send a text message to an Element user
2. Encounter some condition where sending client fails to send necessary keys to all target devices or they somehow don't arrive with all of them (this seems fairly easy on both Nheko and Element as a sender, as soon as the target has multiple clients and some of them are offline. don't ask me how since I don't know the protocol on that level, but it happens all the time)
3. Receiving person comes online on one of their devices that didn't get the decryption key and then tries to read the message

What happened?

Receiver just gets "unable to decrypt message"

Expected behavior

Receiving client asks sender client via some e2ee tunneled direct communication protocol to receive the keys for the message again. Sender client (Nheko) checks that 1. same trust level applies (this is either not a new unknown device, or per-user rather than per-device trust is enabled and the device has the necessary signature and all for that), 2. the message isn't too old (a reasonable time window would probably be around 24h) so plausible deniability is still reasonably adhered to, 3. that the message wasn't deleted in the meantime or something, and then once these checks all end up successful, 4. resends the necessary decryption keys to the target user's device.

Screenshots

No response

Version

0.11.3

Operating system

Linux

Installation method

Flathub

Qt version

No response

C++ compiler

No response

Desktop Environment

No response

Did you use profiles?

• Profiles used?

Relevant log output

No response

Backtrace

No response

[deepbluev7]

Element does not implement requesting keys for such messages anymore, as such they intentionally disabled the recovery mechanism. There is nothing we can do from our side to fix that, I tried already to convince them to change that.

However if it is consistently the Nheko session which fails to send decryptable messages to the other user, make sure that Nheko can see all of the devices from that user. If you can't, try signing out and back in in that session.

But in general what you are requesting is implemented in Nheko and Element did implement it in the past, but dropped it nowadays, which leads to the behaviour you are experiencing.

[ell1e]

Okay, I suggested this for the matrix specs now: matrix-org/matrix-spec#1701 Feel free to weigh in there.

[deepbluev7]

I don't think the spec is the right place for that, since such a mechanism already exists: https://spec.matrix.org/v1.9/client-server-api/#key-requests (as I already said)

[ell1e]

The spec idea was/is that it's made strongly recommended for the given scenario, and would be declared somewhat expected for a functional robust matrix client. Currently at least Element themselves don't seem to share that notion, so it seemed like a worthwhile try.

[deepbluev7]

You should file an issue with Element then, not the spec. That was their choice.

[ell1e]

Thanks for your input, that seems like a fair opinion! I think someone in the nheko chatroom once suggested that it also may not abide to key requests in the exact scenario given in this ticket for plausible deniability reasons. Based on this, it seemed worthwhile to me to suggest the spec actually contain a more concrete suggestion on when requests would usually expected to be granted (because the mechanism seems like it won't be that useful unless the mainstream clients somewhat agree on when it can be made use of). Due to that, I think I'll leave the spec ticket open for now to see what others think, I'm hoping not to upset anyone however. We'll see how it goes