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

Fix ASCII diagrams

Browse source
This commit is contained in:
Will 2021-01-19 16:41:28 -08:00
parent 55aed1d296
commit 6c6bd57ebf
No known key found for this signature in database
GPG key ID: 385872BB265E8BF8
11 changed files with 178 additions and 126 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -18,34 +18,40 @@ exchange fingerprints between users to build a web of trust.
##### Overview
1) Bob publishes the public keys and supported algorithms for his
device. This may include long-term identity keys, and/or one-time
keys.
1) Bob publishes the public keys and supported algorithms for his
device. This may include long-term identity keys, and/or one-time
keys.
+----------+ +--------------+
| Bob's HS | | Bob's Device |
+----------+ +--------------+
| |
|<=============|
/keys/upload
```
+----------+ +--------------+
| Bob's HS | | Bob's Device |
+----------+ +--------------+
| |
|<=============|
/keys/upload
```
2) Alice requests Bob's public identity keys and supported algorithms.
2) Alice requests Bob's public identity keys and supported algorithms.
```
+----------------+ +------------+ +----------+
| Alice's Device | | Alice's HS | | Bob's HS |
+----------------+ +------------+ +----------+
| | |
|=================>|==============>|
/keys/query <federation>
```
3) Alice selects an algorithm and claims any one-time keys needed.
3) Alice selects an algorithm and claims any one-time keys needed.
```
+----------------+ +------------+ +----------+
| Alice's Device | | Alice's HS | | Bob's HS |
+----------------+ +------------+ +----------+
| | |
|=================>|==============>|
/keys/claim <federation>
```
##### Key algorithms
@ -452,6 +458,7 @@ request, and Alice's second device initiates the request. Note how
Alice's first device is not involved in the request or verification
process.
```
+---------------+ +---------------+ +-------------+ +-------------+
| AliceDevice1 | | AliceDevice2 | | BobDevice1 | | BobDevice2 |
+---------------+ +---------------+ +-------------+ +-------------+
@ -468,6 +475,7 @@ process.
| | m.key.verification.cancel | |
| |-------------------------------------------------->|
| | | |
```
After the handshake, the verification process begins.
@ -571,6 +579,7 @@ The process between Alice and Bob verifying each other would be:
The wire protocol looks like the following between Alice and Bob's
devices:
```
+-------------+ +-----------+
| AliceDevice | | BobDevice |
+-------------+ +-----------+
@ -593,6 +602,7 @@ devices:
| m.key.verification.mac |
|<--------------------------------|
| |
```
###### Error and exception handling
@ -805,6 +815,7 @@ she can trust Bob's device if:
The following diagram illustrates how keys are signed:
```
+------------------+ .................. +----------------+
| +--------------+ | .................. : | +------------+ |
| | v v v : : v v v | |
@ -825,6 +836,7 @@ The following diagram illustrates how keys are signed:
| | | ... | | ... | | |
| +------+ | | +----+ |
+----------------+ +--------------+
```
In the diagram, boxes represent keys and lines represent signatures with
the arrows pointing from the signing key to the key being signed. Dotted
@ -834,6 +846,7 @@ the user who created them.
The following diagram illustrates Alice's view, hiding the keys and
signatures that she cannot see:
```
+------------------+ +----------------+ +----------------+
| +--------------+ | | | | +------------+ |
| | v v | v v v | |
@ -854,6 +867,7 @@ signatures that she cannot see:
| | | ... | | ... | | |
| +------+ | | +----+ |
+----------------+ +--------------+
```
[Verification methods](#device-verification) can be used to verify a
user's master key by using the master public key, encoded using unpadded

39
content/client-server-api/modules/push.md
View file

@ -5,26 +5,27 @@ weight: 130
### Push Notifications
+--------------------+ +-------------------+
Matrix HTTP | | | |
Notification Protocol | App Developer | | Device Vendor |
| | | |
+-------------------+ | +----------------+ | | +---------------+ |
| | | | | | | | | |
| Matrix homeserver +-----> Push Gateway +------> Push Provider | |
| | | | | | | | | |
+-^-----------------+ | +----------------+ | | +----+----------+ |
| | | | | |
```
+--------------------+ +-------------------+
Matrix HTTP | | | |
Notification Protocol | App Developer | | Device Vendor |
| | | |
+-------------------+ | +----------------+ | | +---------------+ |
| | | | | | | | | |
| Matrix homeserver +-----> Push Gateway +------> Push Provider | |
| | | | | | | | | |
+-^-----------------+ | +----------------+ | | +----+----------+ |
| | | | | |
Matrix | | | | | |
Client/Server API + | | | | |
| | +--------------------+ +-------------------+
| +--+-+ |
| | <-------------------------------------------+
+---+ |
| | Provider Push Protocol
+----+
Mobile Device or Client
Client/Server API + | | | | |
| | +--------------------+ +-------------------+
| +--+-+ |
| | <-------------------------------------------+
+---+ |
| | Provider Push Protocol
+----+
Mobile Device or Client
```
This module adds support for push notifications. Homeservers send
notifications of events to user-configured HTTP endpoints. Users may

2
content/client-server-api/modules/sso_login.md
View file

@ -64,6 +64,7 @@ opening an embedded web view.
These steps are illustrated as follows:
```
Matrix Client Matrix Homeserver Auth Server
| | |
|-------------(0) GET /login----------->| |
@ -82,6 +83,7 @@ These steps are illustrated as follows:
| | |
|---(5) POST /login with login token--->| |
|<-------------access token-------------| |
```
Note

6
content/client-server-api/modules/third_party_invites.md
View file

@ -46,6 +46,7 @@ third party identifier with the provided identity server. If the lookup
yields a result for a Matrix User ID then the normal invite process can
be initiated. This process ends up looking like this:
```
+---------+ +-------------+ +-----------------+
| Client | | Homeserver | | IdentityServer |
+---------+ +-------------+ +-----------------+
@ -67,12 +68,14 @@ be initiated. This process ends up looking like this:
| Complete the /invite request | |
|<------------------------------------| |
| | |
```
However, if the lookup does not yield a bound User ID, the homeserver
must store the invite on the identity server and emit a valid
`m.room.third_party_invite` event to the room. This process ends up
looking like this:
```
+---------+ +-------------+ +-----------------+
| Client | | Homeserver | | IdentityServer |
+---------+ +-------------+ +-----------------+
@ -100,6 +103,7 @@ looking like this:
| Complete the /invite request | |
|<------------------------------------| |
| | |
```
All homeservers MUST verify the signature in the event's
`content.third_party_invite.signed` object.
@ -127,6 +131,7 @@ and an identity server IS, the full sequence for a third party invite
would look like the following. This diagram assumes H1 and H2 are
residents of the room while H3 is attempting to join.
```
+-------+ +-----------------+ +-----+ +-----+ +-----+ +-----+
| UserA | | ThirdPartyUser | | H1 | | H2 | | H3 | | IS |
+-------+ +-----------------+ +-----+ +-----+ +-----+ +-----+
@ -181,6 +186,7 @@ residents of the room while H3 is attempting to join.
| | | | | | |
| | | | |<----------------------- |
| | | | | |
```
Note that when H1 sends the `m.room.member` event to H2 and H3 it does
not have to block on either server's receipt of the event. Likewise, H1

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

@ -21,6 +21,7 @@ send call events to rooms with exactly two participants.
A call is set up with message events exchanged as follows:
```
Caller Callee
[Place Call]
m.call.invite ----------->
@ -30,15 +31,18 @@ A call is set up with message events exchanged as follows:
<--------------- m.call.answer
[Call is active and ongoing]
<--------------- m.call.hangup
```
Or a rejected call:
```
Caller Callee
m.call.invite ------------>
m.call.candidate --------->
[..candidates..] --------->
[Rejects call]
<-------------- m.call.hangup
```
Calls are negotiated according to the WebRTC specification.