Merge 6e7c8a6da0 into 70c7d59caa

Some clarifications to the release process doc, particularly in view of #2275.

.github/workflows/main.yml

@@ -195,6 +195,8 @@ jobs:
     needs: [calculate-baseurl, build-openapi, generate-changelog]
     # run even if generate-changelog was skipped
     if: ${{ always() }}
+    env:
+      baseURL: "${{ needs.calculate-baseurl.outputs.baseURL }}"
     steps:
       - name: "➕ Setup Node"
         uses: actions/setup-node@v4
@@ -217,8 +219,10 @@ jobs:
         with:
           name: changelog-artifact
           path: content/changelog
+
       - name: "⚙️ hugo"
-        run: hugo --baseURL "${{ needs.calculate-baseurl.outputs.baseURL }}" -d "spec"
+        run: hugo --baseURL "${baseURL}" -d "spec${baseURL}"
+
       # We manually unpack the spec OpenAPI definition JSON to the website tree
       # to make it available to the world in a canonical place:
       # https://spec.matrix.org/latest/client-server-api/api.json
@@ -229,10 +233,13 @@ jobs:
           name: openapi-artifact
       - name: "📝 Unpack the OpenAPI definitions in the right location"
         run: |
-          tar -xzf openapi.tar.gz
+          tar -C "spec${baseURL}" --strip-components=1 -xzf openapi.tar.gz
 
       - name: "📦 Tarball creation"
-        run: tar -czf spec.tar.gz spec
+        run: |
+          cd spec
+          tar -czf ../spec.tar.gz *
+
       - name: "📤 Artifact upload"
         uses: actions/upload-artifact@v4
         with:
@@ -243,6 +250,14 @@ jobs:
     name: "🔎 Validate generated HTML"
     runs-on: ubuntu-latest
     needs: [calculate-baseurl, build-spec]
+    # Run even if `generate-changelog` was skipped.
+    #
+    # `build-spec` has a dependency on `generate-changelog` to ensure order of execution
+    # and to access `needs.generate-changelog.result`. However, `generate-changelog` is
+    # skipped on tag builds; even a transient dependency on `generate-changelog` is then
+    # enough for this step to also be skipped by default on tag builds. Hence the need for
+    # this explicit `if`.
+    if: ${{ !failure() && !cancelled() }}
     steps:
       - name: "📥 Source checkout"
         uses: actions/checkout@v4
@@ -253,14 +268,9 @@ jobs:
           name: spec-artifact
 
       - name: "📝 Unpack the spec"
-        # we have to unpack it into the right path given the baseurl, so that the
-        # links are correct.
-        # eg if baseurl is `/unstable`, we want to put the site in `spec/unstable`.
         run: |
-          mkdir -p "spec${baseURL}"
+          mkdir spec
-          tar -C "spec${baseURL}" --strip-components=1 -xvzf spec.tar.gz
+          tar -C spec -xvzf spec.tar.gz
-        env:
-          baseURL: "${{ needs.calculate-baseurl.outputs.baseURL }}"
 
       - name: "Run htmltest"
         uses: wjdp/htmltest-action@master
@@ -270,8 +280,10 @@ jobs:
   build-historical-spec:
     name: "📖 Build the historical backup spec"
     runs-on: ubuntu-latest
-    needs: [build-openapi]
+    needs: [calculate-baseurl, build-openapi]
     if: ${{ startsWith(github.ref, 'refs/tags/') }}
+    env:
+      baseURL: "${{ needs.calculate-baseurl.outputs.baseURL }}"
     steps:
       - name: "➕ Setup Node"
         uses: actions/setup-node@v4
@@ -291,9 +303,8 @@ jobs:
       - 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"
+          hugo --baseURL "${baseURL}" -d "spec${baseURL}"
 
       - name: "📥 Spec definition download"
         uses: actions/download-artifact@v4
@@ -301,12 +312,51 @@ jobs:
           name: openapi-artifact
       - name: "📝 Unpack the OpenAPI definitions in the right location"
         run: |
-          tar -xzf openapi.tar.gz
+          tar -C "spec${baseURL}" --strip-components=1 -xzf openapi.tar.gz
 
       - name: "📦 Tarball creation"
-        run: tar -czf spec-historical.tar.gz spec
+        run: |
+          cd spec
+          tar -czf ../spec-historical.tar.gz *
+
       - name: "📤 Artifact upload"
         uses: actions/upload-artifact@v4
         with:
           name: spec-historical-artifact
           path: spec-historical.tar.gz
+
+  # If we're building a tag, create a release and publish the artifacts
+  create_release:
+    name: "Create release"
+    if: ${{ !failure() && !cancelled() && startsWith(github.ref, 'refs/tags/') }}
+    needs:
+      - build-spec
+      - build-historical-spec
+    runs-on: ubuntu-latest
+    steps:
+      - name: "📥 Check out changelogs"
+        uses: actions/checkout@1af3b93b6815bc44a9784bd300feb67ff0d1eeb3 # v6.0.0
+        with:
+          sparse-checkout: |
+            content/changelog
+      - name: "📥 Download built spec"
+        uses: actions/download-artifact@37930b1c2abaa49bbe596cd826c3c89aef350131 # v7.0.0
+        with:
+          name: spec-artifact
+      - name: "📥 Download historical spec artifact"
+        uses: actions/download-artifact@37930b1c2abaa49bbe596cd826c3c89aef350131 # v7.0.0
+        with:
+          name: spec-historical-artifact
+      - name: "✨ Create draft release"
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          # Remove front-matter from changelog
+          sed '1,/^---$/d' "content/changelog/${{ github.ref_name }}.md" > changelog.md
+
+          # Create a draft release, using the changelog as release notes, and attaching the spec artifacts.
+          gh release create -d -t "${{ github.ref_name }}" \
+            -F "changelog.md" \
+            "${{ github.ref_name }}" \
+            spec.tar.gz \
+            spec-historical.tar.gz

.github/workflows/netlify.yaml

@@ -45,7 +45,9 @@ jobs:
           name: spec-artifact
 
       - name: "📦 Extract Artifacts"
-        run: tar -xzvf spec.tar.gz && rm spec.tar.gz
+        run: |
+          mkdir spec
+          tar -C spec -xzvf spec.tar.gz && rm spec.tar.gz
         
       - name: "📤 Deploy to Netlify"
         id: netlify

assets/scss/_styles_project.scss

@@ -257,6 +257,69 @@ Custom SCSS for the Matrix spec
 
 }
 
+.endpoints-toc {
+  summary {
+    cursor: pointer;
+    font-weight: $font-weight-bold;
+    font-size: 1.05rem;
+    margin-bottom: 0.5rem;
+  }
+
+  .endpoint-list {
+    list-style: none;
+    padding-left: 0;
+    margin: 0;
+  }
+
+  .endpoint-list li {
+    margin: 0.2rem 0;
+  }
+
+  .endpoint-list a {
+    text-decoration: none;
+    color: inherit;
+    padding: 0.05rem 0.25rem;
+    border-radius: 0.2rem;
+
+    &:hover {
+      background-color: $secondary-background;
+    }
+  }
+
+  .endpoint-list .http-api-method {
+    margin-right: 0.35rem;
+    font-weight: $font-weight-bold;
+  }
+
+  .endpoint-path {
+    font-family: $font-family-monospace;
+    color: $secondary;
+  }
+
+  .endpoint-deprecated {
+    color: $danger;
+    font-weight: $font-weight-bold;
+    margin-left: 0.35rem;
+  }
+
+  .endpoint-module {
+    &:not(:first-child) {
+      margin-top: 0.75rem;
+    }
+  }
+
+  .endpoint-module-title {
+    // font-weight: $font-weight-bold;
+    font-size: 1.20rem;
+    margin-bottom: 0.35rem;
+  }
+}
+
+.page-description {
+  margin-bottom: 1rem;
+  color: inherit;
+}
+
 /* Styles for alert boxes */
 .alert {
   &.note {
@@ -581,4 +644,4 @@ dd {
   .breadcrumb {
     margin: 0;
   }
-}
+}

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/client_server/newsfragments/2280.clarification

@@ -0,0 +1 @@
+Update non-historic mentions of matrix-doc repo to matrix-spec/-proposals. Contributed by @HarHarLinks.

changelogs/client_server/newsfragments/2283.clarification

@@ -0,0 +1 @@
+Remove unintended TeX formatting. Contributed by @HarHarLinks.

changelogs/internal/newsfragments/2219.clarification

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

changelogs/internal/newsfragments/2222.clarification

@@ -0,0 +1 @@
+Clarify vendor prefixing requirements.

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/internal/newsfragments/2258.clarification

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

changelogs/internal/newsfragments/2259.clarification

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

changelogs/internal/newsfragments/2260.clarification

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

changelogs/internal/newsfragments/2261.clarification

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

changelogs/internal/newsfragments/2264.clarification

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

changelogs/internal/newsfragments/2268.clarification

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

changelogs/internal/newsfragments/2275.clarification

@@ -0,0 +1 @@
+Auto-create draft releases when building release tags.

changelogs/internal/newsfragments/2276.feature

@@ -0,0 +1 @@
+Include the spec release version in the filenames in the tarballs generated by CI.

changelogs/internal/newsfragments/2282.clarification

@@ -0,0 +1 @@
+Replace the Twitter link in the footer with our BlueSky and Mastodon socials.

changelogs/internal/newsfragments/2289.clarification

@@ -0,0 +1 @@
+Updates to the release documentation.

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.  

changelogs/server_server/newsfragments/2288.clarification

@@ -0,0 +1 @@
+Specify that callers of `/_matrix/federation/v1/openid/userinfo` must validate the returned user ID.

config/_default/hugo.toml

@@ -75,8 +75,8 @@ status = "unstable"
 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 = "17"
 
 [[params.versions]]
 # We must include this parameter to enable docsy's version picker in the navbar. The picker
@@ -106,25 +106,30 @@ sidebar_menu_compact = true
 #   desc = "Matrix on GitHub"
 # Custom links shown in the center of the footer. (Only supported by our fork of docsy's 'footer/central' partial.)
 [[params.links.bottom]]
-	name = "GitHub"
+  name = "GitHub"
-	url = "https://github.com/matrix-org"
+  url = "https://github.com/matrix-org"
-	icon = "fab fa-github"
+  icon = "fab fa-github"
   desc = "Matrix on GitHub"
 [[params.links.bottom]]
-	name = "GitLab"
+  name = "GitLab"
-	url = "https://gitlab.matrix.org/matrix-org"
+  url = "https://gitlab.matrix.org/matrix-org"
-	icon = "fab fa-gitlab"
+  icon = "fab fa-gitlab"
   desc = "Matrix on GitLab"
 [[params.links.bottom]]
-	name = "YouTube"
+  name = "YouTube"
-	url = "https://www.youtube.com/channel/UCVFkW-chclhuyYRbmmfwt6w"
+  url = "https://www.youtube.com/channel/UCVFkW-chclhuyYRbmmfwt6w"
-	icon = "fab fa-youtube"
+  icon = "fab fa-youtube"
   desc = "Matrix YouTube channel"
 [[params.links.bottom]]
-	name = "Twitter"
+  name = "Mastodon"
-	url = "https://twitter.com/matrixdotorg"
+  url = "https://mastodon.matrix.org/@matrix"
-	icon = "fab fa-x-twitter"
+  icon = "fab fa-mastodon"
-  desc = "Matrix on Twitter"
+  desc = "Matrix on Mastodon"
+[[params.links.bottom]]
+  name = "Bluesky"
+  url = "https://bsky.app/profile/matrix.org"
+  icon = "fab fa-bluesky"
+  desc = "Matrix on Bluesky"
 
 
 # configuration for the hugo development server

content/application-service-api.md

@@ -2,16 +2,14 @@
 title: "Application Service API"
 weight: 30
 type: docs
+description: |
+  The Matrix client-server API and server-server APIs provide a consistent,
+  self-contained federated messaging fabric but leave little room for custom
+  server-side behaviour such as gateways, filters, or extensible hooks. The
+  Application Service API defines a standard way to add this extensible
+  functionality, independent of the underlying homeserver implementation.
 ---
 
-The Matrix client-server API and server-server APIs provide the means to
-implement a consistent self-contained federated messaging fabric.
-However, they provide limited means of implementing custom server-side
-behaviour in Matrix (e.g. gateways, filters, extensible hooks etc). The
-Application Service API (AS API) defines a standard API to allow such
-extensible functionality to be implemented irrespective of the
-underlying homeserver implementation.
-
 ## Application Services
 
 Application services are passive and can only observe events from the
@@ -428,6 +426,8 @@ imports and similar behaviour).
 
 #### Server admin style permissions
 
+{{% changed-in v="1.17" %}}
+
 The homeserver needs to give the application service *full control* over
 its namespace, both for users and for room aliases. This means that the
 AS should be able to manage any users and room alias in its namespace. No additional API
@@ -444,33 +444,59 @@ achieved by including the `as_token` on a `/register` request, along
 with a login type of `m.login.application_service` to set the desired
 user ID without a password.
 
-    POST /_matrix/client/v3/register
+```http
-    Authorization: Bearer YourApplicationServiceTokenHere
+POST /_matrix/client/v3/register
+Authorization: Bearer YourApplicationServiceTokenHere
+```
 
-    Content:
+```json
-    {
+{
-      "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
+{{% boxes/note %}}
-log in without needing the user's password. This is achieved by including the
+{{% added-in v="1.17" %}}
-`as_token` on a `/login` request, along with a login type of
+Servers MUST still allow application services to use the `/register` endpoint
-`m.login.application_service`:
+with a login type of `m.login.application_service` even if they don't support
+the [Legacy Authentication API](/client-server-api/#legacy-api).
+
+In that case application services MUST set the `"inhibit_login": true` parameter
+as they cannot use it to log in as users. If the `inhibit_login` parameter is
+not set to `true`, the server MUST return a 400 HTTP status code with an
+`M_APPSERVICE_LOGIN_UNSUPPORTED` error code.
+{{% /boxes/note %}}
+
+Similarly, logging in as users using the [Legacy authentication API](/client-server-api/#legacy-api)
+needs API changes in order to allow the AS to log in without needing the user's
+password. This is achieved by including the `as_token` on a `/login` request,
+along with a login type of `m.login.application_service`:
 
 {{% added-in v="1.2" %}}
 
-    POST /_matrix/client/v3/login
+```http
-    Authorization: Bearer YourApplicationServiceTokenHere
+POST /_matrix/client/v3/login
+Authorization: Bearer YourApplicationServiceTokenHere
+```
 
-    Content:
+```json
-    {
+{
-      "type": "m.login.application_service",
+  "type": "m.login.application_service",
-      "identifier": {
+  "identifier": {
-        "type": "m.id.user",
+    "type": "m.id.user",
-        "user": "_irc_example"
+    "user": "_irc_example"
-      }
+  }
-    }
+}
+```
+
+{{% boxes/note %}}
+{{% added-in v="1.17" %}}
+Application services MUST NOT use the `/login` endpoint if the server doesn't
+support the Legacy authentication API. If `/login` is called with the
+`m.login.application_service` login type the server MUST return a 400 HTTP
+status code with an `M_APPSERVICE_LOGIN_UNSUPPORTED` error code.
+{{% /boxes/note %}}
 
 Application services which attempt to create users or aliases *outside*
 of their defined namespaces, or log in as users outside of their defined
@@ -512,6 +538,38 @@ client-server endpoint.
 
 {{% http-api spec="client-server" api="appservice_room_directory" %}}
 
+#### Device management
+
+{{% added-in v="1.17" %}}
+
+Application services need to be able to create and delete devices to manage the
+encryption for their users without having to rely on `/login`, which also
+generates an access token for the user, and which might not be available for
+homeservers that only support the [OAuth 2.0 API](/client-server-api/#oauth-20-api).
+
+##### Creating devices
+
+Application services can use the [`PUT /_matrix/client/v3/devices/{deviceId}`](/client-server-api/#put_matrixclientv3devicesdeviceid)
+endpoint to create new devices.
+
+##### Deleting devices
+
+The following endpoints used to delete devices MUST NOT require [User-Interactive
+Authentication](/client-server-api/#user-interactive-authentication-api) when
+used by an application service:
+
+* [`DELETE /_matrix/client/v3/devices/{deviceId}`](/client-server-api/#delete_matrixclientv3devicesdeviceid)
+* [`POST /_matrix/client/v3/delete_devices`](/client-server-api/#post_matrixclientv3delete_devices)
+
+#### Cross-signing
+
+{{% added-in v="1.17" %}}
+
+Appservices need to be able to verify themselves and replace their cross-signing
+keys, so the [`POST /_matrix/client/v3/keys/device_signing/upload`](/client-server-api/#post_matrixclientv3keysdevice_signingupload)
+endpoint MUST NOT require [User-Interactive Authentication](/client-server-api/#user-interactive-authentication-api)
+when used by an application service, even if cross-signing keys already exist.
+
 ### Referencing messages from a third-party network
 
 Application services should include an `external_url` in the `content`

content/changelog/v1.17.md

@@ -0,0 +1,91 @@
+---
+title: v1.17 Changelog
+linkTitle: v1.17
+type: docs
+layout: changelog
+outputs:
+  - html
+  - checklist
+date: 2025-12-18
+---
+
+## Client-Server API
+
+**Removed Endpoints**
+
+- Remove legacy mentions, as per [MSC4210](https://github.com/matrix-org/matrix-spec-proposals/issues/4210). ([#2186](https://github.com/matrix-org/matrix-spec/issues/2186))
+
+**Backwards Compatible Changes**
+
+- Allow application services to masquerade as specific devices belonging to users, as per [MSC4326](https://github.com/matrix-org/matrix-spec-proposals/pull/4326). ([#2221](https://github.com/matrix-org/matrix-spec/issues/2221))
+- Add the `m.oauth` authentication type for User-Interactive Authentication, as per [MSC4312](https://github.com/matrix-org/matrix-spec-proposals/pull/4312). ([#2234](https://github.com/matrix-org/matrix-spec/issues/2234))
+- Allow application services to manage devices and register users without the legacy authentication API, as per [MSC4190](https://github.com/matrix-org/matrix-spec-proposals/pull/4190). ([#2267](https://github.com/matrix-org/matrix-spec/issues/2267))
+
+**Spec Clarifications**
+
+- Push rule IDs are globally unique within their kind. ([#2214](https://github.com/matrix-org/matrix-spec/issues/2214))
+- Don't advertise `creator` field in description of room creation. ([#2215](https://github.com/matrix-org/matrix-spec/issues/2215))
+- `room_id` is required for peeking via `/_matrix/client/v3/events`. ([#2216](https://github.com/matrix-org/matrix-spec/issues/2216))
+- The `server-name` segment of MXC URIs is sanitised differently from the `media-id` segment. ([#2217](https://github.com/matrix-org/matrix-spec/issues/2217))
+- Add note to each endpoint that uses capability negotiation. ([#2223](https://github.com/matrix-org/matrix-spec/issues/2223))
+- Additional OpenGraph properties can be present in URL previews. ([#2225](https://github.com/matrix-org/matrix-spec/issues/2225))
+- Clarify the special casing of membership events and redactions in power levels. ([#2231](https://github.com/matrix-org/matrix-spec/issues/2231))
+- `M_RESOURCE_LIMIT_EXCEEDED` is now listed as a common error code. ([#2232](https://github.com/matrix-org/matrix-spec/issues/2232))
+- Add `m.login.terms` to enumeration of authentication types. ([#2233](https://github.com/matrix-org/matrix-spec/issues/2233))
+- Clarify how to use `state_after` ahead of declaring full support for its spec version. ([#2240](https://github.com/matrix-org/matrix-spec/issues/2240))
+- `device_one_time_keys_count` is only optional if no unclaimed one-time keys exist. ([#2245](https://github.com/matrix-org/matrix-spec/issues/2245))
+- 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. ([#2246](https://github.com/matrix-org/matrix-spec/issues/2246))
+- Usage of the `event_id_only` format for push notifications is not mandatory. ([#2255](https://github.com/matrix-org/matrix-spec/issues/2255))
+- Fix various typos throughout the specification. ([#2224](https://github.com/matrix-org/matrix-spec/issues/2224), [#2227](https://github.com/matrix-org/matrix-spec/issues/2227), [#2250](https://github.com/matrix-org/matrix-spec/issues/2250))
+
+
+## Server-Server API
+
+No significant changes.
+
+
+## Application Service API
+
+**Backwards Compatible Changes**
+
+- Allow application services to masquerade as specific devices belonging to users, as per [MSC4326](https://github.com/matrix-org/matrix-spec-proposals/pull/4326). ([#2221](https://github.com/matrix-org/matrix-spec/issues/2221))
+- Allow application services to manage devices and register users without the legacy authentication API, as per [MSC4190](https://github.com/matrix-org/matrix-spec-proposals/pull/4190). ([#2267](https://github.com/matrix-org/matrix-spec/issues/2267))
+
+**Spec Clarifications**
+
+- Fix JSON formatting in the "Server admin style permissions" examples. ([#2213](https://github.com/matrix-org/matrix-spec/issues/2213))
+
+
+## Identity Service API
+
+No significant changes.
+
+
+## Push Gateway API
+
+No significant changes.
+
+
+## Room Versions
+
+**Spec Clarifications**
+
+- 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. ([#2220](https://github.com/matrix-org/matrix-spec/issues/2220))
+- 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. ([#2249](https://github.com/matrix-org/matrix-spec/issues/2249))
+
+
+## Appendices
+
+No significant changes.
+
+
+## Internal Changes/Tooling
+
+**Spec Clarifications**
+
+- Swapped icon for X (fka. twitter) to updated logo in footer. ([#2219](https://github.com/matrix-org/matrix-spec/issues/2219))
+- Inline Olm & Megolm specifications. ([#2226](https://github.com/matrix-org/matrix-spec/issues/2226), [#2241](https://github.com/matrix-org/matrix-spec/issues/2241), [#2242](https://github.com/matrix-org/matrix-spec/issues/2242))
+- Silence failing redocly-cli rule. ([#2238](https://github.com/matrix-org/matrix-spec/issues/2238))
+- Use NPM Trusted Publishers for publishing `@matrix-org/spec` to npm. ([#2239](https://github.com/matrix-org/matrix-spec/issues/2239))
+- Add version picker in the navbar. ([#2256](https://github.com/matrix-org/matrix-spec/issues/2256), [#2258](https://github.com/matrix-org/matrix-spec/issues/2258), [#2259](https://github.com/matrix-org/matrix-spec/issues/2259), [#2260](https://github.com/matrix-org/matrix-spec/issues/2260), [#2261](https://github.com/matrix-org/matrix-spec/issues/2261), [#2264](https://github.com/matrix-org/matrix-spec/issues/2264), [#2268](https://github.com/matrix-org/matrix-spec/issues/2268))
+- Add a list of endpoints to the top of each spec page. ([#2262](https://github.com/matrix-org/matrix-spec/issues/2262))

content/client-server-api/_index.md

@@ -2,14 +2,14 @@
 title: "Client-Server API"
 weight: 10
 type: docs
+description: |
+  The client-server API allows clients to send messages, control rooms and
+  synchronise conversation history. It is designed to support both lightweight
+  clients which store no state and lazy-load data from the server as required,
+  as well as heavyweight clients which maintain a full local persistent copy of
+  server state.
 ---
 
-The client-server API allows clients to
-send messages, control rooms and synchronise conversation history. It is
-designed to support both lightweight clients which store no state and
-lazy-load data from the server as required - as well as heavyweight
-clients which maintain a full local persistent copy of server state.
-
 ## API Standards
 
 {{% boxes/note %}}
@@ -477,8 +477,7 @@ the API that was used to obtain their current access token.
 
 {{% boxes/note %}}
 Currently the OAuth 2.0 API doesn't cover all the use cases of the legacy API,
-such as automated applications that cannot use a web browser, or
+such as automated applications that cannot use a web browser.
-user management by [application services](application-service-api/#server-admin-style-permissions).
 {{% /boxes/note %}}
 
 ### Authentication API discovery
@@ -502,6 +501,12 @@ user must do that directly in the homeserver's web UI. However, the client can
 signal to the homeserver that the user wishes to create a new account with the
 [`prompt=create`](#user-registration) parameter during authorization.
 
+{{% boxes/note %}}
+{{% added-in v="1.17" %}}
+Application services can use the `/register` endpoint to create users regardless
+of the authentication API supported by the homeserver.
+{{% /boxes/note %}}
+
 ### Login
 
 With the legacy API, a client can obtain an access token by using one of the
@@ -1562,6 +1567,10 @@ If the access token does correspond to an appservice, but the user id does
 not lie within its namespace then the homeserver will respond with an
 errcode of `M_EXCLUSIVE`.
 
+{{% added-in v="1.17" %}} If this login type is used and the server doesn't
+support logging in via the Legacy authentication API, it MUST return a 400 HTTP
+status code with an `M_APPSERVICE_LOGIN_UNSUPPORTED` error code.
+
 ##### Login Fallback
 
 If a client does not recognize any or all login flows it can use the
@@ -4001,42 +4010,42 @@ operations and run in a resource constrained environment. Like embedded
 applications, they are not intended to be fully-fledged communication
 systems.
 
-{{% cs-module name="instant_messaging" %}}
+{{% cs-module name="Instant Messaging" filename="instant_messaging" %}}
-{{% cs-module name="rich_replies" %}}
+{{% cs-module name="Rich replies" filename="rich_replies" %}}
-{{% cs-module name="voip_events" %}}
+{{% cs-module name="Voice over IP" filename="voip_events" %}}
-{{% cs-module name="typing_notifications" %}}
+{{% cs-module name="Typing Notifications" filename="typing_notifications" %}}
-{{% cs-module name="receipts" %}}
+{{% cs-module name="Receipts" filename="receipts" %}}
-{{% cs-module name="read_markers" %}}
+{{% cs-module name="Read and unread markers" filename="read_markers" %}}
-{{% cs-module name="presence" %}}
+{{% cs-module name="Presence" filename="presence" %}}
-{{% cs-module name="content_repo" %}}
+{{% cs-module name="Content repository" filename="content_repo" %}}
-{{% cs-module name="send_to_device" %}}
+{{% cs-module name="Send-to-Device messaging" filename="send_to_device" %}}
-{{% cs-module name="device_management" %}}
+{{% cs-module name="Device Management" filename="device_management" %}}
-{{% cs-module name="end_to_end_encryption" %}}
+{{% cs-module name="End-to-End Encryption" filename="end_to_end_encryption" %}}
-{{% cs-module name="secrets" %}}
+{{% cs-module name="Secrets" filename="secrets" %}}
-{{% cs-module name="history_visibility" %}}
+{{% cs-module name="Room History Visibility" filename="history_visibility" %}}
-{{% cs-module name="push" %}}
+{{% cs-module name="Push Notifications" filename="push" %}}
-{{% cs-module name="third_party_invites" %}}
+{{% cs-module name="Third-party invites" filename="third_party_invites" %}}
-{{% cs-module name="search" %}}
+{{% cs-module name="Server Side Search" filename="search" %}}
-{{% cs-module name="guest_access" %}}
+{{% cs-module name="Guest Access" filename="guest_access" %}}
-{{% cs-module name="room_previews" %}}
+{{% cs-module name="Room Previews" filename="room_previews" %}}
-{{% cs-module name="tags" %}}
+{{% cs-module name="Room Tagging" filename="tags" %}}
-{{% cs-module name="account_data" %}}
+{{% cs-module name="Client Config" filename="account_data" %}}
-{{% cs-module name="admin" %}}
+{{% cs-module name="Server Administration" filename="admin" %}}
-{{% cs-module name="event_context" %}}
+{{% cs-module name="Event Context" filename="event_context" %}}
-{{% cs-module name="sso_login" %}}
+{{% cs-module name="SSO client login/authentication" filename="sso_login" %}}
-{{% cs-module name="dm" %}}
+{{% cs-module name="Direct Messaging" filename="dm" %}}
-{{% cs-module name="ignore_users" %}}
+{{% cs-module name="Ignoring Users" filename="ignore_users" %}}
-{{% cs-module name="stickers" %}}
+{{% cs-module name="Sticker Messages" filename="stickers" %}}
-{{% cs-module name="report_content" %}}
+{{% cs-module name="Reporting Content" filename="report_content" %}}
-{{% cs-module name="third_party_networks" %}}
+{{% cs-module name="Third-party Networks" filename="third_party_networks" %}}
-{{% cs-module name="openid" %}}
+{{% cs-module name="OpenID" filename="openid" %}}
-{{% cs-module name="server_acls" %}}
+{{% cs-module name="Server Access Control Lists (ACLs) for rooms" filename="server_acls" %}}
-{{% cs-module name="mentions" %}}
+{{% cs-module name="User and room mentions" filename="mentions" %}}
-{{% cs-module name="room_upgrades" %}}
+{{% cs-module name="Room Upgrades" filename="room_upgrades" %}}
-{{% cs-module name="server_notices" %}}
+{{% cs-module name="Server Notices" filename="server_notices" %}}
-{{% cs-module name="moderation_policies" %}}
+{{% cs-module name="Moderation policy lists" filename="moderation_policies" %}}
-{{% cs-module name="spaces" %}}
+{{% cs-module name="Spaces" filename="spaces" %}}
-{{% cs-module name="event_replacements" %}}
+{{% cs-module name="Event replacements" filename="event_replacements" %}}
-{{% cs-module name="event_annotations" %}}
+{{% cs-module name="Event annotations and reactions" filename="event_annotations" %}}
-{{% cs-module name="threading" %}}
+{{% cs-module name="Threading" filename="threading" %}}
-{{% cs-module name="reference_relations" %}}
+{{% cs-module name="Reference relations" filename="reference_relations" %}}

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

@@ -87,7 +87,7 @@ Matrix 1.12 is expected to be released in the July-September 2024 calendar quart
 The homeserver SHOULD be able to supply thumbnails for uploaded images
 and videos. The exact file types which can be thumbnailed are not
 currently specified - see [Issue
-\#1938](https://github.com/matrix-org/matrix-doc/issues/1938) for more
+\#1938](https://github.com/matrix-org/matrix-spec/issues/453) for more
 information.
 
 The thumbnail methods are "crop" and "scale". "scale" tries to return an

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

@@ -921,7 +921,7 @@ collaborate to create a common set of translations for all languages.
 
 {{% boxes/note %}}
 Known translations for the emoji are available from
-<https://github.com/matrix-org/matrix-doc/blob/master/data-definitions/>
+<https://github.com/matrix-org/matrix-spec/tree/main/data-definitions/>
 and can be translated online:
 <https://translate.riot.im/projects/matrix-doc/sas-emoji-v1>
 {{% /boxes/note %}}

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

@@ -119,7 +119,7 @@ Clients SHOULD verify the structure of incoming events to ensure that
 the expected keys exist and that they are of the right type. Clients can
 discard malformed events or display a placeholder message to the user.
 Redacted `m.room.message` events MUST be removed from the client. This
-can either be replaced with placeholder text (e.g. "\[REDACTED\]") or
+can either be replaced with placeholder text (e.g. "[REDACTED]") or
 the redacted message can be removed entirely from the messages view.
 
 Events which have attachments (e.g. `m.image`, `m.file`) SHOULD be

content/identity-service-api.md

@@ -2,17 +2,15 @@
 title: "Identity Service API"
 weight: 40
 type: docs
+description: |
+  The Matrix client-server and server-server APIs are largely expressed in
+  Matrix user identifiers. Sometimes it is useful to refer to users by other
+  (“third-party”) identifiers such as email addresses or phone numbers. The
+  Identity Service API describes how mappings between 3PIDs and Matrix user
+  IDs can be established, validated, and used; in practice this has been
+  applied to email addresses and phone numbers.
 ---
 
-The Matrix client-server and server-server APIs are largely expressed in
-Matrix user identifiers. From time to time, it is useful to refer to
-users by other ("third-party") identifiers, or "3PID"s, e.g. their email
-address or phone number. This Identity Service Specification describes
-how mappings between third-party identifiers and Matrix user identifiers
-can be established, validated, and used. This description technically
-may apply to any 3PID, but in practice has only been applied
-specifically to email addresses and phone numbers.
-
 ## General principles
 
 The purpose of an identity server is to validate, store, and answer

content/proposals.md

@@ -408,41 +408,9 @@ development or testing data.
 that a particular MSC works) do not have to follow this process.
 
 1.  Have an idea for a feature.
-1.  Implement the feature using unstable endpoints, vendor prefixes, and
+1.  Implement the feature using [unstable endpoints, vendor prefixes, and
-    unstable feature flags as appropriate.
+    unstable feature flags](#unstable-endpoints-features-and-vendor-prefixes)
-    -   When using unstable endpoints, they MUST include a vendor
+    as appropriate.
-        prefix. For example:
-        `/_matrix/client/unstable/com.example/login`. Vendor prefixes
-        throughout Matrix always use the Java package naming convention.
-        The MSC for the feature should identify which preferred vendor
-        prefix is to be used by early adopters.
-    -   Note that unstable namespaces do not automatically inherit
-        endpoints from stable namespaces: for example, the fact that
-        `/_matrix/client/r0/sync` exists does not imply that
-        `/_matrix/client/unstable/com.example/sync` exists.
-    -   If the client needs to be sure the server supports the feature,
-        an unstable feature flag that MUST be vendor prefixed is to be
-        used. This kind of flag shows up in the `unstable_features`
-        section of `/versions` as, for example, `com.example.new_login`.
-        The MSC for the feature should identify which preferred feature
-        flag is to be used by early adopters.
-    -   When using this approach correctly, the implementation can
-        ship/release the feature at any time, so long as the
-        implementation is able to accept the technical debt that results
-        from needing to provide adequate backwards and forwards
-        compatibility. The implementation MUST support the flag (and
-        server-side implementation) disappearing and be generally safe
-        for users. Note that implementations early in the MSC review
-        process may also be required to provide backwards compatibility
-        with earlier editions of the proposal.
-    -   If the implementation cannot support the technical debt (or if
-        it's impossible to provide forwards/backwards compatibility -
-        e.g. a user authentication change which can't be safely rolled
-        back), the implementation should not attempt to implement the
-        feature and should instead wait for a spec release.
-    -   If at any point after early release, the idea changes in a
-        backwards-incompatible way, the feature flag should also change
-        so that implementations can adapt as needed.
 1.  In parallel, or ahead of implementation, open an MSC and solicit
     review per above.
 1.  Before FCP can be called, the Spec Core Team will require evidence
@@ -452,10 +420,7 @@ that a particular MSC works) do not have to follow this process.
     forwards/backwards compatibility concerns mentioned here.
 1.  The FCP process is completed, and assuming nothing is flagged the
     MSC lands.
-1.  Implementations can now switch to using stable prefixes
+1.  Implementations can now switch to using stable prefixes, assuming that the change
-    (for example, for an endpoint, moving from
-    `/unstable/org.matrix.mscxxxx/frobnicate`
-    to `/v1/frobnicate`), assuming that the change
     is backwards compatible with older implementations. In the rare occasion
     where backwards compatibility is not possible without a new spec release,
     implementations should continue to use unstable prefixes.
@@ -471,13 +436,6 @@ that a particular MSC works) do not have to follow this process.
     started supporting the new spec release, some noise should be raised
     in the general direction of the implementation.
 
-{{% boxes/note %}}
-MSCs MUST still describe what the stable endpoints/feature looks like
-with a note towards the bottom for what the unstable feature
-flag/prefixes are. For example, an MSC would propose `/_matrix/client/r0/new/endpoint`, not `/_matrix/client/unstable/
-com.example/new/endpoint`.
-{{% /boxes/note %}}
-
 In summary:
 
 -   Implementations MUST NOT use stable endpoints before the MSC has
@@ -489,14 +447,90 @@ In summary:
 -   Implementations SHOULD be wary of the technical debt they are
     incurring by moving faster than the spec.
 -   The vendor prefix is chosen by the developer of the feature, using
-    the Java package naming convention. The foundation's preferred
+    the Java package naming convention.
-    vendor prefix is `org.matrix`.
 -   The vendor prefixes, unstable feature flags, and unstable endpoints
     should be included in the MSC, though the MSC MUST be written in a
     way that proposes new stable endpoints. Typically this is solved by
     a small table at the bottom mapping the various values from stable
     to unstable.
 
+#### Unstable endpoints, features and vendor prefixes
+
+Unstable endpoints MUST use `/unstable` as the endpoint version and a
+vendor prefix in Java package naming format. For example:
+`/_matrix/client/unstable/com.example.mscxxxx/login`.
+
+{{% boxes/note %}}
+Proposal authors operating with a Matrix.org Foundation mandate SHOULD use
+a vendor prefix within the `org.matrix` namespace. This namespace is otherwise
+restricted. Authors who don't own a domain MAY use the `io.github` namespace
+instead.
+{{% /boxes/note %}}
+
+Note that unstable namespaces do not automatically inherit endpoints from
+stable namespaces: for example, the fact that `/_matrix/client/v3/sync`
+exists does not imply that `/_matrix/client/unstable/com.example.mscxxxx/sync`
+exists.
+
+Vendor prefixes MUST also be used for:
+
+-   New parameters on existing endpoints. For example:
+    `/_matrix/client/v3/publicRooms?com.example.mscxxxx.ordered_by=member_count`.
+-   New properties in existing JSON objects. For example:
+
+    ```json
+    {
+      "avatar_url": "mxc://matrix.org/SDGdghriugerRg",
+      "displayname": "Alice Margatroid",
+      "com.example.mscxxxx.phone": [{
+        "type": "landline",
+        "number": "+1-206-555-7000"
+      }],
+      ...
+    }
+    ```
+
+-   New values for existing parameters or properties. For example:
+
+    ```json
+    {
+      "errcode": "COM.EXAMPLE.MSCXXXX.M_INVALID_EMAIL",
+      "error": "The email address you provided is invalid."
+    }
+    ```
+
+If the client needs to be sure the server supports the feature, an
+unstable feature flag that MUST also be vendor prefixed is to be used.
+This flag shows up in the `unstable_features` section of
+[`/_matrix/client/versions`](/client-server-api/#get_matrixclientversions)
+as, for example, `com.example.mscxxxx.new_login`.
+
+{{% boxes/note %}}
+MSCs MUST still describe what the stable endpoints/feature looks like
+with a note towards the bottom for what the unstable feature
+flag/prefixes are. For example, an MSC would propose `/_matrix/client/v1/new/endpoint`,
+not `/_matrix/client/unstable/com.example.mscxxxx/new/endpoint`.
+{{% /boxes/note %}}
+
+When using this approach correctly, the implementation can release
+the feature at any time, so long as the implementation is able to
+accept the technical debt that results from needing to provide
+adequate backwards and forwards compatibility. The implementation
+MUST support the flag (and server-side implementation) disappearing
+and be generally safe for users. Note that implementations early in
+the MSC review process may also be required to provide backwards
+compatibility with earlier editions of the proposal.
+
+If the implementation cannot support the technical debt (or if it's
+impossible to provide forwards/backwards compatibility - e.g. a user
+authentication change which can't be safely rolled back), the
+implementation should not attempt to implement the feature and should
+instead wait for a spec release.
+
+If at any point after early release, the idea changes in a
+backwards-incompatible way, the feature flag should also change so
+that implementations can adapt as needed.
+
 ### Placeholder MSCs
 
 Some proposals may contain security-sensitive or private context which can't be

content/push-gateway-api.md

@@ -2,12 +2,11 @@
 title: "Push Gateway API"
 weight: 50
 type: docs
+description: |
+  Clients may want to receive push notifications when events are received at the
+  homeserver. This is managed by a distinct entity called the Push Gateway.
 ---
 
-Clients may want to receive push notifications when events are received
-at the homeserver. This is managed by a distinct entity called the Push
-Gateway.
-
 ## Overview
 
 A client's homeserver forwards information about received events to the

content/server-server-api.md

@@ -2,49 +2,46 @@
 title: "Server-Server API"
 weight: 20
 type: docs
+description: |
+  Matrix homeservers use the Federation APIs (also known as server-server APIs)
+  to communicate with each other. Homeservers use these APIs to push messages in
+  real-time, retrieve historic messages, and query profile or presence
+  information about users on other servers. The APIs are implemented over HTTPS,
+  with authentication provided by public key signatures both at the TLS
+  transport layer and in HTTP Authorization headers.
+
+  There are three main kinds of communication that occur between
+  homeservers:
+
+  Persistent Data Units (PDUs):
+  These events are broadcast from one homeserver to any others that have
+  joined the same room (identified by Room ID). They are persisted in
+  long-term storage and record the history of messages and state for a
+  room.
+
+  Like email, it is the responsibility of the originating server of a PDU
+  to deliver that event to its recipient servers. However PDUs are signed
+  using the originating server's private key so that it is possible to
+  deliver them through third-party servers.
+
+  Ephemeral Data Units (EDUs):
+  These events are pushed between pairs of homeservers. They are not
+  persisted and are not part of the history of a room, nor does the
+  receiving homeserver have to reply to them.
+
+  Queries:
+  These are single request/response interactions between a given pair of
+  servers, initiated by one side sending an HTTPS GET request to obtain
+  some information, and responded by the other. They are not persisted and
+  contain no long-term significant history. They simply request a snapshot
+  state at the instant the query is made.
+
+  EDUs and PDUs are further wrapped in an envelope called a Transaction,
+  which is transferred from the origin to the destination homeserver using
+  an HTTPS PUT request.
+
 ---
 
-Matrix homeservers use the Federation APIs (also known as server-server
-APIs) to communicate with each other. Homeservers use these APIs to push
-messages to each other in real-time, to retrieve historic messages from
-each other, and to query profile and presence information about users on
-each other's servers.
-
-The APIs are implemented using HTTPS requests between each of the
-servers. These HTTPS requests are strongly authenticated using public
-key signatures at the TLS transport layer and using public key
-signatures in HTTP Authorization headers at the HTTP layer.
-
-There are three main kinds of communication that occur between
-homeservers:
-
-Persistent Data Units (PDUs):
-These events are broadcast from one homeserver to any others that have
-joined the same room (identified by Room ID). They are persisted in
-long-term storage and record the history of messages and state for a
-room.
-
-Like email, it is the responsibility of the originating server of a PDU
-to deliver that event to its recipient servers. However PDUs are signed
-using the originating server's private key so that it is possible to
-deliver them through third-party servers.
-
-Ephemeral Data Units (EDUs):
-These events are pushed between pairs of homeservers. They are not
-persisted and are not part of the history of a room, nor does the
-receiving homeserver have to reply to them.
-
-Queries:
-These are single request/response interactions between a given pair of
-servers, initiated by one side sending an HTTPS GET request to obtain
-some information, and responded by the other. They are not persisted and
-contain no long-term significant history. They simply request a snapshot
-state at the instant the query is made.
-
-EDUs and PDUs are further wrapped in an envelope called a Transaction,
-which is transferred from the origin to the destination homeserver using
-an HTTPS PUT request.
-
 ## API standards
 
 The mandatory baseline for server-server communication in Matrix is

data/api/client-server/cross_signing.yaml

@@ -21,13 +21,17 @@ paths:
       x-addedInMatrixVersion: "1.1"
       x-changedInMatrixVersion:
         "1.11": UIA is not always required for this endpoint.
+        "1.17": |-
+          This endpoint no longer requires User-Interactive Authentication when used by an
+          application service.
       summary: Upload cross-signing keys.
       description: |-
         Publishes cross-signing keys for the user.
 
-        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
+        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api),
+        except when used by an application service.
 
-        User-Interactive Authentication MUST be performed, except in these cases:
+        User-Interactive Authentication MUST be performed for regular clients, except in these cases:
         - there is no existing cross-signing master key uploaded to the homeserver, OR
         - there is an existing cross-signing master key and it exactly matches the
           cross-signing master key provided in the request body. If there are any additional

data/api/client-server/device_management.yaml

@@ -87,8 +87,21 @@ paths:
       tags:
         - Device management
     put:
-      summary: Update a device
+      summary: Create or update a device
-      description: Updates the metadata on the given device.
+      x-changedInMatrixVersion:
+        "1.17": The ability to create new devices was added.
+      description: |-
+        Updates the metadata on the given device, or creates a new device.
+
+        The ability to create new devices is only available to application
+        services: regular clients may only update existing devices.
+
+        When a new device was created, the homeserver MUST return a 201 HTTP
+        status code. It MUST return a 200 HTTP status code if a device was
+        updated.
+
+        This endpoint is rate-limited for device creation. Servers MAY use login
+        rate limits.
       operationId: updateDevice
       security:
         - accessTokenQuery: []
@@ -127,19 +140,34 @@ paths:
               examples:
                 response:
                   value: {}
+        "201":
+          description: |-
+            The device was successfully created by the application service.
+          content:
+            application/json:
+              schema:
+                type: object
+              examples:
+                response:
+                  value: {}
         "404":
           description: The current user has no device with the given ID.
       tags:
         - Device management
     delete:
       summary: Delete a device
+      x-changedInMatrixVersion:
+        "1.17": |-
+          This endpoint no longer requires User-Interactive Authentication when used by an
+          application service.
       description: |-
-        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
+        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api),
+        except when used by an application service.
 
         Deletes the given device, and invalidates any access token associated with it.
 
         {{% boxes/warning %}}
-        Since this endpoint uses User-Interactive Authentication, it cannot be used when the access token was obtained
+        When this endpoint requires 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: deleteDevice
@@ -190,13 +218,18 @@ paths:
   /delete_devices:
     post:
       summary: Bulk deletion of devices
+      x-changedInMatrixVersion:
+        "1.17": |-
+          This endpoint no longer requires User-Interactive Authentication when used by an
+          application service.
       description: |-
-        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
+        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api),
+        except when used by an application service.
 
         Deletes the given devices, and invalidates any access token associated with them.
 
         {{% boxes/warning %}}
-        Since this endpoint uses User-Interactive Authentication, it cannot be used when the access token was obtained
+        When this endpoint requires 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: deleteDevices

data/api/client-server/login.yaml

@@ -243,8 +243,13 @@ paths:
                     }
                   }
         "400":
-          description: Part of the request was invalid. For example, the login type may
+          description: |-
-            not be recognised.
+            Part of the request was invalid. For example, the login type may not be recognised.
+
+            Specific error codes used with this status code include:
+              * {{% added-in v="1.17" %}} `M_APPSERVICE_LOGIN_UNSUPPORTED`: an application service
+                used the `m.login.application_service` type, but the server doesn't support logging
+                in via the Legacy authentication API.
           content:
             application/json:
               schema:

data/api/client-server/registration.yaml

@@ -60,6 +60,18 @@ paths:
 
         Any user ID returned by this API must conform to the grammar given in the
         [Matrix specification](/appendices/#user-identifiers).
+
+        {{% boxes/note %}}
+        {{% added-in v="1.17" %}}
+        Even if the server doesn't support the Legacy authentication API, it
+        MUST support this endpoint for application services to be able to
+        [create users](/application-service-api/#server-admin-style-permissions).
+
+        In that case application services MUST set the `"inhibit_login": true`
+        parameter as they cannot use it to log in as users. If the
+        `inhibit_login` parameter is not set to `true`, the server MUST return a
+        400 HTTP status code with an `M_APPSERVICE_LOGIN_UNSUPPORTED` error code.
+        {{% /boxes/note %}}
       operationId: register
       parameters:
         - in: query
@@ -203,6 +215,9 @@ paths:
             * `M_INVALID_USERNAME` : The desired user ID is not a valid user name.
             * `M_EXCLUSIVE` : The desired user ID is in the exclusive namespace
               claimed by an application service.
+            * {{% added-in v="1.17" %}} `M_APPSERVICE_LOGIN_UNSUPPORTED`: an application service
+              used the `m.login.application_service` type without setting `inhibit_login` to `true`,
+              but the server doesn't support logging in via the Legacy authentication API.
 
             These errors may be returned at any stage of the registration process,
             including after authentication if the requested user ID was registered

data/api/client-server/rooms.yaml

@@ -223,7 +223,7 @@ paths:
             type: string
         # XXX: As mentioned in MSC1227, replacing `[not_]membership` with a JSON
         # filter might be a better alternative.
-        # See https://github.com/matrix-org/matrix-doc/issues/1337
+        # See https://github.com/matrix-org/matrix-doc/issues/1227
         - in: query
           name: membership
           description: |-

data/api/client-server/third_party_lookup.yaml

@@ -78,7 +78,7 @@ paths:
                       },
                       "room": {
                         "regexp": "[^\\s]+\\/[^\\s]+",
-                        "placeholder": "matrix-org/matrix-doc"
+                        "placeholder": "matrix-org/matrix-spec"
                       }
                     },
                     "instances": [

data/api/server-server/openid.yaml

@@ -43,7 +43,12 @@ paths:
                 properties:
                   sub:
                     type: string
-                    description: The Matrix User ID who generated the token.
+                    description: |
+                      The Matrix User ID who generated the token.
+
+                      The caller MUST validate that the returned user ID is on the server they
+                      called (i.e. if you make a request to example.com and it returns
+                      `@alice:matrix.org`, the result is invalid).
                     example: "@alice:example.com"
                 required:
                   - sub

layouts/_partials/endpoints-toc.html

@@ -0,0 +1,61 @@
+{{/*
+  
+  Renders a list of API endpoints for the current page, given:
+
+  The outer page's Scratch must contain an "api_endpoints" key, which is either
+  a slice of maps (a list of endpoint metadata dicts) or a map of module name ->
+  slice of endpoint metadata dicts (representing the API modules and the
+  endpoints they each contain). Each endpoint dict must contain the following
+  keys:
+
+    * `anchor`: the HTML anchor for the endpoint
+    * `method`: the HTTP method
+    * `endpoint`: the endpoint path
+    * `summary`: a short summary of the endpoint
+    * `deprecated`: whether the endpoint is deprecated
+    * `module`: the CS API module name, if any, for grouping purposes. If empty,
+      the endpoint is considered "base" or "required".
+  
+*/}}
+
+{{ $raw := .Scratch.Get "api_endpoints" }}
+{{/* Normalize to a slice */}}
+{{ $endpoints := slice }}
+{{ if reflect.IsSlice $raw }}
+  {{ $endpoints = $raw }}
+{{ else if reflect.IsMap $raw }}
+  {{ range $raw }}
+    {{ $endpoints = append $endpoints . }}
+  {{ end }}
+{{ end }}
+{{ if gt (len $endpoints) 0 }}
+  <div class="endpoints-toc mb-4">
+    <details>
+      <summary>List of Endpoints</summary>
+      {{/* Sort by module to group visually */}}
+      {{ $sorted := sort $endpoints "module" }}
+      {{ $current := "" }}
+      {{ range $sorted }}
+        {{ $mod := .module }}
+        {{/* Set a title for the base endpoints */}}
+        {{ if not $mod }}{{ $mod = "Required" }}{{ end }}
+        {{ if ne $mod $current }}
+          {{ if $current }}</ul></div>{{ end }}
+          <div class="endpoint-module">
+            <div class="endpoint-module-title">{{ $mod }}</div>
+            <ul class="endpoint-list">
+          {{ $current = $mod }}
+        {{ end }}
+        {{ $key := printf "%s|%s" .method .anchor }}
+        <li>
+          <a href="#{{ .anchor }}">
+            <span class="http-api-method">{{ .method }}</span>
+            <span class="endpoint-path">{{ .endpoint }}</span>
+            {{ if .deprecated }}<span class="endpoint-deprecated">(deprecated)</span>{{ end }}
+          </a>
+        </li>
+      {{ end }}
+      {{ if $current }}</ul></div>{{ end }}
+    </details>
+  </div>
+{{ end }}

layouts/_partials/openapi/render-api.html

@@ -7,6 +7,8 @@
   of each value in `paths` to get a complete URL.
   * `anchor_base`: an optional prefix for the HTML IDs generated by
   this template.
+  * `page`: the (Hugo) Page object to store endpoint metadata in the Scratch of. Used to build the endpoints TOC.
+  * `module`: the current CS API module name, if any. Used to group endpoints in the TOC.
 
   This template replaces the old {{*_http_api}} template.
 
@@ -15,6 +17,8 @@
 {{ $api_data := index .api_data }}
 {{ $base_url := .base_url }}
 {{ $anchor_base := .anchor_base }}
+{{ $page := .page }}
+{{ $module := .module }}
 
 {{ range $path_name, $path_data := $api_data.paths }}
 
@@ -26,28 +30,28 @@
 
     {{ with $path_data.get }}
 
-        {{ $operation_params := merge $params (dict "method" "GET" "operation_data" . "anchor_base" $anchor_base) }}
+        {{ $operation_params := merge $params (dict "method" "GET" "operation_data" . "anchor_base" $anchor_base "page" $page "module" $module) }}
         {{ partial "openapi/render-operation" $operation_params }}
 
     {{ end }}
 
     {{ with $path_data.post }}
 
-        {{ $operation_params := merge $params (dict "method" "POST" "operation_data" . "anchor_base" $anchor_base) }}
+        {{ $operation_params := merge $params (dict "method" "POST" "operation_data" . "anchor_base" $anchor_base "page" $page "module" $module) }}
         {{ partial "openapi/render-operation" $operation_params }}
 
     {{ end }}
 
     {{ with $path_data.put }}
 
-        {{ $operation_params := merge $params (dict "method" "PUT" "operation_data" . "anchor_base" $anchor_base) }}
+        {{ $operation_params := merge $params (dict "method" "PUT" "operation_data" . "anchor_base" $anchor_base "page" $page "module" $module) }}
         {{ partial "openapi/render-operation" $operation_params }}
 
     {{ end }}
 
     {{ with $path_data.delete }}
 
-        {{ $operation_params := merge $params (dict "method" "DELETE" "operation_data" . "anchor_base" $anchor_base) }}
+        {{ $operation_params := merge $params (dict "method" "DELETE" "operation_data" . "anchor_base" $anchor_base "page" $page "module" $module) }}
         {{ partial "openapi/render-operation" $operation_params }}
 
     {{ end }}

layouts/_partials/openapi/render-operation.html

@@ -7,6 +7,8 @@
   * `operation_data`: the OpenAPI data for the operation
   * `anchor_base`: an optional prefix for the HTML IDs generated by
   this template.
+  * `page`: the (Hugo) Page object to store endpoint metadata in the Scratch of. Used to build the endpoints TOC.
+  * `module`: the current CS API module name, if any. Used to group endpoints in the TOC.
 
   This template renders the operation as a `<section>` containing:
 
@@ -22,6 +24,8 @@
 {{ $method := .method }}
 {{ $endpoint := .endpoint }}
 {{ $operation_data := .operation_data }}
+{{ $page := .page }}
+{{ $module := .module }}
 
 {{ $anchor := "" }}
 {{ if .anchor_base }}
@@ -29,6 +33,27 @@
 {{ end }}
 {{ $anchor = printf "%s%s%s" $anchor (lower $method) (anchorize $endpoint) }}
 
+{{/* Collect endpoints for the on-page endpoints TOC */}}
+{{ if $page }}
+  {{/* Store each endpoint's metadata in a scratch variable */}}
+  {{ $entry := dict "anchor" $anchor "method" $method "endpoint" $endpoint "summary" $operation_data.summary "deprecated" $operation_data.deprecated "module" $module }}
+  {{ if not ($page.Scratch.Get "api_endpoints_seen") }}
+    {{ $page.Scratch.Set "api_endpoints_seen" dict }}
+  {{ end }}
+  {{/* Keep a map of seen endpoints. This is necessary as this partial may be
+       rendered multiple times for the same endpoint (e.g. in the TOC and
+       in the main content), leading to duplicates. */}}
+  {{ $seen := $page.Scratch.Get "api_endpoints_seen" }}
+  {{ $key := printf "%s|%s" $method $endpoint }}
+  {{ if not (index $seen $key) }}
+  {{ if not (reflect.IsSlice ($page.Scratch.Get "api_endpoints")) }}
+    {{ $page.Scratch.Set "api_endpoints" (slice) }}
+  {{ end }}
+  {{ $page.Scratch.Add "api_endpoints" (slice $entry) }}
+    {{ $page.Scratch.SetInMap "api_endpoints_seen" $key true }}
+  {{ end }}
+{{ end }}
+
 <section class="rendered-data">
 
 <details {{ if not site.Params.ui.rendered_data_collapsed }}open{{ end }}>

layouts/_partials/spec-content.html

@@ -0,0 +1,14 @@
+{{- /* Shared render for spec pages: title, optional description, endpoints list, body, and last-mod info. */ -}}
+<div class="td-content">
+  <h1>{{ .Title }}</h1>
+  {{ with .Params.description }}<p class="page-description">{{ . | markdownify }}</p>{{ end }}
+
+  {{/*
+    Render an endpoints table of contents. This is the main difference
+    between our templates (which call the spec-content partial) and the default
+    Docsy template.
+  */}}
+  {{ partial "endpoints-toc.html" . }}
+
+  {{ .Content }}
+</div>

layouts/_shortcodes/cs-module.html

@@ -3,14 +3,39 @@
     This template is used to render a Client-Server API Module. Modules are defined
     alongside the `_index.md` for the CS API.
 
-    The `name` parameter is the file name without extension.
+    The following parameters are expected:
+
+    * `filename` the name of the module file to render, without extension (i.e. `spaces`).
+    * `name` the display name of the module (i.e. `Spaces`).
 
 */}}
 
 {{ $name := .Params.name }}
+{{ $filename := .Params.filename }}
 
 {{ with .Site.GetPage "client-server-api/modules" }}
-    {{ with .Resources.GetMatch (printf "%s%s" $name ".md") }}
+    {{ with .Resources.GetMatch (printf "%s%s" $filename ".md") }}
+        {{/* Preserve previous scratch values so nested modules don't leak */}}
+        {{ $prevPage := .Scratch.Get "endpoint_page" }}
+        {{ $prevModule := .Scratch.Get "endpoint_module" }}
+
+        {{/* Allow endpoints rendered in the module to accumulate on the parent page */}}
+        {{ .Scratch.Set "endpoint_page" $.Page }}
+        {{/* Name the module for grouping in the endpoints list */}}
+        {{ .Scratch.Set "endpoint_module" $name }}
+
 {{ .RenderShortcodes }}
+
+        {{/* Restore previous scratch values */}}
+        {{ if $prevPage }}
+          {{ .Scratch.Set "endpoint_page" $prevPage }}
+        {{ else }}
+          {{ .Scratch.Delete "endpoint_page" }}
+        {{ end }}
+        {{ if $prevModule }}
+          {{ .Scratch.Set "endpoint_module" $prevModule }}
+        {{ else }}
+          {{ .Scratch.Delete "endpoint_module" }}
+        {{ end }}
     {{ end }}
 {{ end }}

layouts/_shortcodes/http-api.html

@@ -23,6 +23,20 @@
 {{ $api := .Params.api}}
 {{ $anchor_base := .Params.anchor_base}}
 
+{{/*
+  
+  Figure out which Page object to pass to the `openapi/render-api` partial.
+  Either our own, or one stored under `endpoint_page` in the Scratch, if one
+  exists.
+
+*/}}
+{{ $target_page := .Page }}
+{{ with .Page.Scratch.Get "endpoint_page" }}
+  {{ $target_page = . }}
+{{ end }}
+
+{{ $module_name := .Page.Scratch.Get "endpoint_module" }}
+
 {{ $api_data := index .Site.Data.api .Params.spec .Params.api }}
 {{ $base_url := (index $api_data.servers 0).variables.basePath.default }}
 {{ $path := delimit (slice "api" $spec $api) "/" }}
@@ -30,4 +44,4 @@
 {{ $api_data = partial "json-schema/resolve-refs" (dict "schema" $api_data "path" $path) }}
 {{ $api_data = partial "json-schema/resolve-allof" $api_data }}
 
-{{ partial "openapi/render-api" (dict "api_data" $api_data "base_url" $base_url "anchor_base" $anchor_base) }}
+{{ partial "openapi/render-api" (dict "api_data" $api_data "base_url" $base_url "anchor_base" $anchor_base "page" $target_page "module" $module_name) }}

layouts/content.html

@@ -1,4 +0,0 @@
-<div class="td-content">
-	<h1>{{ .Title }}</h1>
-	{{ .Content }}
-</div>

layouts/docs/list.html

@@ -1,13 +1,19 @@
 {{/*
 
-  A simplified version of the list.html partial in Docsy.
+  Override the `layouts/docs/list.html` template from Docsy. While this template
+  is equivalent to `single.html`, it's necessary to override both templates to
+  avoid falling back to the default Docsy templates.
+
+  https://gohugo.io/templates/types/#list
+
+  We use this list template to render the Client-Server API spec page and each
+  of its modules.
+
+  The contents of the "main" block below are inserted into the `./baseof.html`
+  base template.
 
 */}}
 
 {{ define "main" }}
-<div class="td-content">
+  {{ partial "spec-content.html" . }}
-	<h1>{{ .Title }}</h1>
-        {{ with .Params.description }}<div class="lead">{{ . | markdownify }}</div>{{ end }}
-	{{ .Content }}
-</div>
 {{ end }}

layouts/docs/single.html

@@ -0,0 +1,19 @@
+{{/*
+
+  Override the `layouts/docs/single.html` template from Docsy. While this template
+  is equivalent to `list.html`, it's necessary to override both templates to
+  avoid falling back to the default Docsy templates.
+
+  https://gohugo.io/templates/types/#single
+
+  We use this single template to render the all API spec pages *except* the
+  Client-Server API. The Client-Server API spec page contains modules, and thus
+  is handled separately, via the `layouts/docs/list.html` template.
+
+  The contents of the "main" block below are inserted into the `./baseof.html`
+  base template.
+
+*/}}
+{{ define "main" }}
+  {{ partial "spec-content.html" . }}
+{{ end }}

meta/releasing.md

@@ -50,11 +50,6 @@ First, can we even release the spec? This stage is mostly preparation work neede
 to ensure a consistent and reliable specification.
 
 1. Ensure `main` is committed with all the spec changes you expect to be there.
-2. Review the changelog to look for typos, wording inconsistencies, or lines which
-   can be merged. For example, "Fix typos" and "Fix spelling" can be condensed to
-   "Fix various typos throughout the specification".
-3. Do a quick skim to ensure changelogs reference the MSCs which brought the changes
-   in. They should be linked to the GitHub MSC PR (not the markdown document).
 
 ## The release
 
@@ -79,20 +74,24 @@ release.
    2. Run `./scripts/generate-changelog.sh v1.2` (using the correct version number).
       The script will use the current date. If that date is wrong, correct the document
       by using the same `YYYY-MM-DD` date format.
-   3. Commit the result.
+   3. Review the changelog to look for typos, wording inconsistencies, or lines which
+      can be merged. For example, "Fix typos" and "Fix spelling" can be condensed to
+      "Fix various typos throughout the specification".
+   4. Do a quick skim to ensure changelogs reference the MSCs which brought the changes
+      in. They should be linked to the GitHub MSC PR (not the markdown document).
+   5. Commit the result.
+   6. Now is a good time to have someone else review the changelog.
 5. Tag the branch with the spec release with a format of `v1.2` (if releasing Matrix 1.2).
 6. Push the release branch and the tag.
 7. GitHub Actions will run its build steps. Wait until these are successful. If fixes
    need to be made to repair the pipeline or spec build, delete and re-tag the release.
    You may need to fix up the changelog file by hand in this case.
-8. Check out and fast-forward `main` to the release branch.
+8. GitHub Actions should have drafted a release based on the new tag. Find it
-9. Create a new release on GitHub from the newly created tag.
+   at https://github.com/matrix-org/matrix-spec/releases.
-   * The title should be just "v1.2" (for example).
+   1. Double-check the generated release notes, and check that `spec-artifact.zip` and
-   * The description should be a copy/paste of the changelog. The generated changelog
+      `spec-historical-artifact.zip` are both attached to the draft release.
-     will be at `content/changelog/v1.2.md` - copy/paste verbatim.
+   2. Publish the draft release.
-   * Upload the artifacts of the GitHub Actions build for the release to the GitHub
+9. Check out and fast-forward `main` to the release branch.
-     release as artifacts themselves. This should be the tarball that will be deployed
-     to spec.matrix.org.
 10. Commit a reversion to `params.version` of `./config/_default/hugo.toml` on `main`:
     ```toml
     [params.version]
@@ -103,7 +102,8 @@ release.
     ```
 11. Push pending commits and ensure the unstable spec updates accordingly from the
     GitHub Actions pipeline.
-12. Deploy the release on the webserver. See internal wiki.
+12. Deploy the release on the webserver. See "Spec release process" in the
+    internal handbook.
 
 ## Patching a release
 

scripts/proposals.js

@@ -6,7 +6,7 @@
  * in the specification.
  *
  * In detail, it:
- * - fetches all GitHub issues from matrix-doc that have the `proposal` label
+ * - fetches all GitHub issues from matrix-spec-proposals that have the `proposal` label
  * - groups them by their state in the MSC process
  * - does some light massaging of them so it's easier for the Hugo template to work with them
  * - store them at /data/msc