From f76ff365456ea38d5d0082284e97e13b70221abb Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Wed, 12 Oct 2022 16:32:00 -0400 Subject: [PATCH] add links --- .../modules/end_to_end_encryption.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/content/client-server-api/modules/end_to_end_encryption.md b/content/client-server-api/modules/end_to_end_encryption.md index 6f2d00b2..0fb74931 100644 --- a/content/client-server-api/modules/end_to_end_encryption.md +++ b/content/client-server-api/modules/end_to_end_encryption.md @@ -436,20 +436,20 @@ In general, verification operates as follows: - Alice requests a key verification with Bob by sending a key verification request event. If the verification is being requested in a room, this will - be an event with type `m.room.message` and `msgtype` - `m.key.verification.request`; if the verification is being requested using + be an event with type [`m.room.message` and `msgtype: + m.key.verification.request`](#mroommessagemkeyverificationrequest); if the verification is being requested using to-device messaging, this will be an event with type - `m.key.verification.request`. This event indicates the verification methods + [`m.key.verification.request`](#mkeyverificationrequest). This event indicates the verification methods that Alice's client supports. (Note that "Alice" and "Bob" may in fact be the same user, in the case where a user is verifying their own devices.) - Bob's client prompts Bob to accept the key verification. When Bob accepts - the verification, Bob's client sends an `m.key.verification.ready` event. + the verification, Bob's client sends an [`m.key.verification.ready`](#mkeyverificationready) event. This event indicates the verification methods, corresponding to the verification methods supported by Alice's client, that Bob's client supports. - Alice's or Bob's devices allow their users to select one of the verification methods supported by both devices to use for verification. When Alice or Bob selects a verification method, their device begins the verification by - sending an `m.key.verification.start` event, indicating the selected + sending an [`m.key.verification.start`](#mkeyverificationstart) event, indicating the selected verification method. Note that if there is only one verification method in common between the devices then the receiver's device (Bob) can auto-select it. @@ -457,11 +457,11 @@ In general, verification operates as follows: verification method. This could involve their clients exchanging messages, Alice and Bob exchanging information out-of-band, and/or Alice and Bob interacting with their devices. -- Alice's and Bob's clients send `m.key.verification.done` events to indicate +- Alice's and Bob's clients send [`m.key.verification.done`](#mkeyverificationdone) events to indicate that the verification was successful. Verifications can be cancelled by either device at any time by sending an -`m.key.verification.cancel` event with a `code` field that indicates the reason +[`m.key.verification.cancel`](#mkeyverificationcancel) event with a `code` field that indicates the reason it was cancelled. When using to-device messages, Alice may not know which of Bob's devices to