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

What is the point of /keys/changes ? #2034

Open
richvdh opened this issue Dec 16, 2024 · 1 comment
Open

What is the point of /keys/changes ? #2034

richvdh opened this issue Dec 16, 2024 · 1 comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@richvdh
Copy link
Member

richvdh commented Dec 16, 2024

Link to problem area:

https://spec.matrix.org/v1.12/client-server-api/#tracking-the-device-list-for-a-user

Issue

The spec says:

Periodically, Alice’s client stores the next_batch field of the result from /sync in persistent storage. If Alice later restarts her client, it can obtain a list of the users who have updated their device list while it was offline by calling /keys/changes, passing the recorded next_batch field as the from parameter. If the client is tracking the device list of any of the users listed in the response, it marks them as outdated. It combines this list with those already flagged as outdated, and initiates a /keys/query request for all of them.

... but won't that return just the same information as calling /sync with the next_batch token (which we will presumably do anyway)?

I don't get it. Which is a particular shame, given I wrote it.

@richvdh richvdh added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Dec 16, 2024
@richvdh
Copy link
Member Author

richvdh commented Dec 16, 2024

oh! I remember!

It's intended for clients which do not persist the other results of /sync (and will therefore be calling /sync without a since token, rather than passing the next_batch token). The client can just cache the device list, and bring it up to date with /keys/changes, rather than doing a complete incremental sync since next_batch.

This could do with clarifying in the spec.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

No branches or pull requests

1 participant