|
|
@ -25,9 +25,9 @@ or an in-room event.
|
|
|
|
After the `m.key.verification.accept` event is sent, either party can send an
|
|
|
|
After the `m.key.verification.accept` event is sent, either party can send an
|
|
|
|
`m.key.verification.start` event to begin the verification. If both parties
|
|
|
|
`m.key.verification.start` event to begin the verification. If both parties
|
|
|
|
send an `m.key.verification.start` event, and they both specify the same
|
|
|
|
send an `m.key.verification.start` event, and they both specify the same
|
|
|
|
verification method, then the event sent by the user whose ID is the smallest
|
|
|
|
verification method, then the event sent by the user whose user ID is the
|
|
|
|
is used, and the event sent by the user whose ID is the largest is ignored. In
|
|
|
|
smallest is used, and the other `m.key.verification.start` event is ignored.
|
|
|
|
the case of a single user verifying two of their devices, the device ID is
|
|
|
|
In the case of a single user verifying two of their devices, the device ID is
|
|
|
|
compared instead. If both parties send an `m.key.verification.start` event,
|
|
|
|
compared instead. If both parties send an `m.key.verification.start` event,
|
|
|
|
but they specify different verification methods, the verification should be
|
|
|
|
but they specify different verification methods, the verification should be
|
|
|
|
cancelled with a `code` of `m.unexpected_message`.
|
|
|
|
cancelled with a `code` of `m.unexpected_message`.
|
|
|
|