Skip to content
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

Historical messages decrypt on cache reloading, but not before #3768

Closed
Tracked by #245
richvdh opened this issue Jul 26, 2024 · 3 comments · Fixed by #3964
Closed
Tracked by #245

Historical messages decrypt on cache reloading, but not before #3768

richvdh opened this issue Jul 26, 2024 · 3 comments · Fixed by #3964
Assignees

Comments

@richvdh
Copy link
Member

richvdh commented Jul 26, 2024

Steps to reproduce

Sign into a new instance of Element X
Verify your device
Open some chats with historic E2EE message, those messages can appear as UTDs
Clear EX cache in developer settings
All historic messages are now decrypted properly

Outcome

What did you expect?

Historic messages decrypt successfully, and are displayed as such, without having to cache reload.

What happened instead?

Historic messages that are shown as UTDs in the timeline seem stuck that way indefinitely. It could be that the keys are being downloaded or processed at the same time as a user trying to open the message, EX is unable to show the message and presents it as a UTD, and subsequently doesn't attempt to decrypt the message again in future.

@richvdh
Copy link
Member Author

richvdh commented Jul 26, 2024

This is tracked on the EXA and EXI repos as element-hq/element-x-android#3234 and element-hq/element-x-ios#3055 respectively

@manuroe
Copy link
Contributor

manuroe commented Jul 26, 2024

If the user paginates in the room, the received paginated messages get decrypted in the timeline. The 20-30 last messages on the room stay UTDs but previous messages are decrypted.

Since client side sorting, we have a mechanism to prefill the room timeline from the room list by subscribing to each displayed rooms. The decryption retries may fail in this condition or they succeed but we fail to notify the UI of the timeline.

@poljar
Copy link
Contributor

poljar commented Jul 26, 2024

I think it's rather that events are received before the backup becomes active, and the timeline doesn't listen for the backup becoming active.

It should listen to the backup becoming active and retry the decryption of all events, since we download room keys on demand, i.e. when we fail to decrypt a event.

Relevant code should be here:

let room_key_from_backups_join_handle = {
let inner = inner.clone();
let room_id = inner.room().room_id();
let stream = client.encryption().backups().room_keys_for_room_stream(room_id);
spawn(async move {
pin_mut!(stream);
while let Some(update) = stream.next().await {
let room = inner.room();
match update {
Ok(info) => {
let mut session_ids = BTreeSet::new();
for set in info.into_values() {
session_ids.extend(set);
}
inner.retry_event_decryption(room, Some(session_ids)).await;
}
// We lagged, so retry every event.
Err(_) => inner.retry_event_decryption(room, None).await,
}
}
})
};

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants