wholetrans/docs-matrix-spec
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

add in-room m.key.verification.request msgtype

Browse source
This commit is contained in:
Hubert Chathi 2022-10-04 17:49:36 -04:00
parent 1cdfbd3cd8
commit 191450ea73
6 changed files with 104 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

15
content/client-server-api/modules/end_to_end_encryption.md
View file

@ -434,11 +434,14 @@ shared by the other messages of that session.
In general, verification operates as follows:
- Alice requests a key verification with Bob by sending an
`m.key.verification.request` event. 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.)
- Alice requests a key verification with Bob by sending an 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
to-device messaging, this will be an event with type
`m.key.verification.request`. 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.
This event indicates the verification methods, corresponding to the
@ -562,6 +565,8 @@ in this specification must be under the `m.key.verification` namespace
and any other event types must be namespaced according to the Java
package naming convention.
{{% event event="m.room.message$m.key.verification.request" %}}
{{% event event="m.key.verification.request" %}}
{{% event event="m.key.verification.ready" %}}

4
content/client-server-api/modules/instant_messaging.md
View file

@ -29,8 +29,8 @@ optional keys, as outlined below. If a client cannot display the given
instead.
Some message types support HTML in the event content that clients should
prefer to display if available. Currently `m.text`, `m.emote`, and
`m.notice` support an additional `format` parameter of
prefer to display if available. Currently `m.text`, `m.emote`, `m.notice`,
and `m.key.verification.request` support an additional `format` parameter of
`org.matrix.custom.html`. When this field is present, a `formatted_body`
with the HTML must be provided. The plain text version of the HTML
should be provided in the `body`.