Merge 2cbda923c8 into fda3be5ee3

assets/scss/_styles_project.scss

@@ -502,13 +502,6 @@ 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

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

config/_default/hugo.toml

@@ -47,7 +47,7 @@ description = "Home of the Matrix specification for decentralised communication"
       [markup.goldmark.extensions.passthrough]
         enable = true
         [markup.goldmark.extensions.passthrough.delimiters]
-          block = [['\[', '\]']]
+          block = [['\[', '\]'], ['$$', '$$']]
           inline = [['\(', '\)']]
   [markup.highlight]
       # See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html
@@ -127,7 +127,8 @@ sidebar_menu_compact = true
 [[server.headers]]
   for = '/**'
   [server.headers.values]
-    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'"
+    # TODO: figure out CSP
+    # 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-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

@@ -687,7 +687,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
 ```
@@ -733,7 +733,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
 ```
@@ -756,7 +756,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
 ```
@@ -790,7 +790,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
 ```
@@ -820,7 +820,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
 ```
@@ -859,7 +859,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               |
@@ -917,7 +917,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": {
@@ -1167,7 +1167,7 @@ user during registration, if applicable.
 
 1. A client might submit a registration request as follows:
 
-   ```nohighlight
+   ```
    POST /_matrix/client/v3/register
    ```
    ```json
@@ -1180,7 +1180,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
    ```
@@ -1215,7 +1215,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
@@ -1230,7 +1230,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
    ```
@@ -1651,7 +1651,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 &
@@ -1684,7 +1684,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
 ```
 
@@ -1696,7 +1696,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
 ```
 
@@ -1721,7 +1721,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
@@ -2044,7 +2044,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 / "-" / "." / "_" / "~"
 ```
 
@@ -2057,7 +2057,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
 ```
 
@@ -2199,7 +2199,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
@@ -2244,7 +2244,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
 ```
@@ -2324,7 +2324,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
 ```
@@ -2932,7 +2932,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]
                ^                      ^
                |                      |
@@ -2950,7 +2950,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]
                                       ^     ^
                                       |     |
@@ -2974,7 +2974,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]
@@ -3069,29 +3069,29 @@ 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" }
 ```
@@ -3099,7 +3099,7 @@ PUT /rooms/!roomid:domain/state/m.another.example.event/11
 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" }
 ```
@@ -3107,7 +3107,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
 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

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

@@ -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
 keys.
 
-```nohighlight
+```
       +----------+  +--------------+
       | Bob's HS |  | Bob's Device |
       +----------+  +--------------+
@@ -29,7 +29,7 @@ keys.
 
 2) Alice requests Bob's public identity keys and supported algorithms.
 
-```nohighlight
+```
       +----------------+  +------------+  +----------+
       | 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.
 
-```nohighlight
+```
       +----------------+  +------------+  +----------+
       | 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
 `m.key.verification.done` messages could be reversed.
 
-```nohighlight
+```
     +---------------+ +---------------+                    +-------------+ +-------------+
     | 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
 devices:
 
-```nohighlight
+```
     +-------------+                    +-----------+
     | AliceDevice |                    | BobDevice |
     +-------------+                    +-----------+
@@ -969,7 +969,7 @@ she can trust Bob's device if:
 
 The following diagram illustrates how keys are signed:
 
-```nohighlight
+```
     +------------------+                ..................   +----------------+
     | +--------------+ |   ..................            :   | +------------+ |
     | |              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
 signatures that she cannot see:
 
-```nohighlight
+```
     +------------------+                +----------------+   +----------------+
     | +--------------+ |                |                |   | +------------+ |
     | |              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:
 
-```nohighlight
+```
       "MATRIX"    |ver|mode| len   | event ID
  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

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

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

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

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

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

@@ -157,7 +157,7 @@ Some secret is encrypted using keys with ID `key_id_1` and `key_id_2`:
 
 `org.example.some.secret`:
 
-```nohighlight
+```
 {
   "encrypted": {
     "key_id_1": {
@@ -177,7 +177,7 @@ and the key descriptions for the keys would be:
 
 `m.secret_storage.key.key_id_1`:
 
-```nohighlight
+```
 {
   "name": "Some key",
   "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`:
 
-```nohighlight
+```
 {
   "name": "Some other key",
   "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`:
 
-```nohighlight
+```
 {
   "key": "key_id_1"
 }
@@ -294,7 +294,7 @@ in the `iterations` parameter.
 
 Example:
 
-```nohighlight
+```
 {
     "passphrase": {
         "algorithm": "m.pbkdf2",

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

@@ -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:
 
-```nohighlight
+```
 #space:example.org
     #general:example.org (!abcdefg:example.org)
     !private:example.org

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

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

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

@@ -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
 ends up looking like this:
 
-```nohighlight
+```
     +---------+                         +-------------+                                    +-----------------+
     | 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
 to the room. This process ends up looking like this:
 
-```nohighlight
+```
     +---------+                         +-------------+                                               +-----------------+
     | 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
 residents of the room while H3 is attempting to join.
 
-```nohighlight
+```
     +-------+ +-----------------+         +-----+                                          +-----+           +-----+                      +-----+
     | UserA | | ThirdPartyUser  |         | H1  |                                          | H2  |           | H3  |                      | IS  |
     +-------+ +-----------------+         +-----+                                          +-----+           +-----+                      +-----+

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

@@ -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:
 
-```nohighlight
+```
     Caller                    Callee
     [Place Call]
     m.call.invite ----------->
@@ -144,7 +144,7 @@ A call is set up with message events exchanged as follows:
 
 Or a rejected call:
 
-```nohighlight
+```
     Caller                      Callee
     m.call.invite ------------>
     m.call.candidate --------->

content/olm-megolm/_index.md

@@ -39,15 +39,16 @@ 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
 ([HKDF-SHA-256][]) with default salt and ``"OLM_ROOT"`` as the info.
 
-\[
+```math
 \begin{aligned}
     S&=\operatorname{ECDH}\left(I_A,E_B\right)\;\parallel\;
        \operatorname{ECDH}\left(E_A,I_B\right)\;\parallel\;
        \operatorname{ECDH}\left(E_A,E_B\right)\\
+
     R_0\;\parallel\;C_{0,0}&=
         \operatorname{HKDF}\left(0,S,\text{``OLM\_ROOT"},64\right)
 \end{aligned}
-\]
+```
 
 #### Advancing the root key
 
@@ -60,7 +61,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
 info.
 
-\[
+```math
 \begin{aligned}
     R_i\;\parallel\;C_{i,0}&=
         \operatorname{HKDF}\left(
@@ -70,7 +71,7 @@ info.
             64
         \right)
 \end{aligned}
-\]
+```
 
 #### Advancing the chain key
 
@@ -78,11 +79,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
 previous chain key as the key.
 
-\[
+```math
 \begin{aligned}
     C_{i,j}&=\operatorname{HMAC}\left(C_{i,j-1},\text{``\char`\\x02"}\right)
 \end{aligned}
-\]
+```
 
 #### Creating a message key
 
@@ -92,11 +93,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 Bob to encrypt messages.
 
-\[
+```math
 \begin{aligned}
     M_{i,j}&=\operatorname{HMAC}\left(C_{i,j},\text{``\char`\\x01"}\right)
 \end{aligned}
-\]
+```
 
 ### The Olm Protocol
 
@@ -205,7 +206,7 @@ a means for recipients to distinguish between them.
 Olm messages start with a one byte version followed by a variable length
 payload followed by a fixed length message authentication code.
 
-```nohighlight
+```text
  +--------------+------------------------------------+-----------+
  | Version Byte | Payload Bytes                      | MAC Bytes |
  +--------------+------------------------------------+-----------+
@@ -241,7 +242,7 @@ MAC protects all of the bytes preceding the MAC.
 Olm pre-key messages start with a one byte version followed by a variable
 length payload.
 
-```nohighlight
+```text
  +--------------+------------------------------------+
  | Version Byte | Payload Bytes                      |
  +--------------+------------------------------------+
@@ -268,12 +269,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
 ``"OLM_KEYS"``.
 
-\[
+```math
 \begin{aligned}
     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)
 \end{aligned}
-\]
+```
 
 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}\).
@@ -305,7 +306,7 @@ has proven ownership of.
    publishes the same identity key, claiming it as her own. Alice downloads
    Eve's keys, and associates \(I_B\) with Eve. Alice sends a message to
    Eve; Eve cannot decrypt it, but forwards it to Bob. Bob believes the
-   Alice sent the message to him, whereas Alice intended it to go to Eve.
+   Alice sent the message to him, wheras Alice intended it to go to Eve.
 
    This is prevented by Alice including the user ID of the intended recpient
    (Eve) in the plain-text of the pre-key message. Bob can now tell that the
@@ -374,7 +375,7 @@ in use (256 bits for this version of Megolm).
 The ratchet is initialised with cryptographically-secure random data, and
 advanced as follows:
 
-\[
+```math
 \begin{aligned}
 R_{i,0} &=
   \begin{cases}
@@ -402,7 +403,7 @@ R_{i,3} &=
   H_3\left(R_{i-1,3}\right) &\text{otherwise}
   \end{cases}
 \end{aligned}
-\]
+```
 
 where \(H_0\), \(H_1\), \(H_2\), and \(H_3\) are different hash
 functions. In summary: every \(2^8\) iterations, \(R_{i,3}\) is
@@ -460,12 +461,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,
 and 128 bit AES IV are derived from the megolm ratchet \(R_i\):
 
-\[
+```math
 \begin{aligned}
  \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) \\
 \end{aligned}
-\]
+```
 
 where \(\parallel\) represents string splitting, and
 \(\operatorname{HKDF}\left(\mathit{salt},\,\mathit{IKM},\,\mathit{info},\,L\right)\)
@@ -496,14 +497,14 @@ received the session data.
 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:
 
-\[
+```math
 \begin{aligned}
     H_0(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x00"}) \\
     H_1(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x01"}) \\
     H_2(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x02"}) \\
     H_3(A) &\equiv \operatorname{HMAC}(A,\text{``\char`\\x03"}) \\
 \end{aligned}
-\]
+```
 
 where \(\operatorname{HMAC}(A, T)\) is the HMAC-SHA-256 of ``T``, using ``A`` as the
 key.
@@ -527,7 +528,7 @@ session.
 
 The session sharing format is as follows:
 
-```nohighlight
+```text
 +---+----+--------+--------+--------+--------+------+-----------+
 | V | i  | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub | Signature |
 +---+----+--------+--------+--------+--------+------+-----------+
@@ -557,7 +558,7 @@ format](#session-sharing-format) except for dropping the signature.
 
 The Megolm session export format is thus as follows:
 
-```nohighlight
+```text
 +---+----+--------+--------+--------+--------+------+
 | V | i  | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub |
 +---+----+--------+--------+--------+--------+------+
@@ -576,7 +577,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
 signature.
 
-```nohighlight
+```text
 +---+------------------------------------+-----------+------------------+
 | V | Payload Bytes                      | MAC Bytes | Signature Bytes  |
 +---+------------------------------------+-----------+------------------+

content/proposals.md

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

content/push-gateway-api.md

@@ -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
 notification provider (e.g. APNS, GCM).
 
-```nohighlight
+```
                                    +--------------------+  +-------------------+
                   Matrix HTTP      |                    |  |                   |
              Notification Protocol |   App Developer    |  |   Device Vendor   |

content/rooms/v10.md

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

content/server-server-api.md

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

layouts/docs/baseof.html

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