Fix broken Markdown lists

pull/2980/head
Will 3 years ago
parent 02a41edc76
commit f0a4f59bb0
No known key found for this signature in database
GPG Key ID: 385872BB265E8BF8

@ -666,36 +666,36 @@ supplied as the input keying material. No salt is used. When the
`key_agreement_protocol` is `curve25519-hkdf-sha256`, the info parameter
is the concatenation of:
> - The string `MATRIX_KEY_VERIFICATION_SAS|`.
> - The Matrix ID of the user who sent the `m.key.verification.start`
> message, followed by `|`.
> - The Device ID of the device which sent the
> `m.key.verification.start` message, followed by `|`.
> - The public key from the `m.key.verification.key` message sent by
> the device which sent the `m.key.verification.start` message,
> followed by `|`.
> - The Matrix ID of the user who sent the `m.key.verification.accept`
> message, followed by `|`.
> - The Device ID of the device which sent the
> `m.key.verification.accept` message, followed by `|`.
> - The public key from the `m.key.verification.key` message sent by
> the device which sent the `m.key.verification.accept` message,
> followed by `|`.
> - The `transaction_id` being used.
- The string `MATRIX_KEY_VERIFICATION_SAS|`.
- The Matrix ID of the user who sent the `m.key.verification.start`
message, followed by `|`.
- The Device ID of the device which sent the
`m.key.verification.start` message, followed by `|`.
- The public key from the `m.key.verification.key` message sent by
the device which sent the `m.key.verification.start` message,
followed by `|`.
- The Matrix ID of the user who sent the `m.key.verification.accept`
message, followed by `|`.
- The Device ID of the device which sent the
`m.key.verification.accept` message, followed by `|`.
- The public key from the `m.key.verification.key` message sent by
the device which sent the `m.key.verification.accept` message,
followed by `|`.
- The `transaction_id` being used.
When the `key_agreement_protocol` is the deprecated method `curve25519`,
the info parameter is the concatenation of:
> - The string `MATRIX_KEY_VERIFICATION_SAS`.
> - The Matrix ID of the user who sent the `m.key.verification.start`
> message.
> - The Device ID of the device which sent the
> `m.key.verification.start` message.
> - The Matrix ID of the user who sent the `m.key.verification.accept`
> message.
> - The Device ID of the device which sent the
> `m.key.verification.accept` message.
> - The `transaction_id` being used.
- The string `MATRIX_KEY_VERIFICATION_SAS`.
- The Matrix ID of the user who sent the `m.key.verification.start`
message.
- The Device ID of the device which sent the
`m.key.verification.start` message.
- The Matrix ID of the user who sent the `m.key.verification.accept`
message.
- The Device ID of the device which sent the
`m.key.verification.accept` message.
- The `transaction_id` being used.
New implementations are discouraged from implementing the `curve25519`
method.
@ -710,14 +710,14 @@ For verification of each party's device keys, HKDF is as defined in RFC
supplied as the input keying material. No salt is used, and in the info
parameter is the concatenation of:
> - The string `MATRIX_KEY_VERIFICATION_MAC`.
> - The Matrix ID of the user whose key is being MAC-ed.
> - The Device ID of the device sending the MAC.
> - The Matrix ID of the other user.
> - The Device ID of the device receiving the MAC.
> - The `transaction_id` being used.
> - The Key ID of the key being MAC-ed, or the string `KEY_IDS` if the
> item being MAC-ed is the list of key IDs.
- The string `MATRIX_KEY_VERIFICATION_MAC`.
- The Matrix ID of the user whose key is being MAC-ed.
- The Device ID of the device sending the MAC.
- The Matrix ID of the other user.
- The Device ID of the device receiving the MAC.
- The `transaction_id` being used.
- The Key ID of the key being MAC-ed, or the string `KEY_IDS` if the
item being MAC-ed is the list of key IDs.
###### SAS method: `decimal`

@ -14,13 +14,13 @@ This module allows a Matrix homeserver to delegate user authentication
to an external authentication server supporting one of these protocols.
In this process, there are three systems involved:
> - A Matrix client, using the APIs defined this specification, which
> is seeking to authenticate a user to a Matrix homeserver.
> - A Matrix homeserver, implementing the APIs defined in this
> specification, but which is delegating user authentication to the
> authentication server.
> - An "authentication server", which is responsible for
> authenticating the user.
- A Matrix client, using the APIs defined this specification, which
is seeking to authenticate a user to a Matrix homeserver.
- A Matrix homeserver, implementing the APIs defined in this
specification, but which is delegating user authentication to the
authentication server.
- An "authentication server", which is responsible for
authenticating the user.
This specification is concerned only with communication between the
Matrix client and the homeserver, and is independent of the SSO protocol

@ -431,13 +431,13 @@ the following subset of the room state:
- If type is `m.room.member`:
> - The target's current `m.room.member` event, if any.
> - If `membership` is `join` or `invite`, the current
> `m.room.join_rules` event, if any.
> - If membership is `invite` and `content` contains a
> `third_party_invite` property, the current
> `m.room.third_party_invite` event with `state_key` matching
> `content.third_party_invite.signed.token`, if any.
- The target's current `m.room.member` event, if any.
- If `membership` is `join` or `invite`, the current
`m.room.join_rules` event, if any.
- If membership is `invite` and `content` contains a
`third_party_invite` property, the current
`m.room.third_party_invite` event with `state_key` matching
`content.third_party_invite.signed.token`, if any.
#### Rejection

Loading…
Cancel
Save