-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gracefully recover from wedged session (discard session for next distribution, or reshare as m.room.key) #1992
Comments
@pmaier1 I'm not really sure what's to be done here. We already have recovery from wedged olm sessions. Can you explain what precise scenario we're trying to cover here? |
Well, to my understanding there still are cases where a user has to manually type |
Hrm. Generally I'd say we should figure out what cases a Any idea what those cases are? |
We only expect to see this when clients or servers need to rollback their database. There are other cases where |
The solution to this ticket is supposed to also solve #2155. |
We think this would be usefull for robustness. But for now we focus efforts on finding root causes of wedging |
It isn't made explicit anywhere above: I believe the intention of this issue is to improve the current olm session recovery: the current implementation does nothing to help with Olm messages that have already been sent. (Which is why As a recipient, if we detect a wedged olm session (which causes us to make a new olm session), we need to tell the sender about the situation so that they know they still need to send us the key. Ideally, the sender needs to send us all megolm keys they already tried to send, but at the very least they need to mark all existing keys as "not yet shared with this device". |
As a partial solution to this, we could not worry about past messages, but at least improve the situation for future messages. Currently: the olm-session unwedging doesn't help with existing megolm sessions until the sending user does a Instead we could:
|
I have split this out to #2389. |
Some more context for the record. |
I asked some questions about how we recover from wedged Olm sessions. The purpose of sending an
There are potentially problems around this mechanism though. Rust SDK seems to not follow the spec which says:
It seems to use creation time instead. We need to align on which is correct. In addition, vdh points out that client session timestamps have been corrupted so we likely need to consider that too. In all cases, recovering from a wedged OIm session involves a new |
Crosslink matrix-org/matrix-rust-sdk#3356 |
High Level:
Explore a way to (selectively!) re-request encryption keys to increase crypto reliability.
Given that olm session can get wedged, could it be possible find a way to recover from that: i.e be able to get back the failed to decrypt message.
IT IS NOT the re-implementation of key-requesting that was terrible (creating a lot of traffic and slowing down everything)
Scenario:
m.room_key
(not a forwarded key)The recipient would send the to_device failed to decrypt ack only to the exact sender of the to device! (different from key requesting that would ask to all the current user devices)
The text was updated successfully, but these errors were encountered: