Add syntax highlighting

content/appendices.md

@@ -87,6 +87,7 @@ Note
 
 Float values are not permitted by this encoding.
 
+```py
 import json
 
 def canonical_json(value):
@@ -100,6 +101,7 @@ Float values are not permitted by this encoding.
         sort_keys=True,
         # Encode the resulting Unicode as UTF-8 bytes.
     ).encode("UTF-8")
+```
 
 #### Grammar
 
@@ -138,44 +140,61 @@ transformation code.
 
 Given the following JSON object:
 
+```json
 {}
+```
 
 The following canonical JSON should be produced:
 
+```json
 {}
+```
 
 Given the following JSON object:
 
+```json
 {
     "one": 1,
     "two": "Two"
 }
+```
 
 The following canonical JSON should be produced:
 
+```json
 {"one":1,"two":"Two"}
+```
 
 Given the following JSON object:
 
+```json
 {
     "b": "2",
     "a": "1"
 }
+```
 
 The following canonical JSON should be produced:
 
+```json
 {"a":"1","b":"2"}
+```
 
 Given the following JSON object:
 
+```json
 {"b":"2","a":"1"}
+```
 
 The following canonical JSON should be produced:
 
+```json
 {"a":"1","b":"2"}
+```
 
 Given the following JSON object:
 
+```json
 {
     "auth": {
         "success": true,
@@ -195,51 +214,70 @@ Given the following JSON object:
         }
     }
 }
+```
 
 The following canonical JSON should be produced:
 
+```json
 {"auth":{"mxid":"@john.doe:example.com","profile":{"display_name":"John Doe","three_pids":[{"address":"john.doe@example.org","medium":"email"},{"address":"123456789","medium":"msisdn"}]},"success":true}}
+```
 
 Given the following JSON object:
 
+```json
 {
     "a": "日本語"
 }
+```
 
 The following canonical JSON should be produced:
 
+```json
 {"a":"日本語"}
+```
 
 Given the following JSON object:
 
+```json
 {
     "本": 2,
     "日": 1
 }
+```
 
 The following canonical JSON should be produced:
 
+```json
 {"日":1,"本":2}
+```
 
 Given the following JSON object:
 
+```json
 {
     "a": "\u65E5"
 }
+```
 
 The following canonical JSON should be produced:
 
+```json
 {"a":"日"}
+```
 
 Given the following JSON object:
 
+```json
 {
     "a": null
 }
+```
 
 The following canonical JSON should be produced:
 
+```json
 {"a":null}
+```
 
 ### Signing Details
 
@@ -263,6 +301,7 @@ The `unsigned` object and the `signatures` object are not covered by the
 signature. Therefore intermediate entities can add unsigned data such as
 timestamps and additional signatures.
 
+```json
 {
    "name": "example.org",
    "signing_keys": {
@@ -277,7 +316,9 @@ timestamps and additional signatures.
       }
    }
 }
+```
 
+```py
 def sign_json(json_object, signing_key, signing_name):
     signatures = json_object.pop("signatures", {})
     unsigned = json_object.pop("unsigned", None)
@@ -293,6 +334,7 @@ timestamps and additional signatures.
         json_object["unsigned"] = unsigned
 
     return json_object
+```
 
 ### Checking for a Signature
 
@@ -872,10 +914,13 @@ In each case, the server name and key ID are as follows:
 
 Given an empty JSON object:
 
+```json
 {}
+```
 
 The JSON signing algorithm should emit the following signed data:
 
+```json
 {
     "signatures": {
         "domain": {
@@ -883,16 +928,20 @@ The JSON signing algorithm should emit the following signed data:
         }
     }
 }
+```
 
 Given the following JSON object with data values in it:
 
+```json
 {
     "one": 1,
     "two": "Two"
 }
+```
 
 The JSON signing algorithm should emit the following signed JSON:
 
+```json
 {
     "one": 1,
     "signatures": {
@@ -902,11 +951,13 @@ The JSON signing algorithm should emit the following signed JSON:
     },
     "two": "Two"
 }
+```
 
 ### Event Signing
 
 Given the following minimally-sized event:
 
+```json
 {
     "room_id": "!x:domain",
     "sender": "@a:domain",
@@ -923,9 +974,11 @@ Given the following minimally-sized event:
         "age_ts": 1000000
     }
 }
+```
 
 The event signing algorithm should emit the following signed event:
 
+```json
 {
     "auth_events": [],
     "content": {},
@@ -948,9 +1001,11 @@ The event signing algorithm should emit the following signed event:
         "age_ts": 1000000
     }
 }
+```
 
 Given the following event containing redactable content:
 
+```json
 {
     "content": {
         "body": "Here is the message content"
@@ -966,9 +1021,11 @@ Given the following event containing redactable content:
         "age_ts": 1000000
     }
 }
+```
 
 The event signing algorithm should emit the following signed event:
 
+```json
 {
     "content": {
         "body": "Here is the message content"
@@ -991,3 +1048,4 @@ The event signing algorithm should emit the following signed event:
         "age_ts": 1000000
     }
 }
+```

content/client-server-api/_index.md

@@ -71,10 +71,12 @@ inconsistency.
 Any errors which occur at the Matrix API level MUST return a "standard
 error response". This is a JSON object which looks like:
 
+```json
 {
   "errcode": "<error code>",
   "error": "<error message>"
 }
+```
 
 The `error` string will be a human-readable error message, usually a
 sentence explaining what went wrong. The `errcode` string will be a
@@ -439,6 +441,7 @@ homeserver returns an HTTP 401 response, with a JSON body, as follows:
     HTTP/1.1 401 Unauthorized
     Content-Type: application/json
 
+```json
 {
   "flows": [
     {
@@ -455,6 +458,7 @@ homeserver returns an HTTP 401 response, with a JSON body, as follows:
   },
   "session": "xxxxxx"
 }
+```
 
 In addition to the `flows`, this object contains some extra information:
 
@@ -482,6 +486,7 @@ type `example.type.foo`, it might submit something like this:
     POST /_matrix/client/r0/endpoint HTTP/1.1
     Content-Type: application/json
 
+```json
 {
   "a_request_parameter": "something",
   "another_request_parameter": "something else",
@@ -491,6 +496,7 @@ type `example.type.foo`, it might submit something like this:
       "example_credential": "verypoorsharedsecret"
   }
 }
+```
 
 If the homeserver deems the authentication attempt to be successful but
 still requires more stages to be completed, it returns HTTP status 401
@@ -501,6 +507,7 @@ client has completed successfully:
     HTTP/1.1 401 Unauthorized
     Content-Type: application/json
 
+```json
 {
   "completed": [ "example.type.foo" ],
   "flows": [
@@ -518,6 +525,7 @@ client has completed successfully:
   },
   "session": "xxxxxx"
 }
+```
 
 Individual stages may require more than one request to complete, in
 which case the response will be as if the request was unauthenticated
@@ -531,6 +539,7 @@ status 401 response as above, with the addition of the standard
     HTTP/1.1 401 Unauthorized
     Content-Type: application/json
 
+```json
 {
   "errcode": "M_FORBIDDEN",
   "error": "Invalid password",
@@ -550,6 +559,7 @@ status 401 response as above, with the addition of the standard
   },
   "session": "xxxxxx"
 }
+```
 
 If the request fails for a reason other than authentication, the server
 returns an error message in the standard format. For example:
@@ -557,10 +567,12 @@ returns an error message in the standard format. For example:
     HTTP/1.1 400 Bad request
     Content-Type: application/json
 
+```json
 {
   "errcode": "M_EXAMPLE_ERROR",
   "error": "Something was wrong"
 }
+```
 
 If the client has completed all stages of a flow, the homeserver
 performs the API call and returns the result as normal. Completed stages
@@ -641,6 +653,7 @@ plain-text.
 To use this authentication type, clients should submit an auth dict as
 follows:
 
+```
 {
   "type": "m.login.password",
   "identifier": {
@@ -649,6 +662,7 @@ follows:
   "password": "<password>",
   "session": "<session ID>"
 }
+```
 
 where the `identifier` property is a user identifier object, as
 described in [Identifier types](#identifier-types).
@@ -656,6 +670,7 @@ described in [Identifier types](#identifier-types).
 For example, to authenticate using the user's Matrix ID, clients would
 submit:
 
+```json
 {
   "type": "m.login.password",
   "identifier": {
@@ -665,11 +680,13 @@ submit:
   "password": "<password>",
   "session": "<session ID>"
 }
+```
 
 Alternatively reply using a 3PID bound to the user's account on the
 homeserver using the `/account/3pid`\_ API rather than giving the `user`
 explicitly as follows:
 
+```json
 {
   "type": "m.login.password",
   "identifier": {
@@ -680,6 +697,7 @@ explicitly as follows:
   "password": "<password>",
   "session": "<session ID>"
 }
+```
 
 In the case that the homeserver does not know about the supplied 3PID,
 the homeserver must respond with 403 Forbidden.
@@ -695,11 +713,13 @@ The user completes a Google ReCaptcha 2.0 challenge
 To use this authentication type, clients should submit an auth dict as
 follows:
 
+```json
 {
   "type": "m.login.recaptcha",
   "response": "<captcha response>",
   "session": "<session ID>"
 }
+```
 
 #### Single Sign-On
 
@@ -730,6 +750,7 @@ information should be submitted to the homeserver.
 To use this authentication type, clients should submit an auth dict as
 follows:
 
+```json
 {
   "type": "m.login.email.identity",
   "threepidCreds": [
@@ -742,6 +763,7 @@ follows:
   ],
   "session": "<session ID>"
 }
+```
 
 Note that `id_server` (and therefore `id_access_token`) is optional if
 the `/requestToken` request did not include them.
@@ -762,6 +784,7 @@ information should be submitted to the homeserver.
 To use this authentication type, clients should submit an auth dict as
 follows:
 
+```json
 {
   "type": "m.login.msisdn",
   "threepidCreds": [
@@ -774,6 +797,7 @@ follows:
   ],
   "session": "<session ID>"
 }
+```
 
 Note that `id_server` (and therefore `id_access_token`) is optional if
 the `/requestToken` request did not include them.
@@ -798,10 +822,12 @@ server can instead send flows `m.login.recaptcha, m.login.dummy` and
 To use this authentication type, clients should submit an auth dict with
 just the type and session, if provided:
 
+```json
 {
   "type": "m.login.dummy",
   "session": "<session ID>"
 }
+```
 
 ##### Fallback
 
@@ -820,11 +846,13 @@ This MUST return an HTML page which can perform this authentication
 stage. This page must use the following JavaScript when the
 authentication has been completed:
 
+```js
 if (window.onAuthDone) {
     window.onAuthDone();
 } else if (window.opener && window.opener.postMessage) {
     window.opener.postMessage("authDone", "*");
 }
+```
 
 This allows the client to either arrange for the global function
 `onAuthDone` to be defined in an embedded browser, or to use the HTML5
@@ -836,15 +864,18 @@ Once a client receives the notification that the authentication stage
 has been completed, it should resubmit the request with an auth dict
 with just the session ID:
 
+```json
 {
   "session": "<session ID>"
 }
+```
 
 #### Example
 
 A client webapp might use the following JavaScript to open a popup
 window which will handle unknown login types:
 
+```js
 /**
  * Arguments:
  *     homeserverUrl: the base url of the homeserver (e.g. "https://matrix.org")
@@ -891,9 +922,9 @@ window which will handle unknown login types:
         "/fallback/web?session=" +
         encodeURIComponent(sessionID);
 
-
    popupWindow = window.open(url);
 }
+```
 
 ##### Identifier types
 
@@ -920,10 +951,12 @@ A client can identify a user using their Matrix ID. This can either be
 the fully qualified Matrix user ID, or just the localpart of the user
 ID.
 
+```json
 "identifier": {
   "type": "m.id.user",
   "user": "<user_id or user localpart>"
 }
+```
 
 #### Third-party ID
 
@@ -940,11 +973,13 @@ using the `/account/3pid`\_ API. See the [3PID
 Types](../appendices.html#pid-types) Appendix for a list of Third-party
 ID media.
 
+```json
 "identifier": {
   "type": "m.id.thirdparty",
   "medium": "<The medium of the third party identifier>",
   "address": "<The canonicalised third party address of the user>"
 }
+```
 
 #### Phone number
 
@@ -962,11 +997,13 @@ If the client wishes to canonicalise the phone number, then it can use
 the `m.id.thirdparty` identifier type with a `medium` of `msisdn`
 instead.
 
+```json
 "identifier": {
   "type": "m.id.phone",
   "country": "<The country that the phone number is from>",
   "phone": "<The phone number>"
 }
+```
 
 The `country` is the two-letter uppercase ISO-3166-1 alpha-2 country
 code that the number in `phone` should be parsed as if it were dialled
@@ -983,6 +1020,7 @@ API](#user-interactive-authentication-api).
 For a simple username/password login, clients should submit a `/login`
 request as follows:
 
+```json
 {
   "type": "m.login.password",
   "identifier": {
@@ -991,11 +1029,13 @@ request as follows:
   },
   "password": "<password>"
 }
+```
 
 Alternatively, a client can use a 3PID bound to the user's account on
 the homeserver using the `/account/3pid`\_ API rather than giving the
 `user` explicitly, as follows:
 
+```json
 {
   "type": "m.login.password",
   "identifier": {
@@ -1004,6 +1044,7 @@ the homeserver using the `/account/3pid`\_ API rather than giving the
   },
   "password": "<password>"
 }
+```
 
 In the case that the homeserver does not know about the supplied 3PID,
 the homeserver must respond with `403 Forbidden`.
@@ -1011,10 +1052,12 @@ the homeserver must respond with `403 Forbidden`.
 To log in using a login token, clients should submit a `/login` request
 as follows:
 
+```json
 {
   "type": "m.login.token",
   "token": "<login token>"
 }
+```
 
 As with [token-based]() interactive login, the `token` must encode the
 user ID. In the case that the token is not valid, the homeserver must
@@ -1166,6 +1209,7 @@ to change their password.
 
 An example of the capability API's response for this capability is:
 
+```json
 {
   "capabilities": {
     "m.change_password": {
@@ -1173,6 +1217,7 @@ An example of the capability API's response for this capability is:
     }
   }
 }
+```
 
 ### `m.room_versions` capability
 
@@ -1183,6 +1228,7 @@ upgrade their rooms.
 
 An example of the capability API's response for this capability is:
 
+```json
 {
   "capabilities": {
     "m.room_versions": {
@@ -1196,6 +1242,7 @@ An example of the capability API's response for this capability is:
     }
   }
 }
+```
 
 This capability mirrors the same restrictions of [room
 versions](../index.html#room-versions) to describe which versions are
@@ -1626,36 +1673,48 @@ There are several APIs provided to `GET` events for a room:
 
 Valid requests look like:
 
+```
 PUT /rooms/!roomid:domain/state/m.example.event
 { "key" : "without a state key" }
-
+```
+```
 PUT /rooms/!roomid:domain/state/m.another.example.event/foo
 { "key" : "with 'foo' as the state key" }
+```
 
 In contrast, these requests are invalid:
 
+```
 POST /rooms/!roomid:domain/state/m.example.event/
 { "key" : "cannot use POST here" }
-
+```
+```
 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`:
 
+```
 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:
 
+```
 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:
 
+```
 PUT /rooms/!roomid:domain/state/m.room.bgd.color
 { "color": "red", "hex": "#ff0000" }
+```
 
 {{room\_send\_cs\_http\_api}}
 
@@ -1872,19 +1931,23 @@ someone, the user performing the ban MUST have the required power level.
 To ban a user, a request should be made to `/rooms/<room_id>/ban`\_
 with:
 
+```json
 {
-      "user_id": "<user id to ban>"
+  "user_id": "<user id to ban>",
   "reason": "string: <reason for the ban>"
 }
+````
 
 Banning a user adjusts the banned member's membership state to `ban`.
 Like with other membership changes, a user can directly adjust the
 target member's state, by making a request to
 `/rooms/<room id>/state/m.room.member/<user id>`:
 
+```json
 {
   "membership": "ban"
 }
+```
 
 A user must be explicitly unbanned with a request to
 `/rooms/<room_id>/unban`\_ before they can re-join the room or be
@@ -1938,11 +2001,13 @@ Homeservers SHOULD implement rate limiting to reduce the risk of being
 overloaded. If a request is refused due to rate limiting, it should
 return a standard error response of the form:
 
+```json
 {
   "errcode": "M_LIMIT_EXCEEDED",
   "error": "string",
   "retry_after_ms": integer (optional)
 }
+```
 
 The `retry_after_ms` key SHOULD be included to tell the client how long
 they have to wait in milliseconds before they can try again.

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

@@ -99,6 +99,7 @@ with the following properties:
 
 Example:
 
+```json
 {
   "key":"06UzBknVHFMwgi7AVloY7ylC+xhOhEX4PkNge14Grl8",
   "signatures": {
@@ -107,6 +108,7 @@ Example:
     }
   }
 }
+```
 
 ##### Device keys
 
@@ -1239,6 +1241,7 @@ keys in [Server-side key backups](#server-side-key-backups) but adds the
 
 Example:
 
+```
 [
     {
         "algorithm": "m.megolm.v1.aes-sha2",
@@ -1255,6 +1258,7 @@ Example:
     },
     ...
 ]
+```
 
 #### Messaging Algorithms
 
@@ -1297,6 +1301,7 @@ device key, and must publish Curve25519 one-time keys.
 
 An event encrypted using Olm has the following format:
 
+```json
 {
   "type": "m.room.encrypted",
   "content": {
@@ -1310,6 +1315,7 @@ An event encrypted using Olm has the following format:
     }
   }
 }
+```
 
 `ciphertext` is a mapping from device Curve25519 key to an encrypted
 payload for that device. `body` is a Base64-encoded Olm message body.
@@ -1334,6 +1340,7 @@ message.
 
 The plaintext payload is of the form:
 
+```json
 {
   "type": "<type of the plaintext event>",
   "content": "<content for the plaintext event>",
@@ -1346,6 +1353,7 @@ The plaintext payload is of the form:
     "ed25519": "<sender_ed25519_key>"
   }
 }
+```
 
 The type and content of the plaintext message event are given in the
 payload.
@@ -1418,6 +1426,7 @@ Devices that support Megolm must support Olm, and include
 
 An event encrypted using Megolm has the following format:
 
+```json
 {
   "type": "m.room.encrypted",
   "content": {
@@ -1428,15 +1437,18 @@ An event encrypted using Megolm has the following format:
     "ciphertext": "<encrypted_payload_base_64>"
   }
 }
+```
 
 The encrypted payload can contain any message event. The plaintext is of
 the form:
 
+```json
 {
   "type": "<event_type>",
   "content": "<event_content>",
   "room_id": "<the room_id>"
 }
+```
 
 We include the room ID in the payload, because otherwise the homeserver
 would be able to change the room a message was sent in.
@@ -1554,6 +1566,7 @@ already shared a room.
 
 Example response:
 
+```json
 {
   "next_batch": "s72595_4483_1934",
   "rooms": {"leave": {}, "join": {}, "invite": {}},
@@ -1570,6 +1583,7 @@ Example response:
     "signed_curve25519": 20
   }
 }
+```
 
 #### Reporting that decryption keys are withheld
 

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

@@ -332,6 +332,7 @@ a rich reply, infinitely.
 
 An `m.in_reply_to` relationship looks like the following:
 
+```
 {
   ...
   "type": "m.room.message",
@@ -347,6 +348,7 @@ An `m.in_reply_to` relationship looks like the following:
     }
   }
 }
+```
 
 ####### Fallbacks and event representation
 

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

@@ -18,12 +18,14 @@ Mentions apply only to [m.room.message]() events where the `msgtype` is
 To make a mention, reference the entity being mentioned in the
 `formatted_body` using an anchor, like so:
 
+```json
 {
     "body": "Hello Alice!",
     "msgtype": "m.text",
     "format": "org.matrix.custom.html",
     "formatted_body": "Hello <a href='https://matrix.to/#/@alice:example.org'>Alice</a>!"
 }
+```
 
 #### Client behaviour
 

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

@@ -282,6 +282,7 @@ user. By default this rule is disabled.
 
 Definition
 
+```json
 {
     "rule_id": ".m.rule.master",
     "default": true,
@@ -291,6 +292,7 @@ Definition
         "dont_notify"
     ]
 }
+```
 
 ######## `.m.rule.suppress_notices`
 
@@ -298,6 +300,7 @@ Matches messages with a `msgtype` of `notice`.
 
 Definition:
 
+```json
 {
     "rule_id": ".m.rule.suppress_notices",
     "default": true,
@@ -313,6 +316,7 @@ Definition:
         "dont_notify",
     ]
 }
+```
 
 ######## `.m.rule.invite_for_me`
 
@@ -320,6 +324,7 @@ Matches any invites to a new room for this user.
 
 Definition:
 
+```json
 {
     "rule_id": ".m.rule.invite_for_me",
     "default": true,
@@ -349,6 +354,7 @@ Definition:
         }
     ]
 }
+```
 
 ######## `.m.rule.member_event`
 
@@ -356,6 +362,7 @@ Matches any `m.room.member_event`.
 
 Definition:
 
+```json
 {
     "rule_id": ".m.rule.member_event",
     "default": true,
@@ -371,6 +378,7 @@ Definition:
         "dont_notify"
     ]
 }
+```
 
 ######## `.m.rule.contains_display_name`
 
@@ -379,6 +387,7 @@ current display name in the room in which it was sent.
 
 Definition:
 
+```json
 {
     "rule_id": ".m.rule.contains_display_name",
     "default": true,
@@ -399,6 +408,7 @@ Definition:
         }
     ]
 }
+```
 
 ######## `.m.rule.tombstone`
 
@@ -408,6 +418,7 @@ an `@room` notification would accomplish.
 
 Definition:
 
+```json
 {
     "rule_id": ".m.rule.tombstone",
     "default": true,
@@ -431,6 +442,7 @@ Definition:
         }
     ]
 }
+```
 
 ######## `.m.rule.roomnotif`
 
@@ -439,6 +451,7 @@ Matches any message whose content is unencrypted and contains the text
 
 Definition:
 
+```json
 {
     "rule_id": ".m.rule.roomnotif",
     "default": true,
@@ -461,6 +474,7 @@ Definition:
         }
     ]
 }
+```
 
 ####### Default Content Rules
 
@@ -471,6 +485,7 @@ part of the user's Matrix ID, separated by word boundaries.
 
 Definition (as a `content` rule):
 
+```json
 {
     "rule_id": ".m.rule.contains_user_name",
     "default": true,
@@ -487,6 +502,7 @@ Definition (as a `content` rule):
         }
     ]
 }
+```
 
 ####### Default Underride Rules
 
@@ -496,6 +512,7 @@ Matches any incoming VOIP call.
 
 Definition:
 
+```json
 {
     "rule_id": ".m.rule.call",
     "default": true,
@@ -515,6 +532,7 @@ Definition:
         }
     ]
 }
+```
 
 ######## `.m.rule.encrypted_room_one_to_one`
 
@@ -526,6 +544,7 @@ encrypted (in 1:1 rooms) or none.
 
 Definition:
 
+```json
 {
     "rule_id": ".m.rule.encrypted_room_one_to_one",
     "default": true,
@@ -549,6 +568,7 @@ Definition:
         }
     ]
 }
+```
 
 ######## `.m.rule.room_one_to_one`
 
@@ -556,6 +576,7 @@ Matches any message sent in a room with exactly two members.
 
 Definition:
 
+```json
 {
     "rule_id": ".m.rule.room_one_to_one",
     "default": true,
@@ -579,6 +600,7 @@ Definition:
         }
     ]
 }
+```
 
 ######## `.m.rule.message`
 
@@ -586,6 +608,7 @@ Matches all chat messages.
 
 Definition:
 
+```json
 {
      "rule_id": ".m.rule.message",
      "default": true,
@@ -601,6 +624,7 @@ Definition:
          "notify"
      ]
 }
+```
 
 ######## `.m.rule.encrypted`
 
@@ -611,6 +635,7 @@ either matches *all* events that are encrypted (in group rooms) or none.
 
 Definition:
 
+```json
 {
      "rule_id": ".m.rule.encrypted",
      "default": true,
@@ -626,6 +651,7 @@ Definition:
          "notify"
      ]
 }
+```
 
 ##### Push Rules: API
 

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

@@ -68,6 +68,7 @@ before delivering them to clients.
 Receipts are sent across federation as EDUs with type `m.receipt`. The
 format of the EDUs are:
 
+```
 {
     <room_id>: {
         <receipt_type>: {
@@ -77,6 +78,7 @@ format of the EDUs are:
     },
     ...
 }
+```
 
 These are always sent as deltas to previously sent receipts. Currently
 only a single `<receipt_type>` should be used: `m.read`.

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

@@ -114,6 +114,7 @@ Some secret is encrypted using keys with ID `key_id_1` and `key_id_2`:
 
 `org.example.some.secret`:
 
+```
 {
   "encrypted": {
     "key_id_1": {
@@ -127,24 +128,29 @@ Some secret is encrypted using keys with ID `key_id_1` and `key_id_2`:
     }
   }
 }
+```
 
 and the key descriptions for the keys would be:
 
 `m.secret_storage.key.key_id_1`:
 
+```
 {
   "name": "Some key",
   "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
   // ... other properties according to algorithm
 }
+```
 
 `m.secret_storage.key.key_id_2`:
 
+```
 {
   "name": "Some other key",
   "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
   // ... other properties according to algorithm
 }
+```
 
 ###### `m.secret_storage.v1.aes-hmac-sha2`
 
@@ -247,15 +253,18 @@ correctly entered the key, clients should:
 For example, the `m.secret_storage.key.key_id` for a key using this
 algorithm could look like:
 
+```json
 {
   "name": "m.default",
   "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
   "iv": "random+data",
   "mac": "mac+of+encrypted+zeros"
 }
+```
 
 and data encrypted using this algorithm could look like this:
 
+```json
 {
   "encrypted": {
       "key_id": {
@@ -265,6 +274,7 @@ and data encrypted using this algorithm could look like this:
       }
   }
 }
+```
 
 ###### Key representation
 
@@ -339,6 +349,7 @@ in the `iterations` parameter.
 
 Example:
 
+```
 {
     "passphrase": {
         "algorithm": "m.pbkdf2",
@@ -348,6 +359,7 @@ Example:
     },
     ...
 }
+```
 
 #### Sharing
 
@@ -407,12 +419,14 @@ previous request. It is sent as an unencrypted to-device event.
 
 Example:
 
+```json
 {
   "name": "org.example.some.secret",
   "action": "request",
   "requesting_device_id": "ABCDEFG",
   "request_id": "randomly_generated_id_9573"
 }
+```
 
 ###### `m.secret.send`
 
@@ -444,7 +458,9 @@ an `m.secret.request` event. It must be encrypted as an
 
 Example:
 
+```json
 {
   "request_id": "randomly_generated_id_9573",
   "secret": "ThisIsASecretDon'tTellAnyone"
 }
+```

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

@@ -125,6 +125,7 @@ This module adds the following properties to the \_ response:
 
 Example response:
 
+```json
 {
   "next_batch": "s72595_4483_1934",
   "rooms": {"leave": {}, "join": {}, "invite": {}},
@@ -141,3 +142,4 @@ Example response:
     ]
   }
 }
+```

content/identity-service-api.md

@@ -69,10 +69,12 @@ communication, and all API calls use a Content-Type of
 Any errors which occur at the Matrix API level MUST return a "standard
 error response". This is a JSON object which looks like:
 
+```json
 {
   "errcode": "<error code>",
   "error": "<error message>"
 }
+```
 
 The `error` string will be a human-readable error message, usually a
 sentence explaining what went wrong. The `errcode` string will be a

content/server-server-api.md

@@ -248,6 +248,7 @@ and any query parameters if present, but should not include the leading
 
 Step 1 sign JSON:
 
+```
 {
     "method": "GET",
     "uri": "/target",
@@ -260,6 +261,7 @@ Step 1 sign JSON:
         }
     }
 }
+```
 
 The server names in the JSON above are the server names for each
 homeserver involved. Delegation from the [server name resolution
@@ -277,6 +279,7 @@ Step 2 add Authorization header:
 
 Example python code:
 
+```py
 def authorization_headers(origin_name, origin_signing_key,
                           destination_name, request_method, request_target,
                           content=None):
@@ -302,6 +305,7 @@ Example python code:
         ))
 
     return ("Authorization", authorization_headers)
+```
 
 ### Response Authentication
 
@@ -1121,6 +1125,7 @@ SHA-256.
 
 ### Example code
 
+```py
 def hash_and_sign_event(event_object, signing_key, signing_name):
     # First we need to hash the event object.
     content_hash = compute_content_hash(event_object)
@@ -1164,6 +1169,7 @@ SHA-256.
     event_json_bytes = encode_canonical_json(event_object)
 
     return hashlib.sha256(event_json_bytes)
+```
 
 ## Security considerations