Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-28 22:14:10 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

fixup! e2ee/device verification: normalize all links

Browse source 
Signed-off-by: Sumner Evans <sumner.evans@automattic.com>
This commit is contained in:
Sumner Evans 2024-06-07 11:31:58 -06:00
parent 4282a1a319
commit a9350fcc41
No known key found for this signature in database
4 changed files with 26 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

22
data/event-schemas/schema/m.key.verification.cancel.yaml
View file

@ -31,17 +31,19 @@ properties:
* `m.user`: The user cancelled the verification. * `m.user`: The user cancelled the verification.
* `m.timeout`: The verification process timed out. Verification processes * `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 * `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 * `m.unknown_method`: The device does not know how to handle the
method. This should be sent for `m.key.verification.start` messages and requested method. This should be sent for
messages defined by individual verification processes. [`m.key.verification.start`](#mkeyverificationstart) messages and
messages defined by individual verification processes.
* `m.unexpected_message`: The device received an unexpected message. Typically * `m.unexpected_message`: The device received an unexpected message.
raised when one of the parties is handling the verification out of order. Typically raised when one of the parties is handling the
verification out of order.
* `m.key_mismatch`: The key was not verified. * `m.key_mismatch`: The key was not verified.
@ -49,8 +51,10 @@ properties:
* `m.invalid_message`: The message received was invalid. * `m.invalid_message`: The message received was invalid.
* `m.accepted`: A `m.key.verification.request` was accepted by a different * `m.accepted`: A
device. The device receiving this error can ignore the verification request. [`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 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 an incorrect message and the client returns `m.invalid_message` to which it

11
data/event-schemas/schema/m.key.verification.m.relates_to.yaml
View file

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

8
data/event-schemas/schema/m.key.verification.ready.yaml
View file

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

5
data/event-schemas/schema/m.key.verification.request.yaml
View file

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