-
Notifications
You must be signed in to change notification settings - Fork 186
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
Sliding Sync: Add E2EE extension (MSC3884) #17454
Merged
MadLittleMods
merged 16 commits into
develop
from
madlittlemods/sliding-sync-e2ee-extension
Jul 22, 2024
Merged
Changes from 9 commits
Commits
Show all changes
16 commits
Select commit
Hold shift + click to select a range
97f12a7
Add MSC3884 E2EE extension to Sliding Sync
MadLittleMods 5642b9f
Add changelog
MadLittleMods 3aef282
Add tests
MadLittleMods 43bca3f
Fix lints
MadLittleMods 1aee3a7
Don't require `to` token in this PR
MadLittleMods 6cb8131
No need for copies
MadLittleMods 81dfb72
Fix bool empty logic
MadLittleMods 3d5972f
Merge branch 'develop' into madlittlemods/sliding-sync-e2ee-extension
MadLittleMods 1822a33
To-Device extension already deletes messages
MadLittleMods 63f3287
Merge branch 'develop' into madlittlemods/sliding-sync-e2ee-extension
MadLittleMods 9a4e2ed
Add test for false-positive new results
MadLittleMods 4704f44
Rename extension response functions
MadLittleMods 94390ff
Use simple wake-up
MadLittleMods 2cfecae
More robust `_bump_notifier_wait_for_events(...)`
MadLittleMods 9043180
Add test to make sure we return when we have e2ee data
MadLittleMods d48fab2
Add wait tests for other sections
MadLittleMods File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
Add E2EE extension support to experimental [MSC3575](https://github.com/matrix-org/matrix-spec-proposals/pull/3575) Sliding Sync `/sync` endpoint. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As an aside to this PR: Why is
device_one_time_keys_count
/device_unused_fallback_key_types
information necessary here?If we assume the device uploading the keys, is the same device specified for the keys, then we could assume they already know about their own keys. I think this is the case because the spec says "The ID of the device these keys belong to. Must match the device ID used when logging in.". And they get the count, etc in the upload response.
If not, it seems like
notifier.wait_for_events(user_id)
should trigger when weupload_keys_for_user(user_id, device_id)
because this would affect thedevice_one_time_keys_count
/device_unused_fallback_key_types
fields in the sync response.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For one time keys and fallback keys other devices can take/use them, and so the requesting device needs to upload more keys in that case. See https://spec.matrix.org/v1.11/client-server-api/#one-time-and-fallback-keys
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really seeing where other devices upload keys for another device. Can you point out the specific language and endpoint that someone would do that?
If that's the case, it seems like we need to update
notifier.wait_for_events(user_id)
to inform when new keys are uploaded.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The flow is: 1) your device uploads, say, 50 OTKs (one-time-keys), 2) another device takes one or more, 3) your device gets told that some of the keys have been taken, 4) your device uploads more OTKs.
So this mechanism in sync is to inform your device when another device has claimed some keys, so that you can upload more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for explaining!
I've created #17474 to track updating
notifier.wait_for_events(user_id)