"Offline encrypted messaging using dehydrated devices" doesn't work, still getting lost messages

[ell1e]

Steps to reproduce

1. Just launched element to see new "** Unable to decrypt: The sender's device has not sent us the keys for this message. **
   Re-request encryption keys from your other sessions." messages.
2. This was after enabling "Offline encrypted messaging using dehydrated devices" weeks ago.

What happened?

unable to decrypt failures that do not recover

What did you expect?

it works

Operating system

Linux/Fedora

Application version

Element version: 1.7.33

How did you install the app?

flatpak

[dbkr]

Could you add a bit more detail to your repro steps? I'm not really sure what the situation is here - it sounds like you're just launching element rather than logging in again? If so, this wouldn't be related to dehydrated devices.

[ell1e]

Yes, I thought this error appears when I wasn't onliine when keys were exchanged, and then come online without the key, but maybe I was wrong. If dehydration doesn't fix this, then maybe the protocol needs another fix on top?

What if when both clients are online at some later point and the sender's session/client still has the history and hasn't deleted the message and still is in the room, other clients would be allowed to re-request it? (A sender client could even track who was in the room before, so if I don't lose my session then it could even resend it to me without worrying about violating the room history setting.) Like, I get this could happen if somebody tried to retract the message actively, but this seems to happen randomly when people just want to talk. And lost messages when nobody tried to lose/delete them is not really something that should happen in a messenger without any recovery path. But I admit that I understand really little why exactly this happen with Matrix in particular, other than it just feels like it is fixable on some level with protocol extensions so it's frustrating to keep seeing it.

[dbkr]

OK - this case should work in theory: your HS should store the message with the key and forward it to your client when it's next online. If you can submit a bug report and get the sender to submit one as well, we should be able to see where it's getting lost, although appreciate that if you're only starting element sometime later, getting a bug report from the sender can be tricky.

[SuperdukeGates]

I have the same problem. And below is my reproduce

1. Be sure the feature_dehydration was enabled in Element-desktop and sign in for account A, the only session for account A.
2. Signed out completely for account A and quit Element-desktop.
3. Account B is always on-line on a mobile device and then send an one-to-one message M to account A.
4. Sign in account A via Element-desktop again and can't decrypt message M.

My Element-desktop is version 1.9.0
My homeserver is matrix-synapse and its version is 1.44.0

EDIT
I checked the server side log that the client, Element-desktop, did issue the "Rehydrating a device" request and then issue the "Dehydrating a device" request. Both requests got the response code 200. But there is no "Claim" request sent from the client.

[uhoreg]

IIRC, it only works if you turn the labs flag on in the config.json, and then do a new login. It doesn't work if you just turn it on in the labs settings. Also, when you log in, you have to unlock SSSS with a passphrase -- it won't work if you verify with emoji/QR codes.

[uhoreg]

The original report was unrelated to dehydrated devices, and we're going to be making dehydrated devices work differently, which will probably result in most of the code being rewritten, so it's unlikely that current bug reports will be applicable to the new code. So I'm going to close this issue for now.