Add option to re-ask info from server

[Biep]

Sometimes message info gets lost, for instance because of local lack of storage. In such cases, after repairing the local problem, the server may not know it has to resend the information. A button or link to tell it so near the error message would be helpful.

[Biep]

@tulir told me:
You should probably specify in the issue that you're talking about decryption keys not being stored because the disk is full, currently it's way too vague.

[t3chguy]

The client has no way of knowing it is missing information as it can't persist that knowledge due to lack of a functioning store.

The button is right there, Clear cache and reload

[t3chguy]

You should probably specify in the issue that you're talking about decryption keys not being stored because the disk is full, currently it's way too vague.

There isn't a way to get those decryption keys again, the server doesn't store them.
You would have to re-ask the other party to send them. Which is #12275

[Biep]

(A) That didn't help for messages originating at other servers. (Though a few hours later one of them did come through spontaneously.)
(B) For the average user, there is no link between the problem and that button. I was asking for something in the error message. "Request keys from your other devices" could have been a button hidden in the setting too, but it isn't (and rightly so).

[t3chguy]

The originating server won't have a copy of the decryption keys either, it is end-to-end encryption.

[Biep]

Well - it ought to have an encrypted version of them, oughtn't it? After all, how could I ever get it otherwise?

[t3chguy]

"Request keys from your other devices"

this is scoped to a single encryption session (which could be as short as to even just be a single event) so it couldn't be in Settings

[t3chguy]

Well - it ought to have an encrypted version of them, oughtn't it? After all, how could I ever get it otherwise?

to_device messages which carry decryption sessions are not kept around, especially on the outbound server.
to_device messages are meant to be delivered once

[Biep]

All right - but a link that effectually repopulates the cache (and if possible does more) at the place of the problem would be very user-friendly.

to_device messages which carry decryption sessions are not kept around, especially on the outbound server.

All right - so that server should ask the sender's client, as soon as it is in the air again? I realise that will be a server issue.

[t3chguy]

so that server should ask the sender's client, as soon as it is in the air again?

This is not something possible in Matrix currently, track #12275

[t3chguy]

but a link that effectually repopulates the cache (and if possible does more) at the place of the problem would be very user-friendly.

Clearing cache won't help you with decryption errors typically so it'd cause additional server load for users clicking it whenever they see it and no benefit most of the time.

[Biep]

Yes, I was thinking of something like a very localised version of #12275 - just getting the keys for this message. Given that they had already been sent to exactly that session, probably no explicit permission would be needed either.

[Biep]

Clearing the whole cache would indeed be overkill - it should be only the bit related to the offending message.

[t3chguy]

The Matrix protocol's sync API doesn't allow such scope. Especially as the protocol won't know which encrypted to_device messages pertain to which encrypted messages.

[Biep]

OK. So it blocks on that. Pity.