-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Sending a message in a 1:1 E2E room triggers explosion of downloading device keys, which takes minutes #3588
Comments
then, the messages sent, and were received fine, and visible on other devices. however, received messages are UISI:
|
Right; this is (mostly) happening because we don't filter the list of users which /sync tells us have changed their device list and instead just add all listed users to the list of users who are waiting for a device list refresh. It would be easy enough to fix, but I need to rework this code (again) to fix #2305 (again) |
Yet another attempt at fixing element-hq/element-web#2305. This now implements the algorithm described at http://matrix.org/speculator/spec/HEAD/client_server/unstable.html#tracking-the-device-list-for-a-user: * We now keep a flag to tell us which users' device lists we are tracking. That makes it much easier to figure out whether we should care about device-update notifications from /sync (thereby fixing element-hq/element-web#3588). * We use the same flag to indicate whether the device list for a particular user is out of date. Previously we did this implicitly by only updating the stored sync token when the list had been updated, but that was somewhat complicated, and in any case didn't help in cases where we initiated the key download due to a user joining an encrypted room. Also fixes element-hq/element-web#3310.
Yet another attempt at fixing element-hq/element-web#2305. This now implements the algorithm described at http://matrix.org/speculator/spec/HEAD/client_server/unstable.html#tracking-the-device-list-for-a-user: * We now keep a flag to tell us which users' device lists we are tracking. That makes it much easier to figure out whether we should care about device-update notifications from /sync (thereby fixing element-hq/element-web#3588). * We use the same flag to indicate whether the device list for a particular user is out of date. Previously we did this implicitly by only updating the stored sync token when the list had been updated, but that was somewhat complicated, and in any case didn't help in cases where we initiated the key download due to a user joining an encrypted room. Also fixes element-hq/element-web#3310.
Yet another attempt at fixing element-hq/element-web#2305. This now implements the algorithm described at http://matrix.org/speculator/spec/HEAD/client_server/unstable.html#tracking-the-device-list-for-a-user: * We now keep a flag to tell us which users' device lists we are tracking. That makes it much easier to figure out whether we should care about device-update notifications from /sync (thereby fixing element-hq/element-web#3588). * We use the same flag to indicate whether the device list for a particular user is out of date. Previously we did this implicitly by only updating the stored sync token when the list had been updated, but that was somewhat complicated, and in any case didn't help in cases where we initiated the key download due to a user joining an encrypted room. Also fixes element-hq/element-web#3310.
Fixed by matrix-org/matrix-js-sdk#425 |
I just tried to send a msg in an e2e 1:1 with Amandine on /staging (using an instance which has been running fine since Friday, starting with clean local storage). The app then froze for about 50s whilst desperately downloading unrelated keys (from users who can't possibly even be even using E2E).
The text was updated successfully, but these errors were encountered: