-
-
Notifications
You must be signed in to change notification settings - Fork 589
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
Support MSC2366 (m.key.verification.ready event) #1110
Closed
Closed
Conversation
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
bwindels
changed the title
Support MSC2366 (
Support MSC2366 (m.key.verification.ready event)
Dec 10, 2019
m.key.verification.ready
event)
bwindels
force-pushed
the
bwindels/verification-ready
branch
from
December 10, 2019 11:14
34f0ffe
to
8b9ed28
Compare
bwindels
force-pushed
the
bwindels/verification-ready
branch
from
December 19, 2019 12:06
b49b3b5
to
9a95c1a
Compare
as MSC2366 adds an extra interactive step to the verification process, we can't wait for the verifier after sending the request. This is a breaking change in the js-sdk as it changes the return type of an existing method.
so we don't need to import the PHASE_ constants where we need to check
as it's harder to determine the other side of a request, given the in-room code also processes remote echos for own events.
also put logic to block non-participating senders in VerificationRequest so it is shared between both channels. Remote echo's should not be passed to the verifier though.
as once in done, the request is removed from the request map and the second .done event that comes in will not find the request anymore, so the request wouldn't be attached to the event anymore, breaking rendering it in the timeline.
next up is inspecting the .request event to determine it reliably in InRoomChannel
also fail validation with any event not sent by or directed to us
as it doesn't need to happen for ToDeviceChannel
but doesn't work yet? data where liveEvent is fished out is undefined
this makes the verifier want to interact with the other party when just reloading the session.
bwindels
force-pushed
the
bwindels/verification-ready
branch
from
January 3, 2020 12:53
437df0f
to
3ec8233
Compare
rather than the sender and from_device (which is not always set) as this was one of the things breaking to_device verification of ones own devices.
this was one of the things breaking to_device verification
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Based off #1109
MSC: https://github.com/uhoreg/matrix-doc/blob/key_verification_accept/proposals/2366-key-verification-accept.md
Part of element-hq/element-web#11224