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

Rework device list tracking logic #425

Merged
merged 1 commit into from
Apr 25, 2017
Merged

Rework device list tracking logic #425

merged 1 commit into from
Apr 25, 2017

Conversation

richvdh
Copy link
Member

@richvdh richvdh commented Apr 25, 2017

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 Sending a message in a 1:1 E2E room triggers explosion of downloading device keys, which takes minutes 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.

@richvdh
Copy link
Member Author

richvdh commented Apr 25, 2017

(should also indirectly help with element-hq/element-web#3660, since it will mean we are less likely to fill up the localstorage for device lists we don't care about)

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.
@NegativeMjark
Copy link
Contributor

There's a lot of console.log being added. I assume it's there for debugging unknown session/key errors in the wild.

Copy link
Contributor

@NegativeMjark NegativeMjark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this LGTM?

@richvdh
Copy link
Member Author

richvdh commented Apr 25, 2017

There's a lot of console.log being added. I assume it's there for debugging unknown session/key errors in the wild.

well, I'm not sure it's a lot - most of them are just being moved around. But yeah, it's basically to try to debug uisis.

@richvdh
Copy link
Member Author

richvdh commented May 5, 2017

Now amended by #431.

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 this pull request may close these issues.

Opening MemberInfo starts a download of many users' keys
2 participants