.github/workflows/main.yml

@@ -1,8 +1,7 @@
 name: "Spec"
 
 env:
-  HUGO_VERSION: 0.148.1
+  HUGO_VERSION: 0.139.0
-  PYTHON_VERSION: 3.13
 
 on:
   push:
@@ -41,7 +40,7 @@ jobs:
       - name: "➕ Setup Python"
         uses: actions/setup-python@v5
         with:
-          python-version: ${{ env.PYTHON_VERSION }}
+          python-version: '3.9'
           cache: 'pip'
           cache-dependency-path: scripts/requirements.txt
       - name: "➕ Install dependencies"
@@ -60,7 +59,7 @@ jobs:
       - name: "➕ Setup Python"
         uses: actions/setup-python@v5
         with:
-          python-version: ${{ env.PYTHON_VERSION }}
+          python-version: '3.9'
           cache: 'pip'
           cache-dependency-path: scripts/requirements.txt
       - name: "➕ Install dependencies"
@@ -79,7 +78,7 @@ jobs:
       - name: "➕ Setup Python"
         uses: actions/setup-python@v5
         with:
-          python-version: ${{ env.PYTHON_VERSION }}
+          python-version: '3.9'
           cache: 'pip'
           cache-dependency-path: scripts/requirements.txt
       - name: "➕ Install dependencies"
@@ -121,7 +120,7 @@ jobs:
       - name: "➕ Setup Python"
         uses: actions/setup-python@v5
         with:
-          python-version: ${{ env.PYTHON_VERSION }}
+          python-version: '3.9'
           cache: 'pip'
           cache-dependency-path: scripts/requirements.txt
       - name: "➕ Install dependencies"
@@ -155,11 +154,6 @@ jobs:
               --api server-server \
               -r "$RELEASE" \
               -o spec/server-server-api/api.json
-          scripts/dump-openapi.py \
-              --base-url "https://spec.matrix.org${{ needs.calculate-baseurl.outputs.baseURL }}" \
-              --api identity \
-              -r "$RELEASE" \
-              -o spec/identity-service-api/api.json
           tar -czf openapi.tar.gz spec
       - name: "📤 Artifact upload"
         uses: actions/upload-artifact@v4
@@ -178,7 +172,7 @@ jobs:
       - name: "➕ Setup Python"
         uses: actions/setup-python@v5
         with:
-          python-version: ${{ env.PYTHON_VERSION }}
+          python-version: '3.9'
       - name: "➕ Install towncrier"
         run: "pip install 'towncrier'"
       - name: "Generate changelog"
@@ -289,11 +283,10 @@ jobs:
           npm i
           npm run get-proposals
       - name: "⚙️ hugo"
-        env:
-          HUGO_PARAMS_VERSION_STATUS: "historical"
         # Create a baseURL like `/v1.2` out of the `v1.2` tag
         run: |
-          hugo --baseURL "/${GITHUB_REF/refs\/tags\//}" -d "spec"
+          echo -e '[params.version]\nstatus="historical"' > historical.toml
+          hugo --config config.toml,historical.toml --baseURL "/${GITHUB_REF/refs\/tags\//}" -d "spec"
 
       - name: "📥 Spec definition download"
         uses: actions/download-artifact@v4

.github/workflows/release.yaml

@@ -12,9 +12,6 @@ jobs:
     defaults:
       run:
         working-directory: packages/npm
-    permissions:
-      contents: read
-      id-token: write
     steps:
       - name: 🧮 Checkout code
         uses: actions/checkout@v4
@@ -26,10 +23,6 @@ jobs:
           cache-dependency-path: packages/npm/yarn.lock
           registry-url: "https://registry.npmjs.org"
 
-      # Ensure npm 11.5.1 or later is installed
-      - name: Update npm
-        run: npm install -g npm@latest
-
       - name: 🔨 Install dependencies
         run: "yarn install --frozen-lockfile"
 
@@ -40,4 +33,10 @@ jobs:
           VERSION: ${{ github.event.release.tag_name }}.0
 
       - name: 🚀 Publish to npm
-        run: npm publish --provenance --access public --tag latest
+        id: npm-publish
+        uses: JS-DevTools/npm-publish@19c28f1ef146469e409470805ea4279d47c3d35c # v3.1.1
+        with:
+          token: ${{ secrets.NPM_TOKEN }}
+          package: packages/npm
+          access: public
+          ignore-scripts: false

README.md

@@ -61,7 +61,7 @@ place after an MSC has been accepted, not as part of a proposal itself.
 
 1. Install the extended version (often the OS default) of Hugo:
    <https://gohugo.io/getting-started/installing>. Note that at least Hugo
-   v0.146.0 is required.
+   v0.123.1 is required.
 
    Alternatively, use the Docker image at
    https://hub.docker.com/r/klakegg/hugo/. (The "extended edition" is required

assets/js/versions.template.js

@@ -1,106 +0,0 @@
-/*
-Copyright 2025 The Matrix.org Foundation C.I.C.
-
-Licensed under the Apache License, Version 2.0 (the "License");
-you may not use this file except in compliance with the License.
-You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-*/
-
-// Determine the current version as defined in hugo.toml. This will either be
-// "unstable" or "vX.X" and doesn't depend on the current URL.
-//
-// The oddity below is an attempt at producing a readable Hugo template while
-// avoiding JS syntax errors in your IDE.
-const currentVersion = `{{ if eq .Site.Params.version.status "unstable" }}
-    {{- /**/ -}}
-    unstable
-    {{- /**/ -}}
-{{ else }}
-    {{- /**/ -}}
-    {{ printf "v%s.%s" .Site.Params.version.major .Site.Params.version.minor }}
-    {{- /**/ -}}
-{{ end }}`;
-
-// Determine the current version segment by regex matching the URL. This will either
-// be "unstable", "latest", "vX.X" (production) or undefined (local & netlify).
-const href = window.location.href;
-const segmentMatches = href.match(/(?<=\/)unstable|latest|v\d+.\d+(?=\/)/);
-const currentSegment = segmentMatches ? segmentMatches[0] : undefined;
-
-// Determine the selected menu element. If we were able to obtain the version
-// segment from the URL (production), use that. Otherwise (local & netlify),
-// fall back to the version as defined in Hugo.
-const selected = currentSegment ?? currentVersion;
-
-function appendVersion(parent, name, url) {
-    // The list item
-    const li = document.createElement("li");
-    if (name === selected) {
-        li.classList.add("selected");
-    }
-    if (name === "latest") {
-        li.classList.add("latest");
-    }
-    parent.appendChild(li);
-
-    // The link
-    const a = document.createElement("a");
-    a.classList.add("dropdown-item");
-    a.setAttribute("href", url);
-    li.appendChild(a);
-
-    // Handle clicks manually to preserve the current path / fragment
-    a.addEventListener("click", (ev) => {
-        // If the URL is a relative link (i.e. the historical versions changelog), just
-        // let the browser load it
-        if (url.startsWith("/")) {
-            return;
-        }
-
-        // If we couldn't determine the current segment, we cannot safely replace
-        // it and have to let the browser load the (root) URL instead
-        if (!currentSegment) {
-            return;
-        }
-
-        // Otherwise, stop further event handling and replace the segment
-        ev.preventDefault();
-        ev.stopPropagation();
-        window.location.href = href.replace(`/${currentSegment}/`, `/${name}/`);
-    });
-
-    // The link text
-    const text = document.createTextNode(name);
-    a.appendChild(text);
-}
-
-fetch("/latest/versions.json")
-    .then(r => r.json())
-    .then(versions => {
-        // Find the surrounding list element
-        const ul = document.querySelector("ul#version-selector");
-        if (!ul) {
-            console.error("Cannot populate version selector: ul element not found");
-            return;
-        }
-
-        // Add a entries for the unstable version and the "latest" shortcut
-        appendVersion(ul, "unstable", "https://spec.matrix.org/unstable");
-        appendVersion(ul, "latest", "https://spec.matrix.org/latest");
-
-        // Add an entry for each proper version
-        for (const version of versions) {
-            appendVersion(ul, version.name, `https://spec.matrix.org/${version.name}`);
-        }
-
-        // For historical versions, simply link to the changelog
-        appendVersion(ul, "historical", '{{ (site.GetPage "changelog/historical").RelPermalink }}');
-    });

assets/scss/_styles_project.scss

@@ -50,20 +50,6 @@ Custom SCSS for the Matrix spec
   a {
     color: $black;
   }
-
-  /* Make the version dropdown scroll if its too large */
-  ul#version-selector {
-    max-height: 80vh;
-    overflow-y: auto;
-  }
-
-  ul#version-selector li.selected a {
-    font-weight: bold;
-  }
-
-  ul#version-selector li.latest a {
-    color: $secondary;
-  }
 }
 
 /* Styles for the sidebar nav */
@@ -330,19 +316,13 @@ Custom SCSS for the Matrix spec
   h2 {
     font-weight: $font-weight-bold;
     font-size: 1.3rem;
-    margin: 1.5rem 0 1rem 0;
+    margin: 3rem 0 .5rem 0;
   }
 
   h3 {
     font-weight: $font-weight-bold;
     font-size: 1.1rem;
-    margin: 1.5rem 0 1rem 0;
+    margin: 1.5rem 0 .75rem 0;
-
-  }
-
-  /* Reduce top margin of h3 if previous sibling is a h2 */
-  h2 + h3 {
-    margin-top: 1rem;
   }
 
   hr {
@@ -387,6 +367,11 @@ Custom SCSS for the Matrix spec
       }
     }
 
+    // add some space between two tables when they are right next to each other
+    & + table {
+        margin-top: 4rem;
+    }
+
     caption {
       caption-side: top;
       color: $dark;
@@ -458,17 +443,6 @@ Custom SCSS for the Matrix spec
     }
   }
 
-  /* Have consistent spacing around tables and examples */
-  table, .highlight {
-    margin-top: 0;
-    margin-bottom: 2rem;
-
-    /* We don't need the margin on the last child of the .rendered-data block */
-    &:last-child {
-      margin-bottom: 0;
-    } 
-  }
-
   pre {
     border: 0;
     border-left: solid 5px $secondary;
@@ -516,13 +490,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/application_service/newsfragments/2213.clarification

@@ -1 +0,0 @@
-Fix JSON formatting in the "Server admin style permissions" examples.

changelogs/application_service/newsfragments/2221.feature

@@ -1 +0,0 @@
-Allow application services to masquerade as specific devices belonging to users, as per [MSC4326](https://github.com/matrix-org/matrix-spec-proposals/pull/4326).

changelogs/client_server/newsfragments/2186.removal

@@ -1 +0,0 @@
-Remove legacy mentions, as per [MSC4210](https://github.com/matrix-org/matrix-spec-proposals/issues/4210).

changelogs/client_server/newsfragments/2214.clarification

@@ -1 +0,0 @@
-Push rule IDs are globally unique within their kind.

changelogs/client_server/newsfragments/2215.clarification

@@ -1 +0,0 @@
-Don't advertise `creator` field in description of room creation.

changelogs/client_server/newsfragments/2216.clarification

@@ -1 +0,0 @@
-`room_id` is required for peeking via `/_matrix/client/v3/events`.

changelogs/client_server/newsfragments/2217.clarification

@@ -1 +0,0 @@
-The `server-name` segment of MXC URIs is sanitised differently from the `media-id` segment.

changelogs/client_server/newsfragments/2221.feature

@@ -1 +0,0 @@
-Allow application services to masquerade as specific devices belonging to users, as per [MSC4326](https://github.com/matrix-org/matrix-spec-proposals/pull/4326).

changelogs/client_server/newsfragments/2223.clarification

@@ -1 +0,0 @@
-Add note to each endpoint that uses capability negotiation.

changelogs/client_server/newsfragments/2224.clarification

@@ -1 +0,0 @@
-Fix various typos throughout the specification.

changelogs/client_server/newsfragments/2225.clarification

@@ -1 +0,0 @@
-Additional OpenGraph properties can be present in URL previews.

changelogs/client_server/newsfragments/2227.clarification

@@ -1 +0,0 @@
-Fix various typos throughout the specification.

changelogs/client_server/newsfragments/2231.clarification

@@ -1 +0,0 @@
-Clarify the special casing of membership events and redactions in power levels.

changelogs/client_server/newsfragments/2232.clarification

@@ -1 +0,0 @@
-`M_RESOURCE_LIMIT_EXCEEDED` is now listed as a common error code.

changelogs/client_server/newsfragments/2233.clarification

@@ -1 +0,0 @@
-Add `m.login.terms` to enumeration of authentication types.

changelogs/client_server/newsfragments/2234.feature

@@ -1 +0,0 @@
-Add the `m.oauth` authentication type for User-Interactive Authentication as per [MSC4312](https://github.com/matrix-org/matrix-spec-proposals/pull/4312).

changelogs/client_server/newsfragments/2240.clarification

@@ -1 +0,0 @@
-Clarify how to use `state_after` ahead of declaring full support for its spec version.

changelogs/client_server/newsfragments/2245.clarification

@@ -1 +0,0 @@
-`device_one_time_keys_count` is only optional if no unclaimed one-time keys exist.

changelogs/client_server/newsfragments/2246.clarification

@@ -1 +0,0 @@
-Clarify that servers may choose not to use `M_USER_DEACTIVATED` at login time, for example for privacy reasons when they can't authenticate deactivated users.

changelogs/client_server/newsfragments/2250.clarification

@@ -1 +0,0 @@
-Minor grammatical fix in the Secrets module description.

changelogs/client_server/newsfragments/2255.clarification

@@ -1 +0,0 @@
-Usage of the `event_id_only` format for push notifications is not mandatory.

changelogs/internal/newsfragments/2219.clarification

@@ -1 +0,0 @@
-Swapped icon for X (fka. twitter) to updated logo in footer.

changelogs/internal/newsfragments/2226.clarification

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

changelogs/internal/newsfragments/2238.clarification

@@ -1 +0,0 @@
-Silence failing redocly-cli rule.

changelogs/internal/newsfragments/2239.clarification

@@ -1 +0,0 @@
-Use NPM Trusted Publishers for publishing `@matrix-org/spec` to npm.

changelogs/internal/newsfragments/2241.clarification

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

changelogs/internal/newsfragments/2242.clarification

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

changelogs/internal/newsfragments/2256.clarification

@@ -1 +0,0 @@
-Add version picker in the navbar.

changelogs/room_versions/newsfragments/2220.clarification

@@ -1 +0,0 @@
-In room versions 8 through 12, clarify that "sufficient permission to invite users" on restricted joins also includes being a joined member of the room.

changelogs/room_versions/newsfragments/2249.clarification

@@ -1 +0,0 @@
-In room versions 3 through 12, clarify that when you have the power to redact, it is possible to redact events that you don't have the power to send.  

config/_default/hugo.toml

@@ -8,7 +8,7 @@ enableRobotsTXT = true
 # We disable RSS, because (a) it's useless, (b) Hugo seems to generate broken
 # links to it when used with a --baseURL (for example, https://spec.matrix.org/v1.4/
 # contains `<link rel="alternate" type="application/rss&#43;xml" href="/v1.4/v1.4/index.xml">`).
-disableKinds = ["taxonomy", "rss"]
+disableKinds = ["taxonomy", "RSS"]
 
 [languages]
 [languages.en]
@@ -23,15 +23,15 @@ description = "Home of the Matrix specification for decentralised communication"
 [menus]
 [[menus.main]]
     name = 'Foundation'
-    url = 'https://matrix.org/foundation/about/'
+    url = 'https://matrix.org/foundation/'
     weight = 10
 [[menus.main]]
-    name = 'User Docs'
+    name = 'FAQs'
-    url = 'https://matrix.org/docs/'
+    url = 'https://matrix.org/faq'
     weight = 20
 [[menus.main]]
     name = 'Blog'
-    url = 'https://matrix.org/blog/'
+    url = 'https://matrix.org/blog/posts'
     weight = 30
 
 [markup]
@@ -43,15 +43,6 @@ description = "Home of the Matrix specification for decentralised communication"
     [markup.goldmark.renderer]
       # Enables us to render raw HTML
       unsafe = true
-    [markup.goldmark.extensions]
-      # Tell Goldmark to pass delimited blocks through the `render-passthrough` render hook.
-      # This is used to render the maths in the Olm spec.
-      # See: https://gohugo.io/functions/transform/tomath/#step-1.
-      [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:
@@ -70,17 +61,13 @@ copyright = "The Matrix.org Foundation CIC"
 [params.version]
 # must be one of "unstable", "current", "historical"
 # this is used to decide whether to show a banner pointing to the current release
-status = "unstable"
+status = "stable"
 # A URL pointing to the latest, stable release of the spec. To be shown in the unstable version warning banner.
 current_version_url = "https://spec.matrix.org/latest"
 # The following is used when status = "stable", and is displayed in various UI elements on a released version
 # of the spec.
-# major = "1"
+major = "1"
-# minor = "16"
+minor = "14"
-
-[[params.versions]]
-# We must include this parameter to enable docsy's version picker in the navbar. The picker
-# is populated automatically in navbar-version-selector.html.
 
 # User interface configuration
 [params.ui]
@@ -123,7 +110,7 @@ sidebar_menu_compact = true
 [[params.links.bottom]]
 	name = "Twitter"
 	url = "https://twitter.com/matrixdotorg"
-	icon = "fab fa-x-twitter"
+	icon = "fab fa-twitter"
   desc = "Matrix on Twitter"
 
 
@@ -134,9 +121,7 @@ sidebar_menu_compact = true
 [[server.headers]]
   for = '/**'
   [server.headers.values]
-    # `style-src 'unsafe-inline'` is needed to correctly render the maths in the Olm spec:
+    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'"
-    # https://github.com/KaTeX/KaTeX/issues/4096
-    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"
@@ -149,7 +134,7 @@ sidebar_menu_compact = true
 [module]
   [module.hugoVersion]
     extended = true
-    min = "0.146.0"
+    min = "0.123.1"
   [[module.imports]]
     path = "github.com/matrix-org/docsy"
     disable = false

content/_index.md

@@ -25,7 +25,6 @@ The specification consists of the following parts:
 * [Identity Service API](/identity-service-api)
 * [Push Gateway API](/push-gateway-api)
 * [Room Versions](/rooms)
-* [Olm & Megolm](/olm-megolm)
 * [Appendices](/appendices)
 
 Additionally, this introduction page contains the key baseline
@@ -152,7 +151,7 @@ request.
 
 How data flows between clients:
 
-```nohighlight
+```
     { Matrix client A }                             { Matrix client B }
         ^          |                                    ^          |
         |  events  |  Client-Server API                 |  events  |

content/appendices.md

@@ -657,48 +657,27 @@ provides no way to encode ASCII punctuation).
 
 #### Room IDs
 
-{{% changed-in v="1.16" %}} Room IDs can now appear without a domain depending on
+A room has exactly one room ID. A room ID has the format:
-the room version.
-
-A room has exactly one room ID. Room IDs take the form:
-
-    !opaque_id
-
-However, the precise format depends upon the [room version specification](/rooms):
-some room versions included a `domain` component, whereas more recent room versions
-omit the domain and use a base64-encoded hash instead.
-
-Room IDs are case-sensitive and not meant to be human-readable. They are intended
-to be used as fully opaque strings by clients, even when a `domain` component is
-present.
-
-If the room version requires a `domain` component, room IDs take the following
-form:
 
     !opaque_id:domain
 
-In such a form, the `opaque_id` is a localpart. The localpart MUST only contain
+The `domain` of a room ID is the [server name](#server-name) of the
-valid non-surrogate Unicode code points, including control characters, except `:`
+homeserver which created the room. The domain is used only for
-and `NUL` (U+0000). The localpart SHOULD only consist of alphanumeric characters
+namespacing to avoid the risk of clashes of identifiers between
-(`A-Z`, `a-z`, `0-9`) when generating them. The `domain` is the [server name](#server-name)
+different homeservers. There is no implication that the room in
-of the homeserver which created the room - it is only used to reduce namespace
+question is still available at the corresponding homeserver.
-collisions. There is no implication that the room in question is still available
-at the corresponding homeserver. Combined, the localpart, domain, and `!` sigil
-MUST NOT exceed 255 bytes.
 
-When a room version requires the `domain`-less format, room IDs are simply the
+Room IDs are case-sensitive. They are not meant to be
-[event ID](#event-ids) of the `m.room.create` event using `!` as the sigil instead
+human-readable. They are intended to be treated as fully opaque strings
-of `$`. The grammar is otherwise inherited verbatim.
+by clients.
 
-{{% boxes/note %}}
+The localpart of a room ID (`opaque_id` above) may contain any valid
-Applications which previously relied upon the `domain` in a room ID can instead
+non-surrogate Unicode code points, including control characters, except `:` and `NUL`
-parse the [user IDs](#user-identifiers) found in the `m.room.create` event's `sender`.
+(U+0000), but it is recommended to only include ASCII letters and
+digits (`A-Z`, `a-z`, `0-9`) when generating them.
 
-Though the `m.room.create` event's `additional_creators` (in `content`) may be
+The length of a room ID, including the `!` sigil and the domain, MUST
-used when present, applications should take care when parsing or interpreting the
+NOT exceed 255 bytes.
-list. The user IDs in `additional_creators` will have correct grammar, but may
-not be real users or may not belong to actual Matrix homeservers.
-{{% /boxes/note %}}
 
 #### Room Aliases
 
@@ -749,13 +728,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 +844,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"}
@@ -356,7 +356,6 @@ service would like to masquerade as.
 Inputs:
 -   Application service token (`as_token`)
 -   User ID in the AS namespace to act as.
--   Device ID belonging to the User ID to act with.
 
 Notes:
 -   This applies to all aspects of the Client-Server API, except for
@@ -376,19 +375,9 @@ service's `user` namespaces. If the parameter is missing, the homeserver
 is to assume the application service intends to act as the user implied
 by the `sender_localpart` property of the registration.
 
-{{% added-in v="1.17" %}} Application services MAY similarly masquerade
-as a specific device ID belonging the user ID through use of the `device_id`
-query string parameter on the request. If the given device ID is not known
-to belong to the user, the server will return a 400 `M_UNKNOWN_DEVICE` error.
-If no `user_id` is supplied, the `device_id` MUST belong to the user implied
-by the `sender_localpart` property of the application service's registration.
-If no `device_id` is supplied, the homeserver is to assume the request is
-being made without a device ID and will fail to complete operations which
-require a device ID (such as uploading one-time keys).
-
 An example request would be:
 
-    GET /_matrix/client/v3/account/whoami?user_id=@_irc_user:example.org&device_id=ABC123
+    GET /_matrix/client/v3/account/whoami?user_id=@_irc_user:example.org
     Authorization: Bearer YourApplicationServiceTokenHere
 
 #### Timestamp massaging
@@ -449,8 +438,8 @@ user ID without a password.
 
     Content:
     {
-      "type": "m.login.application_service",
+      type: "m.login.application_service",
-      "username": "_irc_example"
+      username: "_irc_example"
     }
 
 Similarly, logging in as users needs API changes in order to allow the AS to
@@ -465,7 +454,7 @@ log in without needing the user's password. This is achieved by including the
 
     Content:
     {
-      "type": "m.login.application_service",
+      type: "m.login.application_service",
       "identifier": {
         "type": "m.id.user",
         "user": "_irc_example"
@@ -503,10 +492,10 @@ via the query string). It is expected that the application service use
 the transactions pushed to it to handle events rather than syncing with
 the user implied by `sender_localpart`.
 
-#### Published room directories
+#### Application service room directories
 
-Application services can maintain their own published room directories for
+Application services can maintain their own room directories for their
-their defined third-party protocols. These directories may be accessed by
+defined third-party protocols. These room directories may be accessed by
 clients through additional parameters on the `/publicRooms`
 client-server endpoint.
 

content/changelog/_index.md

@@ -1,7 +1,6 @@
 ---
 title: Changelog
 type: docs
-layout: changelog-index
 weight: 1000
 ---
 

content/changelog/v1.15.md

@@ -1,97 +0,0 @@
----
-title: v1.15 Changelog
-linkTitle: v1.15
-type: docs
-layout: changelog
-outputs:
-  - html
-  - checklist
-date: 2025-06-26
----
-
-## Client-Server API
-
-**New Endpoints**
-
-- Add `GET /_matrix/client/v1/room_summary/{roomIdOrAlias}`, as per [MSC3266](https://github.com/matrix-org/matrix-spec-proposals/pull/3266). ([#2125](https://github.com/matrix-org/matrix-spec/issues/2125))
-- Add `GET /_matrix/client/v1/auth_metadata`, as per [MSC2965](https://github.com/matrix-org/matrix-spec-proposals/pull/2965). ([#2147](https://github.com/matrix-org/matrix-spec/issues/2147))
-
-**Backwards Compatible Changes**
-
-- Add `m.topic` content block to enable rich text in `m.room.topic` events as per [MSC3765](https://github.com/matrix-org/matrix-spec-proposals/pull/3765). ([#2095](https://github.com/matrix-org/matrix-spec/issues/2095))
-- Include device keys with Olm-encrypted events as per [MSC4147](https://github.com/matrix-org/matrix-spec-proposals/pull/4147). ([#2122](https://github.com/matrix-org/matrix-spec/issues/2122))
-- Add `/_matrix/client/v1/room_summary/{roomIdOrAlias}` and extend `/_matrix/client/v1/rooms/{roomId}/hierarchy` with the new optional properties `allowed_room_ids`, `encryption` and `room_version` as per [MSC3266](https://github.com/matrix-org/matrix-spec-proposals/pull/3266). ([#2125](https://github.com/matrix-org/matrix-spec/issues/2125), [#2158](https://github.com/matrix-org/matrix-spec/issues/2158))
-- Add the OAuth 2.0 based authentication API, as per [MSC3861](https://github.com/matrix-org/matrix-spec-proposals/pull/3861) and its sub-proposals. ([#2141](https://github.com/matrix-org/matrix-spec/issues/2141), [#2148](https://github.com/matrix-org/matrix-spec/issues/2148), [#2149](https://github.com/matrix-org/matrix-spec/issues/2149), [#2150](https://github.com/matrix-org/matrix-spec/issues/2150), [#2151](https://github.com/matrix-org/matrix-spec/issues/2151), [#2159](https://github.com/matrix-org/matrix-spec/issues/2159), [#2164](https://github.com/matrix-org/matrix-spec/issues/2164))
-
-**Spec Clarifications**
-
-- Clarify behaviour when the `topic` key of a `m.room.topic` event is absent, null, or empty. ([#2068](https://github.com/matrix-org/matrix-spec/issues/2068))
-- Fix the example of the `GET /sync` endpoint and the `m.room.member` example used in several places. ([#2077](https://github.com/matrix-org/matrix-spec/issues/2077))
-- Clarify the format of third-party invites, including the fact that identity server public keys can be encoded using standard or URL-safe base64. ([#2083](https://github.com/matrix-org/matrix-spec/issues/2083))
-- "Public" rooms in profile look-ups are defined through their join rule and history visibility. ([#2101](https://github.com/matrix-org/matrix-spec/issues/2101))
-- "Public" rooms in user directory queries are defined through their join rule and history visibility. ([#2102](https://github.com/matrix-org/matrix-spec/issues/2102))
-- Rooms published in `/publicRooms` don't necessarily have `public` join rules or `world_readable` history visibility. ([#2104](https://github.com/matrix-org/matrix-spec/issues/2104))
-- "Public" rooms with respect to call invites are defined through their join rule. ([#2106](https://github.com/matrix-org/matrix-spec/issues/2106))
-- "Public" rooms have no specific meaning with respect to moderation policy lists. ([#2107](https://github.com/matrix-org/matrix-spec/issues/2107))
-- "Public" rooms with respect to presence are defined through their join rule. ([#2108](https://github.com/matrix-org/matrix-spec/issues/2108))
-- Spaces are subject to the same access mechanisms as rooms. ([#2109](https://github.com/matrix-org/matrix-spec/issues/2109))
-- Fix various typos throughout the specification. ([#2121](https://github.com/matrix-org/matrix-spec/issues/2121), [#2144](https://github.com/matrix-org/matrix-spec/issues/2144))
-- Clarify that Well-Known URIs are available on the server name's hostname. Contributed by @HarHarLinks. ([#2140](https://github.com/matrix-org/matrix-spec/issues/2140))
-- Add missing fields in example for `ExportedSessionData`. ([#2154](https://github.com/matrix-org/matrix-spec/issues/2154))
-
-
-## Server-Server API
-
-**Backwards Compatible Changes**
-
-- Add `m.topic` content block to enable rich text in `m.room.topic` events as per [MSC3765](https://github.com/matrix-org/matrix-spec-proposals/pull/3765). ([#2095](https://github.com/matrix-org/matrix-spec/issues/2095))
-- Extend `/_matrix/federation/v1/hierarchy/{roomId}` with the new optional properties `encryption` and `room_version` as per [MSC3266](https://github.com/matrix-org/matrix-spec-proposals/pull/3266). ([#2125](https://github.com/matrix-org/matrix-spec/issues/2125))
-
-**Spec Clarifications**
-
-- Add a note to the invite endpoints that invites to local users may be received twice over federation if the homeserver is already in the room. ([#2067](https://github.com/matrix-org/matrix-spec/issues/2067))
-- Clarify the format of third-party invites, including the fact that identity server public keys can be encoded using standard or URL-safe base64. ([#2083](https://github.com/matrix-org/matrix-spec/issues/2083))
-- Clarify that auth event of `content.join_authorised_via_users_server` is only necessary for `m.room.member` with a `membership` of `join`. ([#2100](https://github.com/matrix-org/matrix-spec/issues/2100))
-- Rooms published in `/publicRooms` don't necessarily have `public` join rules or `world_readable` history visibility. ([#2104](https://github.com/matrix-org/matrix-spec/issues/2104))
-- Fix various typos throughout the specification. ([#2128](https://github.com/matrix-org/matrix-spec/issues/2128))
-- Clarify that Well-Known URIs are available on the server name's hostname. Contributed by @HarHarLinks. ([#2140](https://github.com/matrix-org/matrix-spec/issues/2140))
-
-
-## Application Service API
-
-**Spec Clarifications**
-
-- Clarify in the application service registration schema the `url: null` behaviour. ([#2130](https://github.com/matrix-org/matrix-spec/issues/2130))
-
-
-## Identity Service API
-
-**Spec Clarifications**
-
-- Clarify that public keys can be encoded using standard or URL-safe base64. ([#2083](https://github.com/matrix-org/matrix-spec/issues/2083))
-
-
-## Push Gateway API
-
-No significant changes.
-
-
-## Room Versions
-
-No significant changes.
-
-
-## Appendices
-
-No significant changes.
-
-
-## Internal Changes/Tooling
-
-**Spec Clarifications**
-
-- Adjust margins in rendered endpoints. ([#2081](https://github.com/matrix-org/matrix-spec/issues/2081))
-- Replace Hugo shortcodes in OpenAPI output. ([#2088](https://github.com/matrix-org/matrix-spec/issues/2088))
-- Add [well-known funding manifest urls](https://floss.fund/funding-manifest/) to spec to authorise https://matrix.org/funding.json. Contributed by @HarHarLinks. ([#2115](https://github.com/matrix-org/matrix-spec/issues/2115))
-- Fix the historical info box when generating the historical spec in CI. ([#2123](https://github.com/matrix-org/matrix-spec/issues/2123))
-- Update the header navigation menu with links to modern matrix.org. Contributed by @HarHarLinks. ([#2137](https://github.com/matrix-org/matrix-spec/issues/2137))

content/changelog/v1.16.md

@@ -1,103 +0,0 @@
----
-title: v1.16 Changelog
-linkTitle: v1.16
-type: docs
-layout: changelog
-outputs:
-  - html
-  - checklist
-date: 2025-09-17
----
-
-## Client-Server API
-
-**Deprecations**
-
-- Deprecate `m.set_avatar_url` and `m.set_displayname` capabilities, as per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). ([#2071](https://github.com/matrix-org/matrix-spec/issues/2071))
-
-**Removed Endpoints**
-
-- Remove unintentional intentional mentions in replies, as per [MSC4142](https://github.com/matrix-org/matrix-spec-proposals/pull/4142). ([#2210](https://github.com/matrix-org/matrix-spec/issues/2210))
-
-**Backwards Compatible Changes**
-
-- Update user profile endpoints to handle custom fields, and add a new `m.profile_fields` capability, as per [MSC4133](https://github.com/matrix-org/matrix-spec-proposals/pull/4133). ([#2071](https://github.com/matrix-org/matrix-spec/issues/2071))
-- Add `format` query parameter to `GET /state/{eventType}/{stateKey}` to allow fetching metadata of a specific state event. ([#2175](https://github.com/matrix-org/matrix-spec/issues/2175))
-- Add the `use_state_after` query parameter and `state_after` response property to `GET /sync`, as per [MSC4222](https://github.com/matrix-org/matrix-spec-proposals/issues/4222). ([#2187](https://github.com/matrix-org/matrix-spec/issues/2187))
-- When upgrading rooms to [room version 12](/rooms/v12), `additional_creators` may be specified on the [`POST /_matrix/client/v3/rooms/{roomId}/upgrade`](/client-server-api/#post_matrixclientv3roomsroomidupgrade) endpoint, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-- When creating rooms with [room version 12](/rooms/v12), the `trusted_private_chat` preset should merge the invitees into the supplied `content.additional_creators` in the resulting room, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-- In [room version 12](/rooms/v12), the power level of room creators is now infinitely high as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-- In [room version 12](/rooms/v12), room IDs no longer have a domain component as per [MSC4291](https://github.com/matrix-org/matrix-spec-proposals/pull/4291). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-- When creating rooms with [room version 12](/rooms/v12), the initial power levels will restrict the ability to upgrade rooms by default, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-- Add a profile field for a user's time zone, as per [MSC4175](https://github.com/matrix-org/matrix-spec-proposals/pull/4175). ([#2206](https://github.com/matrix-org/matrix-spec/issues/2206))
-- Invites and knocks are now expected to contain the `m.room.create` event in their stripped state entries, as per [MSC4311](https://github.com/matrix-org/matrix-spec-proposals/pull/4311). ([#2207](https://github.com/matrix-org/matrix-spec/issues/2207))
-
-**Spec Clarifications**
-
-- Clarify that `format` is required if `formatted_body` is specified. ([#2167](https://github.com/matrix-org/matrix-spec/issues/2167))
-- The `latest_event` in an aggregated set of thread events uses the same format as the event itself. ([#2169](https://github.com/matrix-org/matrix-spec/issues/2169))
-- Fix various typos throughout the specification. ([#2171](https://github.com/matrix-org/matrix-spec/issues/2171), [#2177](https://github.com/matrix-org/matrix-spec/issues/2177), [#2179](https://github.com/matrix-org/matrix-spec/issues/2179))
-- Clarify that clients should replace events with the most recent replacement by `origin_server_ts`. ([#2190](https://github.com/matrix-org/matrix-spec/issues/2190))
-- Fix `/sync` flow referencing incorrect parameter to use with `/messages`. ([#2195](https://github.com/matrix-org/matrix-spec/issues/2195))
-- Clarify wording around the `world_readable` history visibility setting. Contributed by @HarHarLinks. ([#2204](https://github.com/matrix-org/matrix-spec/issues/2204))
-
-
-## Server-Server API
-
-**Backwards Compatible Changes**
-
-- `invite_room_state` and `knock_room_state` now have additional requirements and validation depending on the room version, as per [MSC4311](https://github.com/matrix-org/matrix-spec-proposals/pull/4311). ([#2207](https://github.com/matrix-org/matrix-spec/issues/2207))
-
-
-## Application Service API
-
-No significant changes.
-
-
-## Identity Service API
-
-No significant changes.
-
-
-## Push Gateway API
-
-No significant changes.
-
-
-## Room Versions
-
-**Backwards Compatible Changes**
-
-- Room IDs in room version 12 are now the event ID of the create event with the normal room ID sigil (`!`), as per [MSC4291](https://github.com/matrix-org/matrix-spec-proposals/pull/4291). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-- Room creators are formalized in room version 12 and have infinitely high power level, as per [MSC4289](https://github.com/matrix-org/matrix-spec-proposals/pull/4289). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-- State Resolution is updated in room version 12 to reduce the opportunity for "state resets", as per [MSC4297](https://github.com/matrix-org/matrix-spec-proposals/pull/4297). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-- The default room version is now room version 12, though servers SHOULD keep using room version 11 for a little while, as per [MSC4304](https://github.com/matrix-org/matrix-spec-proposals/pull/4304). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-- Add [room version 12](/rooms/v12) as per [MSC4304](https://github.com/matrix-org/matrix-spec-proposals/pull/4304). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193), [#2199](https://github.com/matrix-org/matrix-spec/issues/2199))
-
-**Spec Clarifications**
-
-- In room versions 1 through 12, an event's `auth_events` have always needed to belong to the same room as per [MSC4307](https://github.com/matrix-org/matrix-spec-proposals/pull/4307). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-
-
-## Appendices
-
-**Backwards Compatible Changes**
-
-- Room IDs can now appear without a domain component in [room version 12](/rooms/v12), as per [MSC4291](https://github.com/matrix-org/matrix-spec-proposals/pull/4291). ([#2193](https://github.com/matrix-org/matrix-spec/issues/2193))
-
-
-## Internal Changes/Tooling
-
-**Backwards Compatible Changes**
-
-- Add "placeholder MSC" process definition. ([#2157](https://github.com/matrix-org/matrix-spec/issues/2157))
-
-**Spec Clarifications**
-
-- Declare the Application Service Registration schema to follow JSON Schema spec 2020-12. ([#2132](https://github.com/matrix-org/matrix-spec/issues/2132))
-- Declare the event schemas to follow JSON Schema spec 2020-12. ([#2132](https://github.com/matrix-org/matrix-spec/issues/2132))
-- Upgrade the docsy theme to version 0.12.0. ([#2160](https://github.com/matrix-org/matrix-spec/issues/2160))
-- GitHub actions are now building the OpenAPI `spec/identity-service-api/api.json` file. ([#2172](https://github.com/matrix-org/matrix-spec/issues/2172))
-- Minor fixes to JSON schemas. ([#2182](https://github.com/matrix-org/matrix-spec/issues/2182))
-- Specify a correct spelling for "display name". ([#2189](https://github.com/matrix-org/matrix-spec/issues/2189))
-- Fix a grammatical typo on the Matrix Spec Process documentation page. ([#2205](https://github.com/matrix-org/matrix-spec/issues/2205))

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
@@ -134,14 +134,9 @@ entity isn't in the room.
 `mxc://` URIs are vulnerable to directory traversal attacks such as
 `mxc://127.0.0.1/../../../some_service/etc/passwd`. This would cause the
 target homeserver to try to access and return this file. As such,
-homeservers MUST sanitise `mxc://` URIs by:
+homeservers MUST sanitise `mxc://` URIs by allowing only alphanumeric
-
+(`A-Za-z0-9`), `_` and `-` characters in the `server-name` and
--   restricting the `server-name` segment to valid
+`media-id` values. This set of whitelisted characters allows URL-safe
-    [server names](/appendices/#server-name)
--   allowing only alphanumeric (`A-Za-z0-9`), `_` and `-` characters in
-    the `media-id` segment
-
-The resulting set of whitelisted characters allows URL-safe
 base64 encodings specified in RFC 4648. Applying this character
 whitelist is preferable to blacklisting `.` and `/` as there are
 techniques around blacklisted characters (percent-encoded characters,

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  |
     +---------------+ +---------------+                    +-------------+ +-------------+
@@ -528,7 +528,7 @@ messages, Alice only sends one request event (an event with type
 `m.room.message` with `msgtype: m.key.verification.request`, rather than an
 event with type `m.key.verification.request`), to the room. In addition, Alice
 does not send an `m.key.verification.cancel` event to tell Bob's other devices
-that the request has already been accepted; instead, when Bob's other devices
+that the request as already been accepted; instead, when Bob's other devices
 see his `m.key.verification.ready` event, they will know that the request has
 already been accepted, and that they should ignore the request.
 
@@ -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            | |
@@ -1124,7 +1124,7 @@ The process between Alice and Bob verifying each other would be:
    framework as described above.
 3. Alice's client displays a QR code that Bob is able to scan if Bob's client
    indicated the ability to scan, an option to scan Bob's QR code if her client
-   is able to scan. Bob's client displays a QR code that Alice can
+   is able to scan.  Bob's client prompts displays a QR code that Alice can
    scan if Alice's client indicated the ability to scan, and an option to scan
    Alice's QR code if his client is able to scan. The format for the QR code
    is described below. Other options, like starting SAS Emoji verification,
@@ -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
@@ -1457,8 +1457,8 @@ readers without adding any useful extra information.
 ##### `m.olm.v1.curve25519-aes-sha2`
 
 The name `m.olm.v1.curve25519-aes-sha2` corresponds to version 1 of the
-Olm ratchet, as defined by the [Olm specification](/olm-megolm/olm).
+Olm ratchet, as defined by the [Olm
-This uses:
+specification](http://matrix.org/docs/spec/olm.html). This uses:
 
 -   Curve25519 for the initial key agreement.
 -   HKDF-SHA-256 for ratchet key derivation.
@@ -1512,11 +1512,40 @@ message.
 
 The plaintext payload is of the form:
 
-{{% definition path="api/client-server/definitions/olm_payload" %}}
+```json
+{
+  "type": "<type of the plaintext event>",
+  "content": "<content for the plaintext event>",
+  "sender": "<sender_user_id>",
+  "recipient": "<recipient_user_id>",
+  "recipient_keys": {
+    "ed25519": "<our_ed25519_key>"
+  },
+  "keys": {
+    "ed25519": "<sender_ed25519_key>"
+  }
+}
+```
 
 The type and content of the plaintext message event are given in the
 payload.
 
+Other properties are included in order to prevent an attacker from
+publishing someone else's curve25519 keys as their own and subsequently
+claiming to have sent messages which they didn't. `sender` must
+correspond to the user who sent the event, `recipient` to the local
+user, and `recipient_keys` to the local ed25519 key.
+
+Clients must confirm that the `sender_key` property in the cleartext
+`m.room.encrypted` event body, and the `keys.ed25519` property in the
+decrypted plaintext, match the keys returned by
+[`/keys/query`](#post_matrixclientv3keysquery) for
+the given user. Clients must also verify the signature of the keys from the
+`/keys/query` response. Without this check, a client cannot be sure that
+the sender device owns the private part of the ed25519 key it claims to
+have in the Olm payload. This is crucial when the ed25519 key corresponds
+to a verified device.
+
 If a client has multiple sessions established with another device, it
 should use the session from which it last received and successfully
 decrypted a message. For these purposes, a session that has not received
@@ -1526,68 +1555,6 @@ maximum number of olm sessions that it will maintain for each device,
 and expiring sessions on a Least Recently Used basis. The maximum number
 of olm sessions maintained per device should be at least 4.
 
-###### Validation of incoming decrypted events
-
-{{% changed-in v="1.15" %}} Existing checks made more explicit, and checks for `sender_device_keys` added.
-
-After decrypting an incoming encrypted event, clients MUST apply the
-following checks:
-
-1.  The `sender` property in the decrypted content must match the
-    `sender` of the event.
-2.  The `keys.ed25519` property in the decrypted content must match
-    the `sender_key` property in the cleartext `m.room.encrypted`
-    event body.
-3.  The `recipient` property in the decrypted content must match
-    the user ID of the local user.
-4.  The `recipient_keys.ed25519` property in the decrypted content
-    must match the client device's [Ed25519 signing key](#device-keys).
-5.  Where `sender_device_keys` is present in the decrypted content:
-    1.  `sender_device_keys.user_id` must also match the `sender`
-        of the event.
-    2.  `sender_device_keys.keys.ed25519:<device_id>` must also match
-        the `sender_key` property in the cleartext `m.room.encrypted`
-        event body.
-    3.  `sender_device_keys.keys.curve25519:<device_id>` must match
-        the Curve25519 key used to establish the Olm session.
-    4.  The `sender_device_keys` structure must have a valid signature
-        from the key with ID `ed25519:<device_id>` (i.e., the sending
-        device's Ed25519 key).
-
-Any event that does not comply with these checks MUST be discarded.
-
-###### Verification of the sending user for incoming events
-
-{{% added-in v="1.15" %}}
-
-In addition, for each Olm session, clients MUST verify that the
-Curve25519 key used to establish the Olm session does indeed belong
-to the claimed `sender`. This requires a signed "device keys" structure
-for that Curve25519 key, which can be obtained in one of two ways:
-
-1.  An Olm message may be received with a `sender_device_keys` property
-    in the decrypted content.
-2.  The keys are returned via a [`/keys/query`](#post_matrixclientv3keysquery)
-    request. Note that both the Curve25519 key **and** the Ed25519 key in
-    the returned device keys structure must match those used in an
-    Olm-encrypted event as above. (In particular, the Ed25519 key must
-    be present in the **encrypted** content of an Olm-encrypted event
-    to prevent an attacker from claiming another user's Curve25519 key
-    as their own.)
-
-Ownership of the Curve25519 key is then established in one of two ways:
-
-1.  Via [cross-signing](#cross-signing). For this to be sufficient, the
-    device keys structure must be signed by the sender's self-signing key,
-    and that self-signing key must itself have been validated (either via
-    [explicit verification](#device-verification) or a "trust on first use" (TOFU) mechanism).
-2.  Via explicit verification of the device's Ed25519 signing key, as
-    contained in the device keys structure. This is no longer recommended.
-
-A failure to complete these verifications does not necessarily mean that
-the session is bogus; however it is the case that there is no proof that
-the claimed sender is accurate, and the user should be warned accordingly.
-
 ###### Recovering from undecryptable messages
 
 Occasionally messages may be undecryptable by clients due to a variety
@@ -1631,8 +1598,8 @@ This is due to a deprecation of the fields. See
 {{% changed-in v="1.3" %}}
 
 The name `m.megolm.v1.aes-sha2` corresponds to version 1 of the Megolm
-ratchet, as defined by the [Megolm specification](/olm-megolm/megolm).
+ratchet, as defined by the [Megolm
-This uses:
+specification](http://matrix.org/docs/spec/megolm.html). This uses:
 
 -   HMAC-SHA-256 for the hash ratchet.
 -   HKDF-SHA-256, AES-256 in CBC mode, and 8 byte truncated HMAC-SHA-256
@@ -1775,18 +1742,19 @@ property is required for inclusion, though previous versions of the
 specification did not have it. In addition to `/versions`, this can be
 a way to identify the server's support for fallback keys.
 
-| Parameter                        | Type              | Description                                                                                                            |
+
-|----------------------------------|-------------------|------------------------------------------------------------------------------------------------------------------------|
+| Parameter                        | Type               | Description                                                                                                            |
-| device_lists                     | DeviceLists       | Optional. Information on e2e device updates. Note: only present on an incremental sync.                                |
+|----------------------------------|--------------------|------------------------------------------------------------------------------------------------------------------------|
-| device_one_time_keys_count       | {string: integer} | **Required if any unclaimed one-time keys exist.** For each key algorithm, the number of unclaimed one-time keys currently held on the server for this device. If the count for an algorithm is zero, servers MAY omit that algorithm. If the count for all algorithms is zero, servers MAY omit this parameter entirely. |
+| device_lists                     | DeviceLists        | Optional. Information on e2e device updates. Note: only present on an incremental sync.                                |
-| device_unused_fallback_key_types | [string]          | **Required.** The unused fallback key algorithms.                                                                      |
+| device_one_time_keys_count       | {string: integer}  | Optional. For each key algorithm, the number of unclaimed one-time keys currently held on the server for this device.  If an algorithm is unlisted, the count for that algorithm is assumed to be zero.  If this entire parameter is missing, the count for all algorithms is assumed to be zero.  |
+| device_unused_fallback_key_types | [string]           | **Required.** The unused fallback key algorithms.                                                                      |
 
 `DeviceLists`
 
-| Parameter | Type     | Description                                                                                                                                                      |
+| Parameter  | Type      | Description                                                                                                                                                      |
-|-----------|----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|------------|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| changed   | [string] | List of users who have updated their device identity or cross-signing keys, or who now share an encrypted room with the client since the previous sync response. |
+| changed    | [string]  | List of users who have updated their device identity or cross-signing keys, or who now share an encrypted room with the client since the previous sync response. |
-| left      | [string] | List of users with whom we do not share any encrypted rooms anymore since the previous sync response.                                                            |
+| left       | [string]  | List of users with whom we do not share any encrypted rooms anymore since the previous sync response.                                                            |
 
 {{% boxes/note %}}
 For optimal performance, Alice should be added to `changed` in Bob's

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

@@ -195,7 +195,7 @@ given event (for example, if an event is edited multiple times). These should
 be [aggregated](#aggregations-of-child-events) by the homeserver.
 
 The aggregation format of `m.replace` relationships gives the **most recent**
-valid replacement event, formatted [as normal](#room-event-format).
+replacement event, formatted [as normal](#room-event-format).
 
 The most recent event is determined by comparing `origin_server_ts`; if two or
 more replacement events have identical `origin_server_ts`, the event with the
@@ -268,11 +268,6 @@ Client authors are reminded to take note of the requirements for [Validity of
 replacement events](#validity-of-replacement-events), and to ignore any
 invalid replacement events that are received.
 
-Clients should render the content of the **most recent** valid replacement event. The
-most recent event is determined by comparing `origin_server_ts`; if two or more
-replacement events have identical `origin_server_ts`, the event with the
-lexicographically largest `event_id` is treated as more recent.
-
 ##### Permalinks
 
 When creating [links](/appendices/#uris) to events (also known as permalinks),
@@ -369,7 +364,7 @@ property under `m.new_content`.
 
 A particular constraint applies to events which replace a [reply](#rich-replies):
 in contrast to the original reply, there should be no `m.in_reply_to` property
-in the `m.relates_to` object, since it would be redundant (see
+in the the `m.relates_to` object, since it would be redundant (see
 [Applying `m.new_content`](#applying-mnew_content) above, which notes that the
 original event's `m.relates_to` is preserved), as well as being contrary to the
 spirit of the event relationships mechanism which expects only one "parent" per

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

@@ -63,8 +63,7 @@ for sending events:
 The following API endpoints are allowed to be accessed by guest accounts
 for their own account maintenance:
 
-* [PUT /profile/{userId}/displayname](#put_matrixclientv3profileuseridkeyname). Guest users may only modify their display name; other profile fields may not be changed.
+* [PUT /profile/{userId}/displayname](#put_matrixclientv3profileuseriddisplayname)
-* {{% added-in v="1.16" %}} [DELETE /profile/{userId}/displayname](#delete_matrixclientv3profileuseridkeyname). Again, guest users may delete their display name but not other profile fields.
 * [GET /devices](#get_matrixclientv3devices)
 * [GET /devices/{deviceId}](#get_matrixclientv3devicesdeviceid)
 * [PUT /devices/{deviceId}](#put_matrixclientv3devicesdeviceid)

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

@@ -16,8 +16,8 @@ The four options for the `m.room.history_visibility` event are:
 
 -   `world_readable` - All events while this is the
     `m.room.history_visibility` value may be shared by any participating
-    homeserver with any authenticated user, regardless of whether they have
+    homeserver with anyone, regardless of whether they have ever joined
-    ever joined the room. This includes [guest users](#guest-access).
+    the room.
 -   `shared` - Previous events are always accessible to newly joined
     members. All events in the room are accessible, even those sent when
     the member was not a part of the room.
@@ -44,7 +44,7 @@ setting at that time was more restrictive.
 #### Client behaviour
 
 Clients may want to display a notice that events may be read by
-non-joined users if the history visibility is set to `world_readable`.
+non-joined people if the history visibility is set to `world_readable`.
 
 #### Server behaviour
 

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

@@ -3,9 +3,6 @@
 
 {{% changed-in v="1.7" %}}
 
-{{% changed-in v="1.17" %}}: the legacy push rules that looked for mentions in
-the `body` of the event were removed.
-
 This module allows users to "mention" other users and rooms within a room event.
 This is primarily used as an indicator that the recipient should receive a notification
 about the event.
@@ -41,18 +38,19 @@ encrypted as normal. To properly process mentions in encrypted rooms, events
 must be decrypted first. See [receiving notifications](#receiving-notifications).
 {{% /boxes/warning %}}
 
-{{% boxes/note %}}
+Note that, for backwards compatibility, push rules such as [`.m.rule.contains_display_name`](#_m_rule_contains_display_name),
+[`.m.rule.contains_user_name`](#_m_rule_contains_user_name), and
+[`.m.rule.roomnotif`](#_m_rule_roomnotif) continue to  match if the `body` of
+the event contains the user's display name or ID. To avoid unintentional notifications,
+**it is recommended that clients include a `m.mentions` property on each event**.
+(If there are no mentions to include it can be an empty object.)
+
+{{% boxes/rationale %}}
 In previous versions of the specification, mentioning users was done by
 including the user's display name or the localpart of their Matrix ID and room
 mentions were done by including the string "@room" in the plaintext `body` of
-the event. When the `m.mentions` field was introduced, those push rules were
+the event. This was prone to confusing and buggy behaviour.
-disabled if the `m.mentions` field was present.
+{{% /boxes/rationale %}}
-
-To avoid unintentional notifications with clients and servers that still use
-those push rules, **it is recommended that clients still include a `m.mentions`
-property on each event**. (If there are no mentions to include it can be an
-empty object.)
-{{% /boxes/note %}}
 
 #### Client behaviour
 

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

@@ -18,9 +18,8 @@ the entity making the decisions on filtering is best positioned to
 interpret the rules how it sees fit.
 
 Moderation policy lists are stored as room state events. There are no
-restrictions on how the rooms can be configured in terms of
+restrictions on how the rooms can be configured (they could be public,
-[join rules](#mroomjoin_rules), [history visibility](#room-history-visibility),
+private, encrypted, etc).
-encryption, etc.
 
 There are currently 3 kinds of entities which can be affected by rules:
 `user`, `server`, and `room`. All 3 are described with

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

@@ -68,7 +68,5 @@ will cause the server to automatically set their presence to `online`.
 
 #### Security considerations
 
-Presence information is published to all users who share a room with the
+Presence information is shared with all users who share a room with the
-target user. If the target user is a member of a room with a `public`
+target user. In large public rooms this could be undesirable.
-[join rule](#mroomjoin_rules), any other user in the federation is
-able to gain access to the target user's presence. This could be undesirable.

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

@@ -1,7 +1,7 @@
 
 ### Push Notifications
 
-```nohighlight
+```
                                    +--------------------+  +-------------------+
                   Matrix HTTP      |                    |  |                   |
              Notification Protocol |   App Developer    |  |   Device Vendor   |
@@ -83,7 +83,7 @@ Push Ruleset
 :   A push ruleset *scopes a set of rules according to some criteria*. For
     example, some rules may only be applied for messages from a particular
     sender, a particular room, or by default. The push ruleset contains the
-    entire set of rules.
+    entire set of scopes and rules.
 
 #### Push Rules
 
@@ -91,8 +91,10 @@ A push rule is a single rule that states under what *conditions* an
 event should be passed onto a push gateway and *how* the notification
 should be presented. There are different "kinds" of push rules and each
 rule has an associated priority. Every push rule MUST have a `kind` and
-`rule_id`. The `rule_id` is a unique string within the kind of rule.
+`rule_id`. The `rule_id` is a unique string within the kind of rule and
-Rules may have extra keys depending on the value of `kind`.
+its' scope: `rule_ids` do not need to be unique between rules of the
+same kind on different devices. Rules may have extra keys depending on
+the value of `kind`.
 
 The different `kind`s of rule, in the order that they are checked, are:
 
@@ -380,9 +382,6 @@ The following `alt_aliases` values will NOT match:
 
 **`contains_display_name`**
 
-{{% changed-in v="1.17" %}}: this condition is deprecated and **should not be
-used in new push rules**.
-
 This matches messages where `content.body` contains the owner's display name in
 that room. This is a separate condition because display names may change and as such
 it would be hard to maintain a rule that matched the user's display name. This
@@ -414,9 +413,6 @@ Parameters:
 
 #### Predefined Rules
 
-{{% changed-in v="1.17" %}}: the legacy default push rules that looked for
-mentions in the `body` of the event were removed.
-
 Homeservers can specify "server-default rules". They operate at a lower
 priority than "user-defined rules", except for the `.m.rule.master` rule
 which has always a higher priority than any other rule. The `rule_id`
@@ -561,6 +557,41 @@ Definition:
 }
 ```
 
+<a id="_m_rule_contains_display_name"></a> **`.m.rule.contains_display_name`**
+
+{{% changed-in v="1.7" %}}
+
+As of `v1.7`, this rule is deprecated and **should only be enabled if the event
+does not have an [`m.mentions` property](#definition-mmentions)**.
+
+Matches any message whose content contains the user's current display name
+in the room in which it was sent.
+
+Definition:
+
+```json
+{
+    "rule_id": ".m.rule.contains_display_name",
+    "default": true,
+    "enabled": true,
+    "conditions": [
+        {
+            "kind": "contains_display_name"
+        }
+    ],
+    "actions": [
+        "notify",
+        {
+            "set_tweak": "sound",
+            "value": "default"
+        },
+        {
+            "set_tweak": "highlight"
+        }
+    ]
+}
+```
+
 <a id="_m_rule_is_room_mention"></a> **`.m.rule.is_room_mention`**
 
 {{% added-in v="1.7" %}}
@@ -595,6 +626,44 @@ Definition:
 }
 ```
 
+<a id="_m_rule_roomnotif"></a> **`.m.rule.roomnotif`**
+
+{{% changed-in v="1.7" %}}
+
+As of `v1.7`, this rule is deprecated and **should only be enabled if the event
+does not have an [`m.mentions` property](#definition-mmentions)**.
+
+Matches any message from a sender with the proper power level whose content
+contains the text `@room`, signifying the whole room should be notified of
+the event.
+
+Definition:
+
+```json
+{
+    "rule_id": ".m.rule.roomnotif",
+    "default": true,
+    "enabled": true,
+    "conditions": [
+        {
+            "kind": "event_match",
+            "key": "content.body",
+            "pattern": "@room"
+        },
+        {
+            "kind": "sender_notification_permission",
+            "key": "room"
+        }
+    ],
+    "actions": [
+        "notify",
+        {
+            "set_tweak": "highlight"
+        }
+    ]
+}
+```
+
 **<a id="mruletombstone"></a>`.m.rule.tombstone`**
 
 Matches any state event whose type is `m.room.tombstone`. This is
@@ -707,6 +776,39 @@ Definition:
 }
 ```
 
+##### Default Content Rules
+
+<a id="_m_rule_contains_user_name"></a> **`.m.rule.contains_user_name`**
+
+{{% changed-in v="1.7" %}}
+
+As of `v1.7`, this rule is deprecated and **should only be enabled if the event
+does not have an [`m.mentions` property](#definition-mmentions)**.
+
+Matches any message whose content contains the local 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,
+    "enabled": true,
+    "pattern": "[the local part of the user's Matrix ID]",
+    "actions": [
+        "notify",
+        {
+            "set_tweak": "sound",
+            "value": "default"
+        },
+        {
+            "set_tweak": "highlight"
+        }
+    ]
+}
+```
+
 ##### Default Underride Rules
 
 **`.m.rule.call`**

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/rich_replies.md

@@ -20,9 +20,9 @@ Previously, a rich reply could only reference another `m.room.message` event.
 {{% boxes/note %}}
 {{% changed-in v="1.13" %}}
 In previous versions of the specification, rich replies could include a fallback
-representation of the original message in the `body` (using a prefix sequence)
+representation of the original message message in the `body` (using a prefix
-and `formatted_body` (using a custom HTML element) for clients that do not
+sequence) and `formatted_body` (using a custom HTML element) for clients that do
-support rich replies. This is no longer the case, but clients SHOULD still
+not support rich replies. This is no longer the case, but clients SHOULD still
 remove this fallback before rendering the event.
 
 To strip the fallback on the `body`, the client should iterate over each
@@ -64,16 +64,11 @@ as if it were to be under `m.relates_to` directly instead.
 
 #### Mentioning the replied to user
 
-{{% boxes/note %}}
+In order to notify users of the reply, it may be desirable to include the `sender`
-{{% changed-in v="1.16" %}}
+of the replied to event and any users mentioned in that event. See
-Clients SHOULD no longer propagate mentioned users in the replied to event.
+[user and room mentions](#user-and-room-mentions) for additional information.
-{{% /boxes/note %}}
-
-In order to notify users of the reply, it MAY be desirable to include the `sender`
-of the replied to event. See [user and room mentions](#user-and-room-mentions) for
-additional information.
 
-An example including mentioning the original sender:
+An example including mentioning the original sender and other users:
 
 ```json
 {
@@ -88,6 +83,8 @@ An example including mentioning the original sender:
       "user_ids": [
         // The sender of $another_event.
         "@alice:example.org",
+        // Another Matrix ID copied from the m.mentions property of $another_event.
+        "@bob:example.org"
       ]
     }
   },

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

@@ -6,7 +6,7 @@ It is sometimes desirable to offer a preview of a room, where a user can
 This can be particularly effective when combined with [Guest Access](#guest-access).
 
 Previews are implemented via the `world_readable` [Room History
-Visibility](#room-history-visibility) setting, along with a special version of the [GET
+Visibility](#room-history-visibility). setting, along with a special version of the [GET
 /events](#get_matrixclientv3events) endpoint.
 
 #### Client behaviour

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

@@ -36,17 +36,6 @@ server:
     previous room, no `type` is specified on the new room's create event
     either.
 
-{{% boxes/note %}}
-{{% added-in v="1.16" %}} If both the new and old [room version](/rooms) support
-additional creators, the server will not transfer those additional creators automatically.
-They must be explicitly set during the `/upgrade` call.
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-{{% added-in v="1.16" %}} When upgrading to room version 12 or later, the `predecessor` field MAY NOT contain
-an `event_id`.
-{{% /boxes/note %}}
-
 3.  Replicates transferable state events to the new room. The exact
     details for what is transferred is left as an implementation detail,
     however the recommended state events to transfer are:

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

@@ -26,10 +26,9 @@ on certain keys of certain event types.
 
 The supported keys to search over are:
 
--   `content.body` in [`m.room.message`](/client-server-api/#mroommessage)
+-   `content.body` in `m.room.message`
--   `content.name` in [`m.room.name`](/client-server-api/#mroomname)
+-   `content.name` in `m.room.name`
--   In [`m.room.topic`](/client-server-api/#mroomtopic), `content.topic`
+-   `content.topic` in `m.room.topic`
-    as well as the `body` of the `text/plain` representation in `content['m.topic']`.
 
 The search will *not* include rooms that are end to end encrypted.
 

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

@@ -58,8 +58,8 @@ available on all their clients. Unless the user specifies otherwise,
 clients will try to use the default key to decrypt secrets.
 
 Clients that want to present a simplified interface to users by not supporting
-multiple keys should use the default key if one is specified. If no default
+multiple keys should use the default key if one is specified. If not default
-key is specified, the client may behave as if no key is present at
+key is specified, the client may behave as if there is no key is present at
 all. When such a client creates a key, it should mark that key as being the
 default key.
 
@@ -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

@@ -2,8 +2,8 @@
 
 {{% added-in v="1.2" %}}
 
-Often used to group rooms of similar subject matter (such as an "Official
+Often used to group rooms of similar subject matter (such as a public "Official
-matrix.org rooms" space or a "Work stuff" space), spaces are a way to
+matrix.org rooms" space or personal "Work stuff" space), spaces are a way to
 organise rooms while being represented as rooms themselves.
 
 A space is defined by the [`m.space` room type](#types), making it known as a
@@ -18,11 +18,11 @@ In the default power level structure, this would be `100`. Clients might wish to
 go a step further and explicitly ignore notification counts on space-rooms.
 
 Membership of a space is defined and controlled by the existing mechanisms which
-govern a room: [`m.room.member`](/client-server-api#mroommember), [`m.room.history_visibility`](/client-server-api#mroomhistory_visibility),
+govern a room: [`m.room.member`](#mroommember), [`m.room.history_visibility`](#mroomhistory_visibility),
-and [`m.room.join_rules`](/client-server-api#mroomjoin_rules). Canonical aliases and invites, including
+and [`m.room.join_rules`](#mroomjoin_rules). Public spaces are encouraged to have
-third-party invites, still work just as they do in normal rooms as well. Furthermore,
+a similar setup to public rooms: `world_readable` history visibility, published
-spaces can also be published in the [room directory](/client-server-api#published-room-directory) to make them
+canonical alias, and suitably public `join_rule`. Invites, including third-party
-discoverable.
+invites, still work just as they do in normal rooms as well.
 
 All other aspects of regular rooms are additionally carried over, such as the
 ability to set arbitrary state events, hold room account data, etc. Spaces are
@@ -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
@@ -87,9 +87,10 @@ the state of `#space:example.org` would consist of:
 }
 ```
 
-No state events in the child rooms themselves would be required (though they can also
+No state events in the child rooms themselves would be required (though they
-be present). This allows for users to define spaces without needing explicit permission
+can also be present). This allows for users
-from the room moderators/admins.
+to define personal/private spaces to organise their own rooms without needing explicit
+permission from the room moderators/admins.
 
 Child rooms can be removed from a space by omitting the `via` key of `content` on the
 relevant state event, such as through redaction or otherwise clearing the `content`.

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

@@ -6,10 +6,9 @@ allow users to log into applications via a single web-based
 authentication portal. Examples include OpenID Connect, "Central
 Authentication Service" (CAS) and SAML.
 
-This module allows a Matrix homeserver that supports the [legacy authentication
+This module allows a Matrix homeserver to delegate user authentication
-API](#legacy-api) to delegate user authentication to an external authentication
+to an external authentication server supporting one of these protocols.
-server supporting one of these protocols. In this process, there are three
+In this process, there are three systems involved:
-systems involved:
 
 -   A Matrix client, using the APIs defined in this specification, which
     is seeking to authenticate a user to a Matrix homeserver.
@@ -25,7 +24,7 @@ used to communicate with the authentication server. Different Matrix
 homeserver implementations might support different SSO protocols.
 
 Clients and homeservers implementing the SSO flow will need to consider
-both [login](#legacy-login) and [user-interactive authentication](#user-interactive-authentication-api). The flow is
+both [login](#login) and [user-interactive authentication](#user-interactive-authentication-api). The flow is
 similar in both cases, but there are slight differences.
 
 Typically, SSO systems require a single "callback" URI to be configured
@@ -67,7 +66,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

@@ -5,8 +5,8 @@ This module adds in support for inviting new members to a room where
 their Matrix user ID is not known, instead addressing them by a third-party
 identifier such as an email address. There are two flows here; one
 if a Matrix user ID is known for the third-party identifier, and one if
-not. Either way, the client calls [`/invite`](#thirdparty_post_matrixclientv3roomsroomidinvite)
+not. Either way, the client calls [`/invite`](#post_matrixclientv3roomsroomidinvite) with the details of the
-with the details of the third-party identifier.
+third-party identifier.
 
 The homeserver asks the identity server whether a Matrix user ID is
 known for that identifier:
@@ -37,14 +37,12 @@ A client asks a server to invite a user by their third-party identifier.
 
 #### Server behaviour
 
-Upon receipt of an [`/invite`](#thirdparty_post_matrixclientv3roomsroomidinvite),
+Upon receipt of an [`/invite`](#post_matrixclientv3roomsroomidinvite), the server is expected to look up the
-the server is expected to look up the third-party identifier with the provided
+third-party identifier with the provided identity server. If the lookup
-identity server by making a call to [`/_matrix/identity/v2/lookup`](/identity-service-api/#post_matrixidentityv2lookup).
+yields a result for a Matrix User ID then the normal invite process can
-If the lookup yields a result for a Matrix User ID then the normal [invite
+be initiated. This process ends up looking like this:
-process](/server-server-api/#inviting-to-a-room) can be initiated. This process
-ends up looking like this:
 
-```nohighlight
+```
     +---------+                         +-------------+                                    +-----------------+
     | Client  |                         | Homeserver  |                                    | IdentityServer  |
     +---------+                         +-------------+                                    +-----------------+
@@ -68,13 +66,12 @@ ends up looking like this:
         |                                     |                                                    |
 ```
 
-However, if the lookup does not yield a bound User ID, the homeserver must store
+However, if the lookup does not yield a bound User ID, the homeserver
-the invite on the identity server with a call to
+must store the invite on the identity server and emit a valid
-[`/_matrix/identity/v2/store-invite`](/identity-service-api/#post_matrixidentityv2store-invite)
+`m.room.third_party_invite` event to the room. This process ends up
-and emit a valid [`m.room.third_party_invite`](#mroomthird_party_invite) event
+looking like this:
-to the room. This process ends up looking like this:
 
-```nohighlight
+```
     +---------+                         +-------------+                                               +-----------------+
     | Client  |                         | Homeserver  |                                               | IdentityServer  |
     +---------+                         +-------------+                                               +-----------------+
@@ -104,19 +101,16 @@ to the room. This process ends up looking like this:
         |                                     |                                                               |
 ```
 
-The third-party user will then need to verify their identity, which results in a
+All homeservers MUST verify the signature in the event's
-request to [`/_matrix/federation/v1/3pid/onbind`](/server-server-api/#put_matrixfederationv13pidonbind)
-from the identity server to the homeserver that bound the third-party identifier
-to a user. The homeserver then exchanges the `m.room.third_party_invite` event
-in the room for a complete [`m.room.member`](#mroommember) event with
-`content.membership: invite` and a `content.third_party_invite` property for the
-user that has bound the third-party identifier. If the invitee is on a different
-homeserver than the inviting user, the invitee's homeserver makes a request to
-[`/_matrix/federation/v1/exchange_third_party_invite/{roomId}`](/server-server-api/#put_matrixfederationv1exchange_third_party_inviteroomid).
-
-All homeservers MUST verify the signature in the `m.room.member` event's
 `content.third_party_invite.signed` object.
 
+The third-party user will then need to verify their identity, which
+results in a call from the identity server to the homeserver that bound
+the third-party identifier to a user. The homeserver then exchanges the
+`m.room.third_party_invite` event in the room for a complete
+`m.room.member` event for `membership: invite` for the user that has
+bound the third-party identifier.
+
 If a homeserver is joining a room for the first time because of an
 `m.room.third_party_invite`, the server which is already participating
 in the room (which is chosen as per the standard server-server
@@ -133,7 +127,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  |
     +-------+ +-----------------+         +-----+                                          +-----+           +-----+                      +-----+
@@ -199,8 +193,8 @@ at any time - the completion is not shown in the diagram.
 
 H1 MUST verify the request from H3 to ensure the `signed` property is
 correct as well as the `key_validity_url` as still being valid. This is
-done by making a request to the identity server's
+done by making a request to the [identity server
-[`/pubkey/isvalid`](/identity-service-api/#get_matrixidentityv2pubkeyisvalid)
+/isvalid](/identity-service-api/#get_matrixidentityv2pubkeyisvalid)
 endpoint, using the provided URL rather than constructing a new one. The
 query string and response for the provided URL must match the Identity
 Service Specification.

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

@@ -185,7 +185,7 @@ included under the `m.relations` property in `unsigned` for the thread root. For
 ```
 
 `latest_event` is the most recent event (topologically to the server) in the thread sent by an
-un-[ignored user](#ignoring-users). It should be serialized in the same form as the event itself.
+un-[ignored user](#ignoring-users).
 
 Note that, as in the example above, child events of the `latest_event` should
 themselves be aggregated and included under `m.relations` for that event. The

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 --------->
@@ -202,13 +202,11 @@ specific user, and should be set to the Matrix user ID of that user. Invites
 without an `invitee` field are defined to be intended for any member of the
 room other than the sender of the event.
 
-Clients should consider an incoming call if they see a non-expired invite event
+Clients should consider an incoming call if they see a non-expired invite event where the `invitee` field is either
-where the `invitee` field is either absent or equal to their user's Matrix ID.
+absent or equal to their user's Matrix ID, however they should evaluate whether or not to ring based on their
-They should, however, evaluate whether or not to ring based on their user's trust
+user's trust relationship with the callers and/or where the call was placed. As a starting point, it is
-relationship with the callers and/or where the call was placed. As a starting
+suggested that clients ignore call invites from users in public rooms. It is strongly recommended that
-point, it is RECOMMENDED that clients ignore call invites in rooms with a
+when clients do not ring for an incoming call invite, they still display the call invite in the room and
-[join rule](#mroomjoin_rules) of `public`. When clients suppress ringing for an
-incoming call invite, they SHOULD still display the call invite in the room and
 annotate that it was ignored.
 
 ##### Glare

content/olm-megolm/_index.md

@@ -1,10 +0,0 @@
----
-title: "Olm & Megolm"
-weight: 61
-type: docs
----
-
-Matrix uses the Olm and Megolm cryptographic ratchets for [end-to-end encryption](../client-server-api/#end-to-end-encryption).
-
--   [Olm: A Cryptographic Ratchet](/olm-megolm/olm/)
--   [Megolm group ratchet](/olm-megolm/megolm/)

content/olm-megolm/megolm.md

@@ -1,378 +0,0 @@
----
-title: "Megolm group ratchet"
-weight: 20
-type: docs
----
-
-An AES-based cryptographic ratchet intended for group communications.
-
-## Background
-
-The Megolm ratchet is intended for encrypted messaging applications where there
-may be a large number of recipients of each message, thus precluding the use of
-peer-to-peer encryption systems such as [Olm][].
-
-It also allows a recipient to decrypt received messages multiple times. For
-instance, in client/server applications, a copy of the ciphertext can be stored
-on the (untrusted) server, while the client need only store the session keys.
-
-## Overview
-
-Each participant in a conversation uses their own outbound session for
-encrypting messages. A session consists of a ratchet and an [Ed25519][] keypair.
-
-Secrecy is provided by the ratchet, which can be wound forwards but not
-backwards, and is used to derive a distinct message key for each message.
-
-Authenticity is provided via Ed25519 signatures.
-
-The value of the ratchet, and the public part of the Ed25519 key, are shared
-with other participants in the conversation via secure peer-to-peer
-channels. Provided that peer-to-peer channel provides authenticity of the
-messages to the participants and deniability of the messages to third parties,
-the Megolm session will inherit those properties.
-
-## The Megolm ratchet algorithm
-
-The Megolm ratchet \(R_i\) consists of four parts, \(R_{i,j}\) for
-\(j \in {0,1,2,3}\). The length of each part depends on the hash function
-in use (256 bits for this version of Megolm).
-
-The ratchet is initialised with cryptographically-secure random data, and
-advanced as follows:
-
-\[
-\begin{aligned}
-R_{i,0} &=
-  \begin{cases}
-  H_0\left(R_{2^{24}(n-1),0}\right) &\text{if }\exists n | i = 2^{24}n\\
-  R_{i-1,0} &\text{otherwise}
-  \end{cases}\\
-R_{i,1} &=
-  \begin{cases}
-  H_1\left(R_{2^{24}(n-1),0}\right) &\text{if }\exists n | i = 2^{24}n\\
-  H_1\left(R_{2^{16}(m-1),1}\right) &\text{if }\exists m | i = 2^{16}m\\
-  R_{i-1,1} &\text{otherwise}
-  \end{cases}\\
-R_{i,2} &=
-  \begin{cases}
-  H_2\left(R_{2^{24}(n-1),0}\right) &\text{if }\exists n | i = 2^{24}n\\
-  H_2\left(R_{2^{16}(m-1),1}\right) &\text{if }\exists m | i = 2^{16}m\\
-  H_2\left(R_{2^8(p-1),2}\right) &\text{if }\exists p | i = 2^8p\\
-  R_{i-1,2} &\text{otherwise}
-  \end{cases}\\
-R_{i,3} &=
-  \begin{cases}
-  H_3\left(R_{2^{24}(n-1),0}\right) &\text{if }\exists n | i = 2^{24}n\\
-  H_3\left(R_{2^{16}(m-1),1}\right) &\text{if }\exists m | i = 2^{16}m\\
-  H_3\left(R_{2^8(p-1),2}\right) &\text{if }\exists p | i = 2^8p\\
-  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
-reseeded from \(R_{i,2}\). Every \(2^{16}\) iterations, \(R_{i,2}\)
-and \(R_{i,3}\) are reseeded from \(R_{i,1}\). Every \(2^{24}\)
-iterations, \(R_{i,1}\), \(R_{i,2}\) and \(R_{i,3}\) are reseeded
-from \(R_{i,0}\).
-
-The complete ratchet value, \(R_{i}\), is hashed to generate the keys used
-to encrypt each message. This scheme allows the ratchet to be advanced an
-arbitrary amount forwards while needing at most 1020 hash computations.  A
-client can decrypt chat history onwards from the earliest value of the ratchet
-it is aware of, but cannot decrypt history from before that point without
-reversing the hash function.
-
-This allows a participant to share its ability to decrypt chat history with
-another from a point in the conversation onwards by giving a copy of the
-ratchet at that point in the conversation.
-
-
-## The Megolm protocol
-
-### Session setup
-
-Each participant in a conversation generates their own Megolm session. A
-session consists of three parts:
-
-* a 32 bit counter, \(i\).
-* an [Ed25519][] keypair, \(K\).
-* a ratchet, \(R_i\), which consists of four 256-bit values,
-  \(R_{i,j}\) for \(j \in {0,1,2,3}\).
-
-The counter \(i\) is initialised to \(0\). A new Ed25519 keypair is
-generated for \(K\). The ratchet is simply initialised with 1024 bits of
-cryptographically-secure random data.
-
-A single participant may use multiple sessions over the lifetime of a
-conversation. The public part of \(K\) is used as an identifier to
-discriminate between sessions.
-
-### Sharing session data
-
-To allow other participants in the conversation to decrypt messages, the
-session data is formatted as described in [Session-sharing format](#session-sharing-format). It is then
-shared with other participants in the conversation via a secure peer-to-peer
-channel (such as that provided by [Olm][]).
-
-When the session data is received from other participants, the recipient first
-checks that the signature matches the public key. They then store their own
-copy of the counter, ratchet, and public key.
-
-### Message encryption
-
-This version of Megolm uses [AES-256][] in [CBC][] mode with [PKCS#7][] padding and
-[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\):
-
-\[
-\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)\)
-refers to the [HMAC-based key
-derivation function][] using using [SHA-256][] as the hash function
-([HKDF-SHA-256][]) with a salt value of \(\mathit{salt}\), input key material of
-\(\mathit{IKM}\), context string \(\mathit{info}\), and output keying material length of
-\(L\) bytes.
-
-The plain-text is encrypted with AES-256, using the key \(\mathit{AES\_KEY}_{i}\)
-and the IV \(\mathit{AES\_IV}_{i}\) to give the cipher-text, \(X_{i}\).
-
-The ratchet index \(i\), and the cipher-text \(X_{i}\), are then packed
-into a message as described in [Message format](#message-format). Then the entire message
-(including the version bytes and all payload bytes) are passed through
-HMAC-SHA-256. The first 8 bytes of the MAC are appended to the message.
-
-Finally, the authenticated message is signed using the Ed25519 keypair; the 64
-byte signature is appended to the message.
-
-The complete signed message, together with the public part of \(K\) (acting
-as a session identifier), can then be sent over an insecure channel. The
-message can then be authenticated and decrypted only by recipients who have
-received the session data.
-
-### Advancing the ratchet
-
-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:
-
-\[
-\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.
-
-For outbound sessions, the updated ratchet and counter are stored in the
-session.
-
-In order to maintain the ability to decrypt conversation history, inbound
-sessions should store a copy of their earliest known ratchet value (unless they
-explicitly want to drop the ability to decrypt that history - see [Partial
-Forward Secrecy](#partial-forward-secrecy)). They may also choose to cache calculated ratchet values,
-but the decision of which ratchet states to cache is left to the application.
-
-## Data exchange formats
-
-### Session sharing format
-
-This format is used for the initial sharing of a Megolm session with other
-group participants who need to be able to read messages encrypted by this
-session.
-
-The session sharing format is as follows:
-
-```nohighlight
-+---+----+--------+--------+--------+--------+------+-----------+
-| V | i  | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub | Signature |
-+---+----+--------+--------+--------+--------+------+-----------+
-0   1    5        37       69      101      133    165         229   bytes
-```
-
-The version byte, ``V``, is ``"\x02"``.
-
-This is followed by the ratchet index, \(i\), which is encoded as a
-big-endian 32-bit integer; the ratchet values \(R_{i,j}\); and the public
-part of the Ed25519 keypair \(K\).
-
-The data is then signed using the Ed25519 keypair, and the 64-byte signature is
-appended.
-
-### Session export format
-
-Once the session is initially shared with the group participants, each
-participant needs to retain a copy of the session if they want to maintain
-their ability to decrypt messages encrypted with that session.
-
-For forward-secrecy purposes, a participant may choose to store a ratcheted
-version of the session. But since the ratchet index is covered by the
-signature, this would invalidate the signature. So we define a similar format,
-called the *session export format*, which is identical to the [session sharing
-format](#session-sharing-format) except for dropping the signature.
-
-The Megolm session export format is thus as follows:
-
-```nohighlight
-+---+----+--------+--------+--------+--------+------+
-| V | i  | R(i,0) | R(i,1) | R(i,2) | R(i,3) | Kpub |
-+---+----+--------+--------+--------+--------+------+
-0   1    5        37       69      101      133    165   bytes
-```
-
-The version byte, ``V``, is ``"\x01"``.
-
-This is followed by the ratchet index, \(i\), which is encoded as a
-big-endian 32-bit integer; the ratchet values \(R_{i,j}\); and the public
-part of the Ed25519 keypair \(K\).
-
-### Message format
-
-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
-+---+------------------------------------+-----------+------------------+
-| V | Payload Bytes                      | MAC Bytes | Signature Bytes  |
-+---+------------------------------------+-----------+------------------+
-0   1                                    N          N+8                N+72   bytes
-```
-
-The version byte, ``V``, is ``"\x03"``.
-
-The payload uses a format based on the [Protocol Buffers encoding][]. It
-consists of the following key-value pairs:
-
-**Name**|**Tag**|**Type**|**Meaning**
-:-----:|:-----:|:-----:|:-----:
-Message-Index|0x08|Integer|The index of the ratchet, i
-Cipher-Text|0x12|String|The cipher-text, Xi, of the message
-
-Within the payload, integers are encoded using a variable length encoding. Each
-integer is encoded as a sequence of bytes with the high bit set followed by a
-byte with the high bit clear. The seven low bits of each byte store the bits of
-the integer. The least significant bits are stored in the first byte.
-
-Strings are encoded as a variable-length integer followed by the string itself.
-
-Each key-value pair is encoded as a variable-length integer giving the tag,
-followed by a string or variable-length integer giving the value.
-
-The payload is followed by the MAC. The length of the MAC is determined by the
-authenticated encryption algorithm being used (8 bytes in this version of the
-protocol). The MAC protects all of the bytes preceding the MAC.
-
-The length of the signature is determined by the signing algorithm being used
-(64 bytes in this version of the protocol). The signature covers all of the
-bytes preceding the signature.
-
-## Limitations
-
-### Message Replays
-
-A message can be decrypted successfully multiple times. This means that an
-attacker can re-send a copy of an old message, and the recipient will treat it
-as a new message.
-
-To mitigate this it is recommended that applications track the ratchet indices
-they have received and that they reject messages with a ratchet index that
-they have already decrypted.
-
-### Lack of Transcript Consistency
-
-In a group conversation, there is no guarantee that all recipients have
-received the same messages. For example, if Alice is in a conversation with Bob
-and Charlie, she could send different messages to Bob and Charlie, or could
-send some messages to Bob but not Charlie, or vice versa.
-
-Solving this is, in general, a hard problem, particularly in a protocol which
-does not guarantee in-order message delivery. For now it remains the subject of
-future research.
-
-### Lack of Backward Secrecy
-
-[Backward secrecy](https://intensecrypto.org/public/lec_08_hash_functions_part2.html#sec-forward-and-backward-secrecy)
-(also called 'future secrecy' or 'post-compromise security') is the property
-that if current private keys are compromised, an attacker cannot decrypt
-future messages in a given session.  In other words, when looking
-**backwards** in time at a compromise which has already happened, **current**
-messages are still secret.
-
-By itself, Megolm does not possess this property: once the key to a Megolm
-session is compromised, the attacker can decrypt any message that was
-encrypted using a key derived from the compromised or subsequent ratchet
-values.
-
-In order to mitigate this, the application should ensure that Megolm sessions
-are not used indefinitely. Instead it should periodically start a new session,
-with new keys shared over a secure channel.
-
-<!-- TODO: Can we recommend sensible lifetimes for Megolm sessions? Probably
-   depends how paranoid we're feeling, but some guidelines might be useful. -->
-
-### Partial Forward Secrecy
-
-[Forward secrecy](https://intensecrypto.org/public/lec_08_hash_functions_part2.html#sec-forward-and-backward-secrecy)
-(also called 'perfect forward secrecy') is the property that if the current
-private keys are compromised, an attacker cannot decrypt *past* messages in
-a given session. In other words, when looking **forwards** in time towards a
-potential future compromise, **current** messages will be secret.
-
-In Megolm, each recipient maintains a record of the ratchet value which allows
-them to decrypt any messages sent in the session after the corresponding point
-in the conversation. If this value is compromised, an attacker can similarly
-decrypt past messages which were encrypted by a key derived from the
-compromised or subsequent ratchet values. This gives 'partial' forward
-secrecy.
-
-To mitigate this issue, the application should offer the user the option to
-discard historical conversations, by winding forward any stored ratchet values,
-or discarding sessions altogether.
-
-### Dependency on secure channel for key exchange
-
-The design of the Megolm ratchet relies on the availability of a secure
-peer-to-peer channel for the exchange of session keys. Any vulnerabilities in
-the underlying channel are likely to be amplified when applied to Megolm
-session setup.
-
-For example, if the peer-to-peer channel is vulnerable to an unknown key-share
-attack, the entire Megolm session become similarly vulnerable. For example:
-Alice starts a group chat with Eve, and shares the session keys with Eve. Eve
-uses the unknown key-share attack to forward the session keys to Bob, who
-believes Alice is starting the session with him. Eve then forwards messages
-from the Megolm session to Bob, who again believes they are coming from
-Alice. Provided the peer-to-peer channel is not vulnerable to this attack, Bob
-will realise that the key-sharing message was forwarded by Eve, and can treat
-the Megolm session as a forgery.
-
-A second example: if the peer-to-peer channel is vulnerable to a replay
-attack, this can be extended to entire Megolm sessions.
-
-## License
-
-The Megolm specification (this document) is licensed under the Apache License,
-Version 2.0 http://www.apache.org/licenses/LICENSE-2.0.
-
-[Ed25519]: http://ed25519.cr.yp.to/
-[HMAC-based key derivation function]: https://tools.ietf.org/html/rfc5869
-[HKDF-SHA-256]: https://tools.ietf.org/html/rfc5869
-[HMAC-SHA-256]: https://tools.ietf.org/html/rfc2104
-[SHA-256]: https://tools.ietf.org/html/rfc6234
-[AES-256]: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
-[CBC]: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
-[PKCS#7]: https://tools.ietf.org/html/rfc2315
-[Olm]: https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/olm.md
-[Protocol Buffers encoding]: https://developers.google.com/protocol-buffers/docs/encoding

content/olm-megolm/olm.md

@@ -1,334 +0,0 @@
----
-title: "Olm: A Cryptographic Ratchet"
-weight: 10
-type: docs
----
-
-An implementation of the double cryptographic ratchet described by
-https://whispersystems.org/docs/specifications/doubleratchet/.
-
-## Notation
-
-This document uses \(\parallel\) to represent string concatenation. When
-\(\parallel\) appears on the right hand side of an \(=\) it means that
-the inputs are concatenated. When \(\parallel\) appears on the left hand
-side of an \(=\) it means that the output is split.
-
-When this document uses \(\operatorname{ECDH}\left(K_A,K_B\right)\) it means
-that each party computes a Diffie-Hellman agreement using their private key 
-and the remote party's public key.
-So party \(A\) computes \(\operatorname{ECDH}\left(K_B^{public},K_A^{private}\right)\)
-and party \(B\) computes \(\operatorname{ECDH}\left(K_A^{public},K_B^{private}\right)\).
-
-Where this document uses \(\operatorname{HKDF}\left(salt,IKM,info,L\right)\) it
-refers to the [HMAC-based key derivation function][] with a salt value of
-\(salt\), input key material of \(IKM\), context string \(info\),
-and output keying material length of \(L\) bytes.
-
-## The Olm Algorithm
-
-### Initial setup
-
-The setup takes four [Curve25519][] inputs: Identity keys for Alice and Bob,
-\(I_A\) and \(I_B\), and one-time keys for Alice and Bob,
-\(E_A\) and \(E_B\). A shared secret, \(S\), is generated using
-[Triple Diffie-Hellman][]. The initial 256 bit root key, \(R_0\), and 256
-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.
-
-\[
-\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
-
-Advancing a root key takes the previous root key, \(R_{i-1}\), and two
-Curve25519 inputs: the previous ratchet key, \(T_{i-1}\), and the current
-ratchet key \(T_i\). The even ratchet keys are generated by Alice.
-The odd ratchet keys are generated by Bob. A shared secret is generated
-using Diffie-Hellman on the ratchet keys. The next root key, \(R_i\), and
-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.
-
-\[
-\begin{aligned}
-    R_i\;\parallel\;C_{i,0}&=
-        \operatorname{HKDF}\left(
-            R_{i-1},
-            \operatorname{ECDH}\left(T_{i-1},T_i\right),
-            \text{``OLM\_RATCHET"},
-            64
-        \right)
-\end{aligned}
-\]
-
-### Advancing the chain key
-
-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.
-
-\[
-\begin{aligned}
-    C_{i,j}&=\operatorname{HMAC}\left(C_{i,j-1},\text{``\char`\\x02"}\right)
-\end{aligned}
-\]
-
-### Creating a message key
-
-Creating a message key takes the current chain key, \(C_{i,j}\). The
-message key, \(M_{i,j}\), is the [HMAC-SHA-256][] of ``"\x01"`` using the
-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.
-
-\[
-\begin{aligned}
-    M_{i,j}&=\operatorname{HMAC}\left(C_{i,j},\text{``\char`\\x01"}\right)
-\end{aligned}
-\]
-
-## The Olm Protocol
-
-### Creating an outbound session
-
-Bob publishes the public parts of his identity key, \(I_B\), and some
-single-use one-time keys \(E_B\).
-
-Alice downloads Bob's identity key, \(I_B\), and a one-time key,
-\(E_B\). She generates a new single-use key, \(E_A\), and computes a
-root key, \(R_0\), and a chain key \(C_{0,0}\). She also generates a
-new ratchet key \(T_0\).
-
-### Sending the first pre-key messages
-
-Alice computes a message key, \(M_{0,j}\), and a new chain key,
-\(C_{0,j+1}\), using the current chain key. She replaces the current chain
-key with the new one.
-
-Alice encrypts her plain-text with the message key, \(M_{0,j}\), using an
-authenticated encryption scheme (see below) to get a cipher-text,
-\(X_{0,j}\).
-
-She then sends the following to Bob:
- * The public part of her identity key, \(I_A\)
- * The public part of her single-use key, \(E_A\)
- * The public part of Bob's single-use key, \(E_B\)
- * The current chain index, \(j\)
- * The public part of her ratchet key, \(T_0\)
- * The cipher-text, \(X_{0,j}\)
-
-Alice will continue to send pre-key messages until she receives a message from
-Bob.
-
-### Creating an inbound session from a pre-key message
-
-Bob receives a pre-key message as above.
-
-Bob looks up the private part of his single-use key, \(E_B\). He can now
-compute the root key, \(R_0\), and the chain key, \(C_{0,0}\), from
-\(I_A\), \(E_A\), \(I_B\), and \(E_B\).
-
-Bob then advances the chain key \(j\) times, to compute the chain key used
-by the message, \(C_{0,j}\). He now creates the
-message key, \(M_{0,j}\), and attempts to decrypt the cipher-text,
-\(X_{0,j}\). If the cipher-text's authentication is correct then Bob can
-discard the private part of his single-use one-time key, \(E_B\).
-
-Bob stores Alice's initial ratchet key, \(T_0\), until he wants to
-send a message.
-
-### Sending normal messages
-
-Once a message has been received from the other side, a session is considered
-established, and a more compact form is used.
-
-To send a message, the user checks if they have a sender chain key,
-\(C_{i,j}\). Alice uses chain keys where \(i\) is even. Bob uses chain
-keys where \(i\) is odd. If the chain key doesn't exist then a new ratchet
-key \(T_i\) is generated and a new root key \(R_i\) and chain key
-\(C_{i,0}\) are computed using \(R_{i-1}\), \(T_{i-1}\) and
-\(T_i\).
-
-A message key,
-\(M_{i,j}\) is computed from the current chain key, \(C_{i,j}\), and
-the chain key is replaced with the next chain key, \(C_{i,j+1}\). The
-plain-text is encrypted with \(M_{i,j}\), using an authenticated encryption
-scheme (see below) to get a cipher-text, \(X_{i,j}\).
-
-The user then sends the following to the recipient:
- * The current chain index, \(j\)
- * The public part of the current ratchet key, \(T_i\)
- * The cipher-text, \(X_{i,j}\)
-
-### Receiving messages
-
-The user receives a message as above with the sender's current chain index, \(j\),
-the sender's ratchet key, \(T_i\), and the cipher-text, \(X_{i,j}\).
-
-The user checks if they have a receiver chain with the correct
-\(i\) by comparing the ratchet key, \(T_i\). If the chain doesn't exist
-then they compute a new root key, \(R_i\), and a new receiver chain, with
-chain key \(C_{i,0}\), using \(R_{i-1}\), \(T_{i-1}\) and
-\(T_i\).
-
-If the \(j\) of the message is less than
-the current chain index on the receiver then the message may only be decrypted
-if the receiver has stored a copy of the message key \(M_{i,j}\). Otherwise
-the receiver computes the chain key, \(C_{i,j}\). The receiver computes the
-message key, \(M_{i,j}\), from the chain key and attempts to decrypt the
-cipher-text, \(X_{i,j}\).
-
-If the decryption succeeds the receiver updates the chain key for \(T_i\)
-with \(C_{i,j+1}\) and stores the message keys that were skipped in the
-process so that they can decode out of order messages. If the receiver created
-a new receiver chain then they discard their current sender chain so that
-they will create a new chain when they next send a message.
-
-## The Olm Message Format
-
-Olm uses two types of messages. The underlying transport protocol must provide
-a means for recipients to distinguish between them.
-
-### Normal Messages
-
-Olm messages start with a one byte version followed by a variable length
-payload followed by a fixed length message authentication code.
-
-```nohighlight
- +--------------+------------------------------------+-----------+
- | Version Byte | Payload Bytes                      | MAC Bytes |
- +--------------+------------------------------------+-----------+
-```
-
-The version byte is ``"\x03"``.
-
-The payload consists of key-value pairs where the keys are integers and the
-values are integers and strings. The keys are encoded as a variable length
-integer tag where the 3 lowest bits indicates the type of the value:
-0 for integers, 2 for strings. If the value is an integer then the tag is
-followed by the value encoded as a variable length integer. If the value is
-a string then the tag is followed by the length of the string encoded as
-a variable length integer followed by the string itself.
-
-Olm uses a variable length encoding for integers. Each integer is encoded as a
-sequence of bytes with the high bit set followed by a byte with the high bit
-clear. The seven low bits of each byte store the bits of the integer. The least
-significant bits are stored in the first byte.
-
-**Name**|**Tag**|**Type**|**Meaning**
-:-----:|:-----:|:-----:|:-----:
-Ratchet-Key|0x0A|String|The public part of the ratchet key, Ti, of the message
-Chain-Index|0x10|Integer|The chain index, j, of the message
-Cipher-Text|0x22|String|The cipher-text, Xi, j, of the message
-
-The length of the MAC is determined by the authenticated encryption algorithm
-being used. (Olm version 1 uses [HMAC-SHA-256][], truncated to 8 bytes). The
-MAC protects all of the bytes preceding the MAC.
-
-### Pre-Key Messages
-
-Olm pre-key messages start with a one byte version followed by a variable
-length payload.
-
-```nohighlight
- +--------------+------------------------------------+
- | Version Byte | Payload Bytes                      |
- +--------------+------------------------------------+
-```
-
-The version byte is ``"\x03"``.
-
-The payload uses the same key-value format as for normal messages.
-
-**Name**|**Tag**|**Type**|**Meaning**
-:-----:|:-----:|:-----:|:-----:
-One-Time-Key|0x0A|String|The public part of Bob's single-use key, Eb.
-Base-Key|0x12|String|The public part of Alice's single-use key, Ea.
-Identity-Key|0x1A|String|The public part of Alice's identity key, Ia.
-Message|0x22|String|An embedded Olm message with its own version and MAC.
-
-## Olm Authenticated Encryption
-
-### Version 1
-
-Version 1 of Olm uses [AES-256][] in [CBC][] mode with [PKCS#7][] padding for
-encryption and [HMAC-SHA-256][] (truncated to 64 bits) for authentication.  The
-256 bit AES key, 256 bit HMAC key, and 128 bit AES IV are derived from the
-message key using [HKDF-SHA-256][] using the default salt and an info of
-``"OLM_KEYS"``.
-
-\[
-\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}\).
-
-Then the entire message (including the Version Byte and all Payload Bytes) are
-passed through [HMAC-SHA-256][]. The first 8 bytes of the MAC are appended to the message.
-
-## Message authentication concerns
-
-To avoid unknown key-share attacks, the application must include identifying
-data for the sending and receiving user in the plain-text of (at least) the
-pre-key messages. Such data could be a user ID, a telephone number;
-alternatively it could be the public part of a keypair which the relevant user
-has proven ownership of.
-
-### Example attacks
-
-1. Alice publishes her public [Curve25519][] identity key, \(I_A\). Eve
-   publishes the same identity key, claiming it as her own. Bob downloads
-   Eve's keys, and associates \(I_A\) with Eve. Alice sends a message to
-   Bob; Eve intercepts it before forwarding it to Bob. Bob believes the
-   message came from Eve rather than Alice.
-
-   This is prevented if Alice includes her user ID in the plain-text of the
-   pre-key message, so that Bob can see that the message was sent by Alice
-   originally.
-
-2. Bob publishes his public [Curve25519][] identity key, \(I_B\). Eve
-   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.
-
-   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
-   message was meant for Eve rather than him.
-
-## IPR
-
-The Olm specification (this document) is hereby placed in the public domain.
-
-## Feedback
-
-Can be sent to olm at matrix.org.
-
-## Acknowledgements
-
-The ratchet that Olm implements was designed by Trevor Perrin and Moxie
-Marlinspike - details at https://whispersystems.org/docs/specifications/doubleratchet/. Olm is
-an entirely new implementation written by the Matrix.org team.
-
-[Curve25519]: http://cr.yp.to/ecdh.html
-[Triple Diffie-Hellman]: https://whispersystems.org/blog/simplifying-otr-deniability/
-[HMAC-based key derivation function]: https://tools.ietf.org/html/rfc5869
-[HKDF-SHA-256]: https://tools.ietf.org/html/rfc5869
-[HMAC-SHA-256]: https://tools.ietf.org/html/rfc2104
-[SHA-256]: https://tools.ietf.org/html/rfc6234
-[AES-256]: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
-[CBC]: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
-[PKCS#7]: https://tools.ietf.org/html/rfc2315

content/proposals.md

@@ -1,6 +1,6 @@
 ---
 title: "Spec Change Proposals"
-weight: 62
+weight: 60
 type: docs
 ---
 
@@ -185,10 +185,6 @@ is as follows:
     -   Take care in creating your proposal. Specify your intended
         changes, and give reasoning to back them up. Changes without
         justification will likely be poorly received by the community.
-    -   At the time of creating your draft you will not yet know the PR number, so you
-        should use a placeholder number to name your file and edit that
-        after PR submission. The suggested steps are described in
-        detail [in the proposals guide](https://github.com/matrix-org/matrix-spec-proposals#1-writing-the-proposal).
 -   Fork and make a PR to the
     [matrix-spec-proposals](https://github.com/matrix-org/matrix-spec-proposals) repository.
     The ID of your PR will become the MSC ID for the lifetime of your
@@ -281,7 +277,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
          +-------+         |          +------+        |  +---------------+
@@ -497,42 +493,6 @@ In summary:
     a small table at the bottom mapping the various values from stable
     to unstable.
 
-### Placeholder MSCs
-
-Some proposals may contain security-sensitive or private context which can't be
-publicly disclosed until a later stage in the idea or solution process. Typically,
-the initial idea is validated using some amount of implementation or experimentation
-and may require an MSC number to make that implementation easier.
-
-Placeholder MSCs are used to represent proposals in a state where implementation
-is ongoing, but the MSC details can't yet be disclosed. Authors which feel as
-though their MSC could be highly sensitive MUST get in contact with the Spec Core
-Team or [Security Team](https://matrix.org/security-disclosure-policy/) prior to
-opening their MSC. If either team determines that a placeholder MSC is required,
-it may be opened as such.
-
-There are a few expectations attached to placeholder MSCs:
-
-* They have a title which marks them WIP, and are in the "draft" state.
-* They have the following labels: `[proposal-placeholder, action-required, needs-implementation]`.
-  * Notably, *not* `proposal`.
-* They are relatively short-lived (ideally less than 6-12 months in placeholder).
-* They propose solutions which are reasonably likely to be accepted. If a placeholder
-  needs to be closed because the idea won't work, isn't needed, etc, then the MSC's
-  content MUST be published ahead of that closure.
-  * Note: the MSC's publication (and therefore closure) may be delayed until an
-    appropriate point in the security disclosure cycle. For example, an alternative
-    MSC being published, or a stream of work being completed.
-* When they are updated to receive real content, the following happens:
-  1. The Spec Core Team or the author leaves a comment to cause a notification
-     that the MSC has been replaced with real content.
-  2. The `proposal` label (or its equivalent) is added to trigger chat notifications
-     in the public Matrix rooms. The `proposal-placeholder` and `action-required`
-     labels should be removed at this stage as well. Other labels are removed/applied
-     per normal process.
-* The Spec Core Team is aware of the intended MSC's title and purpose. This is
-  especially important if the Security Team approved the use of a placeholder MSC.
-
 ## Proposal Tracking
 
 This is a living document generated from the list of proposals on the
@@ -555,7 +515,7 @@ resolve to the desired MSC, whether it started as an issue or a PR.
 Other metadata:
 
 -   The MSC number is taken from the GitHub Pull Request ID. This is
-    carried for the lifetime of the proposal. These IDs do not necessarily
+    carried for the lifetime of the proposal. These IDs do not necessary
     represent a chronological order.
 -   The GitHub PR title will act as the MSC's title.
 -   Please link to the spec PR (if any) by adding a "PRs: \#1234" line

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/_index.md

@@ -36,12 +36,11 @@ Alternatively, consider flipping the column/row organization to be features
 up top and versions on the left.
 -->
 
-| Feature \ Version | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
+| Feature \ Version | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 |
-|-------------------|---|---|---|---|---|---|---|---|---|----|----|----|
+|-------------------|---|---|---|---|---|---|---|---|---|----|----|
-| **Knocking**      | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
+| **Knocking**      | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ | ✔ | ✔ |
-| **Restricted join rules** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ | ✔ | ✔ |
+| **Restricted join rules** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ | ✔ |
-| **`knock_restricted` join rule** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ |
+| **`knock_restricted` join rule** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ |
-| **Additional room creators** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ |
 
 ## Complete list of room versions
 
@@ -53,22 +52,9 @@ stable and unstable periodically for a variety of reasons, including
 discovered security vulnerabilities and age.
 
 Clients should not ask room administrators to upgrade their rooms if the
-room is running a stable version. Servers SHOULD use **room version 12** as
+room is running a stable version. Servers SHOULD use **room version 11** as
 the default room version when creating new rooms.
 
-{{% boxes/note %}}
-
-{{% added-in v="1.16" %}}
-
-Room version 12 is introduced and made default in this specification release.
-Servers are encouraged to continue using room version 11 as the default room
-version for the early days and weeks following this specification release,
-and then gradually switch the default over when they deem appropriate.
-
-<!-- TODO(SCT): Remove this note box in Matrix 1.17 -->
-
-{{% /boxes/note %}}
-
 The available room versions are:
 
 -   [Version 1](/rooms/v1) - **Stable**. The initial room version.
@@ -90,9 +76,6 @@ The available room versions are:
 -   [Version 10](/rooms/v10) - **Stable**. Enforces integer-only power levels
     and adds `knock_restricted` join rule.
 -   [Version 11](/rooms/v11) - **Stable**. Clarifies the redaction algorithm.
--   [Version 12](/rooms/v12) - **Stable**. Changes room IDs to be hashes of the
-    create event, formalizes room creators with infinite power level, and iterates
-    on state resolution.
 
 ## Room version grammar
 

content/rooms/fragments/v1-auth-rules.md

@@ -30,14 +30,10 @@ The rules are as follows:
         specified by the [auth events
         selection](/server-server-api#auth-events-selection)
         algorithm described in the server specification, reject.
-
-        **Note**: This room version requires an `m.room.create` event to be selected.
     3.  If there are entries which were themselves rejected under the [checks
         performed on receipt of a
         PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
     4. If there is no `m.room.create` event among the entries, reject.
-    5. If any event in `auth_events` has a `room_id` which does not match that of
-       the event being authorised, reject.
 3. If the `content` of the `m.room.create` event in the room state has the
    property `m.federate` set to `false`, and the `sender` domain of the event
    does not match the `sender` domain of the create event, reject.

content/rooms/fragments/v12-event-format.md

@@ -1,4 +0,0 @@
-
-Events in rooms of this version have the following structure:
-
-{{% definition path="api/server-server/definitions/pdu_v12" %}}

content/rooms/fragments/v3-auth-rules.md

@@ -38,14 +38,10 @@ The complete list of rules, as of room version 3, is as follows:
         specified by the [auth events
         selection](/server-server-api#auth-events-selection)
         algorithm described in the server specification, reject.
-
-        **Note**: This room version requires an `m.room.create` event to be selected.
     3.  If there are entries which were themselves rejected under the [checks
         performed on receipt of a
         PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
     4. If there is no `m.room.create` event among the entries, reject.
-    5. If any event in `auth_events` has a `room_id` which does not match that of
-       the event being authorised, reject.
 3. If the `content` of the `m.room.create` event in the room state has the
    property `m.federate` set to `false`, and the `sender` domain of the event
    does not match the `sender` domain of the create event, reject.

content/rooms/fragments/v3-handling-redactions.md

@@ -17,9 +17,6 @@ is met:
 2. The domain of the redaction event's `sender` matches that of the
    original event's `sender`.
 
-Note that the first condition holds true even when the `sender` doesn't have a
-high enough power level to send the type of event that they're redacting.
-
 If the server would apply a redaction, the redaction event is also sent
 to clients. Otherwise, the server simply waits for a valid partner event
 to arrive where it can then re-check the above.

content/rooms/fragments/v8-auth-rules.md

@@ -44,14 +44,10 @@ The rules are as follows:
         specified by the [auth events
         selection](/server-server-api#auth-events-selection)
         algorithm described in the server specification, reject.
-
-        **Note**: This room version requires an `m.room.create` event to be selected.
     3.  If there are entries which were themselves rejected under the [checks
         performed on receipt of a
         PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
     4. If there is no `m.room.create` event among the entries, reject.
-    5. If any event in `auth_events` has a `room_id` which does not match that of
-       the event being authorised, reject.
 3. If the `content` of the `m.room.create` event in the room state has the
    property `m.federate` set to `false`, and the `sender` domain of the event
    does not match the `sender` domain of the create event, reject.
@@ -74,7 +70,7 @@ The rules are as follows:
             1.  If membership state is `join` or `invite`, allow.
             2.  If the `join_authorised_via_users_server` key in `content`
                 is not a user with sufficient permission to invite other
-                users or is not a joined member of the room, reject.
+                users, reject.
             3.  Otherwise, allow.
         6.  If the `join_rule` is `public`, allow.
         7.  Otherwise, reject.

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
@@ -120,14 +120,10 @@ The rules are as follows:
         specified by the [auth events
         selection](/server-server-api#auth-events-selection)
         algorithm described in the server specification, reject.
-
-        **Note**: This room version requires an `m.room.create` event to be selected.
     3.  If there are entries which were themselves rejected under the [checks
         performed on receipt of a
         PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
     4. If there is no `m.room.create` event among the entries, reject.
-    5. If any event in `auth_events` has a `room_id` which does not match that of
-       the event being authorised, reject.
 3. If the `content` of the `m.room.create` event in the room state has the
    property `m.federate` set to `false`, and the `sender` domain of the event
    does not match the `sender` domain of the create event, reject.
@@ -150,7 +146,7 @@ The rules are as follows:
             1.  If membership state is `join` or `invite`, allow.
             2.  If the `join_authorised_via_users_server` key in `content`
                 is not a user with sufficient permission to invite other
-                users or is not a joined member of the room, reject.
+                users, reject.
             3.  Otherwise, allow.
         6.  If the `join_rule` is `public`, allow.
         7.  Otherwise, reject.

content/rooms/v11.md

@@ -127,14 +127,10 @@ The rules are as follows:
         specified by the [auth events
         selection](/server-server-api#auth-events-selection)
         algorithm described in the server specification, reject.
-
-        **Note**: This room version requires an `m.room.create` event to be selected.
     3.  If there are entries which were themselves rejected under the [checks
         performed on receipt of a
         PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
     4. If there is no `m.room.create` event among the entries, reject.
-    5. If any event in `auth_events` has a `room_id` which does not match that of
-       the event being authorised, reject.
 3. If the `content` of the `m.room.create` event in the room state has the
    property `m.federate` set to `false`, and the `sender` domain of the event
    does not match the `sender` domain of the create event, reject.
@@ -157,7 +153,7 @@ The rules are as follows:
             1.  If membership state is `join` or `invite`, allow.
             2.  If the `join_authorised_via_users_server` key in `content`
                 is not a user with sufficient permission to invite other
-                users or is not a joined member of the room, reject.
+                users, reject.
             3.  Otherwise, allow.
         6.  If the `join_rule` is `public`, allow.
         7.  Otherwise, reject.

content/rooms/v12.md

@@ -1,501 +0,0 @@
----
-title: Room Version 12
-type: docs
-weight: 100
-version: 12
----
-
-This room version builds on [version 11](/rooms/v11), iterating on the state resolution
-algorithm, giving room creators infinite power level, and changing the format of room
-IDs to be a hash of the create event.
-
-## Client considerations
-
-### Event format
-
-Clients SHOULD observe the following changes to events in this room version:
-
-* Room IDs no longer include a domain component and are instead a hash of the
-  `m.room.create` event, per below. See the [room ID grammar](/appendices#room-ids)
-  for more information.
-
-* A concept of "room creators" is formally defined as the `sender` of the `m.room.create`
-  event *plus* any `additional_creators` from the `m.room.create` event's `content`,
-  if present. In prior room versions, the only creator was the `sender` of the
-  `m.room.create` event (or `creator` in much older room versions).
-
-* Room creators have infinitely high power level and cannot be specified in the
-  `m.room.power_levels` event, nor can they be changed after the room is created.
-
-## Server implementation components
-
-{{% boxes/warning %}}
-The information contained in this section is strictly for server
-implementors. Applications which use the Client-Server API are generally
-unaffected by the intricacies contained here. The section above
-regarding client considerations is the resource that Client-Server API
-use cases should reference.
-{{% /boxes/warning %}}
-
-Room version 12 is based upon room version 11 with the following considerations.
-
-### Event format
-
-{{% rver-fragment name="v12-event-format" %}}
-
-### Authorization rules
-
-Events must be signed by the server denoted by the `sender` property.
-
-The types of state events that affect authorization are:
-
--   [`m.room.create`](/client-server-api#mroomcreate)
--   [`m.room.member`](/client-server-api#mroommember)
--   [`m.room.join_rules`](/client-server-api#mroomjoin_rules)
--   [`m.room.power_levels`](/client-server-api#mroompower_levels)
--   [`m.room.third_party_invite`](/client-server-api#mroomthird_party_invite)
-
-{{% boxes/note %}}
-Power levels are inferred from defaults when not explicitly supplied.
-For example, mentions of the `sender`'s power level can also refer to
-the default power level for users in the room.
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-{{% added-in v=12 %}} The power level of "room creators" is infinitely high.
-
-Room creators include:
-* The user ID denoted by the `sender` of the `m.room.create` event in the room.
-* Any user IDs contained in the `additional_creators` array in `content` of the
-  `m.room.create` event in the room, if `additional_creators` is present.
-
-Room creators cannot be demoted to a lower power level, even through `m.room.power_levels`.
-This is reflected in rule 10.4 below.
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-`m.room.redaction` events are subject to auth rules in the same way as any other event.
-In practice, that means they will normally be allowed by the auth rules, unless the
-`m.room.power_levels` event sets a power level requirement for `m.room.redaction`
-events via the `events` or `events_default` properties. In particular, the _redact
-level_ is **not** considered by the auth rules.
-
-The ability to send a redaction event does not mean that the redaction itself should
-be performed. Receiving servers must perform additional checks, as described in
-the [Handling redactions](#handling-redactions) section.
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-The `m.room.create` event MUST NOT be selected for `auth_events` on events. The
-`room_id` (being the `m.room.create` event's ID) implies this instead. This is
-reflected in a change to rule 3.2 below.
-{{% /boxes/note %}}
-
-The rules are as follows:
-
-1.  If type is `m.room.create`:
-    1.  If it has any `prev_events`, reject.
-    2.  {{% changed-in v=12 %}} If the event has a `room_id`, reject.
-
-        **Note**: The room ID is the event ID of the event with sigil `!` instead
-        of `$`.
-    3.  If `content.room_version` is present and is not a recognised
-        version, reject.
-    4.  {{% added-in v=12 %}} If `additional_creators` is present in `content` and
-        is not an array of strings where each string passes the same [user ID](/appendices#user-identifiers)
-        validation applied to `sender`, reject.
-    5.  Otherwise, allow.
-2. {{% added-in v=12 %}} If the event's `room_id` is not an event ID for an accepted
-   (not rejected) `m.room.create` event, with the sigil `!` instead of `$`, reject.
-3.  Considering the event's `auth_events`:
-    1.  If there are duplicate entries for a given `type` and `state_key` pair,
-        reject.
-    2.  {{% changed-in v=12 %}} If there are entries whose `type` and `state_key`
-        don't match those specified by the [auth events selection](/server-server-api#auth-events-selection)
-        algorithm described in the server specification, reject.
-
-        **Note**: In this room version, `m.room.create` MUST NOT be selected.
-    3.  If there are entries which were themselves rejected under the [checks
-        performed on receipt of a
-        PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
-    5.  If any event in `auth_events` has a `room_id` which does not match that of
-        the event being authorised, reject.
-4. If the `content` of the `m.room.create` event in the room state has the
-   property `m.federate` set to `false`, and the `sender` domain of the event
-   does not match the `sender` domain of the create event, reject.
-5.  If type is `m.room.member`:
-    1.  If there is no `state_key` property, or no `membership` property in
-        `content`, reject.
-    2.  If `content` has a `join_authorised_via_users_server`
-        key:
-        1.  If the event is not validly signed by the homeserver of the user ID denoted
-            by the key, reject.
-    3.  If `membership` is `join`:
-        1.  If the only previous event is an `m.room.create` and the
-            `state_key` is the sender of the `m.room.create`, allow.
-        2.  If the `sender` does not match `state_key`, reject.
-        3.  If the `sender` is banned, reject.
-        4.  If the `join_rule` is `invite` or `knock` then allow if
-            membership state is `invite` or `join`.
-        5.  If the `join_rule` is `restricted` or `knock_restricted`:
-            1.  If membership state is `join` or `invite`, allow.
-            2.  If the `join_authorised_via_users_server` key in `content`
-                is not a user with sufficient permission to invite other
-                users or is not a joined member of the room, reject.
-            3.  Otherwise, allow.
-        6.  If the `join_rule` is `public`, allow.
-        7.  Otherwise, reject.
-    4.  If `membership` is `invite`:
-        1.  If `content` has a `third_party_invite` property:
-            1.  If *target user* is banned, reject.
-            2.  If `content.third_party_invite` does not have a `signed`
-                property, reject.
-            3.  If `signed` does not have `mxid` and `token` properties,
-                reject.
-            4.  If `mxid` does not match `state_key`, reject.
-            5.  If there is no `m.room.third_party_invite` event in the
-                current room state with `state_key` matching `token`,
-                reject.
-            6.  If `sender` does not match `sender` of the
-                `m.room.third_party_invite`, reject.
-            7.  If any signature in `signed` matches any public key in
-                the `m.room.third_party_invite` event, allow. The public
-                keys are in `content` of `m.room.third_party_invite` as:
-                1.  A single public key in the `public_key` property.
-                2.  A list of public keys in the `public_keys` property.
-            8.  Otherwise, reject.
-        2.  If the `sender`'s current membership state is not `join`,
-            reject.
-        3.  If *target user*'s current membership state is `join` or
-            `ban`, reject.
-        4.  If the `sender`'s power level is greater than or equal to
-            the *invite level*, allow.
-        5.  Otherwise, reject.
-    5.  If `membership` is `leave`:
-        1.  If the `sender` matches `state_key`, allow if and only if
-            that user's current membership state is `invite`, `join`,
-            or `knock`.
-        2.  If the `sender`'s current membership state is not `join`,
-            reject.
-        3.  If the *target user*'s current membership state is `ban`,
-            and the `sender`'s power level is less than the *ban level*,
-            reject.
-        4.  If the `sender`'s power level is greater than or equal to
-            the *kick level*, and the *target user*'s power level is
-            less than the `sender`'s power level, allow.
-        5.  Otherwise, reject.
-    6.  If `membership` is `ban`:
-        1.  If the `sender`'s current membership state is not `join`,
-            reject.
-        2.  If the `sender`'s power level is greater than or equal to
-            the *ban level*, and the *target user*'s power level is less
-            than the `sender`'s power level, allow.
-        3.  Otherwise, reject.
-    7. If `membership` is `knock`:
-        1.  If the `join_rule` is anything other than `knock` or
-            `knock_restricted`, reject.
-        2.  If `sender` does not match `state_key`, reject.
-        3.  If the `sender`'s current membership is not `ban`, `invite`,
-            or `join`, allow.
-        4.  Otherwise, reject.
-    8.  Otherwise, the membership is unknown. Reject.
-6.  If the `sender`'s current membership state is not `join`, reject.
-7.  If type is `m.room.third_party_invite`:
-    1.  Allow if and only if `sender`'s current power level is greater
-        than or equal to the *invite level*.
-8.  If the event type's *required power level* is greater than the
-    `sender`'s power level, reject.
-9.  If the event has a `state_key` that starts with an `@` and does not
-    match the `sender`, reject.
-10. If type is `m.room.power_levels`:
-    1.  If any of the properties `users_default`, `events_default`, `state_default`,
-        `ban`, `redact`, `kick`, or `invite` in `content` are present and
-        not an integer, reject.
-    2.  If either of the properties `events` or `notifications` in `content`
-        are present and not an object with values that are integers,
-        reject.
-    3.  If the `users` property in `content` is not an object with keys that
-        are valid user IDs with values that are integers, reject.
-    4.  {{% added-in v=12 %}} If the `users` property in `content` contains the
-        `sender` of the `m.room.create` event or any of the `additional_creators`
-        array (if present) from the `content` of the `m.room.create` event, reject.
-    5.  If there is no previous `m.room.power_levels` event in the room,
-        allow.
-    6.  For the properties `users_default`, `events_default`, `state_default`,
-        `ban`, `redact`, `kick`, `invite` check if they were added,
-        changed or removed. For each found alteration:
-        1.  If the current value is higher than the `sender`'s current
-            power level, reject.
-        2.  If the new value is higher than the `sender`'s current power
-            level, reject.
-    7.  For each entry being changed in, or removed from, the `events` or
-        `notifications` properties:
-        1.  If the current value is greater than the `sender`'s current
-            power level, reject.
-    8.  For each entry being added to, or changed in, the `events` or
-        `notifications` properties:
-        1.  If the new value is greater than the `sender`'s current power
-            level, reject.
-    9.  For each entry being changed in, or removed from, the `users` property,
-        other than the `sender`'s own entry:
-        1.  If the current value is greater than or equal to the `sender`'s
-            current power level, reject.
-    10. For each entry being added to, or changed in, the `users` property:
-        1.  If the new value is greater than the `sender`'s current power
-            level, reject.
-    10. Otherwise, allow.
-11. Otherwise, allow.
-
-{{% boxes/note %}}
-Some consequences of these rules:
-
--   Unless you are a member of the room, the only permitted operations
-    (apart from the initial create/join) are: joining a public room;
-    accepting or rejecting an invitation to a room.
--   To unban somebody, you must have power level greater than or equal
-    to both the kick *and* ban levels, *and* greater than the target
-    user's power level.
-{{% /boxes/note %}}
-
-### State resolution
-
-{{% boxes/note %}}
-{{% added-in v=12 %}} This state resolution algorithm is largely the same as the
-algorithm found in [room version 2](/rooms/v2) with the following modifications:
-
-1. The *iterative auth checks algorithm* in the [Algorithm](#algorithm) subsection
-   now starts with an *empty* state map instead of the unconflicted state map.
-
-2. A new [definition](#definitions) for *conflicted state subgraph* has been added
-   which describes events that are required to authorize events during iterative
-   auth checks.
-
-3. To ensure the new conflicted state subgraph is actually referenced, the definition
-   for *full conflicted set* additionally includes the subgraph.
-{{% /boxes/note %}}
-
-The room state *S′(E)* after an event *E* is defined in terms of the
-room state *S(E)* before *E*, and depends on whether *E* is a state
-event or a message event:
-
--   If *E* is a message event, then *S′(E)* = *S(E)*.
--   If *E* is a state event, then *S′(E)* is *S(E)*, except that its
-    entry corresponding to the `event_type` and `state_key` of *E* is
-    replaced by the `event_id` of *E*.
-
-The room state *S(E)* before *E* is the *resolution* of the set of
-states {*S′(E*<sub>1</sub>*)*, *S′(E*<sub>2</sub>*)*, …}
-after the `prev_event`s {*E*<sub>1</sub>, *E*<sub>2</sub>, …} of *E*.
-The resolution of a set of states is given in the algorithm below.
-
-#### Definitions
-
-The state resolution algorithm for version 2 rooms uses the following
-definitions, given the set of room states
-{*S*<sub>1</sub>, *S*<sub>2</sub>, …}:
-
-**Power events.**
-A *power event* is a state event with type `m.room.power_levels` or
-`m.room.join_rules`, or a state event with type `m.room.member` where
-the `membership` is `leave` or `ban` and the `sender` does not match the
-`state_key`. The idea behind this is that power events are events that
-might remove someone's ability to do something in the room.
-
-**Unconflicted state map and conflicted state set.**
-The keys of the state maps *S<sub>i</sub>* are 2-tuples of strings of the form
-*K* = `(event_type, state_key)`. The values *V* are state events.
-The key-value pairs (*K*, *V*) across all state maps *S<sub>i</sub>* can be
-divided into two collections.
-If a given key *K* is present in every *S<sub>i</sub>* with the same value *V*
-in each state map, then the pair (*K*, *V*) belongs to the *unconflicted state map*.
-Otherwise, *V* belongs to the *conflicted state set*.
-
-Note that the unconflicted state map only has one event for each key *K*,
-whereas the conflicted state set may contain multiple events with the same key.
-
-**Auth chain.**
-The *auth chain* of an event *E* is the set containing all of *E*'s auth events,
-all of *their* auth events, and so on recursively, stretching back to the
-start of the room. Put differently, these are the events reachable by walking
-the graph induced by an event's `auth_events` links.
-
-**Auth difference.**
-The *auth difference* is calculated by first calculating the full auth
-chain for each state *S*<sub>*i*</sub>, that is the union of the auth
-chains for each event in *S*<sub>*i*</sub>, and then taking every event
-that doesn't appear in every auth chain. If *C*<sub>*i*</sub> is the
-full auth chain of *S*<sub>*i*</sub>, then the auth difference is
-∪ *C*<sub>*i*</sub> − ∩ *C*<sub>*i*</sub>.
-
-{{% added-in v=12 %}} **Conflicted state subgraph.**
-Starting from an event in the *conflicted state set* and following `auth_events`
-edges may lead to another event in the conflicted state set. The union of all
-such paths between any pair of events in the conflicted state set (including
-endpoints) forms a subgraph of the original `auth_event` graph, called the
-*conflicted state subgraph*.
-
-{{% changed-in v=12 %}} **Full conflicted set.**
-The *full conflicted set* is the union of the conflicted state set, the conflicted
-state subgraph, and the auth difference.
-
-**Reverse topological power ordering.**
-The *reverse topological power ordering* of a set of events is the
-lexicographically smallest topological ordering based on the DAG formed
-by auth events. The reverse topological power ordering is ordered from
-earliest event to latest. For comparing two topological orderings to
-determine which is the lexicographically smallest, the following
-comparison relation on events is used: for events *x* and *y*,
-*x* &lt; *y* if
-
-1.  *x*'s sender has *greater* power level than *y*'s sender, when
-    looking at their respective `auth_event`s; or
-2.  the senders have the same power level, but *x*'s `origin_server_ts`
-    is *less* than *y*'s `origin_server_ts`; or
-3.  the senders have the same power level and the events have the same
-    `origin_server_ts`, but *x*'s `event_id` is *less* than *y*'s
-    `event_id`.
-
-The reverse topological power ordering can be found by sorting the
-events using Kahn's algorithm for topological sorting, and at each step
-selecting, among all the candidate vertices, the smallest vertex using
-the above comparison relation.
-
-**Mainline ordering.**
-Let *P* = *P*<sub>0</sub> be an `m.room.power_levels` event.
-Starting with *i* = 0, repeatedly fetch *P*<sub>*i*+1</sub>, the
-`m.room.power_levels` event in the `auth_events` of *P<sub>i</sub>*.
-Increment *i* and repeat until *P<sub>i</sub>* has no `m.room.power_levels`
-event in its `auth_events`.
-The *mainline of P*<sub>0</sub> is the list of events
-    [*P*<sub>0</sub> , *P*<sub>1</sub>, ... , *P<sub>n</sub>*],
-fetched in this way.
-
-Let *e* = *e<sub>0</sub>* be another event (possibly another
-`m.room.power_levels` event). We can compute a similar list of events
-    [*e*<sub>1</sub>, ..., *e<sub>m</sub>*],
-where *e*<sub>*j*+1</sub> is the `m.room.power_levels` event in the
-`auth_events` of *e<sub>j</sub>* and where *e<sub>m</sub>* has no
-`m.room.power_levels` event in its `auth_events`. (Note that the event we
-started with, *e<sub>0</sub>*, is not included in this list. Also note that it
-may be empty, because *e* may not cite an `m.room.power_levels` event in its
-`auth_events` at all.)
-
-Now compare these two lists as follows.
-* Find the smallest index *j* ≥ 1 for which *e<sub>j</sub>* belongs to the
-   mainline of *P*.
-* If such a *j* exists, then *e<sub>j</sub>* = *P<sub>i</sub>* for some unique
-  index *i* ≥ 0. Otherwise set *i* = ∞, where ∞ is a sentinel value greater
-  than any integer.
-* In both cases, the *mainline position* of *e* is *i*.
-
-Given mainline positions calculated from *P*, the *mainline ordering based on* *P* of a set of events is the ordering,
-from smallest to largest, using the following comparison relation on
-events: for events *x* and *y*, *x* &lt; *y* if
-
-1.  the mainline position of *x* is **greater** than
-    the mainline position of *y* (i.e. the auth chain of
-    *x* is based on an earlier event in the mainline than *y*); or
-2.  the mainline positions of the events are the same, but *x*'s
-    `origin_server_ts` is *less* than *y*'s `origin_server_ts`; or
-3.  the mainline positions of the events are the same and the events have the
-    same `origin_server_ts`, but *x*'s `event_id` is *less* than *y*'s
-    `event_id`.
-
-**Iterative auth checks.**
-The *iterative auth checks algorithm* takes as input an initial room
-state and a sorted list of state events, and constructs a new room state
-by iterating through the event list and applying the state event to the
-room state if the state event is allowed by the [authorization
-rules](/server-server-api#authorization-rules).
-If the state event is not allowed by the authorization rules, then the
-event is ignored. If a `(event_type, state_key)` key that is required
-for checking the authorization rules is not present in the state, then
-the appropriate state event from the event's `auth_events` is used if
-the auth event is not rejected.
-
-#### Algorithm
-
-The *resolution* of a set of states is obtained as follows:
-
-1.  Select the set *X* of all *power events* that appear in the *full
-    conflicted set*. For each such power event *P*, enlarge *X* by adding
-    the events in the auth chain of *P* which also belong to the full
-    conflicted set. Sort *X* into a list using the *reverse topological
-    power ordering*.
-2.  {{% changed-in v=12 %}} Apply the *iterative auth checks algorithm*,
-    starting from an *empty* state map, to the list of events from the previous
-    step to get a partially resolved state.
-3.  Take all remaining events that weren't picked in step 1 and order
-    them by the mainline ordering based on the power level in the
-    partially resolved state obtained in step 2.
-4.  Apply the *iterative auth checks algorithm* on the partial resolved
-    state and the list of events from the previous step.
-5.  Update the result by replacing any event with the event with the
-    same key from the *unconflicted state map*, if such an event exists,
-    to get the final resolved state.
-
-#### Rejected events
-
-Events that have been rejected due to failing auth based on the state at
-the event (rather than based on their auth chain) are handled as usual
-by the algorithm, unless otherwise specified.
-
-Note that no events rejected due to failure to auth against their auth
-chain should appear in the process, as they should not appear in state
-(the algorithm only uses events that appear in either the state sets or
-in the auth chain of the events in the state sets).
-
-{{% boxes/rationale %}}
-This helps ensure that different servers' view of state is more likely
-to converge, since rejection state of an event may be different. This
-can happen if a third server gives an incorrect version of the state
-when a server joins a room via it (either due to being faulty or
-malicious). Convergence of state is a desirable property as it ensures
-that all users in the room have a (mostly) consistent view of the state
-of the room. If the view of the state on different servers diverges it
-can lead to bifurcation of the room due to e.g. servers disagreeing on
-who is in the room.
-
-Intuitively, using rejected events feels dangerous, however:
-
-1.  Servers cannot arbitrarily make up state, since they still need to
-    pass the auth checks based on the event's auth chain (e.g. they
-    can't grant themselves power levels if they didn't have them
-    before).
-2.  For a previously rejected event to pass auth there must be a set of
-    state that allows said event. A malicious server could therefore
-    produce a fork where it claims the state is that particular set of
-    state, duplicate the rejected event to point to that fork, and send
-    the event. The duplicated event would then pass the auth checks.
-    Ignoring rejected events would therefore not eliminate any potential
-    attack vectors.
-{{% /boxes/rationale %}}
-
-Rejected auth events are deliberately excluded from use in the iterative
-auth checks, as auth events aren't re-authed (although non-auth events
-are) during the iterative auth checks.
-
-## Unchanged from v11
-
-The following sections have not been modified since v11, but are included for
-completeness.
-
-### Redactions
-
-{{% rver-fragment name="v11-redactions" %}}
-
-### Handling redactions
-
-{{% rver-fragment name="v3-handling-redactions" %}}
-
-### Event IDs
-
-{{% rver-fragment name="v4-event-ids" %}}
-
-### Canonical JSON
-
-{{% rver-fragment name="v6-canonical-json" %}}
-
-### Signing key validity period
-
-{{% rver-fragment name="v5-signing-requirements" %}}

content/rooms/v6.md

@@ -102,14 +102,10 @@ The rules are as follows:
         specified by the [auth events
         selection](/server-server-api#auth-events-selection)
         algorithm described in the server specification, reject.
-
-        **Note**: This room version requires an `m.room.create` event to be selected.
     3.  If there are entries which were themselves rejected under the [checks
         performed on receipt of a
         PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
     4. If there is no `m.room.create` event among the entries, reject.
-    5. If any event in `auth_events` has a `room_id` which does not match that of
-       the event being authorised, reject.
 3. If the `content` of the `m.room.create` event in the room state has the
    property `m.federate` set to `false`, and the `sender` domain of the event
    does not match the `sender` domain of the create event, reject.

content/rooms/v7.md

@@ -81,14 +81,10 @@ The rules are as follows:
         specified by the [auth events
         selection](/server-server-api#auth-events-selection)
         algorithm described in the server specification, reject.
-
-        **Note**: This room version requires an `m.room.create` event to be selected.
     3.  If there are entries which were themselves rejected under the [checks
         performed on receipt of a
         PDU](/server-server-api/#checks-performed-on-receipt-of-a-pdu), reject.
     4. If there is no `m.room.create` event among the entries, reject.
-    5. If any event in `auth_events` has a `room_id` which does not match that of
-       the event being authorised, reject.
 3. If the `content` of the `m.room.create` event in the room state has the
    property `m.federate` set to `false`, and the `sender` domain of the event
    does not match the `sender` domain of the create event, reject.

content/server-server-api.md

@@ -119,8 +119,7 @@ to send. The process overall is as follows:
     server must present a valid certificate for the hostname.
 
 3.  If the hostname is not an IP literal, a regular HTTPS request is
-    made to `https://<hostname>/.well-known/matrix/server` (according to
+    made to `https://<hostname>/.well-known/matrix/server`, expecting
-    [RFC 8615](https://datatracker.ietf.org/doc/html/rfc8615)), expecting
     the schema defined later in this section. 30x redirects should be
     followed, however redirection loops should be avoided. Responses
     (successful or otherwise) to the `/.well-known` endpoint should be
@@ -289,7 +288,7 @@ and any query parameters if present, but should not include the leading
 
 Step 1 sign JSON:
 
-```nohighlight
+```
 {
     "method": "POST",
     "uri": "/target",
@@ -461,12 +460,9 @@ specification](/rooms).
 Whenever a server receives an event from a remote server, the receiving
 server must ensure that the event:
 
-1.  {{% changed-in v="1.16" %}} Is a valid event, otherwise it is dropped. For
+1.  Is a valid event, otherwise it is dropped. For an event to be valid, it
-    an event to be valid, it must comply with the event format of that [room version](/rooms).
+    must contain a `room_id`, and it must comply with the event format of
-    For some room versions, a `room_id` may also be required on the event in order
+    that [room version](/rooms).
-    to determine the room version to check the event against. See the event format
-    section of the [room version specifications](/rooms) for details on when it
-    is required.
 2.  Passes signature checks, otherwise it is dropped.
 3.  Passes hash checks, otherwise it is redacted before being processed
     further.
@@ -532,8 +528,7 @@ the sender permission to send the event. The `auth_events` for the
 `m.room.create` event in a room is empty; for other events, it should be
 the following subset of the room state:
 
-- {{% changed-in v="1.16" %}} Depending on the [room version](/rooms), the
+- The `m.room.create` event.
-  `m.room.create` event.
 
 - The current `m.room.power_levels` event, if any.
 
@@ -548,8 +543,8 @@ the following subset of the room state:
       `third_party_invite` property, the current
       `m.room.third_party_invite` event with `state_key` matching
       `content.third_party_invite.signed.token`, if any.
-    - If `membership` is `join`, `content.join_authorised_via_users_server`
+    - If `content.join_authorised_via_users_server` is present,
-      is present, and the [room version supports restricted rooms](/rooms/#feature-matrix),
+      and the [room version supports restricted rooms](/rooms/#feature-matrix),
       then the `m.room.member` event with `state_key` matching
       `content.join_authorised_via_users_server`.
 
@@ -822,7 +817,7 @@ ResidentServer->JoiningServer: send_join response
 JoiningServer->Client: join response
 -->
 
-```nohighlight
+```
 +---------+          +---------------+            +-----------------+ +-----------------+
 | Client  |          | JoiningServer |            | DirectoryServer | | ResidentServer  |
 +---------+          +---------------+            +-----------------+ +-----------------+
@@ -945,18 +940,6 @@ Note that invites are used to indicate that knocks were accepted. As such,
 receiving servers should be prepared to manually link up a previous knock
 to an invite if the invite event does not directly reference the knock.
 
-{{% boxes/note %}}
-{{% added-in v="1.16" %}} `invite_room_state` MUST now have its entries formatted
-according to the room's version (see [room version specification](/rooms)). However,
-servers SHOULD consider their local ecosystems before returning the described
-`400 M_MISSING_PARAM` error code. While migrating, servers SHOULD warn about
-invites which fail the validation rather than error in room versions 1 through 11.
-All invites to other room versions which fail validation SHOULD result in an error.
-
-The specification suggests that servers finish their migration no later than
-January 2026, though servers may extend this as required to support their users.
-{{% /boxes/note %}}
-
 {{% http-api spec="server-server" api="invites-v1" %}}
 
 {{% http-api spec="server-server" api="invites-v2" %}}
@@ -987,8 +970,9 @@ the event to other servers in the room.
 ## Third-party invites
 
 {{% boxes/note %}}
-More information about third-party invites is available in the Client-Server API
+More information about third-party invites is available in the
-under the [Third-party invites](/client-server-api/#third-party-invites) module.
+[Client-Server API](/client-server-api) under
+the Third-party Invites module.
 {{% /boxes/note %}}
 
 When a user wants to invite another user in a room but doesn't know the
@@ -1001,41 +985,38 @@ API](/identity-service-api).
 
 ### Cases where an association exists for a third-party identifier
 
-If the third-party identifier is already bound to a Matrix ID, a [lookup
+If the third-party identifier is already bound to a Matrix ID, a lookup
-request](/identity-service-api/#post_matrixidentityv2lookup) on the identity
+request on the identity server will return it. The invite is then
-server will return it. The invite is then processed by the inviting homeserver
+processed by the inviting homeserver as a standard `m.room.member`
-as a [standard `m.room.member` invite event](#inviting-to-a-room). This is the
+invite event. This is the simplest case.
-simplest case.
 
 ### Cases where an association doesn't exist for a third-party identifier
 
 If the third-party identifier isn't bound to any Matrix ID, the inviting
-homeserver will request the identity server to [store an invite](/identity-service-api/#invitation-storage)
+homeserver will request the identity server to store an invite for this
-for this identifier and to deliver it to whoever binds it to its Matrix ID. It
+identifier and to deliver it to whoever binds it to its Matrix ID. It
-will also send an [`m.room.third_party_invite`](/client-server-api/#mroomthird_party_invite)
+will also send an `m.room.third_party_invite` event in the room to
-event in the room to specify a display name, a token and public keys the
+specify a display name, a token and public keys the identity server
-identity server provided as a response to the invite storage request.
+provided as a response to the invite storage request.
-
+
-When a third-party identifier with pending invites gets bound to a Matrix ID,
+When a third-party identifier with pending invites gets bound to a
-the identity server will send a request to the [`/3pid/onbind`](#put_matrixfederationv13pidonbind)
+Matrix ID, the identity server will send a POST request to the ID's
-endpoint of the the ID's homeserver as described in the [Invitation
+homeserver as described in the [Invitation
-Storage](/identity-service-api#invitation-storage) section of the Identity
+Storage](/identity-service-api#invitation-storage)
-Service API.
+section of the Identity Service API.
 
 The following process applies for each invite sent by the identity
 server:
 
-The invited homeserver will create an [`m.room.member`](/client-server-api/#mroommember)
+The invited homeserver will create an `m.room.member` invite event
-invite event containing a special `third_party_invite` section containing the
+containing a special `third_party_invite` section containing the token
-token and a `signed` object, both provided by the identity server.
+and a signed object, both provided by the identity server.
 
 If the invited homeserver is in the room the invite came from, it can
 auth the event and send it.
 
 However, if the invited homeserver isn't in the room the invite came
-from, it will need to request the inviting homeserver to auth the event
+from, it will need to request the room's homeserver to auth the event.
-at the [`/exchange_third_party_invite`](#put_matrixfederationv1exchange_third_party_inviteroomid)
-endpoint.
 
 {{% http-api spec="server-server" api="third_party_invite" %}}
 
@@ -1064,10 +1045,11 @@ user's Matrix ID and the token delivered when the invite was stored,
 this verification will prove that the `m.room.member` invite event comes
 from the user owning the invited third-party identifier.
 
-## Published Room Directory
+## Public Room Directory
 
-To complement the [room directory in the Client-Server API](/client-server-api#published-room-directory),
+To complement the [Client-Server
-homeservers need a way to query the published rooms of another server.
+API](/client-server-api)'s room directory,
+homeservers need a way to query the public rooms for another server.
 This can be done by making a request to the `/publicRooms` endpoint for
 the server the room directory should be retrieved for.
 
@@ -1355,7 +1337,7 @@ calculated as follows.
 The *content hash* of an event covers the complete event including the
 *unredacted* contents. It is calculated as follows.
 
-First, any existing `unsigned`, `signatures`, and `hashes` properties are
+First, any existing `unsigned`, `signature`, and `hashes` members are
 removed. The resulting object is then encoded as [Canonical
 JSON](/appendices#canonical-json), and the JSON is hashed using
 SHA-256.

data/api/application-service/definitions/namespace_list.yaml

@@ -11,7 +11,6 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
-$schema: https://json-schema.org/draft/2020-12/schema
 
 type: array
 items:

data/api/application-service/definitions/protocol.yaml

@@ -23,4 +23,3 @@ allOf:
       type: array
       items:
         $ref: protocol_instance.yaml
-  required: ['instances']

data/api/application-service/definitions/protocol_base.yaml

@@ -77,4 +77,4 @@ properties:
         "placeholder": "#foobar"
       }
     }
-required: ['user_fields', 'location_fields', 'icon', 'field_types']
+required: ['user_fields', 'location_fields', 'icon', 'field_types', 'instances']

data/api/application-service/definitions/registration.yaml

@@ -11,7 +11,6 @@
 # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 # See the License for the specific language governing permissions and
 # limitations under the License.
-$schema: https://json-schema.org/draft/2020-12/schema
 
 type: object
 title: Registration
@@ -20,7 +19,7 @@ properties:
     type: string
     description: A unique, user-defined ID of the application service which will never change.
   url:
-    type: ["null", "string"]
+    type: string
     description: The URL for the application service. May include a path after the domain name. Optionally set to null if no traffic is required.
   as_token:
     type: string

data/api/client-server/account_deactivation.yaml

@@ -1,141 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2022 The Matrix.org Foundation C.I.C.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-openapi: 3.1.0
-info:
-  title: Matrix Client-Server Account Deactivation API
-  version: 1.0.0
-paths:
-  /account/deactivate:
-    post:
-      summary: Deactivate a user's account.
-      description: |-
-        Deactivate the user's account, removing all ability for the user to
-        login again.
-
-        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
-
-        An access token should be submitted to this endpoint if the client has
-        an active session.
-
-        The homeserver may change the flows available depending on whether a
-        valid access token is provided.
-
-        Unlike other endpoints, this endpoint does not take an `id_access_token`
-        parameter because the homeserver is expected to sign the request to the
-        identity server instead.
-      security:
-        - {}
-        - accessTokenQuery: []
-        - accessTokenBearer: []
-      operationId: deactivateAccount
-      requestBody:
-        content:
-          application/json:
-            schema:
-              type: object
-              properties:
-                auth:
-                  description: Additional authentication information for the user-interactive
-                    authentication API.
-                  allOf:
-                    - $ref: definitions/auth_data.yaml
-                id_server:
-                  type: string
-                  description: |-
-                    The identity server to unbind all of the user's 3PIDs from.
-                    If not provided, the homeserver MUST use the `id_server`
-                    that was originally use to bind each identifier. If the
-                    homeserver does not know which `id_server` that was,
-                    it must return an `id_server_unbind_result` of
-                    `no-support`.
-                  example: example.org
-                erase:
-                  x-addedInMatrixVersion: "1.10"
-                  type: boolean
-                  description: |-
-                    Whether the user would like their content to be erased as
-                    much as possible from the server.
-
-                    Erasure means that any users (or servers) which join the
-                    room after the erasure request are served redacted copies of
-                    the events sent by this account. Users which had visibility
-                    on those events prior to the erasure are still able to see
-                    unredacted copies. No redactions are sent and the erasure
-                    request is not shared over federation, so other servers
-                    might still serve unredacted copies.
-
-                    The server should additionally erase any non-event data
-                    associated with the user, such as [account data](/client-server-api/#client-config)
-                    and [contact 3PIDs](/client-server-api/#adding-account-administrative-contact-information).
-
-                    Defaults to `false` if not present.
-        required: true
-      responses:
-        "200":
-          description: The account has been deactivated.
-          content:
-            application/json:
-              schema:
-                type: object
-                properties:
-                  id_server_unbind_result:
-                    type: string
-                    enum:
-                      - success
-                      - no-support
-                    description: |-
-                      An indicator as to whether or not the homeserver was able to unbind
-                      the user's 3PIDs from the identity server(s). `success` indicates
-                      that all identifiers have been unbound from the identity server while
-                      `no-support` indicates that one or more identifiers failed to unbind
-                      due to the identity server refusing the request or the homeserver
-                      being unable to determine an identity server to unbind from. This
-                      must be `success` if the homeserver has no identifiers to unbind
-                      for the user.
-                    example: success
-                required:
-                  - id_server_unbind_result
-        "401":
-          description: The homeserver requires additional authentication information.
-          content:
-            application/json:
-              schema:
-                $ref: definitions/auth_response.yaml
-        "429":
-          description: This request was rate-limited.
-          content:
-            application/json:
-              schema:
-                $ref: definitions/errors/rate_limited.yaml
-      tags:
-        - Account management
-servers:
-  - url: "{protocol}://{hostname}{basePath}"
-    variables:
-      protocol:
-        enum:
-          - http
-          - https
-        default: https
-      hostname:
-        default: localhost:8008
-      basePath:
-        default: /_matrix/client/v3
-components:
-  securitySchemes:
-    accessTokenQuery:
-      $ref: definitions/security.yaml#/accessTokenQuery
-    accessTokenBearer:
-      $ref: definitions/security.yaml#/accessTokenBearer

data/api/client-server/administrative_contact.yaml

@@ -99,10 +99,6 @@ paths:
         has been removed, making this endpoint behave as though it was `false`.
         This results in this endpoint being an equivalent to `/3pid/bind` rather
         than dual-purpose.
-
-        This endpoint uses [capabilities negotiation](/client-server-api/#capabilities-negotiation).
-        Clients SHOULD check the value of the [`m.3pid_changes` capability](/client-server-api/#m3pid_changes-capability)
-        to determine if this endpoint is available.
       operationId: post3PIDs
       deprecated: true
       security:
@@ -205,15 +201,6 @@ paths:
 
         Homeservers should prevent the caller from adding a 3PID to their account if it has
         already been added to another user's account on the homeserver.
-
-        This endpoint uses [capabilities negotiation](/client-server-api/#capabilities-negotiation).
-        Clients SHOULD check the value of the [`m.3pid_changes` capability](/client-server-api/#m3pid_changes-capability)
-        to determine if this endpoint is available.
-
-        {{% boxes/warning %}}
-        Since this endpoint uses User-Interactive Authentication, it cannot be used when the access token was obtained
-        via the [OAuth 2.0 API](/client-server-api/#oauth-20-api).
-        {{% /boxes/warning %}}
       operationId: add3PID
       security:
         - accessTokenQuery: []
@@ -339,10 +326,6 @@ paths:
         Unlike other endpoints, this endpoint does not take an `id_access_token`
         parameter because the homeserver is expected to sign the request to the
         identity server instead.
-
-        This endpoint uses [capabilities negotiation](/client-server-api/#capabilities-negotiation).
-        Clients SHOULD check the value of the [`m.3pid_changes` capability](/client-server-api/#m3pid_changes-capability)
-        to determine if this endpoint is available.
       operationId: delete3pidFromAccount
       security:
         - accessTokenQuery: []

data/api/client-server/appservice_room_directory.yaml

@@ -13,21 +13,18 @@
 # limitations under the License.
 openapi: 3.1.0
 info:
-  title: Matrix Client-Server Application Service Published Room Directory API
+  title: Matrix Client-Server Application Service Room Directory API
   version: 1.0.0
 paths:
   "/directory/list/appservice/{networkId}/{roomId}":
     put:
-      summary: |-
+      summary: Updates a room's visibility in the application service's room directory.
-        Updates a room's visibility in the application service's published room
-        directory.
       description: |-
-        Updates the visibility of a given room in the application service's
+        Updates the visibility of a given room on the application service's room
-        published room directory.
+        directory.
 
-        This API is similar to the
+        This API is similar to the room directory visibility API used by clients
-        [visibility API](/client-server-api#put_matrixclientv3directorylistroomroomid)
+        to update the homeserver's more general room directory.
-        used by clients to update the homeserver's more general published room directory.
 
         This API requires the use of an application service access token (`as_token`)
         instead of a typical client's access_token. This API cannot be invoked by

data/api/client-server/authed-content-repo.yaml

@@ -379,8 +379,7 @@ paths:
           description: |-
             The OpenGraph data for the URL, which may be empty. Some values are
             replaced with matrix equivalents if they are provided in the response.
-            The differences from the [OpenGraph protocol](https://ogp.me/) are
+            The differences from the OpenGraph protocol are described here.
-            described here.
           content:
             application/json:
               schema:
@@ -395,9 +394,6 @@ paths:
                     format: uri
                     description: An [`mxc://` URI](/client-server-api/#matrix-content-mxc-uris) to
                       the image. Omitted if there is no image.
-                additionalProperties:
-                    description: |-
-                      Additional properties as per the [OpenGraph](https://ogp.me/) protocol.
               examples:
                 response:
                   value: {

data/api/client-server/capabilities.yaml

@@ -73,25 +73,11 @@ paths:
                           - default
                           - available
                       m.set_displayname:
-                        deprecated: true
                         $ref: '#/components/schemas/booleanCapability'
-                        description: |
+                        description: Capability to indicate if the user can change their display name.
-                          **Deprecated:** Capability to indicate if the user can change their display name.
-                          Refer to `m.profile_fields` for extended profile management.
-                          
-                          For backwards compatibility, servers that directly or indirectly include the
-                          `displayname` profile field in the `m.profile_fields` capability MUST also
-                          set this capability accordingly.
                       m.set_avatar_url:
-                        deprecated: true
                         $ref: '#/components/schemas/booleanCapability'
-                        description: |
+                        description: Capability to indicate if the user can change their avatar.
-                          **Deprecated:** Capability to indicate if the user can change their avatar.
-                          Refer to `m.profile_fields` for extended profile management.
-
-                          For backwards compatibility, servers that directly or indirectly include the
-                          `avatar_url` profile field in the `m.profile_fields` capability MUST also
-                          set this capability accordingly.
                       m.3pid_changes:
                         $ref: '#/components/schemas/booleanCapability'
                         description: Capability to indicate if the user can change 3PID associations
@@ -100,47 +86,6 @@ paths:
                         $ref: '#/components/schemas/booleanCapability'
                         description: Capability to indicate if the user can generate tokens to log further
                           clients into their account.
-                      m.profile_fields:
-                        x-addedInMatrixVersion: "1.16"
-                        type: object
-                        title: ProfileFieldsCapability
-                        description: Capability to indicate if the user can set or modify extended profile fields via
-                          [`PUT /_matrix/client/v3/profile/{userId}/{keyName}`](/client-server-api/#put_matrixclientv3profileuseridkeyname).
-                          If absent, clients SHOULD assume custom profile fields are supported, provided the
-                          homeserver advertises a specification version that includes `m.profile_fields` in the
-                          [`/versions`](/client-server-api/#get_matrixclientversions) response.
-                        properties:
-                          allowed:
-                            type: array
-                            description: |
-                              If present, a list of profile fields that clients are allowed to create, modify or delete,
-                              provided `enabled` is `true`; no other profile fields may be changed.
-                              
-                              If absent, clients may set all profile fields except those forbidden by the `disallowed`
-                              list, where present.
-                            items:
-                              type: string
-                            example:
-                              - "m.example_field"
-                              - "org.example.job_title"
-                          disallowed:
-                            type: array
-                            description:  |
-                              This property has no meaning if `allowed` is also specified.
-                              
-                              Otherwise, if present, a list of profile fields that clients are _not_ allowed to create, modify or delete.
-                              Provided `enabled` is `true`, clients MAY assume that they can set any profile field which is not
-                              included in this list.
-                            items:
-                              type: string
-                            example:
-                              - "org.example.managed_field"
-                          enabled:
-                            type: boolean
-                            description: "`true` if the user can create, update or delete any profile fields, `false` otherwise."
-                            example: true
-                        required:
-                          - enabled
               examples:
                 response:
                   value: {

data/api/client-server/content-repo.yaml

@@ -605,8 +605,7 @@ paths:
           description: |-
             The OpenGraph data for the URL, which may be empty. Some values are
             replaced with matrix equivalents if they are provided in the response.
-            The differences from the [OpenGraph](https://ogp.me/) protocol are
+            The differences from the OpenGraph protocol are described here.
-            described here.
           content:
             application/json:
               schema:
@@ -621,9 +620,6 @@ paths:
                     format: uri
                     description: An [`mxc://` URI](/client-server-api/#matrix-content-mxc-uris) to
                       the image. Omitted if there is no image.
-                additionalProperties:
-                    description: |-
-                      Additional properties as per the [OpenGraph](https://ogp.me/) protocol.
               examples:
                 response:
                   value: {

data/api/client-server/create_room.yaml

@@ -33,23 +33,9 @@ paths:
         2. An `m.room.member` event for the creator to join the room. This is
            needed so the remaining events can be sent.
 
-        3. A default `m.room.power_levels` event. Overridden by the
+        3. A default `m.room.power_levels` event, giving the room creator
-           `power_level_content_override` parameter.
+           (and not other members) permission to send state events. Overridden
-
+           by the `power_level_content_override` parameter.
-           In [room versions](/rooms) 1 through 11, the room creator (and not
-           other members) will be given permission to send state events.
-
-           In room versions 12 and later, the room creator is given infinite
-           power level and cannot be specified in the `users` field of
-           `m.room.power_levels`, so is not listed explicitly.
-
-           **Note**: For `trusted_private_chat`, the users specified in the
-           `invite` parameter SHOULD also be appended to `additional_creators`
-           by the server, per the `creation_content` parameter.
-
-           If the room's version is 12 or higher, the power level for sending
-           `m.room.tombstone` events MUST explicitly be higher than `state_default`.
-           For example, set to 150 instead of 100.
 
         4. An `m.room.canonical_alias` event if `room_alias_name` is given.
 
@@ -75,10 +61,8 @@ paths:
 
         The server will create a `m.room.create` event in the room with the
         requesting user as the creator, alongside other keys provided in the
-        `creation_content` or implied by behaviour of `creation_content`.
+        `creation_content`.
       operationId: createRoom
-      x-changedInMatrixVersion:
-        "1.16": Added server behaviour for how the initial power levels change depending on room version.
       security:
         - accessTokenQuery: []
         - accessTokenBearer: []
@@ -103,9 +87,12 @@ paths:
                     - public
                     - private
                   description: |-
-                    The room's visibility in the server's
+                    A `public` visibility indicates that the room will be shown
-                    [published room directory](/client-server-api#published-room-directory).
+                    in the published room list. A `private` visibility will hide
-                    Defaults to `private`.
+                    the room from the published room list. Rooms default to
+                    `private` visibility if this key is not included. NB: This
+                    should not be confused with `join_rules` which also uses the
+                    word `public`.
                 room_alias_name:
                   type: string
                   description: |-
@@ -122,17 +109,15 @@ paths:
                 name:
                   type: string
                   description: |-
-                    If this is included, an [`m.room.name`](/client-server-api/#mroomname) event
+                    If this is included, an `m.room.name` event will be sent
-                    will be sent into the room to indicate the name for the room.
+                    into the room to indicate the name of the room. See Room
-                    This overwrites any [`m.room.name`](/client-server-api/#mroomname)
+                    Events for more information on `m.room.name`.
-                    event in `initial_state`.
                 topic:
                   type: string
                   description: |-
-                    If this is included, an [`m.room.topic`](/client-server-api/#mroomtopic)
+                    If this is included, an `m.room.topic` event will be sent
-                    event with a `text/plain` mimetype will be sent into the room
+                    into the room to indicate the topic for the room. See Room
-                    to indicate the topic for the room. This overwrites any
+                    Events for more information on `m.room.topic`.
-                    [`m.room.topic`](/client-server-api/#mroomtopic) event in `initial_state`.
                 invite:
                   type: array
                   description: |-
@@ -158,20 +143,11 @@ paths:
                 creation_content:
                   title: CreationContent
                   type: object
-                  x-changedInMatrixVersion:
-                    "1.16": Added server behaviour for how to handle `trusted_private_chat` and invited users.
                   description: |-
                     Extra keys, such as `m.federate`, to be added to the content
-                    of the [`m.room.create`](/client-server-api/#mroomcreate) event.
+                    of the [`m.room.create`](/client-server-api/#mroomcreate) event. The server will overwrite the following
-
-                    The server will overwrite the following
                     keys: `creator`, `room_version`. Future versions of the specification
                     may allow the server to overwrite other keys.
-
-                    When using the `trusted_private_chat` preset, the server SHOULD combine
-                    `additional_creators` specified here and the `invite` array into the
-                    eventual `m.room.create` event's `additional_creators`, deduplicating
-                    between the two parameters.
                 initial_state:
                   type: array
                   description: |-

data/api/client-server/cross_signing.yaml

@@ -39,13 +39,6 @@ paths:
         they already exist. Allowing clients to upload the same set of keys more than once 
         makes this endpoint idempotent in the case where the response is lost over the network,
         which would otherwise cause a UIA challenge upon retry.
-
-        {{% boxes/note %}}
-        When this endpoint requires User-Interactive Authentication,
-        it uses the [`m.oauth`](/client-server-api/#oauth-authentication)
-        authentication type if the access token was obtained
-        via the [OAuth 2.0 API](/client-server-api/#oauth-20-api).
-        {{% /boxes/note %}}
       operationId: uploadCrossSigningKeys
       security:
         - accessTokenQuery: []

data/api/client-server/definitions/key_backup_session_data.yaml

@@ -23,7 +23,6 @@ properties:
     type: string
     description: |-
       The end-to-end message encryption algorithm that the key is for. Must be `m.megolm.v1.aes-sha2`.
-    example: "m.megolm.v1.aes-sha2"
   forwarding_curve25519_key_chain:
     type: array
     items:
@@ -31,24 +30,31 @@ properties:
     description: |-
       Chain of Curve25519 keys through which this session was forwarded, via [m.forwarded_room_key](/client-server-api/#mforwarded_room_key)
       events.
-    example: [ "hPQNcabIABgGnx3/ACv/jmMmiQHoeFfuLB17tzWp6Hw" ]
   sender_key:
     type: string
     description: |-
       Unpadded base64-encoded device Curve25519 key.
-    example: "RF3s+E7RkTQTGF2d8Deol0FkQvgII2aJDf3/Jp5mxVU"
   sender_claimed_keys:
     type: object
     additionalProperties:
       type: string
     description: |-
       A map from algorithm name (`ed25519`) to the Ed25519 signing key of the sending device.
-    example: { "ed25519": "aj40p+aw64yPIdsxoog8jhPu9i7l7NcFRecuOQblE3Y" }
   session_key:
     type: string
     description: |-
       Unpadded base64-encoded session key in [session-export format](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#session-export-format).
-    example: "AgAAAADxKHa9uFxcXzwYoNueL5Xqi69IkD4sni8Llf..."
+example: {
+  "algorithm": "m.megolm.v1.aes-sha2",
+  "forwarding_curve25519_key_chain": [
+    "hPQNcabIABgGnx3/ACv/jmMmiQHoeFfuLB17tzWp6Hw"
+  ],
+  "sender_key": "RF3s+E7RkTQTGF2d8Deol0FkQvgII2aJDf3/Jp5mxVU",
+  "sender_claimed_keys": {
+    "ed25519": "aj40p+aw64yPIdsxoog8jhPu9i7l7NcFRecuOQblE3Y",
+  },
+  "session_key": "AgAAAADxKHa9uFxcXzwYoNueL5Xqi69IkD4sni8Llf..."
+}
 required:
   - algorithm
   - forwarding_curve25519_key_chain

data/api/client-server/definitions/m.oauth_params.yaml

@@ -1,30 +0,0 @@
-# Copyright 2025 The Matrix.org Foundation C.I.C.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-type: object
-title: m.oauth params
-description: Schema for `m.oauth` entry in the `params` object in a User-Interactive Authentication response.
-required: ['url']
-properties:
-  url:
-    type: string
-    format: uri
-    description: |
-      A URL pointing to the homeserver's OAuth account management web UI
-      where the user can approve the action. MUST be a valid URI with scheme
-      `http://` or `https://`, the latter being RECOMMENDED.
-    pattern: "^https?://"
-example: {
-    "url": "https://example.org/account/reset-cross-signing"
-}

data/api/client-server/definitions/olm_payload.yaml

@@ -1,88 +0,0 @@
-# Copyright 2025 The Matrix.org Foundation C.I.C
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-
-type: object
-title: OlmPayload
-description: |-
-  The plaintext payload of Olm message events.
-properties:
-  type:
-    type: string
-    description: The type of the event.
-  content:
-    type: object
-    description: The event content.
-  sender:
-    type: string
-    description: The user ID of the event sender.
-  recipient:
-    type: string
-    description: The user ID of the intended event recipient.
-  recipient_keys:
-    description: The recipient's signing keys of the encrypted event.
-    $ref: "#/components/schemas/SigningKeys"
-  keys:
-    $ref: "#/components/schemas/SigningKeys"
-    description: The sender's signing keys of the encrypted event.
-  sender_device_keys:
-    $ref: device_keys.yaml 
-    description: The sender's device keys.
-    x-addedInMatrixVersion: "1.15"
-required:
-  - type
-  - content
-  - sender
-  - recipient
-  - recipient_keys
-  - keys
-components:
-  schemas:
-    SigningKeys:
-      type: object
-      title: SigningKeys
-      description: Public keys used for an `m.olm.v1.curve25519-aes-sha2` event.
-      properties:
-        ed25519:
-          type: string
-          description: The Ed25519 public key encoded using unpadded base64.
-      required:
-        - ed25519
-example: {
-  "type": "<type of the plaintext event>",
-  "content": "<content for the plaintext event>",
-  "sender": "<sender_user_id>",
-  "recipient": "<recipient_user_id>",
-  "recipient_keys": {
-    "ed25519": "<our_ed25519_key>"
-  },
-  "keys": {
-    "ed25519": "<sender_ed25519_key>"
-  },
-  "sender_device_keys": {
-    "algorithms": ["<supported>", "<algorithms>"],
-    "user_id": "<user_id>",
-    "device_id": "<device_id>",
-    "keys": {
-      "ed25519:<device_id>": "<sender_ed25519_key>",
-      "curve25519:<device_id>": "<sender_curve25519_key>"
-    },
-    "signatures": {
-      "<user_id>": {
-        "ed25519:<device_id>": "<device_signature>",
-        "ed25519:<ssk_id>": "<ssk_signature>",
-      }
-    }
-  }
-}

data/api/client-server/definitions/protocol.yaml

@@ -41,4 +41,3 @@ allOf:
                   This is the identifier to use as the `third_party_instance_id` in a request to
                   [`POST /_matrix/client/v3/publicRooms`](/client-server-api/#post_matrixclientv3publicrooms).
                 example: "irc-freenode"
-  required: ['instances']

data/api/client-server/definitions/public_rooms_chunk.yaml

@@ -13,12 +13,10 @@
 # limitations under the License.
 
 type: object
-title: "PublishedRoomsChunk"
+title: "PublicRoomsChunk"
 properties:
   canonical_alias:
     type: string
-    format: mx-room-alias
-    pattern: "^#"
     description: The canonical alias of the room, if any.
     example: "#general:example.org"
   name:
@@ -31,19 +29,15 @@ properties:
     example: 42
   room_id:
     type: string
-    format: mx-room-id
-    pattern: "^!"
     description: The ID of the room.
     example: "!abcdefg:example.org"
   topic:
     type: string
-    description: |-
+    description: The topic of the room, if any.
-      The plain text topic of the room. Omitted if no `text/plain` mimetype
-      exists in [`m.room.topic`](/client-server-api/#mroomtopic).
     example: "All things general"
   world_readable:
     type: boolean
-    description: Whether the room may be viewed by users without joining.
+    description: Whether the room may be viewed by guest users without joining.
     example: false
   guest_can_join:
     type: boolean
@@ -65,6 +59,7 @@ properties:
     example: "public"
   room_type:
     type: string
+    x-addedInMatrixVersion: "1.4"
     description: |-
       The `type` of room (from [`m.room.create`](/client-server-api/#mroomcreate)), if any.
 required:

data/api/client-server/definitions/public_rooms_response.yaml

@@ -13,15 +13,28 @@
 # limitations under the License.
 
 type: object
-description: A list of the published rooms on the server.
+description: A list of the rooms on the server.
 required: ["chunk"]
 properties:
   chunk:
     type: array
     description: |-
-      A paginated chunk of published rooms.
+      A paginated chunk of public rooms.
     items:
-      $ref: "public_rooms_chunk.yaml"
+      allOf:
+        - $ref: "public_rooms_chunk.yaml"
+        - type: object
+          title: PublicRoomsChunk
+          properties:
+            # Override description of join_rule
+            join_rule:
+              type: string
+              description: |-
+                The room's join rule. When not present, the room is assumed to
+                be `public`. Note that rooms with `invite` join rules are not
+                expected here, but rooms with `knock` rules are given their
+                near-public nature.
+              example: "public"
   next_batch:
     type: string
     description: |-
@@ -37,7 +50,7 @@ properties:
   total_room_count_estimate:
     type: integer
     description: |-
-        An estimate on the total number of published rooms, if the
+        An estimate on the total number of public rooms, if the
         server has an estimate.
 example: {
   "chunk": [

data/api/client-server/definitions/push_ruleset.yaml

@@ -34,6 +34,24 @@ properties:
     type: array
 type: object
 example: {
+  "content": [
+    {
+      "actions": [
+        "notify",
+        {
+          "set_tweak": "sound",
+          "value": "default"
+        },
+        {
+          "set_tweak": "highlight"
+        }
+      ],
+      "default": true,
+      "enabled": true,
+      "pattern": "alice",
+      "rule_id": ".m.rule.contains_user_name"
+    }
+  ],
   "override": [
     {
       "actions": [],
@@ -95,14 +113,12 @@ example: {
       ],
       "conditions": [
         {
-            "kind": "event_property_contains",
+          "kind": "contains_display_name"
-            "key": "content.m\\.mentions.user_ids",
-            "value": "@alice:example.com"
         }
       ],
       "default": true,
       "enabled": true,
-      "rule_id": ".m.rule.is_user_mention"
+      "rule_id": ".m.rule.contains_display_name"
     },
     {
       "actions": [

data/api/client-server/definitions/room_summary.yaml

@@ -1,44 +0,0 @@
-# Copyright 2025 The Matrix.org Foundation C.I.C.
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-#     http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-type: object
-title: RoomSummary
-allOf:
-  - $ref: public_rooms_chunk.yaml
-  - type: object
-    properties:
-      room_type:
-        type: string
-        description: The `type` of room (from
-          [`m.room.create`](/client-server-api/#mroomcreate)),
-          if any.
-      allowed_room_ids:
-        type: array
-        items:
-          type: string
-          format: mx-room-id
-          pattern: "^!"
-        description: |-
-          If the room is a [restricted room](/server-server-api/#restricted-rooms), these are the room IDs which
-          are specified by the join rules. Empty or omitted otherwise.
-      encryption:
-        type: string
-        enum:
-          - "m.megolm.v1.aes-sha2"
-        description: |-
-          The encryption algorithm to be used to encrypt messages sent in the
-          room.
-      room_version:
-        description: The version of the room.
-        type: string