fixup! e2ee/device verification: normalize all links

Signed-off-by: Sumner Evans <sumner.evans@automattic.com>
pull/1830/head
Sumner Evans 6 months ago
parent 4282a1a319
commit a9350fcc41
No known key found for this signature in database

@ -31,17 +31,19 @@ properties:
* `m.user`: The user cancelled the verification.
* `m.timeout`: The verification process timed out. Verification processes
can define their own timeout parameters.
can define their own timeout parameters.
* `m.unknown_transaction`: The device does not know about the given transaction
ID.
ID.
* `m.unknown_method`: The device does not know how to handle the requested
method. This should be sent for `m.key.verification.start` messages and
messages defined by individual verification processes.
* `m.unknown_method`: The device does not know how to handle the
requested method. This should be sent for
[`m.key.verification.start`](#mkeyverificationstart) messages and
messages defined by individual verification processes.
* `m.unexpected_message`: The device received an unexpected message. Typically
raised when one of the parties is handling the verification out of order.
* `m.unexpected_message`: The device received an unexpected message.
Typically raised when one of the parties is handling the
verification out of order.
* `m.key_mismatch`: The key was not verified.
@ -49,8 +51,10 @@ properties:
* `m.invalid_message`: The message received was invalid.
* `m.accepted`: A `m.key.verification.request` was accepted by a different
device. The device receiving this error can ignore the verification request.
* `m.accepted`: A
[`m.key.verification.request`](#mkeyverificationrequest) was
accepted by a different device. The device receiving this error can
ignore the verification request.
Clients should be careful to avoid error loops. For example, if a device sends
an incorrect message and the client returns `m.invalid_message` to which it

@ -1,9 +1,9 @@
---
description: |-
Required when sent as an in-room message. Indicates the
`m.key.verification.request` that this message is related to. Note that for
encrypted messages, this property should be in the unencrypted portion of the
event.
[`m.key.verification.request`](#mkeyverificationrequest) that this message is
related to. Note that for encrypted messages, this property should be in the
unencrypted portion of the event.
properties:
rel_type:
type: string
@ -15,7 +15,8 @@ properties:
event_id:
type: string
description: |-
The event ID of the `m.key.verification.request` that this message is
related to.
The event ID of the
[`m.key.verification.request`](#mkeyverificationrequest) that this
message is related to.
type: object
title: VerificationRelatesTo

@ -4,7 +4,7 @@ allOf:
description: |-
Accepts a key verification request. Sent in response to an
`m.key.verification.request` event.
[`m.key.verification.request`](#mkeyverificationrequest) event.
properties:
content:
properties:
@ -16,14 +16,14 @@ properties:
type: string
description: |-
Required when sent as a to-device message. The transaction ID of the
verification request, as given in the `m.key.verification.request`
message.
verification request, as given in the
[`m.key.verification.request`](#mkeyverificationrequest) message.
methods:
type: array
description: |-
The verification methods supported by the sender, corresponding to
the verification methods indicated in the
`m.key.verification.request` message.
[`m.key.verification.request`](#mkeyverificationrequest) message.
items:
type: string
m.relates_to:

@ -4,8 +4,9 @@ allOf:
description: |-
Requests a key verification using to-device messaging. When requesting a key
verification in a room, a `m.room.message` should be used, with
[`m.key.verification.request`](#mroommessagemkeyverificationrequest) as msgtype.
verification in a room, a [`m.room.message`](#mroommessage should be used,
with [`m.key.verification.request`](#mroommessagemkeyverificationrequest) as
msgtype.
properties:
content:
properties:

Loading…
Cancel
Save