Include Olm & Megolm specifications in main spec

assets/scss/_styles_project.scss

@@ -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 */
 .pageinfo-primary {
   @include media-breakpoint-up(lg) {

changelogs/internal/newsfragments/2226.clarification

@@ -0,0 +1 @@
+Inline Olm & Megolm specifications.

config/_default/hugo.toml

@@ -43,6 +43,12 @@ description = "Home of the Matrix specification for decentralised communication"
     [markup.goldmark.renderer]
       # Enables us to render raw HTML
       unsafe = true
+    [markup.goldmark.extensions]
+      [markup.goldmark.extensions.passthrough]
+        enable = true
+        [markup.goldmark.extensions.passthrough.delimiters]
+          block = [['\[', '\]']]
+          inline = [['\(', '\)']]
   [markup.highlight]
       # See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html
       # If the style is changed, remember to regenerate the CSS with:
@@ -121,7 +127,7 @@ sidebar_menu_compact = true
 [[server.headers]]
   for = '/**'
   [server.headers.values]
-    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'"
+    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'"
     X-XSS-Protection = "1; mode=block"
     X-Content-Type-Options = "nosniff"
     # Strict-Transport-Security = "max-age=31536000; includeSubDomains; preload"

content/_index.md

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

content/appendices.md

@@ -749,13 +749,13 @@ history (a permalink).
 
 The Matrix URI scheme is defined as follows (`[]` enclose optional parts, `{}`
 enclose variables):
-```
+```nohighlight
 matrix:[//{authority}/]{type}/{id without sigil}[/{type}/{id without sigil}...][?{query}][#{fragment}]
 ```
 
 As a schema, this can be represented as:
 
-```
+```nohighlight
 MatrixURI = "matrix:" hier-part [ "?" query ] [ "#" fragment ]
 hier-part = [ "//" authority "/" ] path
 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
 defined in [RFC 3986](https://tools.ietf.org/html/rfc3986):
 
-```
+```nohighlight
 https://matrix.to/#/<identifier>/<extra parameter>?<additional arguments>
 ```
 

content/application-service-api.md

@@ -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
 works as follows:
 
-```
+```nohighlight
     Typical
     HS ---> AS : Homeserver sends events with transaction ID T.
        <---    : Application Service sends back 200 OK.
 ```
 
-```
+```nohighlight
     AS ACK Lost
     HS ---> AS : Homeserver sends events with transaction ID T.
        <-/-    : AS 200 OK is lost.
@@ -258,7 +258,7 @@ have been omitted for brevity):
 
 **Typical**
 
-```
+```nohighlight
 AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"}
     HS ---> AS : /_matrix/app/v1/ping {"transaction_id": "meow"}
     HS <--- AS : 200 OK {}
@@ -267,7 +267,7 @@ AS <--- HS : 200 OK {"duration_ms": 123}
 
 **Incorrect `hs_token`**
 
-```
+```nohighlight
 AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"}
     HS ---> AS : /_matrix/app/v1/ping {"transaction_id": "meow"}
     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**
 
-```
+```nohighlight
 AS ---> HS : /_matrix/client/v1/appservice/{appserviceId}/ping {"transaction_id": "meow"}
     HS -/-> AS : /_matrix/app/v1/ping {"transaction_id": "meow"}
 AS <--- HS : 502 Bad Gateway {"errcode": "M_CONNECTION_FAILED"}

content/client-server-api/_index.md

@@ -683,7 +683,7 @@ request 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:
 
-```
+```nohighlight
 HTTP/1.1 401 Unauthorized
 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
 type `example.type.foo`, it might submit something like this:
 
-```
+```nohighlight
 POST /_matrix/client/v3/endpoint HTTP/1.1
 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
 client has completed successfully:
 
-```
+```nohighlight
 HTTP/1.1 401 Unauthorized
 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
 `errcode` and `error` fields describing the error. For example:
 
-```
+```nohighlight
 HTTP/1.1 401 Unauthorized
 Content-Type: application/json
 ```
@@ -816,7 +816,7 @@ Content-Type: application/json
 If the request fails for a reason other than authentication, the server
 returns an error message in the standard format. For example:
 
-```
+```nohighlight
 HTTP/1.1 400 Bad request
 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
 flow with three stages will resemble the following diagram:
 
-```
+```nohighlight
     _______________________
     |       Stage 0         |
     | 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
 follows:
 
-```
+```nohighlight
 {
   "type": "m.login.password",
   "identifier": {
@@ -1163,7 +1163,7 @@ user during registration, if applicable.
 
 1. A client might submit a registration request as follows:
 
-   ```
+   ```nohighlight
    POST /_matrix/client/v3/register
    ```
    ```json
@@ -1176,7 +1176,7 @@ user during registration, if applicable.
 2. The server requires the user to accept some terms of service before
    registration, so returns the following response:
 
-   ```
+   ```nohighlight
    HTTP/1.1 401 Unauthorized
    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
    accepted the documents:
-   ```
+   ```nohighlight
    POST /_matrix/client/v3/register
    ```
    ```json
@@ -1226,7 +1226,7 @@ user during registration, if applicable.
    ```
 
 5. All authentication steps have now completed, so the request is successful:
-   ```
+   ```nohighlight
    HTTP/1.1 200 OK
    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:
 
-```
+```nohighlight
 https://account.example.com/oauth2/auth?
     client_id     = s6BhdRkqt3 &
     response_type = code &
@@ -1680,7 +1680,7 @@ used in the authorization request.
 
 A successful authorization will have a `code` value, for example:
 
-```
+```nohighlight
 https://app.example.com/oauth2-callback#state=ewubooN9weezeewah9fol4oothohroh3&code=iuB7Eiz9heengah1joh2ioy9ahChuP6R
 ```
 
@@ -1692,7 +1692,7 @@ A failed authorization will have the following values:
 
 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
 ```
 
@@ -1717,7 +1717,7 @@ type, the expiration time, and the refresh token.
 
 Sample token request:
 
-```
+```nohighlight
 POST /oauth2/token HTTP/1.1
 Host: account.example.com
 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
 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 / "-" / "." / "_" / "~"
 ```
 
@@ -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),
 which is defined as the following ASCII ranges:
 
-```
+```nohighlight
 %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:
 
-```
+```nohighlight
 POST /oauth2/revoke HTTP/1.1
 Host: auth.example.com
 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
 the `error` field.
 
-```
+```nohighlight
 HTTP/1.1 401 Unauthorized
 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
 error code, as shown below:
 
-```
+```nohighlight
 HTTP/1.1 403 Forbidden
 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
 `E0` and `E1`. This can be visualised as follows:
 
-```
+```nohighlight
     [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
 a single new event `E6`. The response can be visualised as:
 
-```
+```nohighlight
     [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
 omitting `E7`. This forms a gap, which we can see in the visualisation:
 
-```
+```nohighlight
                                             | gap |
                                             | <-> |
     [E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6]->[E7]->[E8]->[E9]->[E10]
@@ -3065,45 +3065,45 @@ to another.
 
 Valid requests look like:
 
-```
+```nohighlight
 PUT /rooms/!roomid:domain/state/m.example.event
 { "key" : "without a state key" }
 ```
-```
+```nohighlight
 PUT /rooms/!roomid:domain/state/m.another.example.event/foo
 { "key" : "with 'foo' as the state key" }
 ```
 
 In contrast, these requests are invalid:
 
-```
+```nohighlight
 POST /rooms/!roomid:domain/state/m.example.event/
 { "key" : "cannot use POST here" }
 ```
-```
+```nohighlight
 PUT /rooms/!roomid:domain/state/m.another.example.event/foo/11
 { "key" : "txnIds are not supported" }
 ```
 
 Care should be taken to avoid setting the wrong `state key`:
 
-```
+```nohighlight
 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" }
 ```
 
 The `state_key` is often used to store state about individual users, by
 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
 { "animal" : "cat", "reason": "fluffy" }
 ```
 
 In some cases, there may be no need for a `state_key`, so it can be
 omitted:
 
-```
+```nohighlight
 PUT /rooms/!roomid:domain/state/m.room.bgd.color
 { "color": "red", "hex": "#ff0000" }
 ```

content/client-server-api/modules/content_repo.md

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