archive
/
matrix-spec
mirror of https://github.com/matrix-org/matrix-spec
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add fonts, circumvent docsy's built-in katex support and limit CSP relaxation

Browse Source
pull/2226/head
Johannes Marbach 2 months ago
parent 2cbda923c8
commit 1c86b1d296
42 changed files with 100 additions and 93 deletions
Show Stats Download Patch File Download Diff File

7
assets/scss/_styles_project.scss
Unescape Escape View File

@ -502,6 +502,13 @@ Make padding symmetrical (this selector is used in the default styles to apply p
} }
} }
/* Adjust the width of math to match normal paragraphs */
@include media-breakpoint-up(lg) {
.katex-display {
max-width: 80%;
}
}
/* Adjust default styles for info banner */ /* Adjust default styles for info banner */
.pageinfo-primary { .pageinfo-primary {
@include media-breakpoint-up(lg) { @include media-breakpoint-up(lg) {

5
config/_default/hugo.toml
Unescape Escape View File

@ -47,7 +47,7 @@ description = "Home of the Matrix specification for decentralised communication"
[markup.goldmark.extensions.passthrough] [markup.goldmark.extensions.passthrough]
enable = true enable = true
[markup.goldmark.extensions.passthrough.delimiters] [markup.goldmark.extensions.passthrough.delimiters]
block = [['\[', '\]'], ['$$', '$$']] block = [['\[', '\]']]
inline = [['\(', '\)']] inline = [['\(', '\)']]
[markup.highlight] [markup.highlight]
# See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html # See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html
@ -127,8 +127,7 @@ sidebar_menu_compact = true
[[server.headers]] [[server.headers]]
for = '/**' for = '/**'
[server.headers.values] [server.headers.values]
# TODO: figure out CSP Content-Security-Policy = "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self'; img-src 'self' data:; connect-src 'self'; font-src 'self' data:; media-src 'self'; child-src 'self'; form-action 'self'; object-src 'self'"
# Content-Security-Policy = "default-src 'self'; style-src 'self'; script-src 'self'; img-src 'self' data:; connect-src 'self'; font-src 'self' data:; media-src 'self'; child-src 'self'; form-action 'self'; object-src 'self'"
X-XSS-Protection = "1; mode=block" X-XSS-Protection = "1; mode=block"
X-Content-Type-Options = "nosniff" X-Content-Type-Options = "nosniff"
# Strict-Transport-Security = "max-age=31536000; includeSubDomains; preload" # Strict-Transport-Security = "max-age=31536000; includeSubDomains; preload"

2
content/_index.md
Unescape Escape View File

@ -151,7 +151,7 @@ request.
How data flows between clients: How data flows between clients:
``` ```nohighlight
{ Matrix client A } { Matrix client B } { Matrix client A } { Matrix client B }
^ | ^ | ^ | ^ |
| events | Client-Server API | events | | events | Client-Server API | events |

6
content/appendices.md
Unescape Escape View File

@ -749,13 +749,13 @@ history (a permalink).
The Matrix URI scheme is defined as follows (`[]` enclose optional parts, `{}` The Matrix URI scheme is defined as follows (`[]` enclose optional parts, `{}`
enclose variables): enclose variables):
``` ```nohighlight
matrix:[//{authority}/]{type}/{id without sigil}[/{type}/{id without sigil}...][?{query}][#{fragment}] matrix:[//{authority}/]{type}/{id without sigil}[/{type}/{id without sigil}...][?{query}][#{fragment}]
``` ```
As a schema, this can be represented as: As a schema, this can be represented as:
``` ```nohighlight
MatrixURI = "matrix:" hier-part [ "?" query ] [ "#" fragment ] MatrixURI = "matrix:" hier-part [ "?" query ] [ "#" fragment ]
hier-part = [ "//" authority "/" ] path hier-part = [ "//" authority "/" ] path
path = entity-descriptor ["/" entity-descriptor] path = entity-descriptor ["/" entity-descriptor]
@ -865,7 +865,7 @@ below for more details.
A matrix.to URI has the following format, based upon the specification A matrix.to URI has the following format, based upon the specification
defined in [RFC 3986](https://tools.ietf.org/html/rfc3986): defined in [RFC 3986](https://tools.ietf.org/html/rfc3986):
``` ```nohighlight
https://matrix.to/#/<identifier>/<extra parameter>?<additional arguments> https://matrix.to/#/<identifier>/<extra parameter>?<additional arguments>
``` ```

10
content/application-service-api.md
Unescape Escape View File

@ -178,13 +178,13 @@ The application service API provides a transaction API for sending a
list of events. Each list of events includes a transaction ID, which list of events. Each list of events includes a transaction ID, which
works as follows: works as follows:
``` ```nohighlight
Typical Typical
HS ---> AS : Homeserver sends events with transaction ID T. HS ---> AS : Homeserver sends events with transaction ID T.
<--- : Application Service sends back 200 OK. <--- : Application Service sends back 200 OK.
``` ```
``` ```nohighlight
AS ACK Lost AS ACK Lost
HS ---> AS : Homeserver sends events with transaction ID T. HS ---> AS : Homeserver sends events with transaction ID T.
<-/- : AS 200 OK is lost. <-/- : AS 200 OK is lost.
@ -258,7 +258,7 @@ have been omitted for brevity):
**Typical** **Typical**
``` ```nohighlight
AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"} AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"}
HS ---> AS : /_matrix/app/v1/ping {"transaction_id": "meow"} HS ---> AS : /_matrix/app/v1/ping {"transaction_id": "meow"}
HS <--- AS : 200 OK {} HS <--- AS : 200 OK {}
@ -267,7 +267,7 @@ AS <--- HS : 200 OK {"duration_ms": 123}
**Incorrect `hs_token`** **Incorrect `hs_token`**
``` ```nohighlight
AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"} AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"}
HS ---> AS : /_matrix/app/v1/ping {"transaction_id": "meow"} HS ---> AS : /_matrix/app/v1/ping {"transaction_id": "meow"}
HS <--- AS : 403 Forbidden {"errcode": "M_FORBIDDEN"} HS <--- AS : 403 Forbidden {"errcode": "M_FORBIDDEN"}
@ -276,7 +276,7 @@ AS <--- HS : 502 Bad Gateway {"errcode": "M_BAD_STATUS", "status": 403, "body":
**Can't connect to appservice** **Can't connect to appservice**
``` ```nohighlight
AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"} AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"}
HS -/-> AS : /_matrix/app/v1/ping {"transaction_id": "meow"} HS -/-> AS : /_matrix/app/v1/ping {"transaction_id": "meow"}
AS <--- HS : 502 Bad Gateway {"errcode": "M_CONNECTION_FAILED"} AS <--- HS : 502 Bad Gateway {"errcode": "M_CONNECTION_FAILED"}

60
content/client-server-api/_index.md
Unescape Escape View File

@ -683,7 +683,7 @@ request parameter.
A client should first make a request with no `auth` parameter. A client should first make a request with no `auth` parameter.
The homeserver returns an HTTP 401 response, with a JSON body, as follows: The homeserver returns an HTTP 401 response, with a JSON body, as follows:
``` ```nohighlight
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
Content-Type: application/json Content-Type: application/json
``` ```
@ -729,7 +729,7 @@ given. It also contains other keys dependent on the auth type being
attempted. For example, if the client is attempting to complete auth attempted. For example, if the client is attempting to complete auth
type `example.type.foo`, it might submit something like this: type `example.type.foo`, it might submit something like this:
``` ```nohighlight
POST /_matrix/client/v3/endpoint HTTP/1.1 POST /_matrix/client/v3/endpoint HTTP/1.1
Content-Type: application/json Content-Type: application/json
``` ```
@ -752,7 +752,7 @@ along with the same object as when no authentication was attempted, with
the addition of the `completed` key which is an array of auth types the the addition of the `completed` key which is an array of auth types the
client has completed successfully: client has completed successfully:
``` ```nohighlight
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
Content-Type: application/json Content-Type: application/json
``` ```
@ -786,7 +786,7 @@ but the client may make a second attempt, it returns the same HTTP
status 401 response as above, with the addition of the standard status 401 response as above, with the addition of the standard
`errcode` and `error` fields describing the error. For example: `errcode` and `error` fields describing the error. For example:
``` ```nohighlight
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
Content-Type: application/json Content-Type: application/json
``` ```
@ -816,7 +816,7 @@ Content-Type: application/json
If the request fails for a reason other than authentication, the server If the request fails for a reason other than authentication, the server
returns an error message in the standard format. For example: returns an error message in the standard format. For example:
``` ```nohighlight
HTTP/1.1 400 Bad request HTTP/1.1 400 Bad request
Content-Type: application/json Content-Type: application/json
``` ```
@ -855,7 +855,7 @@ must still give a 401 response to requests with no auth data.
At a high level, the requests made for an API call completing an auth At a high level, the requests made for an API call completing an auth
flow with three stages will resemble the following diagram: flow with three stages will resemble the following diagram:
``` ```nohighlight
_______________________ _______________________
| Stage 0 | | Stage 0 |
| No auth | | No auth |
@ -913,7 +913,7 @@ This specification defines the following auth types:
To use this authentication type, clients should submit an auth dict as To use this authentication type, clients should submit an auth dict as
follows: follows:
``` ```nohighlight
{ {
"type": "m.login.password", "type": "m.login.password",
"identifier": { "identifier": {
@ -1163,7 +1163,7 @@ user during registration, if applicable.
1. A client might submit a registration request as follows: 1. A client might submit a registration request as follows:
``` ```nohighlight
POST /_matrix/client/v3/register POST /_matrix/client/v3/register
``` ```
```json ```json
@ -1176,7 +1176,7 @@ user during registration, if applicable.
2. The server requires the user to accept some terms of service before 2. The server requires the user to accept some terms of service before
registration, so returns the following response: registration, so returns the following response:
``` ```nohighlight
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
Content-Type: application/json Content-Type: application/json
``` ```
@ -1211,7 +1211,7 @@ user during registration, if applicable.
4. The client repeats the registration request, confirming that the user has 4. The client repeats the registration request, confirming that the user has
accepted the documents: accepted the documents:
``` ```nohighlight
POST /_matrix/client/v3/register POST /_matrix/client/v3/register
``` ```
```json ```json
@ -1226,7 +1226,7 @@ user during registration, if applicable.
``` ```
5. All authentication steps have now completed, so the request is successful: 5. All authentication steps have now completed, so the request is successful:
``` ```nohighlight
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/json Content-Type: application/json
``` ```
@ -1647,7 +1647,7 @@ This authorization request URL must be opened in the user's browser:
Sample authorization request, with extra whitespaces for readability: Sample authorization request, with extra whitespaces for readability:
``` ```nohighlight
https://account.example.com/oauth2/auth? https://account.example.com/oauth2/auth?
client_id = s6BhdRkqt3 & client_id = s6BhdRkqt3 &
response_type = code & response_type = code &
@ -1680,7 +1680,7 @@ used in the authorization request.
A successful authorization will have a `code` value, for example: A successful authorization will have a `code` value, for example:
``` ```nohighlight
https://app.example.com/oauth2-callback#state=ewubooN9weezeewah9fol4oothohroh3&code=iuB7Eiz9heengah1joh2ioy9ahChuP6R https://app.example.com/oauth2-callback#state=ewubooN9weezeewah9fol4oothohroh3&code=iuB7Eiz9heengah1joh2ioy9ahChuP6R
``` ```
@ -1692,7 +1692,7 @@ A failed authorization will have the following values:
For example: For example:
``` ```nohighlight
https://app.example.com/oauth2-callback#state=ewubooN9weezeewah9fol4oothohroh3&error=access_denied&error_description=The+resource+owner+or+authorization+server+denied+the+request.&error_uri=https%3A%2F%2Ferrors.example.com%2F https://app.example.com/oauth2-callback#state=ewubooN9weezeewah9fol4oothohroh3&error=access_denied&error_description=The+resource+owner+or+authorization+server+denied+the+request.&error_uri=https%3A%2F%2Ferrors.example.com%2F
``` ```
@ -1717,7 +1717,7 @@ type, the expiration time, and the refresh token.
Sample token request: Sample token request:
``` ```nohighlight
POST /oauth2/token HTTP/1.1 POST /oauth2/token HTTP/1.1
Host: account.example.com Host: account.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
@ -2040,7 +2040,7 @@ When generating a new `device_id`, the client SHOULD generate a random string
with enough entropy. It SHOULD only use characters from the unreserved character with enough entropy. It SHOULD only use characters from the unreserved character
list defined by [RFC 3986 section 2.3](https://datatracker.ietf.org/doc/html/rfc3986#section-2.3): list defined by [RFC 3986 section 2.3](https://datatracker.ietf.org/doc/html/rfc3986#section-2.3):
``` ```nohighlight
unreserved = a-z / A-Z / 0-9 / "-" / "." / "_" / "~" unreserved = a-z / A-Z / 0-9 / "-" / "." / "_" / "~"
``` ```
@ -2053,7 +2053,7 @@ In any case it MUST only use characters allowed by the OAuth 2.0 scope
definition in [RFC 6749 section 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3), definition in [RFC 6749 section 3.3](https://datatracker.ietf.org/doc/html/rfc6749#section-3.3),
which is defined as the following ASCII ranges: which is defined as the following ASCII ranges:
``` ```nohighlight
%x21 / %x23-5B / %x5D-7E %x21 / %x23-5B / %x5D-7E
``` ```
@ -2195,7 +2195,7 @@ The body of the request includes the following parameters, encoded as
For example, revoking using the access token: For example, revoking using the access token:
``` ```nohighlight
POST /oauth2/revoke HTTP/1.1 POST /oauth2/revoke HTTP/1.1
Host: auth.example.com Host: auth.example.com
Content-Type: application/x-www-form-urlencoded Content-Type: application/x-www-form-urlencoded
@ -2240,7 +2240,7 @@ set to `true` on all but the following Client-Server APIs:
Servers MAY additionally include details of why the lock was applied in Servers MAY additionally include details of why the lock was applied in
the `error` field. the `error` field.
``` ```nohighlight
HTTP/1.1 401 Unauthorized HTTP/1.1 401 Unauthorized
Content-Type: application/json Content-Type: application/json
``` ```
@ -2320,7 +2320,7 @@ When a client attempts to perform an action while suspended, the server MUST
respond with a `403 Forbidden` error response with `M_USER_SUSPENDED` as the respond with a `403 Forbidden` error response with `M_USER_SUSPENDED` as the
error code, as shown below: error code, as shown below:
``` ```nohighlight
HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden
Content-Type: application/json Content-Type: application/json
``` ```
@ -2928,7 +2928,7 @@ For example, a `/sync` request might return a range of four events
`E2`, `E3`, `E4` and `E5` within a given room, omitting two prior events `E2`, `E3`, `E4` and `E5` within a given room, omitting two prior events
`E0` and `E1`. This can be visualised as follows: `E0` and `E1`. This can be visualised as follows:
``` ```nohighlight
[E0]->[E1]->[E2]->[E3]->[E4]->[E5] [E0]->[E1]->[E2]->[E3]->[E4]->[E5]
^ ^ ^ ^
| | | |
@ -2946,7 +2946,7 @@ deprecated `/events` API) support long-polling in this way.
Continuing the example above, an incremental sync might report Continuing the example above, an incremental sync might report
a single new event `E6`. The response can be visualised as: a single new event `E6`. The response can be visualised as:
``` ```nohighlight
[E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6] [E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6]
^ ^ ^ ^
| | | |
@ -2970,7 +2970,7 @@ the `since` parameter. The server knows about four new events, `E7`, `E8`,
the server sends a `limited` response containing `E8`, `E9` and `E10`but the server sends a `limited` response containing `E8`, `E9` and `E10`but
omitting `E7`. This forms a gap, which we can see in the visualisation: omitting `E7`. This forms a gap, which we can see in the visualisation:
``` ```nohighlight
| gap | | gap |
| <-> | | <-> |
[E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6]->[E7]->[E8]->[E9]->[E10] [E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6]->[E7]->[E8]->[E9]->[E10]
@ -3065,29 +3065,29 @@ to another.
Valid requests look like: Valid requests look like:
``` ```nohighlight
PUT /rooms/!roomid:domain/state/m.example.event PUT /rooms/!roomid:domain/state/m.example.event
{ "key" : "without a state key" } { "key" : "without a state key" }
``` ```
``` ```nohighlight
PUT /rooms/!roomid:domain/state/m.another.example.event/foo PUT /rooms/!roomid:domain/state/m.another.example.event/foo
{ "key" : "with 'foo' as the state key" } { "key" : "with 'foo' as the state key" }
``` ```
In contrast, these requests are invalid: In contrast, these requests are invalid:
``` ```nohighlight
POST /rooms/!roomid:domain/state/m.example.event/ POST /rooms/!roomid:domain/state/m.example.event/
{ "key" : "cannot use POST here" } { "key" : "cannot use POST here" }
``` ```
``` ```nohighlight
PUT /rooms/!roomid:domain/state/m.another.example.event/foo/11 PUT /rooms/!roomid:domain/state/m.another.example.event/foo/11
{ "key" : "txnIds are not supported" } { "key" : "txnIds are not supported" }
``` ```
Care should be taken to avoid setting the wrong `state key`: Care should be taken to avoid setting the wrong `state key`:
``` ```nohighlight
PUT /rooms/!roomid:domain/state/m.another.example.event/11 PUT /rooms/!roomid:domain/state/m.another.example.event/11
{ "key" : "with '11' as the state key, but was probably intended to be a txnId" } { "key" : "with '11' as the state key, but was probably intended to be a txnId" }
``` ```
@ -3095,7 +3095,7 @@ PUT /rooms/!roomid:domain/state/m.another.example.event/11
The `state_key` is often used to store state about individual users, by The `state_key` is often used to store state about individual users, by
using the user ID as the `state_key` value. For example: using the user ID as the `state_key` value. For example:
``` ```nohighlight
PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Aexample.org PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Aexample.org
{ "animal" : "cat", "reason": "fluffy" } { "animal" : "cat", "reason": "fluffy" }
``` ```
@ -3103,7 +3103,7 @@ PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Aexample.org
In some cases, there may be no need for a `state_key`, so it can be In some cases, there may be no need for a `state_key`, so it can be
omitted: omitted:
``` ```nohighlight
PUT /rooms/!roomid:domain/state/m.room.bgd.color PUT /rooms/!roomid:domain/state/m.room.bgd.color
{ "color": "red", "hex": "#ff0000" } { "color": "red", "hex": "#ff0000" }
``` ```

2
content/client-server-api/modules/content_repo.md
Unescape Escape View File

@ -33,7 +33,7 @@ specification.
Content locations are represented as Matrix Content (`mxc://`) URIs. They Content locations are represented as Matrix Content (`mxc://`) URIs. They
look like: look like:
``` ```nohighlight
mxc://<server-name>/<media-id> mxc://<server-name>/<media-id>
<server-name> : The name of the homeserver where this content originated, e.g. matrix.org <server-name> : The name of the homeserver where this content originated, e.g. matrix.org

16
content/client-server-api/modules/end_to_end_encryption.md
Unescape Escape View File

@ -18,7 +18,7 @@ exchange fingerprints between users to build a web of trust.
device. This may include long-term identity keys, and/or one-time device. This may include long-term identity keys, and/or one-time
keys. keys.
``` ```nohighlight
+----------+ +--------------+ +----------+ +--------------+
| Bob's HS | | Bob's Device | | Bob's HS | | Bob's Device |
+----------+ +--------------+ +----------+ +--------------+
@ -29,7 +29,7 @@ keys.
2) Alice requests Bob's public identity keys and supported algorithms. 2) Alice requests Bob's public identity keys and supported algorithms.
``` ```nohighlight
+----------------+ +------------+ +----------+ +----------------+ +------------+ +----------+
| Alice's Device | | Alice's HS | | Bob's HS | | Alice's Device | | Alice's HS | | Bob's HS |
+----------------+ +------------+ +----------+ +----------------+ +------------+ +----------+
@ -40,7 +40,7 @@ keys.
3) Alice selects an algorithm and claims any one-time keys needed. 3) Alice selects an algorithm and claims any one-time keys needed.
``` ```nohighlight
+----------------+ +------------+ +----------+ +----------------+ +------------+ +----------+
| Alice's Device | | Alice's HS | | Bob's HS | | Alice's Device | | Alice's HS | | Bob's HS |
+----------------+ +------------+ +----------+ +----------------+ +------------+ +----------+
@ -491,7 +491,7 @@ this example, Bob's device sends the `m.key.verification.start`, Alice's device
could also send that message. As well, the order of the could also send that message. As well, the order of the
`m.key.verification.done` messages could be reversed. `m.key.verification.done` messages could be reversed.
``` ```nohighlight
+---------------+ +---------------+ +-------------+ +-------------+ +---------------+ +---------------+ +-------------+ +-------------+
| AliceDevice1 | | AliceDevice2 | | BobDevice1 | | BobDevice2 | | AliceDevice1 | | AliceDevice2 | | BobDevice1 | | BobDevice2 |
+---------------+ +---------------+ +-------------+ +-------------+ +---------------+ +---------------+ +-------------+ +-------------+
@ -695,7 +695,7 @@ The process between Alice and Bob verifying each other would be:
The wire protocol looks like the following between Alice and Bob's The wire protocol looks like the following between Alice and Bob's
devices: devices:
``` ```nohighlight
+-------------+ +-----------+ +-------------+ +-----------+
| AliceDevice | | BobDevice | | AliceDevice | | BobDevice |
+-------------+ +-----------+ +-------------+ +-----------+
@ -969,7 +969,7 @@ she can trust Bob's device if:
The following diagram illustrates how keys are signed: The following diagram illustrates how keys are signed:
``` ```nohighlight
+------------------+ .................. +----------------+ +------------------+ .................. +----------------+
| +--------------+ | .................. : | +------------+ | | +--------------+ | .................. : | +------------+ |
| | v v v : : v v v | | | | v v v : : v v v | |
@ -1000,7 +1000,7 @@ the user who created them.
The following diagram illustrates Alice's view, hiding the keys and The following diagram illustrates Alice's view, hiding the keys and
signatures that she cannot see: signatures that she cannot see:
``` ```nohighlight
+------------------+ +----------------+ +----------------+ +------------------+ +----------------+ +----------------+
| +--------------+ | | | | +------------+ | | +--------------+ | | | | +------------+ |
| | v v | v v v | | | | v v | v v v | |
@ -1218,7 +1218,7 @@ The binary segment MUST be of the following form:
For example, if Alice displays a QR code encoding the following binary data: For example, if Alice displays a QR code encoding the following binary data:
``` ```nohighlight
"MATRIX" |ver|mode| len | event ID "MATRIX" |ver|mode| len | event ID
4D 41 54 52 49 58 02 00 00 2D 21 41 42 43 44 ... 4D 41 54 52 49 58 02 00 00 2D 21 41 42 43 44 ...
| user's cross-signing key | other user's cross-signing key | shared secret | user's cross-signing key | other user's cross-signing key | shared secret

2
content/client-server-api/modules/push.md
Unescape Escape View File

@ -1,7 +1,7 @@
### Push Notifications ### Push Notifications
``` ```nohighlight
+--------------------+ +-------------------+ +--------------------+ +-------------------+
Matrix HTTP | | | | Matrix HTTP | | | |
Notification Protocol | App Developer | | Device Vendor | Notification Protocol | App Developer | | Device Vendor |

2
content/client-server-api/modules/receipts.md
Unescape Escape View File

@ -214,7 +214,7 @@ before delivering them to clients.
Some receipts are sent across federation as EDUs with type `m.receipt`. The Some receipts are sent across federation as EDUs with type `m.receipt`. The
format of the EDUs are: format of the EDUs are:
``` ```nohighlight
{ {
<room_id>: { <room_id>: {
<receipt_type>: { <receipt_type>: {

10
content/client-server-api/modules/secrets.md
Unescape Escape View File

@ -157,7 +157,7 @@ Some secret is encrypted using keys with ID `key_id_1` and `key_id_2`:
`org.example.some.secret`: `org.example.some.secret`:
``` ```nohighlight
{ {
"encrypted": { "encrypted": {
"key_id_1": { "key_id_1": {
@ -177,7 +177,7 @@ and the key descriptions for the keys would be:
`m.secret_storage.key.key_id_1`: `m.secret_storage.key.key_id_1`:
``` ```nohighlight
{ {
"name": "Some key", "name": "Some key",
"algorithm": "m.secret_storage.v1.aes-hmac-sha2", "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
@ -187,7 +187,7 @@ and the key descriptions for the keys would be:
`m.secret_storage.key.key_id_2`: `m.secret_storage.key.key_id_2`:
``` ```nohighlight
{ {
"name": "Some other key", "name": "Some other key",
"algorithm": "m.secret_storage.v1.aes-hmac-sha2", "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
@ -199,7 +199,7 @@ If `key_id_1` is the default key, then we also have:
`m.secret_storage.default_key`: `m.secret_storage.default_key`:
``` ```nohighlight
{ {
"key": "key_id_1" "key": "key_id_1"
} }
@ -294,7 +294,7 @@ in the `iterations` parameter.
Example: Example:
``` ```nohighlight
{ {
"passphrase": { "passphrase": {
"algorithm": "m.pbkdf2", "algorithm": "m.pbkdf2",

2
content/client-server-api/modules/spaces.md
Unescape Escape View File

@ -58,7 +58,7 @@ parent to the room. The `state_key` for the event is the child room's ID.
For example, to achieve the following: For example, to achieve the following:
``` ```nohighlight
#space:example.org #space:example.org
#general:example.org (!abcdefg:example.org) #general:example.org (!abcdefg:example.org)
!private:example.org !private:example.org

2
content/client-server-api/modules/sso_login.md
Unescape Escape View File

@ -67,7 +67,7 @@ opening an embedded web view.
These steps are illustrated as follows: These steps are illustrated as follows:
``` ```nohighlight
Matrix Client Matrix Homeserver Auth Server Matrix Client Matrix Homeserver Auth Server
| | | | | |
|-------------(0) GET /login----------->| | |-------------(0) GET /login----------->| |

6
content/client-server-api/modules/third_party_invites.md
Unescape Escape View File

@ -44,7 +44,7 @@ If the lookup yields a result for a Matrix User ID then the normal [invite
process](/server-server-api/#inviting-to-a-room) can be initiated. This process process](/server-server-api/#inviting-to-a-room) can be initiated. This process
ends up looking like this: ends up looking like this:
``` ```nohighlight
+---------+ +-------------+ +-----------------+ +---------+ +-------------+ +-----------------+
| Client | | Homeserver | | IdentityServer | | Client | | Homeserver | | IdentityServer |
+---------+ +-------------+ +-----------------+ +---------+ +-------------+ +-----------------+
@ -74,7 +74,7 @@ the invite on the identity server with a call to
and emit a valid [`m.room.third_party_invite`](#mroomthird_party_invite) event and emit a valid [`m.room.third_party_invite`](#mroomthird_party_invite) event
to the room. This process ends up looking like this: to the room. This process ends up looking like this:
``` ```nohighlight
+---------+ +-------------+ +-----------------+ +---------+ +-------------+ +-----------------+
| Client | | Homeserver | | IdentityServer | | Client | | Homeserver | | IdentityServer |
+---------+ +-------------+ +-----------------+ +---------+ +-------------+ +-----------------+
@ -133,7 +133,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 would look like the following. This diagram assumes H1 and H2 are
residents of the room while H3 is attempting to join. residents of the room while H3 is attempting to join.
``` ```nohighlight
+-------+ +-----------------+ +-----+ +-----+ +-----+ +-----+ +-------+ +-----------------+ +-----+ +-----+ +-----+ +-----+
| UserA | | ThirdPartyUser | | H1 | | H2 | | H3 | | IS | | UserA | | ThirdPartyUser | | H1 | | H2 | | H3 | | IS |
+-------+ +-----------------+ +-----+ +-----+ +-----+ +-----+ +-------+ +-----------------+ +-----+ +-----+ +-----+ +-----+

4
content/client-server-api/modules/voip_events.md
Unescape Escape View File

@ -129,7 +129,7 @@ or not there have been any changes to the Matrix spec.
A call is set up with message events exchanged as follows: A call is set up with message events exchanged as follows:
``` ```nohighlight
Caller Callee Caller Callee
[Place Call] [Place Call]
m.call.invite -----------> m.call.invite ----------->
@ -144,7 +144,7 @@ A call is set up with message events exchanged as follows:
Or a rejected call: Or a rejected call:
``` ```nohighlight
Caller Callee Caller Callee
m.call.invite ------------> m.call.invite ------------>
m.call.candidate ---------> m.call.candidate --------->

43
content/olm-megolm/_index.md
Unescape Escape View File

@ -39,16 +39,15 @@ bit chain key, \(C_{0,0}\), are derived from the shared secret using an
HMAC-based Key Derivation Function using [SHA-256][] as the hash function HMAC-based Key Derivation Function using [SHA-256][] as the hash function
([HKDF-SHA-256][]) with default salt and ``"OLM_ROOT"`` as the info. ([HKDF-SHA-256][]) with default salt and ``"OLM_ROOT"`` as the info.
```math \[
\begin{aligned} \begin{aligned}
S&=\operatorname{ECDH}\left(I_A,E_B\right)\;\parallel\; S&=\operatorname{ECDH}\left(I_A,E_B\right)\;\parallel\;
\operatorname{ECDH}\left(E_A,I_B\right)\;\parallel\; \operatorname{ECDH}\left(E_A,I_B\right)\;\parallel\;
\operatorname{ECDH}\left(E_A,E_B\right)\\ \operatorname{ECDH}\left(E_A,E_B\right)\\
R_0\;\parallel\;C_{0,0}&= R_0\;\parallel\;C_{0,0}&=
\operatorname{HKDF}\left(0,S,\text{``OLM\_ROOT"},64\right) \operatorname{HKDF}\left(0,S,\text{``OLM\_ROOT"},64\right)
\end{aligned} \end{aligned}
``` \]
#### Advancing the root key #### Advancing the root key
@ -61,7 +60,7 @@ chain key, \(C_{i,0}\), are derived from the shared secret using
[HKDF-SHA-256][] using \(R_{i-1}\) as the salt and ``"OLM_RATCHET"`` as the [HKDF-SHA-256][] using \(R_{i-1}\) as the salt and ``"OLM_RATCHET"`` as the
info. info.
```math \[
\begin{aligned} \begin{aligned}
R_i\;\parallel\;C_{i,0}&= R_i\;\parallel\;C_{i,0}&=
\operatorname{HKDF}\left( \operatorname{HKDF}\left(
@ -71,7 +70,7 @@ info.
64 64
\right) \right)
\end{aligned} \end{aligned}
``` \]
#### Advancing the chain key #### Advancing the chain key
@ -79,11 +78,11 @@ Advancing a chain key takes the previous chain key, \(C_{i,j-1}\). The next
chain key, \(C_{i,j}\), is the [HMAC-SHA-256][] of ``"\x02"`` using the chain key, \(C_{i,j}\), is the [HMAC-SHA-256][] of ``"\x02"`` using the
previous chain key as the key. previous chain key as the key.
```math \[
\begin{aligned} \begin{aligned}
C_{i,j}&=\operatorname{HMAC}\left(C_{i,j-1},\text{``\char`\\x02"}\right) C_{i,j}&=\operatorname{HMAC}\left(C_{i,j-1},\text{``\char`\\x02"}\right)
\end{aligned} \end{aligned}
``` \]
#### Creating a message key #### Creating a message key
@ -93,11 +92,11 @@ current chain key as the key. The message keys where \(i\) is even are used
by Alice to encrypt messages. The message keys where \(i\) is odd are used by Alice to encrypt messages. The message keys where \(i\) is odd are used
by Bob to encrypt messages. by Bob to encrypt messages.
```math \[
\begin{aligned} \begin{aligned}
M_{i,j}&=\operatorname{HMAC}\left(C_{i,j},\text{``\char`\\x01"}\right) M_{i,j}&=\operatorname{HMAC}\left(C_{i,j},\text{``\char`\\x01"}\right)
\end{aligned} \end{aligned}
``` \]
### The Olm Protocol ### The Olm Protocol
@ -206,7 +205,7 @@ a means for recipients to distinguish between them.
Olm messages start with a one byte version followed by a variable length Olm messages start with a one byte version followed by a variable length
payload followed by a fixed length message authentication code. payload followed by a fixed length message authentication code.
```text ```nohighlight
+--------------+------------------------------------+-----------+ +--------------+------------------------------------+-----------+
| Version Byte | Payload Bytes | MAC Bytes | | Version Byte | Payload Bytes | MAC Bytes |
+--------------+------------------------------------+-----------+ +--------------+------------------------------------+-----------+
@ -242,7 +241,7 @@ MAC protects all of the bytes preceding the MAC.
Olm pre-key messages start with a one byte version followed by a variable Olm pre-key messages start with a one byte version followed by a variable
length payload. length payload.
```text ```nohighlight
+--------------+------------------------------------+ +--------------+------------------------------------+
| Version Byte | Payload Bytes | | Version Byte | Payload Bytes |
+--------------+------------------------------------+ +--------------+------------------------------------+
@ -269,12 +268,12 @@ encryption and [HMAC-SHA-256][] (truncated to 64 bits) for authentication. The
message key using [HKDF-SHA-256][] using the default salt and an info of message key using [HKDF-SHA-256][] using the default salt and an info of
``"OLM_KEYS"``. ``"OLM_KEYS"``.
```math \[
\begin{aligned} \begin{aligned}
AES\_KEY_{i,j}\;\parallel\;HMAC\_KEY_{i,j}\;\parallel\;AES\_IV_{i,j} AES\_KEY_{i,j}\;\parallel\;HMAC\_KEY_{i,j}\;\parallel\;AES\_IV_{i,j}
&= \operatorname{HKDF}\left(0,M_{i,j},\text{``OLM\_KEYS"},80\right) &= \operatorname{HKDF}\left(0,M_{i,j},\text{``OLM\_KEYS"},80\right)
\end{aligned} \end{aligned}
``` \]
The plain-text is encrypted with AES-256, using the key \(AES\_KEY_{i,j}\) The plain-text is encrypted with AES-256, using the key \(AES\_KEY_{i,j}\)
and the IV \(AES\_IV_{i,j}\) to give the cipher-text, \(X_{i,j}\). and the IV \(AES\_IV_{i,j}\) to give the cipher-text, \(X_{i,j}\).
@ -375,7 +374,7 @@ in use (256 bits for this version of Megolm).
The ratchet is initialised with cryptographically-secure random data, and The ratchet is initialised with cryptographically-secure random data, and
advanced as follows: advanced as follows:
```math \[
\begin{aligned} \begin{aligned}
R_{i,0} &= R_{i,0} &=
\begin{cases} \begin{cases}
@ -403,7 +402,7 @@ R_{i,3} &=
H_3\left(R_{i-1,3}\right) &\text{otherwise} H_3\left(R_{i-1,3}\right) &\text{otherwise}
\end{cases} \end{cases}
\end{aligned} \end{aligned}
``` \]
where \(H_0\), \(H_1\), \(H_2\), and \(H_3\) are different hash where \(H_0\), \(H_1\), \(H_2\), and \(H_3\) are different hash
functions. In summary: every \(2^8\) iterations, \(R_{i,3}\) is functions. In summary: every \(2^8\) iterations, \(R_{i,3}\) is
@ -461,12 +460,12 @@ This version of Megolm uses [AES-256][] in [CBC][] mode with [PKCS#7][] padding
[HMAC-SHA-256][] (truncated to 64 bits). The 256 bit AES key, 256 bit HMAC key, [HMAC-SHA-256][] (truncated to 64 bits). The 256 bit AES key, 256 bit HMAC key,
and 128 bit AES IV are derived from the megolm ratchet \(R_i\): and 128 bit AES IV are derived from the megolm ratchet \(R_i\):
```math \[
\begin{aligned} \begin{aligned}
\mathit{AES\_KEY}_{i}\;\parallel\;\mathit{HMAC\_KEY}_{i}\;\parallel\;\mathit{AES\_IV}_{i} \mathit{AES\_KEY}_{i}\;\parallel\;\mathit{HMAC\_KEY}_{i}\;\parallel\;\mathit{AES\_IV}_{i}
&= \operatorname{HKDF}\left(0,\,R_{i},\text{"MEGOLM\_KEYS"},\,80\right) \\ &= \operatorname{HKDF}\left(0,\,R_{i},\text{"MEGOLM\_KEYS"},\,80\right) \\
\end{aligned} \end{aligned}
``` \]
where \(\parallel\) represents string splitting, and where \(\parallel\) represents string splitting, and
\(\operatorname{HKDF}\left(\mathit{salt},\,\mathit{IKM},\,\mathit{info},\,L\right)\) \(\operatorname{HKDF}\left(\mathit{salt},\,\mathit{IKM},\,\mathit{info},\,L\right)\)
@ -497,14 +496,14 @@ received the session data.
After each message is encrypted, the ratchet is advanced. This is done as After each message is encrypted, the ratchet is advanced. This is done as
described in [The Megolm ratchet algorithm](#the-megolm-ratchet-algorithm), using the following definitions: described in [The Megolm ratchet algorithm](#the-megolm-ratchet-algorithm), using the following definitions:
```math \[
\begin{aligned} \begin{aligned}
H_0(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x00"}) \\ H_0(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x00"}) \\
H_1(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x01"}) \\ H_1(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x01"}) \\
H_2(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x02"}) \\ H_2(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x02"}) \\
H_3(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x03"}) \\ H_3(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x03"}) \\
\end{aligned} \end{aligned}
``` \]
where \(\operatorname{HMAC}(A, T)\) is the HMAC-SHA-256 of ``T``, using ``A`` as the where \(\operatorname{HMAC}(A, T)\) is the HMAC-SHA-256 of ``T``, using ``A`` as the
key. key.
@ -528,7 +527,7 @@ session.
The session sharing format is as follows: The session sharing format is as follows:
```text ```nohighlight
+---+----+--------+--------+--------+--------+------+-----------+ +---+----+--------+--------+--------+--------+------+-----------+
| V | i | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub | Signature | | V | i | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub | Signature |
+---+----+--------+--------+--------+--------+------+-----------+ +---+----+--------+--------+--------+--------+------+-----------+
@ -558,7 +557,7 @@ format](#session-sharing-format) except for dropping the signature.
The Megolm session export format is thus as follows: The Megolm session export format is thus as follows:
```text ```nohighlight
+---+----+--------+--------+--------+--------+------+ +---+----+--------+--------+--------+--------+------+
| V | i | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub | | V | i | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub |
+---+----+--------+--------+--------+--------+------+ +---+----+--------+--------+--------+--------+------+
@ -577,7 +576,7 @@ Megolm messages consist of a one byte version, followed by a variable length
payload, a fixed length message authentication code, and a fixed length payload, a fixed length message authentication code, and a fixed length
signature. signature.
```text ```nohighlight
+---+------------------------------------+-----------+------------------+ +---+------------------------------------+-----------+------------------+
| V | Payload Bytes | MAC Bytes | Signature Bytes | | V | Payload Bytes | MAC Bytes | Signature Bytes |
+---+------------------------------------+-----------+------------------+ +---+------------------------------------+-----------+------------------+

2
content/proposals.md
Unescape Escape View File

@ -281,7 +281,7 @@ corresponding labels for each stage on the
[matrix-spec-proposals](https://github.com/matrix-org/matrix-spec-proposals) [matrix-spec-proposals](https://github.com/matrix-org/matrix-spec-proposals)
pull request trackers. pull request trackers.
``` ```nohighlight
+ + + +
Proposals | Spec PRs | Additional States Proposals | Spec PRs | Additional States
+-------+ | +------+ | +---------------+ +-------+ | +------+ | +---------------+

2
content/push-gateway-api.md
Unescape Escape View File

@ -14,7 +14,7 @@ A client's homeserver forwards information about received events to the
push gateway. The gateway then submits a push notification to the push push gateway. The gateway then submits a push notification to the push
notification provider (e.g. APNS, GCM). notification provider (e.g. APNS, GCM).
``` ```nohighlight
+--------------------+ +-------------------+ +--------------------+ +-------------------+
Matrix HTTP | | | | Matrix HTTP | | | |
Notification Protocol | App Developer | | Device Vendor | Notification Protocol | App Developer | | Device Vendor |

2
content/rooms/v10.md
Unescape Escape View File

@ -18,7 +18,7 @@ refined in [room version 9](/rooms/v9)).
Clients should render the new join rule accordingly for such rooms. For example: Clients should render the new join rule accordingly for such rooms. For example:
``` ```nohighlight
This room is: This room is:
[ ] Public [ ] Public
[x] Private [x] Private

4
content/server-server-api.md
Unescape Escape View File

@ -289,7 +289,7 @@ and any query parameters if present, but should not include the leading
Step 1 sign JSON: Step 1 sign JSON:
``` ```nohighlight
{ {
"method": "POST", "method": "POST",
"uri": "/target", "uri": "/target",
@ -822,7 +822,7 @@ ResidentServer->JoiningServer: send_join response
JoiningServer->Client: join response JoiningServer->Client: join response
--> -->
``` ```nohighlight
+---------+ +---------------+ +-----------------+ +-----------------+ +---------+ +---------------+ +-----------------+ +-----------------+
| Client | | JoiningServer | | DirectoryServer | | ResidentServer | | Client | | JoiningServer | | DirectoryServer | | ResidentServer |
+---------+ +---------------+ +-----------------+ +-----------------+ +---------+ +---------------+ +-----------------+ +-----------------+

3
layouts/docs/baseof.html
Unescape Escape View File

@ -13,7 +13,8 @@
<head> <head>
{{ partial "head.html" . }} {{ partial "head.html" . }}
{{ if .Page.Store.Get "hasMath" }} {{ if .Page.Store.Get "hasMath" }}
<link href="https://cdn.jsdelivr.net/npm/katex@0.16.23/dist/katex.min.css" rel="stylesheet"> <link href="/css/katex.min.css" rel="preload" as="style">
<link href="/css/katex.min.css" rel="stylesheet">
{{ end }} {{ end }}
</head> </head>
<body class="td-{{ .Kind }}{{ with .Page.Params.body_class }} {{ . }}{{ end }}"> <body class="td-{{ .Kind }}{{ with .Page.Params.body_class }} {{ . }}{{ end }}">

BIN
static/css/fonts/KaTeX_AMS-Regular.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Caligraphic-Bold.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Caligraphic-Regular.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Fraktur-Bold.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Fraktur-Regular.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Main-Bold.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Main-BoldItalic.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Main-Italic.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Main-Regular.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Math-BoldItalic.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Math-Italic.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_SansSerif-Bold.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_SansSerif-Italic.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_SansSerif-Regular.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Script-Regular.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Size1-Regular.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Size2-Regular.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Size3-Regular.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Size4-Regular.woff2
View File

Binary file not shown.

BIN
static/css/fonts/KaTeX_Typewriter-Regular.woff2
View File

Binary file not shown.

1
static/css/katex.min.css vendored
View File

File diff suppressed because one or more lines are too long
Write Preview
Loading…
Cancel
Save