diff --git a/.gitignore b/.gitignore
index c1a34c50..e69de29b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,16 +0,0 @@
-node_modules
-/data/msc
-/env*
-/resources
-/scripts/swagger
-/scripts/tmp
-/hugo-config.toml
-/public
-*.pyc
-*.swp
-_rendered.rst
-/.vscode/
-/.idea/
-/spec/
-changelogs/rendered.*
-.hugo_build.lock
diff --git a/.gitmodules b/.gitmodules
deleted file mode 100644
index 5e606ab2..00000000
--- a/.gitmodules
+++ /dev/null
@@ -1,4 +0,0 @@
-[submodule "themes/docsy"]
-	path = themes/docsy
-	url = https://github.com/matrix-org/docsy.git
-	branch = master
diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
deleted file mode 100644
index 2e72e186..00000000
--- a/CONTRIBUTING.rst
+++ /dev/null
@@ -1,175 +0,0 @@
-Contributing to matrix-doc
-==========================
-
-Everyone is welcome to contribute to the Matrix specification!
-
-Please ensure that you sign off your contributions. See `Sign off`_ below.
-
-Code style
-----------
-
-The documentation style is described at
-https://github.com/matrix-org/matrix-doc/blob/master/meta/documentation_style.rst.
-
-Python code within the ``matrix-doc`` project should follow the same style as
-synapse, which is documented at
-https://github.com/matrix-org/synapse/tree/master/docs/code_style.md.
-
-Matrix-doc workflows
---------------------
-
-Specification changes
-~~~~~~~~~~~~~~~~~~~~~
-
-The Matrix specification documents the APIs which Matrix clients and servers use.
-For this to be effective, the APIs need to be present and working correctly in a
-server before they can be documented in the specification. This process can take
-some time to complete.
-
-Changes to the protocol (new endpoints, ideas, etc) need to go through the
-`proposals process <https://matrix.org/docs/spec/proposals>`_. Other changes,
-such as fixing bugs, typos, or clarifying existing behaviour do not need a proposal.
-If you're not sure, visit us at `#matrix-spec:matrix.org`_ and ask.
-
-Other changes
-~~~~~~~~~~~~~
-
-The above process is unnecessary for smaller changes, and those which do not
-put new requirements on servers. This category of changes includes the
-following:
-
-* Changes to the scripts used to generate the specification.
-
-* Addition of features which have been in use in practice for some time, but
-  have never made it into the spec (including anything with the `spec-omission
-  <https://github.com/matrix-org/matrix-doc/labels/spec-omission>`_ label).
-
-* Likewise, corrections to the specification, to fix situations where, in
-  practice, servers and clients behave differently to the specification,
-  including anything with the `spec-bug
-  <https://github.com/matrix-org/matrix-doc/labels/spec-bug>`_ label.
-
-  (If there is any doubt about whether it is the spec or the implementations
-  that need fixing, please discuss it with us first in `#matrix-spec:matrix.org`_.)
-
-* Clarifications to the specification which do not change the behaviour of
-  Matrix servers or clients in a way which might introduce compatibility
-  problems for existing deployments. This includes anything with the
-  `clarification <https://github.com/matrix-org/matrix-doc/labels/clarification>`_
-  label.
-
-  For example, areas where the specification is unclear do not require a proposal
-  to fix. On the other hand, introducing new behaviour is best represented by a
-  proposal.
-
-* Design or aesthetic changes, such as improving accessibility, colour schemes,
-  etc. Please check in with us at `#matrix-docs:matrix.org`_ with your proposed
-  design change before opening a PR so we can work with you on it.
-
-For such changes, please do just open a `pull request`_. If you're not sure if
-your change is covered by the above, please visit `#matrix-spec:matrix.org` and
-ask.
-
-.. _`pull request`: https://help.github.com/articles/about-pull-requests
-.. _`#matrix-spec:matrix.org`: https://matrix.to/#/#matrix-spec:matrix.org
-.. _`#matrix-docs:matrix.org`: https://matrix.to/#/#matrix-docs:matrix.org
-
-
-Adding to the changelog
-~~~~~~~~~~~~~~~~~~~~~~~
-
-All API specifications require a changelog entry. Adding to the changelog can only
-be done after you've opened your pull request, so be sure to do that first.
-
-The changelog is managed by Towncrier (https://github.com/hawkowl/towncrier) in the
-form of "news fragments". The news fragments for the client-server API are stored
-under ``changelogs/client_server/newsfragments``.
-
-To create a changelog entry, create a file named in the format ``prNumber.type`` in
-the ``newsfragments`` directory. The ``type`` can be one of the following:
-
-* ``new`` - Used when adding new endpoints. Please have the file contents be the
-  method and route being added, surrounded in markdown code tags. For example: \`POST
-  /accounts/whoami\`.
-
-* ``feature`` - Used when adding backwards-compatible changes to the API.
-
-* ``clarification`` - Used when an area of the spec is being improved upon and does
-  not change or introduce any functionality.
-
-* ``breaking`` - Used when the change is not backwards compatible.
-
-* ``deprecation`` - Used when deprecating something.
-
-All news fragments must have a brief summary explaining the change in the
-contents of the file. The summary must end in a full stop to be in line with
-the style guide and formatting must be done using Markdown.
-
-Changes that do not change the spec, such as changes to the build script, formatting,
-CSS, etc should not get a news fragment.
-
-Sign off
---------
-
-We ask that everybody who contributes to their project signs off their
-contributions, as explained below.
-
-We follow a simple 'inbound=outbound' model for contributions: the act of
-submitting an 'inbound' contribution means that the contributor agrees to
-license their contribution under the same terms as the project's overall 'outbound'
-license - in our case, this is Apache Software License v2 (see LICENSE).
-
-In order to have a concrete record that your contribution is intentional
-and you agree to license it under the same terms as the project's license, we've adopted the
-same lightweight approach that the Linux Kernel
-(https://www.kernel.org/doc/Documentation/SubmittingPatches), Docker
-(https://github.com/docker/docker/blob/master/CONTRIBUTING.md), and many other
-projects use: the DCO (Developer Certificate of Origin:
-http://developercertificate.org/). This is a simple declaration that you wrote
-the contribution or otherwise have the right to contribute it to Matrix::
-
-    Developer Certificate of Origin
-    Version 1.1
-
-    Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
-    660 York Street, Suite 102,
-    San Francisco, CA 94110 USA
-
-    Everyone is permitted to copy and distribute verbatim copies of this
-    license document, but changing it is not allowed.
-
-    Developer's Certificate of Origin 1.1
-
-    By making a contribution to this project, I certify that:
-
-    (a) The contribution was created in whole or in part by me and I
-        have the right to submit it under the open source license
-        indicated in the file; or
-
-    (b) The contribution is based upon previous work that, to the best
-        of my knowledge, is covered under an appropriate open source
-        license and I have the right under that license to submit that
-        work with modifications, whether created in whole or in part
-        by me, under the same open source license (unless I am
-        permitted to submit under a different license), as indicated
-        in the file; or
-
-    (c) The contribution was provided directly to me by some other
-        person who certified (a), (b) or (c) and I have not modified
-        it.
-
-    (d) I understand and agree that this project and the contribution
-        are public and that a record of the contribution (including all
-        personal information I submit with it, including my sign-off) is
-        maintained indefinitely and may be redistributed consistent with
-        this project or the open source license(s) involved.
-
-If you agree to this for your contribution, then all that's needed is to
-include the line in your commit or pull request comment::
-
-    Signed-off-by: Your Name <your@email.example.org>
-
-...using your real name; unfortunately pseudonyms and anonymous contributions
-can't be accepted. Git makes this trivial - just use the -s flag when you do
-``git commit``, having first set ``user.name`` and ``user.email`` git configs
-(which you should have done anyway :)
diff --git a/README.md b/README.md
deleted file mode 100644
index 2bf5feb6..00000000
--- a/README.md
+++ /dev/null
@@ -1,104 +0,0 @@
-# Matrix Specification
-
-This repository contains the Matrix Specification, rendered at [spec.matrix.org](http://spec.matrix.org/).
-
-Developers looking to use Matrix should join [#matrix-dev:matrix.org](https://matrix.to/#/#matrix-dev:matrix.org)
-on Matrix for help.
-
-Spec authors and proposal writers are welcome to join [#matrix-spec:matrix.org](https://matrix.to/#/#matrix-spec:matrix.org).
-We welcome contributions! See [CONTRIBUTING.rst](./CONTRIBUTING.rst) for details.
-
-## Structure
-
-The Matrix spec is compiled with [Hugo](https://gohugo.io/) (a static site generator) with the following structure:
-
-* `/assets`: assets that need postprocessing using [Hugo Pipes](https://gohugo.io/hugo-pipes/introduction/).
-  For example, Sass files would go here.
-
-* `/content`: files that will become pages in the site go here. Typically these are Markdown files with some YAML front
-  matter indicating, [among other things](https://gohugo.io/content-management/front-matter/), what layout should be
-  applied to this page. The organization of files under `/content` determines the organization of pages in the built
-  site.
-
-* `/data`: this can contain TOML, YAML, or JSON files. Files kept here are directly available to template code as
-  [data objects](https://gohugo.io/templates/data-templates/), so templates don't need to load them from a file and
-  parse them. This is also where our Swagger/OpenAPI definitions and schemas are.
-
-* `/layouts`: this contains [Hugo templates](https://gohugo.io/templates/). Some templates define the overall layout of
-  a page: for example, whether it has header, footer, sidebar, and so on.
-    * `/layouts/partials`: these templates can be called from other templates, so they can be used to factor out
-      template code that's used in more than one template. An obvious example here is something like a sidebar, where
-      several different page layouts might all include the sidebar. But also, partial templates can return values: this
-      means they can be used like functions, that can be called by multiple templates to do some common processing.
-    * `/layouts/shortcodes`: these templates can be called directly from files in `/content`.
-
-* `/static`: static files which don't need preprocessing. JS or CSS files could live here.
-
-* `/themes`: you can use just Hugo or use it with a theme. Themes primarily provide additional templates, which are
-  supplied in a `/themes/$theme_name/layouts` directory. You can use a theme but customise it by providing your own
-  versions of any of the theme layouts in the base `/layouts` directory. That is, if a theme provides
-  `/themes/$theme_name/layouts/sidebar.html` and you provide `/layouts/sidebar.html`, then your version of the
-  template will be used.
-
-It also has the following top-level file:
-
-* `config.toml`: site-wide configuration settings. Some of these are built-in and you can add your own. Config settings
-  defined here are available in templates. All these directories above are configurable via `config.toml` settings.
-
-Additionally, the following directories may be of interest:
-
-* `/attic`: Here contains historical sections of specification and legacy drafts for the specification.
-* `/changelogs`: Various bits of changelog for the specification areas.
-* `/data-definitions`: Bits of structured data consumable by Matrix implementations.
-* `/meta`: Documentation relating to the spec's processes that are otherwise untracked (release instructions, etc).
-* `/scripts`: Various scripts for generating the spec and validating its contents.
-* `/proposals`: Matrix Spec Change (MSC) proposals. See <https://spec.matrix.org/unstable/proposals/>.
-
-## Authoring changes to the spec
-
-Please read [CONTRIBUTING.rst](./CONTRIBUTING.rst) before authoring a change to the spec. Note that spec authoring takes
-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.74 is required.
-
-   Alternatively, use the Docker image at
-   https://hub.docker.com/r/klakegg/hugo/. (The "extended edition" is required
-   to process the SCSS.)
-2. Run `git submodule update --init --recursive` for good measure.
-3. Run `npm i` to install the dependencies. Note that this will require NodeJS to be installed.
-4. Run `npm run get-proposals` to seed proposal data. This is merely for populating the content of the "Spec Change Proposals"
-   page and is not required.
-5. Run `hugo serve` (or `docker run --rm -it -v $(pwd):/src -p 1313:1313
-   klakegg/hugo:ext serve`) to run a local webserver which builds whenever a file
-   change is detected. If watching doesn't appear to be working for you, try
-   adding `--disableFastRender` to the commandline.
-6. Edit the specification 🙂
-
-We use a highly customized [Docsy](https://www.docsy.dev/) theme for our generated site, which uses Bootstrap and Font
-Awesome. If you're looking at making design-related changes to the spec site, please coordinate with us in
-[#matrix-docs:matrix.org](https://matrix.to/#/#matrix-docs:matrix.org) before opening a PR.
-
-## Building the specification
-
-If for some reason you're not a CI/CD system and want to render a static version of the spec for yourself, follow the above
-steps for authoring changes to the specification and instead of `hugo serve` run `hugo -d "spec"` - this will generate the
-spec to `/spec`. If you'd like to serve the spec off a path instead of a domain root (eg: `/unstable`), add `--baseURL "/unstable"`
-to the `hugo -d "spec"` command.
-
-For building the swagger definitions, create a python3 virtualenv and activate it. Then run `pip install -r ./scripts/requirements.txt`
-and finally `python ./scripts/dump-swagger.py` to generate it to `./scripts/swagger/api-docs.json`. To make use of the generated file,
-there are a number of options:
-
-* It can be uploaded from your filesystem to an online editor/viewer such as [on the swagger website](http://editor.swagger.io/).
-* You can run a local HTTP server by running `./scripts/swagger-http-server.py`, and then view the documentation via an
-  online viewer; for example, at <http://petstore.swagger.io/?url=http://localhost:8000/api-docs.json>.
-* You can host the swagger UI yourself. See <https://github.com/swagger-api/swagger-ui#how-to-run> for advice on how to
-  do so.
-
-## Issue tracking
-
-Specification issues are tracked on github at <https://github.com/matrix-org/matrix-doc/issues>.
-
-See [meta/github-labels.rst](./meta/github-labels.rst) for information on what the labels mean.
diff --git a/assets/icons/logo.svg b/assets/icons/logo.svg
deleted file mode 100644
index ec067c8e..00000000
--- a/assets/icons/logo.svg
+++ /dev/null
@@ -1,5 +0,0 @@
-<svg width="75" height="32" xmlns="http://www.w3.org/2000/svg">
-  <g fill="#000" fill-rule="nonzero">
-    <path d="M.936.732V31.25H3.13v.732H.095V0h3.034v.732zM9.386 10.407v1.544h.044a4.461 4.461 0 0 1 1.487-1.368c.58-.323 1.245-.485 1.993-.485.72 0 1.377.14 1.972.42.595.279 1.047.771 1.355 1.477.338-.5.796-.941 1.377-1.323.58-.383 1.266-.574 2.06-.574.602 0 1.16.074 1.674.22.514.148.954.383 1.322.707.366.323.653.746.859 1.268.205.522.308 1.15.308 1.887v7.633H20.71v-6.464c0-.383-.015-.743-.044-1.082a2.305 2.305 0 0 0-.242-.882 1.473 1.473 0 0 0-.584-.596c-.257-.146-.606-.22-1.047-.22-.44 0-.796.085-1.068.253-.272.17-.485.39-.639.662a2.654 2.654 0 0 0-.308.927 7.074 7.074 0 0 0-.078 1.048v6.354h-3.128v-6.398c0-.338-.007-.673-.021-1.004a2.825 2.825 0 0 0-.188-.916 1.411 1.411 0 0 0-.55-.673c-.258-.168-.636-.253-1.135-.253a2.33 2.33 0 0 0-.584.1 1.94 1.94 0 0 0-.705.374c-.228.184-.422.449-.584.794-.161.346-.242.798-.242 1.357v6.619H6.434V10.407h2.952zM25.842 12.084a3.751 3.751 0 0 1 1.233-1.17 5.37 5.37 0 0 1 1.685-.629 9.579 9.579 0 0 1 1.884-.187c.573 0 1.153.04 1.74.121.588.081 1.124.24 1.609.475.484.235.88.562 1.19.981.308.42.462.975.462 1.666v5.934c0 .516.03 1.008.088 1.478.058.471.161.824.308 1.06H32.87a4.435 4.435 0 0 1-.22-1.104c-.5.515-1.087.876-1.762 1.081a7.084 7.084 0 0 1-2.071.31c-.544 0-1.05-.067-1.52-.2a3.472 3.472 0 0 1-1.234-.617 2.87 2.87 0 0 1-.826-1.059c-.199-.426-.298-.934-.298-1.522 0-.647.114-1.18.342-1.6.227-.419.52-.753.881-1.004.36-.25.771-.437 1.234-.562.462-.125.929-.224 1.399-.298.47-.073.932-.132 1.387-.176.456-.044.86-.11 1.212-.199.353-.088.631-.217.837-.386.206-.169.301-.415.287-.74 0-.337-.055-.606-.166-.804a1.217 1.217 0 0 0-.44-.464 1.737 1.737 0 0 0-.639-.22 5.292 5.292 0 0 0-.782-.055c-.617 0-1.101.132-1.454.397-.352.264-.558.706-.617 1.323h-3.128c.044-.735.227-1.345.55-1.83zm6.179 4.423a5.095 5.095 0 0 1-.639.165 9.68 9.68 0 0 1-.716.11c-.25.03-.5.067-.749.11a5.616 5.616 0 0 0-.694.177 2.057 2.057 0 0 0-.594.298c-.17.125-.305.284-.408.474-.103.192-.154.434-.154.728 0 .28.051.515.154.706.103.192.242.342.419.453.176.11.381.187.617.231.234.044.477.066.726.066.617 0 1.094-.102 1.432-.309.338-.205.587-.452.75-.739.16-.286.26-.576.297-.87.036-.295.055-.53.055-.707v-1.17a1.4 1.4 0 0 1-.496.277zM43.884 10.407v2.096h-2.291v5.647c0 .53.088.883.264 1.059.176.177.529.265 1.057.265.177 0 .345-.007.507-.022.161-.015.316-.037.463-.066v2.426a7.49 7.49 0 0 1-.882.089 21.67 21.67 0 0 1-.947.022c-.484 0-.944-.034-1.377-.1a3.233 3.233 0 0 1-1.145-.386 2.04 2.04 0 0 1-.782-.816c-.191-.353-.287-.816-.287-1.39v-6.728H36.57v-2.096h1.894v-3.42h3.129v3.42h2.29zM48.355 10.407v2.118h.044a3.907 3.907 0 0 1 1.454-1.754 4.213 4.213 0 0 1 1.036-.497 3.734 3.734 0 0 1 1.145-.176c.206 0 .433.037.683.11v2.912a5.862 5.862 0 0 0-.528-.077 5.566 5.566 0 0 0-.595-.033c-.573 0-1.058.096-1.454.287a2.52 2.52 0 0 0-.958.783 3.143 3.143 0 0 0-.518 1.158 6.32 6.32 0 0 0-.154 1.434v5.14h-3.128V10.407h2.973zM54.039 8.642V6.06h3.128v2.582H54.04zm3.128 1.765v11.405H54.04V10.407h3.128zM58.797 10.407h3.569l2.005 2.978 1.982-2.978h3.459l-3.745 5.339 4.208 6.067h-3.57l-2.378-3.596-2.38 3.596h-3.502l4.097-6.001zM74.094 31.25V.732H71.9V0h3.035v31.982H71.9v-.732z"/>
-  </g>
-</svg>
diff --git a/assets/scss/_variables_project.scss b/assets/scss/_variables_project.scss
deleted file mode 100644
index 1e7e3950..00000000
--- a/assets/scss/_variables_project.scss
+++ /dev/null
@@ -1,41 +0,0 @@
-/*
-Copyright 2020, 2021 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.
-*/
-
-$primary: #FFF;
-$secondary: #0098D4;
-$dark: #333;
-$gray-100: #FBFBFB;
-
-$secondary-background: #E5F5FB;
-$secondary-lighter-background: #F4FaFC;
-$secondary-lightest-background: #FBFDFD;
-
-
-$warning: #FF6666;
-$note: $secondary;
-
-$note-background: $secondary-background;
-$warning-background: #FFE0E0;
-
-$table-row-alternate: $secondary-lightest-background;
-$table-row-default: $secondary-lighter-background;
-
-/*
- Opt to serve fonts locally by overriding web-font-path to be a non-google fonts URL.
- This is only possible with our modified docsy theme: https://github.com/matrix-org/docsy
- */
-$web-font-path: "../css/fonts/Inter.css";
-$google_font_name: "Inter";
diff --git a/assets/scss/custom.scss b/assets/scss/custom.scss
deleted file mode 100644
index 62ae4532..00000000
--- a/assets/scss/custom.scss
+++ /dev/null
@@ -1,428 +0,0 @@
-/*
-Copyright 2020, 2021 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.
-*/
-
-/*
-Custom SCSS for the Matrix spec
-*/
-
-@import "variables_project";
-@import "variables";
-
-/* Overrides for the navbar */
-.td-navbar {
-  box-shadow: 0px 0px 8px rgba(179, 179, 179, 0.25);
-  min-height: 5rem;
-
-  .navbar-brand {
-    font-size: 1.1rem;
-
-    .navbar-version {
-      color: $secondary;
-    }
-
-  }
-
-  a {
-    color: $black;
-  }
-}
-
-/* Styles for the sidebar nav */
-.td-sidebar-nav {
-  scroll-behavior: smooth;
-  overscroll-behavior: contain;
-
-  &>.td-sidebar-nav__section {
-    margin-top: 1rem;
-  }
-
-  &>.td-sidebar-nav__section > li > a.td-sidebar-link {
-      font-weight: $font-weight-bold;
-      font-size: 1.3rem;
-  }
-
-  /* This is to make the width of the items that have sub-items (like room versions)
-  the same as the width of items that don't (like changelog) */
-  .pr-md-3, .px-md-3 {
-    padding-right: 0 !important;
-  }
-
-  a.indent-1 {
-    padding-left: 1rem !important;
-  }
-
-  a.indent-2 {
-    padding-left: 2rem;
-  }
-
-  a, a.td-sidebar-link {
-    color: $gray-800;
-    font-weight: $font-weight-normal;
-    padding-top: .2rem;
-    padding-bottom: .2rem;
-
-    display: block;
-    transition: all 100ms ease-in-out;
-
-    &:hover {
-      background-color: $secondary-lighter-background;
-      color: $gray-800;
-    }
-
-    &.active, &active:hover {
-      background-color: $secondary-background;
-      font-weight: $font-weight-normal;
-    }
-  }
-}
-
-@media (min-width: 768px) {
-  @supports (position: sticky) {
-    .td-sidebar-nav {
-      /* This overrides calc(100vh - 10rem);, which gives us a blank space at the bottom of the sidebar */
-      max-height: calc(100vh - 6rem);
-    }
-  }
-}
-
-/* Customise footer */
-footer {
-  box-shadow: 0px 0px 8px rgba(179, 179, 179, 0.25);
-}
-
-/* Auto numbering for headings */
-.td-content {
-
-  counter-reset: h2;
-
-  &> h2 {
-    counter-reset: h3
-  }
-
-  &> h3 {
-    counter-reset: h4
-  }
-
-  &> h4 {
-    counter-reset: h5
-  }
-
-  &> h5 {
-    counter-reset: h6
-  }
-
-  &> h2:not(.no-numbers):before {
-    display: inline; visibility: visible; counter-increment: h2; content: counter(h2) ". "
-  }
-
-  &> h3:not(.no-numbers):before {
-    display: inline; visibility: visible; counter-increment: h3; content: counter(h2) "." counter(h3) ". "
-  }
-
-  &> h4:not(.no-numbers):before {
-    display: inline; visibility: visible; counter-increment: h4; content: counter(h2) "." counter(h3) "." counter(h4) ". "
-  }
-
-  &> h5:not(.no-numbers):before {
-    display: inline; visibility: visible; counter-increment: h5; content: counter(h2) "." counter(h3) "." counter(h4) "." counter(h5) ". "
-  }
-
-  &> h6:not(.no-numbers):before {
-    display: inline; visibility: visible; counter-increment: h6; content: counter(h2) "." counter(h3) "." counter(h4) "." counter(h5) "." counter(h6) ". "
-  }
-
-}
-
-/* Adjust heading anchors for site header */
-.td-content {
-  &> h2,
-  &> h3,
-  &> h4,
-  &> h5,
-  &> h6,
-  .rendered-data h1 {
-    scroll-margin-top: 5rem;
-  }
-}
-
-/* Styles for the table of contents */
-#toc {
-  padding-top: .5rem;
-  padding-left: 1.5rem;
-
-  ol {
-    padding-left: 1rem;
-    counter-reset: section;
-    list-style-type: none;
-  }
-
-  #TableOfContents {
-    &>ol>li {
-      margin-bottom: .5rem;
-
-      &>a {
-        font-weight: $font-weight-bold;
-      }
-    }
-
-    ol {
-      padding-left: 0;
-    }
-
-    &>ol>li>a {
-      padding-left: 1rem;
-    }
-
-    &>ol>li>ol>li>a {
-      padding-left: 2rem;
-    }
-
-    &>ol>li>ol>li>ol>li>a {
-      padding-left: 3rem;
-    }
-
-    &>ol>li>ol>li>ol>li>ol>li>a {
-      padding-left: 4rem;
-    }
-
-    &>ol>li>ol>li>ol>li>ol>li>ol>li>a {
-      padding-left: 5rem;
-    }
-
-  }
-
-  li a:before {
-    counter-increment: section;
-    content: counters(section, ".") " ";
-  }
-
-  #toc-title {
-    font-weight: $font-weight-bold;
-    font-size: 1.3rem;
-  }
-
-}
-
-/* Styles for alert boxes */
-.alert {
-  &.note {
-    &:not(.omit-title):before {
-      content: "INFO: ";
-      font-weight: $font-weight-bold;
-    }
-    border: 2px solid $note;
-    border-left-width: 5px;
-    background: $note-background;
-  }
-
-  &.rationale {
-    &:not(.omit-title):before {
-      content: "RATIONALE: ";
-      font-weight: $font-weight-bold;
-    }
-    border: 2px solid $note;
-    border-left-width: 5px;
-    background: $note-background;
-  }
-
-  &.warning {
-    &:not(.omit-title):before {
-      content: "WARNING: ";
-      font-weight: $font-weight-bold;
-    }
-    border: 2px solid $warning;
-    border-left-width: 5px;
-    background: $warning-background;
-  }
-}
-
-/* Styles for sections that are rendered from data, such as HTTP APIs and event schemas */
-.rendered-data {
-  margin: 1rem 0 3rem 0;
-
-  details {
-
-    summary {
-      padding: .5rem 0;
-      list-style-position: outside;
-    }
-  }
-
-  .deprecated-inline {
-
-    &:after {
-      content: " — DEPRECATED";
-      color: $warning;
-      font-weight: $font-weight-bold;
-    }
-  }
-
-  h1 {
-    display: inline-block;
-    font-size: 1.3rem;
-
-    .endpoint {
-      color: $secondary;
-    }
-  }
-
-  h2 {
-    font-weight: $font-weight-bold;
-    font-size: 1.3rem;
-    margin: 3rem 0 .5rem 0;
-  }
-
-  h3 {
-    font-weight: $font-weight-bold;
-    font-size: 1.1rem;
-    margin: 1.5rem 0 .75rem 0;
-  }
-
-  h2 + table, h3 + table, h3 + div.highlight {
-    margin-top: 0;
-  }
-
-  hr {
-    border-bottom: 2px solid $dark;
-    margin-bottom: 1.5rem;
-  }
-
-  p {
-    max-width: 80%;
-  }
-
-  p code, table code {
-    background-color: $white;
-  }
-
-  table {
-    table-layout: fixed;
-    width: 100%;
-    margin: 4rem 0;
-
-    caption {
-      caption-side: top;
-      color: $dark;
-      font-size: 1rem;
-      font-weight: $font-weight-bold;
-    }
-
-    th, td, caption {
-      padding: 1rem;
-    }
-
-    th {
-      background-color: $white;
-    }
-
-    caption, tr {
-      background-color: $table-row-default;
-    }
-
-    tr:nth-child(even) {
-      background-color: $table-row-alternate;
-    }
-
-    &.basic-info, &.basic-info th, &.basic-info td {
-      table-layout: fixed;
-      margin: 1rem 0 .5rem 0;
-      background-color: $white;
-    }
-
-    &.basic-info th {
-      width: 15rem;
-    }
-
-    .col-name, .col-type, .col-status {
-      width: 25%;
-    }
-
-    .col-description {
-      width: 50%;
-    }
-
-    .col-status-description {
-      width: 75%;
-    }
-
-  }
-
-  pre {
-    border: 0;
-    border-left: solid 5px $secondary;
-  }
-
-  .http-api-method {
-    font-weight: $font-weight-bold;
-  }
-
-}
-
-/* Miscellaneous custom bits */
-
-/* Update link colours for MAtrix style */
-a, a:hover {
-  color: $secondary;
-}
-
-/* This is needed to stop the bottom of the Matrix icon from getting snipped off. */
-.td-navbar .navbar-brand svg {
-  height: 32px;
-}
-
-/* Give code samples and pre elements full-width */
-.td-content > .highlight, .td-content > pre {
-  max-width: 100%;
-}
-
-/* The default CSS applies a style for blockquotes but only to immediate children
-of .td-content. This applies the same style to any blockquotes that descend from
-.td-content. */
-.td-content blockquote {
-  padding: 0 0 0 1rem;
-  margin-bottom: $spacer;
-  color: $gray-600;
-  border-left: 6px solid $secondary;
-}
-
-/*
-Make padding symmetrical (this selector is used in the default styles to apply padding-left: 3rem)
-*/
-.pl-md-5, .px-md-5 {
-  padding-right: 3rem;
-}
-
-/* Adjust default styles for info banner */
-.pageinfo-primary {
-  max-width: 80%;
-  margin-left: 0;
-  border: 0;
-  border-left: solid 5px $secondary;
-  background-color: $gray-100;
-}
-
-.pageinfo-unstable {
-  background-image: url('../icons/unstable.png');
-  background-position: left 1rem center;
-  background-repeat: no-repeat;
-  padding-left: 100px;
-}
-
-/* Full-width tables */
-.td-content > table {
-  width: 100%;
-  display: table;
-}
diff --git a/attic/drafts/ancient_federated_versioning_design_notes.rst b/attic/drafts/ancient_federated_versioning_design_notes.rst
deleted file mode 100644
index 036989eb..00000000
--- a/attic/drafts/ancient_federated_versioning_design_notes.rst
+++ /dev/null
@@ -1,11 +0,0 @@
-Versioning is, like, hard for backfilling backwards because of the number of homeservers involved.
-
-The way we solve this is by doing versioning as an acyclic directed graph of PDUs. For backfilling purposes, this is done on a per context basis.
-When we send a PDU we include all PDUs that have been received for that context that hasn't been subsequently listed in a later PDU. The trivial case is a simple list of PDUs, e.g. A <- B <- C. However, if two servers send out a PDU at the same to, both B and C would point at A - a later PDU would then list both B and C.
-
-Problems with opaque version strings:
-    - How do you do clustering without mandating that a cluster can only have one transaction in flight to a given remote homeserver at a time.
-      If you have multiple transactions sent at once, then you might drop one transaction, receive another with a version that is later than the dropped transaction and which point ARGH WE LOST A TRANSACTION.
-    - How do you do backfilling? A version string defines a point in a stream w.r.t. a single homeserver, not a point in the context.
-
-We only need to store the ends of the directed graph, we DO NOT need to do the whole one table of nodes and one of edges.
diff --git a/attic/drafts/application_services.rst b/attic/drafts/application_services.rst
deleted file mode 100644
index 9c8b6b69..00000000
--- a/attic/drafts/application_services.rst
+++ /dev/null
@@ -1,244 +0,0 @@
-.. TODO
-  Sometimes application services need to create rooms (e.g. when lazy loading 
-  from room aliases). Created rooms need to have a user that created them, so 
-  federation works (as it relies on an entry existing in m.room.member). We should 
-  be able to add metadata to m.room.member to state that this user is an application 
-  service, a virtual user, etc.
-
-Application Services
-====================
-
-Overview
-========
-
-Application services provide a way of implementing custom serverside functionality
-on top of Matrix without the complexity of implementing the full federation API.
-By acting as a trusted service logically located behind an existing homeserver,
-Application services are decoupled from:
-
-* Signing or validating federated traffic or conversation history
-* Validating authorisation constraints on federated traffic
-* Managing routing or retry schemes to the rest of the Matrix federation
-
-As such, developers can focus entirely on implementing application logic rather
-than being concerned with the details of managing Matrix federation.
-
-Features available to application services include:
-
-* Privileged subscription to any events available to the homeserver
-* Synthesising virtual users
-* Synthesising virtual rooms
-* Injecting message history for virtual rooms
- 
-Features not provided by application services include:
-
-* Intercepting and filtering/modifying message or behaviour within a room
-  (this is a job for a Policy Server, as it requires a single logical focal
-  point for messages in order to consistently apply the custom business logic)
- 
-Example use cases for application services include:
-
-* Exposing existing communication services in Matrix
-
-  * Gateways to/from standards-based protocols (SIP, XMPP, IRC, RCS (MSRP), SIMPLE, Lync, etc)
-  * Gateways to/from closed services (e.g. WhatsApp)
-  * Gateways could be architected as:
-  
-    * Act as a virtual client on the non-Matrix network
-      (e.g. connect as multiple virtual clients to an IRC or XMPP server)
-    * Act as a server on the non-Matrix network
-      (e.g. speak s2s XMPP federation, or IRC link protocol)
-    * Act as an application service on the non-Matrix network
-      (e.g. link up as IRC services, or an XMPP component)
-    * Exposing a non-Matrix client interface listener from the AS
-      (e.g. listen on port 6667 for IRC clients, or port 5222 for XMPP clients)
-
-
-* Bridging existing APIs into Matrix
-   * e.g. SMS/MMS aggregator APIs
-   * Domain-specific APIs such as SABRE
-
-* Integrating more exotic content into Matrix
-   * e.g. MIDI<->Matrix gateway/bridge
-   * 3D world <-> Matrix bridge
-
-* Application services:
-   * Search engines (e.g. elasticsearch search indices)
-   * Notification systems (e.g. send custom pushes for various hooks)
-   * VoIP Conference services
-   * Text-to-speech and Speech-to-text services
-   * Signal processing
-   * IVR
-   * Server-machine translation
-   * Censorship service
-   * Multi-User Gaming (Dungeons etc)
-   * Other "constrained worlds" (e.g. 3D geometry representations)
-
-     * applying physics to a 3D world on the serverside
-
-       * (applying gravity and friction and air resistance... collision detection)
-       * domain-specific merge conflict resolution of events
-
-   * Payment style transactional usecases with transactional guarantees
-
-Architecture Outline
-====================
-
-The application service registers with its host homeserver to offer its services.
-
-In the registration process, the AS provides:
-
-* Credentials to identify itself as an approved application service for that HS
-* Details of the namespaces of users and rooms the AS is acting on behalf of and
-  "subscribing to"
-* Namespaces are defined as a list of regexps against which to match room aliases,
-  room IDs, and user IDs. Regexps give the flexibility to say, sub-domain MSISDN
-  ranges per AS, whereas a blunt prefix string does not. These namespaces are further
-  configured by setting whether they are ``exclusive`` or not. An exclusive namespace
-  prevents entities other than the aforementioned AS from creating/editing/deleting
-  entries within that namespace. This does not affect the visibility/readability of
-  entries within that namespace (e.g. it doesn't prevent users joining exclusive
-  aliases, or ASes from listening to exclusive aliases, but does prevent both users
-  and ASes from creating/editing/deleting aliases within that namespace).
-* There is overlap between selecting events via the csv2 Filter API and subscribing
-  to events here - perhaps subscription involves passing a filter token into the
-  registration API.
-* A URL base for receiving requests from the HS (as the AS is a server,
-  implementers expect to receive data via inbound requests rather than
-  long-poll outbound requests)
-
-On HS handling events to unknown users:
-
-* If the HS receives an event for an unknown user who is in the namespace delegated to 
-  the AS, then the HS queries the AS for the profile of that user.  If the AS
-  confirms the existence of that user (from its perspective), then the HS
-  creates an account to represent the virtual user.
-* The namespace of virtual user accounts should conform to a structure like
-  ``@.irc.freenode.Arathorn:matrix.org``.  This lets Matrix users communicate with
-  foreign users who are not yet mapped into Matrix via 3PID mappings or through
-  an existing non-virtual Matrix user by trying to talk to them via a gateway.
-* The AS can alternatively preprovision virtual users using the existing CS API
-  rather than lazy-loading them in this manner.
-* The AS may want to link the matrix ID of the sender through to their 3PID in
-  the remote ecosystem.  E.g. a message sent from ``@matthew:matrix.org`` may wish
-  to originate from Arathorn on irc.freenode.net in the case of an IRC bridge.
-  It's left as an AS implementation detail as to how the user should authorise
-  the AS to act on its behalf.
-
-On HS handling events to unknown rooms:
-
-* If the HS receives an invite to an unknown room which is in the namespace
-  delegated to the AS, then the HS queries the AS for the existence of that room.
-  If the AS confirms its existence (from its perspective), then the HS creates
-  the room.
-* The initial state of the room may be populated by the AS by querying an
-  initialSync API (probably a subset of the CS initialSync API, to reuse the
-  same pattern for the equivalent function).  As messages have to be signed
-  from the point of ``m.room.create``, we will not be able to back-populate
-  arbitrary history for rooms which are lazy-created in this manner, and instead
-  have to chose the amount of history to be synchronised into the AS as a one-off.
-* If exposing arbitrary history is required, then:
-   
-  * either: the room history must be preemptively provisioned in the HS by the AS via
-    the CS API (TODO: meaning the CS API needs to support massaged
-    timestamps), resulting in conversation history being replicated between
-    the HS and the source store.
-  * or: the HS must delegate conversation storage entirely to the
-    AS using a Storage API (not defined here) which allows the existing
-    conversation store to back the HS, complete with all necessary Matrix
-    metadata (e.g. hashes, signatures, federation DAG, etc).  This obviously
-    increases the burden of implementing an AS considerably, but is the only
-    option if the implementer wants to avoid duplicating conversation history
-    between the external data source and the HS.
-
-On HS handling events to existing users and rooms:
-
-* If the HS receives an event for a user or room that already exists (either
-  provisioned by the AS or by normal client interactions), then the message
-  is handled as normal.
-* Events in the namespaces of rooms and users that the AS has subscribed to
-  are pushed to the AS using the same pattern as the federation API (without
-  any of the encryption or federation metadata).  This serves precisely the
-  same purpose as the CS event stream and has the same data flow semantics
-  (and indeed an AS implementer could chose to use the CS event stream instead)
-  
-  * Events are linearised to avoid the AS having to handle the complexity of
-    linearisation, and because if linearisation is good enough for CS, it
-    should be good enough for AS. Should the AS require non-linearised events
-    from Matrix, it should implement the federation API rather than the AS API
-    instead.
-  * HS->AS event pushes are retried for reliability with sequence numbers
-    (or logical timestamping?) to preserve the linearisation order and ensure
-    a reliable event stream.
-  * Clustered HSes must linearise just as they do for the CS API.  Clustered
-    ASes must loadbalance the inbound stream across the cluster as required.
-
-On AS relaying events from unknown-to-HS users:
-
-* AS injects the event to the HS using the CS API, irrespective of whether the
-  target user or room is known to the HS or not.  If the HS doesn't recognise
-  the target it goes through the same lazy-load provisioning as per above.
-* The reason for not using a subset of the federation API here is because it
-  allows AS developers to reuse existing CS SDKs and benefit from the more
-  meaningful error handling of the CS API.  The sending user ID must be
-  explicitly specified, as it cannot be inferred from the access_token, which
-  will be the same for all AS requests.
-
-  * TODO: or do we maintain a separate ``access_token`` mapping?  It seems like
-    unnecessary overhead for the AS developer; easier to just use a single
-    privileged ``access_token`` and just track which ``user_id`` is emitting events?
-  * If the AS is spoofing the identity of a real (not virtual) matrix user,
-    we should actually let them log themselves in via OAuth2 to give permission
-    to the AS to act on their behalf.
-  * We can't auth gatewayed virtual users from 3rd party systems who are being
-    relayed into Matrix, as the relaying is happening whether the user likes it
-    or not.  Therefore we do need to be able to spoof sender ID for virtual users.
- 
-On AS relaying events in unknown-to-HS rooms:
-
-* See above.
-
-On AS publishing aliases for virtual rooms:
-
-* AS uses the normal alias management API to preemptively create/delete public
-  directory entries for aliases for virtual rooms provided by the AS.
-* In order to create these aliases, the underlying room ID must also exist, so
-  at least the ``m.room.create`` of that room must also be prepopulated.  It seems
-  sensible to prepopulate the required initial state and history of the room to
-  avoid a two-phase prepopulation process.
-   
-On unregistering the AS from the HS:
-
-* An AS must tell the HS when it is going offline in order to stop receiving
-  requests from the HS.  It does this by hitting an API on the HS.
-
-AS Visibility:
-
-* If an AS needs to sniff events in a room in order to operate on them (e.g.
-  to act as a search engine) but not inject traffic into the room, it should
-  do so by subscribing to the relevant events without actually joining the room.
-* If the AS needs to participate in the room as a virtual user (e.g. an IVR
-  service, or a bot, or a gatewayed virtual user), it should join the room
-  normally.
-* There are rare instances where an AS may wish to participate in a room
-  (including inserting messages), but be hidden from the room list - e.g. a
-  conferencing server focus bot may wish to join many rooms as the focus and
-  both listen to VoIP setups and inject its own VoIP answers, without ever
-  being physically seen in the room.  In this scenario, the user should set
-  its presence to 'invisible', a state that HSes should only allow AS-authed
-  users to set.
-   
-E2E Encryption
-
-* The AS obviously has no visibility to E2E encrypted messages, unless it is
-  explicitly added to an encrypted room and participates in the group chat
-  itself.
-
-Extensions to CS API
-====================
-
-* Ability to assert the identity of the virtual user for all methods.
-* Ability to massage timestamps when prepopulating historical state and
-  messages of virtual rooms (either by overriding ``origin_server_ts`` (preferred) or
-  adding an ``as_ts`` which we expect clients to honour)
-* Ability to delete aliases (including from the directory) as well as create them.
diff --git a/attic/drafts/data_flows.rst b/attic/drafts/data_flows.rst
deleted file mode 100644
index 4e8cd09a..00000000
--- a/attic/drafts/data_flows.rst
+++ /dev/null
@@ -1,222 +0,0 @@
-Data flows for use cases
-========================
-
-::
-
- <- Data from server to client
- -> Data from client to server
-
-Instant Messaging
------------------
-
-Without storage
-~~~~~~~~~~~~~~~
-
-::
-
- Home screen
-   Data required on load:
-    <- For each room the user is joined: Name, topic, # members, last message, room ID, aliases
-   Data required when new message arrives for a room:
-    <- Room ID, message content, sender (user ID, display name, avatar url)
-   Data required when someone invites you to a room:
-    <- Room ID, sender (user ID, display name, avatar url), Room Name, Room Topic
-   Data required when you leave a room on another device:
-    <- Room ID
-   Data required when you join a room on another device:
-    <- Name, topic, # members, last message, room ID, aliases
-   Data required when your profile info changes on another device:
-    <- new profile info e.g. avatar, display name, etc.
-    
-   Creating a room
-    -> Invitee list of user IDs, public/private, name of room, alias of room, topic of room
-    <- Room ID
-   
-   Joining a room (and dumped into chat screen on success)
-    -> Room ID / Room alias
-    <- Room ID, Room aliases (plural), Name, topic, member list (f.e. member: user ID, 
-       avatar, presence, display name, power level, whether they are typing), enough 
-       messages to fill screen (and whether there are more)
-      
- Chat Screen
-   Data required when member name changes:
-    <- new name, room ID, user ID, when in the context of the room did this occur
-   Data required when the room name changes:
-    <- new name, room ID, old room name?
-   Invite a user:
-    -> user ID, room ID
-    <- display name / avatar of user invited (if known)
-   Kick a user:
-    -> user ID, room ID
-    <- what message it came after
-   Leave a room:
-    -> room ID
-    <- what message it came after
-      
-   Send a message
-    -> Message content, room ID, message sequencing (eg sending my 1st, 2nd, 3rd msg)
-    <- actual content sent (if server mods it), what message it comes after (to correctly
-       display the local echo)
-      
-    Place a call (receive a call is just reverse)
-     <- turn servers
-     -> SDP offer
-     -> Ice candidates (1 by 1; trickling)
-     <- SDP answer
-     <- Ice candidates
-    
-    Scrolling back (infinite scrolling)
-     -> Identifier for the earliest message, # requested messages
-     <- requested messages (f.e change in display name, what the old name was), whether
-        there are more.
-
-
-With storage
-~~~~~~~~~~~~
-::
-    
-  Home Screen
-    On Load
-     -> Identifier which tells the server the client's current state (which rooms it is aware
-        of, which messages it has, what display names for users, etc..)
-     <- A delta from the client's current state to the current state on the server (e.g. the
-        new rooms, the *latest* message if different, the changed display names, the new 
-        invites, etc). f.e Room: Whether the cache of the room that you have has been replaced 
-        with this new state.
-        
-    Pre-load optimisation (not essential for this screen)
-      -> Number of desired messages f.e room to cache
-      <- f.e Room: the delta OR the entire state
-     
-
-Bug Tracking
-------------
-::
-
-  Landing Page
-    On Load
-     <- Issues assigned to me, Issues I'm watching, Recent activity on other issues includes
-        comments, list of projects
-    
-    Search for an issue (assume text)
-     -> Search string
-     <- List of paginated issues
-       Request page 2:
-        -> Page number requested
-        <- Page of paginated issues
-  
-  Issue Page
-    On Load
-     -> Issue ID and Project ID (equiv to Room)
-     <- Issue contents e.g. priority, resolution state, etc. All comments e.g. user ID, 
-        comment text, timestamp. Entire issue history e.g. changes in priority
-     
-    Post a comment
-     -> Issue ID, comment content, Project ID (equiv to Room)
-     <- actual content sent (if modded), what comment it comes after
-    
-    Set issue priority
-     -> Issue ID, Project ID, desired priority
-     <- What action in the history it came after
-     
-    Someone else sets issue priority
-     <- Issue ID, Project ID, new priority, where in the history
-
-
-Mapping model use cases to matrix models (Room, Message, etc)
-=============================================================
-
-To think about:
- - Do we want to support the idea of forking off new rooms from existing ones? This
-   and forums could benefit from it.
-
-Bug tracking UI
----------------
-::
-
- Projects => Rooms
- Issues => Message Events
- Comments => Message Events (relates_to key)
-
-Projects:
- - Unlikely that there will be 100,000s of issues, so having to pull in all the issues for a project is okay.
- - Permissions are usually per project and this Just Works.
- - New issues come in automatically and Just Work.
- - Can have read-only members
-
-Issues:
- - Don't really want 1 Room per Issue, else you can have thousands of Rooms PER PROJECT, hence choice for    
-   Issues as Messages. Don't need to join a room for each issue.
- - Idea of issue owner is clear (sender of the message)
- - Updating issues requires an additional event similar to comments (with ``relates_to``)? Could possibly
-   be state events? Don't really want all the history if say the priority was changed 1000 times, just want
-   the current state of the key.
-
-Comments:
- - Additional event with ``relates_to`` key.
-
-
-Forum
------
-::
-
- Forum => Room (with pointers to Board Rooms)
- Boards => Room (with pointers to Thread Rooms)
- Threads => Room
- Messages => Message Events
-
-Forum:
- - Contains 10s of Boards.
- - Contains special Message Events which point to different rooms f.e Board.
-
-Boards:
- - Contains 100s of Threads.
- - Contains special Message Events which point to different rooms f.e. Thread.
-
-Threads:
- - Contains 100s of Messages.
-
-Can't do this nicely with the current Federation API because you have loads of
-Rooms and what does posting a message look like? Creating a thread is done by..?
-The user who is posting cannot create the thread because otherwise they would be
-the room creator and have ultimate privileges. So it has to be created by a bot
-of some kind which ties into auth (Application services?). To follow a board,
-you need a bot to join the Board Room and then watch it for changes... 
-
-Fundamental problem with forums is that there is only 1 PDU graph per room and
-you either have to pull in lots of graphs separately or one graph and filter it
-separately to get to the desired sub set of data. You have to subscribe into a
-lot of graphs if you subscribe to a board... If you have the entire board...
-good luck scrollbacking a particular thread.
-
-
-Google+ Community
------------------
-::
-
- Community => Room (with pointers to Category Rooms)
- Category => Room
- Post => Message Events
- Comment => Message Events (relates_to key)
-
-Community:
- - Contains 10s of categories.
- - Contains special Message Events which point to different rooms f.e Category.
- - Moderators of the community are mods in this room. They are in charge of making
-   new categories and the subsequent rooms. Can get a bit funky if a mod creates a
-   category room without the same permissions as the community room... but another
-   mod can always delete the pointer to the buggy category room and make a new one.
- - Do we want to support the idea of forking off new rooms from existing ones? This
-   and forums could benefit from it.
-
-Category:
- - Contains 1000s of posts.
- - Same permissions as the community room. How to enforce? Fork off the community
-   room?
-
-Posts:
- - Contains 10s of comments.
-
-This is similar to forums but you can more reasonably say "screw it, pull in the
-entire community of posts."
-
diff --git a/attic/drafts/erik-model.rst b/attic/drafts/erik-model.rst
deleted file mode 100644
index b2f9908d..00000000
--- a/attic/drafts/erik-model.rst
+++ /dev/null
@@ -1,141 +0,0 @@
-This is a standalone description of the data architecture of Synapse. There is a
-lot of overlap with the current specification, so it has been split out here for
-posterity. Hopefully all the important bits have been merged into the relevant
-places in the main spec.
-
-
-Model
------
-
-Overview
-~~~~~~~~
-
-Matrix is used to reliably distribute data between sets of `users`.
-
-Users are associated with one of many matrix `servers`. These distribute,
-receive and store data on behalf of its registered users. Servers can be run on
-any host accessible from the internet.
-
-When a user wishes to send data to users on different servers the local server
-will distribute the data to each remote server. These will in turn distribute
-to their local users involved.
-
-A user sends and receives data using one or more authenticated `clients`
-connected to his server. Clients may persist data locally or request it when
-required from the server.
-
-Events
-~~~~~~
-An event is a collection of data (the `payload`) and metadata to be distributed
-across servers and is the primary data unit in Matrix.  Events are extensible
-so that clients and servers can add extra arbitrary fields to both the payload
-or metadata.
-
-Events are distributed to interested servers upon creation. Historical events
-may be requested from servers; servers are not required to produce all
-or any events requested.
-
-All events have a metadata `type` field that is used by client and servers to
-determine how the payload should be processed and used. There are a number of
-types reserved by the protocol for particular uses, but otherwise types may be
-defined by applications, clients or servers for their own purposes.
-
-.. TODO : Namespacing of new types.
-
-Graph
-+++++
-Each event has a list of zero or more `parent` events. These relations form
-directed acyclic graphs of events called `event graphs`. Every event graph has
-a single root event, and each event graph forms the basis of the history of a
-matrix room.
-
-Event graphs give a partial ordering of events, i.e. given two events one may
-be considered to have come before the other if one is an ancestor of the other.
-Since two events may be on separate branches, not all events can be compared in
-this manner.
-
-Every event has a metadata `depth` field that is a positive integer that is
-strictly greater than the depths of any of its parents. The root event should
-have a depth of 1.
-
-[Note: if one event is before another, then it must have a strictly smaller
-depth]
-
-Integrity
-+++++++++
-
-.. TODO: Specify the precise subset of essential fields
-
-Portions of events will be signed by one or more servers or clients. The parent
-relations, type, depth and payload (as well as other metadata fields that will
-be specified) must be signed by the originating server. [Note: Thus, once an
-event is distributed and referenced by later events, they effectively become
-immutable].
-
-The payload may also be encrypted by clients, except in the case where the
-payload needs to be interpreted by the servers. A list of event types that
-cannot have an encrypted payload are given later.
-
-
-State
-~~~~~
-Event graphs may have meta information associated with them, called `state`.
-State can be updated over time by servers or clients, subject to
-authorisation.
-
-The state of a graph is split into `sections` that can be atomically updated
-independently of each other.
-
-State is stored within the graph itself, and can be computed by looking at the
-graph in its entirety. We define the state at a given event to be the state of
-the sub graph of all events "before" and including that event.
-
-Some sections of the state may determine behaviour of the protocol, including
-authorisation and distribution. These sections must not be encrypted.
-
-State Events
-++++++++++++
-`State events` are events that update a section of state data for a room. These
-state events hold all the same properties of events, and are part of the event
-graph. The payload of the event is the replacement value for the particular
-section of state being updated.
-
-State events must also include a `state_key` metadata field. The pair of fields
-type and state_key uniquely defines the section of state that is to be updated.
-
-State Resolution
-++++++++++++++++
-A given state section may have multiple state events associated with it in a
-given graph. A consistent method of selecting which state event takes
-precedence is therefore required.
-
-This is done by taking the latest state events, i.e. the set of events that are
-either incomparable or after every other event in the graph. A state resolution
-algorithm is then applied to this set to select the single event that takes
-precedence.
-
-The state resolution algorithm must be transitive and not depend on server
-state, as it must consistently select the same event irrespective of the server
-or the order the events were received in.
-
-State Dictionary
-++++++++++++++++
-The state dictionary is the mapping from sections of state to the state events
-which set the section to its current value.  The state dictionary, like the
-state itself, depends on the events currently in the graph and so is updated
-with each new event received.
-
-Since the sections of the state are defined by the pair of strings from the
-type and state_key of the events that update them, the state dictionary can be
-defined as a mapping from the pair (type, state_key) to a state event with
-those values in the graph.
-
-Deleting State
-++++++++++++++
-State sections may also be deleted, i.e. removed from the state dictionary. The
-state events will still be present in the event graph.
-
-This is done by sending a special state event indicating that the given entry
-should be removed from the dictionary. These events follow the same rules for
-state resolution, with the added requirement that it loses all conflicts.
-[Note: This is required to make the algorithm transitive.]
diff --git a/attic/drafts/erikj_federation.rst b/attic/drafts/erikj_federation.rst
deleted file mode 100644
index 86d5acd4..00000000
--- a/attic/drafts/erikj_federation.rst
+++ /dev/null
@@ -1,253 +0,0 @@
-Federation
-==========
-.. sectnum::
-.. contents:: Table of Contents
-
-
-Auth chain
-~~~~~~~~~~
-
-The *auth chain* for an event is the recursive list of auth events and the auth
-chain for those auth events.
-
-.. Note:: The auth chain for an event gives all the information a server needs
-          to accept an event. However, being given an auth chain for an event
-          that appears valid does not mean that the event might not later be
-          rejected. For example if we discover that the sender had been banned
-          between the join event listed in the auth events and the event being
-          authed.
-
-**TODO**: Clean the above explanations up a bit.
-
-
-Auth chain resolution
-~~~~~~~~~~~~~~~~~~~~~
-
-If an auth check fails, or if we get told something we accepted should have
-been rejected, we need to try and determine who is right.
-
-If two servers disagree about the validity of the auth events, both should
-inform the other of what they think the current auth chain is. If either are
-missing auth events that they know are valid (through authorization and state
-resolution) they process the missing events as usual.
-
-If either side notice that the other has accepted an auth events we think
-should be rejected (for reasons *not* in their auth chain), that server should
-inform the other with suitable proof.
-
-The proofs can be:
-
-- An *event chain* that shows an auth event is *not* an ancestor of the event.
-  This can be done by giving the full ancestor chains up to the depth of the
-  invalid auth event.
-- Given an event (and event chain?) showing that authorization had been revoked.
-
-If a server discovers it cannot prove the other side is wrong, then it accepts
-that the other is correct; i.e. we always accept that the other side is correct
-unless we can prove otherwise.
-
-
-Constructing a new event
-------------------------
-
-    **TODO**
-
-When constructing a new event, the server should insert the following fields:
-
-- ``prev_events``: The list of event ids of what the server believes are the
-  current leaf nodes of the event graph (i.e., nodes that have been received
-  but are yet to be referenced by another event).
-- ``depth``: An integer one greater than the maximum depth of the event's
-  previous events.
-- ``auth_events``: The list of event ids that authorizes this event. This
-  should be a subset of the current state.
-- ``origin_server_ts``: The time the server created the event.
-- ``origin``: The name of the server.
-
-
-Signing and Hashes
-~~~~~~~~~~~~~~~~~~
-
-    **TODO**
-
-Validation
-----------
-
-    **TODO**
-
-Domain specific string
-    A string of the form ``<prefix><localpart>:<domain>``, where <prefix> is a
-    single character, ``<localpart>`` is an arbitrary string that does not
-    include a colon, and `<domain>` is a valid server name.
-
-``room_id``
-    A domain specific string with prefix ``!`` that is static across all events
-    in a graph and uniquely identifies it. The ``domain`` should be that of the
-    homeserver that created the room (i.e., the server that generated the
-    first ``m.room.create`` event).
-
-``sender``
-    The entity that logically sent the event. This is usually a user id, but
-    can also be a server name.
-
-User Id
-    A domain specific string with prefix ``@`` representing a user account. The
-    ``domain`` is the homeserver of the user and is the server used to contact
-    the user.
-
-Joining a room
---------------
-
-If a user requests to join a room that the server is already in (i.e. the a
-user on that server has already joined the room) then the server can simply
-generate a join event and send it as normal.
-
-If the server is not already in the room it needs to will need to join via
-another server that is already in the room. This is done as a two step process.
-
-First, the local server requests from the remote server a skeleton of a join
-event. The remote does this as the local server does not have the event graph
-to use to fill out the ``prev_events`` key in the new event. Critically, the
-remote server does not process the event it responded with.
-
-Once the local server has this event, it fills it out with any extra data and
-signs it. Once ready the local server sends this event to a remote server
-(which could be the same or different from the first remote server), this
-remote server then processes the event and distributes to all the other
-participating servers in that room. The local server is told about the
-current state and complete auth chain for the join event. The local server
-can then process the join event itself.
-
-
-.. Note::
-   Finding which server to use to join any particular room is not specified.
-
-
-Inviting a user
----------------
-
-To invite a remote user to a room we need their homeserver to sign the invite
-event. This is done by sending the event to the remote server, which then signs
-the event, before distributing the invite to other servers.
-
-
-Handling incoming events
-------------------------
-
-When a server receives an event, it should:
-
-#. Check if it knows about the room. If it doesn't, then it should get the
-   current state and auth events to determine whether the server *should* be in
-   the room. If so continue, if not drop or reject the event
-#. If the server already knew about the room, check the prev events to see if
-   it is missing any events. If it is, request them. Servers should limit how
-   far back they will walk the event graph for missing events.
-#. If the server does not have all the prev events, then it should request the
-   current state and auth events from a server.
-
-
-Failures
---------
-
-A server can notify a remote server about something it thinks it has done
-wrong using the failures mechanism. For example, the remote accepted an event
-the local think it shouldn't have.
-
-A failure has a severity level depending on the action taken by the local
-server. These levels are:
-
-``FATAL``
-    The local server could not parse the event, for example due to a missing
-    required field.
-
-``ERROR``
-    The local server *could* parse the event, but it was rejected. For example,
-    the event may have failed an authorization check.
-
-``WARN``
-    The local server accepted the event, but something was unexpected about it.
-    For example, the event may have referenced another event the local server
-    thought should be rejected.
-
-A failure also includes several other fields:
-
-``code``
-    A numeric code (to be defined later) indicating a particular type of
-    failure.
-
-``reason``
-    A short string indicating what was wrong, for diagnosis purposes on the
-    remote server.
-
-``affected``
-    The event id of the event this failure is responding to. For example, if
-    an accepted event referenced a rejected event, this would point to the
-    accepted one.
-
-``source``
-    The event id of the event that was the source of this unexpected behaviour.
-    For example, if an accepted event referenced a rejected event, this would
-    point to the rejected one.
-
-
-Appendix
-========
-
-    **TODO**
-
-Example event:
-
-.. code::
-
-    {
-        "auth_events": [
-            [
-                "$14187571482fLeia:localhost:8480",
-                {
-                    "sha256": "kiZUclzzPetHfy0rVoYKnYXnIv5VxH8a4996zVl8xbw"
-                }
-            ],
-            [
-                "$14187571480odWTd:localhost:8480",
-                {
-                    "sha256": "GqtndjviW9yPGaZ6EJfzuqVCRg5Lhoyo4YYv1NFP7fw"
-                }
-            ],
-            [
-                "$14205549830rrMar:localhost:8480",
-                {
-                    "sha256": "gZmL23QdWjNOmghEZU6YjqgHHrf2fxarKO2z5ZTbkig"
-                }
-            ]
-        ],
-        "content": {
-            "body": "Test!",
-            "msgtype": "m.text"
-        },
-        "depth": 250,
-        "event_id": "$14207181140uTFlx:localhost:8480",
-        "hashes": {
-            "sha256": "k1nuafFdFvZXzhb5NeTE0Q2Jkqu3E8zkh3uH3mqwIxc"
-        },
-        "origin": "localhost:8480",
-        "origin_server_ts": 1420718114694,
-        "prev_events": [
-            [
-                "$142071809077XNNkP:localhost:8480",
-                {
-                    "sha256": "xOnU1b+4LOVz5qih0dkNFrdMgUcf35fKx9sdl/gqhjY"
-                }
-            ]
-        ],
-        "room_id": "!dwZDafgDEFTtpPKpLy:localhost:8480",
-        "sender": "@bob:localhost:8480",
-        "signatures": {
-            "localhost:8480": {
-                "ed25519:auto": "Nzd3D+emFBJJ4LCTzQEZaKO0Sa3sSTR1fGpu8OWXYn+7XUqke9Q1jYUewrEfxb3lPxlYWm/GztVUJizLz1K5Aw"
-            }
-        },
-        "type": "m.room.message",
-        "unsigned": {
-            "age": 500
-        }
-    }
diff --git a/attic/drafts/flows_and_auth.rst b/attic/drafts/flows_and_auth.rst
deleted file mode 100644
index 5fd6b8f1..00000000
--- a/attic/drafts/flows_and_auth.rst
+++ /dev/null
@@ -1,146 +0,0 @@
-Failures
---------
-
-A server may encouter an error when trying to process an event received from a
-remote server. In these cases the server may send a `failure` to the remote.
-
-A `failure` references both the event that it was trying to process and the
-event that triggered the processing. For example, a failure may be emitted if
-one of the parents of the received events was not authorized.
-
-A failure also includes a `severity` field that indicates what action was taken
-by the server. There are three valid values:
-
-  * `Fatal`: The server failed to parse the event. The event is dropped by the
-    server as well as all descendants.
-  * `Error`: The server rejected the event, for example due to authorization.
-    That event is dropped, but descendants may be accepted.
-  * `Warn`: The server accepted all events, but believes the remote did
-    something wrong. For example, references an event the local server believes
-    is unauthorized.
-
-
-Data Flows
-----------
-
-Invite
-++++++
-
-To invite a remote user to an existing room a server distributes an invitiation
-event signed by the remote invitee's server (allowing other servers in the room
-to be sure that the invitee's server had seen the invite.)
-
-To get the remote server's signature on the event it is sent in a special
-request to the remote server, which then responds with the signed invite (if it
-accepted it as valid.) The remote server may respond with an error if the user
-does not exist.
-
-Join
-++++
-
-If a server is already in the room it can simply emit a join event for the user
-joining.
-
-If the server is not currently in the room it needs to join via a remote server
-in the room, therefore to join a room a server must have have both the room id
-and a list of remote servers that may be in the room.
-
-To join via a remote server the local server first requests a valid join event
-for the room from the remote server. The local then fills it out, signs it, and
-then sends the final join event to the remote server for distribution. The
-remore responds to this second request with the current state of the room at
-the join request and the auth chain for that state.
-
-
-Authorization
--------------
-
-The authorization for an event depends solely on the current state at that
-event. If a policy server is configured for the room, then the authorization
-for the event is the signature of the policy server.
-
-The state events that affect whether an event is authorized are called
-`protocol events`, and are:
-
-  * `m.room.create`
-  * `m.room.power_levels`
-  * `m.room.member`
-  * `m.room.join_rules`
-
-All events *must* list all the protocol events that grant them their
-authorization. All origin servers *must* serve up on request the full graph of
-protocol events for all events it has sent. The graph of protocol events is the
-connected directed acyclic graph with events as nodes and the list of protocol
-events their edges.
-
-
-Join
-++++
-
-A user may join a room if:
-
-  * The join rule is "public".
-  * The join rule is "invite" and the user has been invited by a user that has
-    already joined.
-  * The user is in the `may_join` list.
-
-
-Invite
-++++++
-
-A user may invite another user if the join rule is either "public" or "invite"
-and the user has joined the room.
-
-
-Creation
-++++++++
-
-A `m.room.create` must be the first event in the room.
-
-
-Ban, Kick and Redaction
-+++++++++++++++++++++++
-
-To ban or kick another user in the room, or to redact an event, then the user
-must have a power level of at least that specificied in the
-`m.room.power_level` event for kick, ban and redactions.
-
-
-Other Events
-++++++++++++
-
-A user may send an event if all the following hold true:
-
-  * The user is in the room.
-  * If the type of the event is listed in the `m.room.power_levels`, then the
-    user must have at least that power level. Otherwise, the user must have a
-    power level of at least `events_default` or `state_default`, depending on
-    if the event is a message or state event respectively.
-
-
-Unauthorized Events
--------------------
-
-An unauthorized event should not be accepted into the event graph, i.e. new
-events should not reference any unauthorized events. There are situations where
-this can happen and so it is not considered an error to include an unauthorized
-event in the event graph. It is an error for events to refer unauthorized
-events in their `auth_events` section and will in turn be considered
-unauthorized.
-
-A server may choose to store only the redacted form of an unauthorized event if
-it is included in the event graph.
-
-A server may emit a warning to a remote server if it references an event it
-considers unauthorized.
-
-
-State and Authorization Querying
---------------------------------
-
-A local server may become aware that it and a remote server's view of the
-current state are inconsistent. The local server may then send its current
-state to the remote, which responds with its view of the current state. Both
-servers should then recompute the local state. If they are conforming
-implementations then they will reach the same conclusions.
-
diff --git a/attic/drafts/general_api.rst b/attic/drafts/general_api.rst
deleted file mode 100644
index baad3901..00000000
--- a/attic/drafts/general_api.rst
+++ /dev/null
@@ -1,1186 +0,0 @@
-Table of Contents
-=================
-
-.. contents:: Table of Contents
-.. sectnum::
-
-Summary of changes from v1
-==========================
-
-Version 2.0
------------
-- Event filtering (type/room/users, federation-style events)
-- Incremental initial syncing
-- Deleting state
-- Race conditions on event stream / actions
-- Out-of-order events
-- Published room API: support searching remote HSes.
-- Account management: specifically the concept of devices so push works.
-- Multiple devices
-   - Presence status unioning: is partially specced (needs more eyes).
-   - Syncing data between multiple devices: is specced.  
-   - TODO: Push for offline devices.
-
-Lower priority
-~~~~~~~~~~~~~~
-- Capabilities
-- Editing/updating messages (updates key)
-- Room alias API
-
-Version 2.1
------------
-- Comments (relates_to key)
-- Contextual messages (view messages around an arbitrary message)
-- Rejecting invites
-- State event pagination (e.g. from initial sync)
-- Initial sync pagination (e.g. X most recent rooms)
- 
-Out of scope
-------------
-- Searching messages
-
-Version 2 API
-=============
-
-Legend:
- - ``[TODO]``: API is not in this document yet.
- - ``[ONGOING]``: API is proposed but needs more work. There are known issues 
-   to be addressed.
- - ``[Draft]``: API is proposed and has no outstanding issues to be addressed, 
-   but needs more feedback.
- - ``[Final]``:  The API has no outstanding issues.
-
-This contains the formal proposal for Matrix Client-Server API v2. This API 
-would completely replace v1. It is a general API, not specific to any particular 
-protocol e.g. HTTP. The following APIs will remain unchanged from v1:
-
-- Content repository API
-
-This version will change the path prefix for HTTP:
- - Version 1: ``/_matrix/client/api/v1``
- - Version 2: ``/_matrix/client/v2``
- 
-Note the lack of the ``api`` segment. This is for consistency between other 
-homeserver path prefixes.
-
-Terminology:
- - ``Chunk token`` : An opaque string which can be used to return another chunk
-   of results. For example, the initial sync API and scrollback/contextual 
-   windowing APIs. If the total size of the data set is unknown, it should
-   return a chunk token to navigate it.
- - ``Filter token`` : An opaque string representing the inputs originally given
-   to the filter API.
- - ``Pagination token`` : An opaque string used for pagination requests. For
-   example, the published room list API. The size of the data set is known (e.g.
-   because a snapshot of it was taken) and you can do "Page X of Y" style 
-   navigation.
-
- 
-Filter API ``[Draft]``
-------------------------
-
-Inputs:
- - Which event types (incl wildcards)
- - Which room IDs
- - Which user IDs (for profile/presence)
- - Whether you want federation-style event JSON
- - Whether you want coalesced ``updates`` events
- - Whether you want coalesced ``relates_to`` events (and the max # to coalesce,
-   and the relationship types, and the sort order)
- - limit= param? (XXX: probably not; this should be done in the query itself)
- - Which keys to return for events? e.g. no ``origin_server_ts`` if you don't 
-   show timestamps (n.b. encrypted keys can't be filtered out)
-Outputs:
- - An opaque token which represents the inputs, the "filter token".
-Notes:
- - The token may expire, in which case you would need to request another one.
- - The token could be as simple as a concatenation of the requested filters with
-   a delimiter between them.
- - Omitting the token on APIs results in ALL THE THINGS coming down.
- - Clients should remember which token they need to use for which API.
- - It should be possible to define negative filters (e.g. not presence)
- - HTTP note: If the filter API is a separate endpoint, then you could easily 
-   allow APIs which use filtering to ALSO specifiy query parameters to tweak the
-   filter.
-
-Global initial sync API ``[Draft]``
--------------------------------------
-.. NOTE::
- - The output to this should also have something like:
-    For each room the user is invited to:
-      - The invite event
-      - Other state info (e.g. room name, topic, join_rules to know if pubilc)
-      - # members?
-
-    so clients know more information about the room other than the user_id of the
-    inviter, timestamp and the room ID.
-
- v2.1:
-   - Will need some form of state event pagination like we have for message 
-     events to handle large amounts of state events for a room. Need to think of
-     the consequences of this: you may not get a ``m.room.member`` for someone's 
-     message and so cannot display their display name / avatar. Do we want to 
-     provide pagination on an event type basis?
-   - Handle paginating initial sync results themselves (e.g. 10 most recent 
-     rooms)
-
-Inputs:
- - A way of identifying the user (e.g. access token, user ID, etc)
- - Filter to apply (e.g. a single room ID for a 'room initial sync')
- - Chunk token (for incremental deltas)
-Outputs:
- - For each room the user is joined:
-    - Requested state events
-    - # members
-    - max of limit= message events
-    - room ID
-Notes:
- - If a chunk token is applied, you will get a delta relative to the last request
-    performed with that streaming token rather than all the rooms.
-Compacting notes:
- - Fixes the problem with the same event appearing in both the ``messages`` and
-   ``state`` keys. Represent as something like::
-
-     {
-       events: { event_id: Event, ... },
-       messages: [ event_id, event_id, ...],
-       state: [ event_id, event_id, ...],
-     }
-Duplicate content notes:
- - For non-compacted state events, duplicate state events in the ``messages`` 
-   key need to have a ``prev_content`` to correctly display the state change 
-   text. This is not required for ``state`` key events, which just represent 
-   the *current* state and as such do not need a ``prev_content``. Compacted 
-   state events will need to specify the ``prev_content``.
-What data flows does it address:
- - Home screen: data required on load.
- - XXX: would this also be used for initially loading room history screens too?
-
-Event Stream API ``[Draft]``
-----------------------------
-Inputs:
- - Position in the stream (chunk token)
- - Filter to apply: which event types, which room IDs, whether to get 
-   out-of-order events, which users to get presence/profile updates for
- - User ID
- - Device ID
-Outputs:
- - 0-N events the client hasn't seen. NB: Deleted state events will be missing a
-   ``content`` key. Deleted message events are ``m.room.redaction`` events.
- - New position in the stream. (chunk token)
-State Events Ordering Notes:
- - Homeservers may receive state events over federation that are superceded by 
-   state events previously sent to the client. The homeserver *cannot* send 
-   these events to the client else they would end up erroneously clobbering the
-   superceding state event. 
- - As a result, the homeserver reserves the right to omit sending state events 
-   which are known to be superceded already.
- - This may result in missed *state* events. However, the state of the room will
-   always be eventually consistent.
-Message Events Ordering Notes:
- - Homeservers may receive message events over federation that happened a long 
-   time ago. The client may or may not be interested in these message events.
- - For clients which do not store scrollback for a room (they discard events 
-   after processing them), this is not a problem as they only care about the 
-   recent messages.
- - For clients which do persist scrollback for a room, they need to know about 
-   the message event and where to insert it so that scrollback remains 
-   consistent and doesn't omit messages.
- - Clients can specify an input parameter stating that they wish to receive 
-   these out-of-order events.
- - The event, when it comes down the stream, will indicate which event it comes 
-   after.
-Rejected events:
- - A homeserver may find out via federation that it should not have accepted 
-   an event (e.g. to send a message/state event in a room). For example, it may
-   send an event to another homeserver and receive an auth event stating 
-   that the event should not have been sent. 
- - If this happens, the homeserver will send a ``m.room.redaction`` for the 
-   event in question. This will be a local server event (not shared with other 
-   servers).
- - If the event was a state event, it will synthesise a new state event to 
-   correct the client's room state. This will be a local server event (not 
-   shared with other servers).
- - In practice, clients don't need any extra special handling for this.
-Unknown rooms:
- - You could receive events for rooms you are unaware of (e.g. you didn't do an
-   initial sync, or your HS lost its database and is told from another HS that 
-   they are in this room). How do you handle this?
-   - The simplest option would be to redo the initial sync with a filter on the
-   room ID you're unaware of. This would retrieve the room state so you can 
-   display the room.
-What data flows does it address:
- - Home Screen: Data required when new message arrives for a room
- - Home Screen: Data required when someone invites you to a room
- - Home Screen: Data required when you leave a room on another device
- - Home Screen: Data required when you join a room on another device
- - Home Screen: Data required when your profile info changes on another device
- - Chat Screen: Data required when member name changes
- - Chat Screen: Data required when the room name changes
- - Chat Screen: Data required when a new message arrives
- 
-Room Creation API ``[Draft]``
------------------------------
-Inputs:
-  - Invitee list of user IDs, published/not, state events to set on creation 
-    e.g. name of room, alias of room, topic of room
-Output:
-  - Room ID
-Notes:
-  - This is a special case of joining a room. See the notes on joining a room.
-What data flows does it address:
-  - Home Screen: Creating a room
- 
-Joining API ``[Draft]``
------------------------
-Inputs:
- - Room ID (with list of servers to join from) / room alias / invite event ID
- - Optional filter (which events to return, whether the returned events should 
-   come down the event stream)
-Outputs:
- - Room ID, the returned state events from the filter e.g. Room aliases 
-   (plural), Name, topic, member list (f.e. member: user ID, avatar, presence, 
-   display name, power level, whether they are typing), enough messages to fill
-   screen (and whether there are more)
-Notes:
- - How do you return room information? In response to the join, or from the 
-   event stream?
- - The events returned need to be filterable. Different clients for the same 
-   user may want different information (e.g. the client performing the join may
-   jump to the chat screen and therefore want some messages, whereas the client
-   not performing the join just needs to be aware of the new room).
- - As a result, the join response should return events *instead of* to the 
-   event stream, depending on the client.
-Mapping messages to the event stream:
- - Once you join a room, you will start getting message events for it. How do 
-   you know when you started getting events for this room? You need to know so 
-   you can provide a token when scrolling back. You cannot currently infer this
-   from the join event itself, as individual events do not have tokens (only 
-   chunks do).
- - This token can be provided as a separate server-generated event, or an 
-   annotation on the join event itself.
- - We propose that a server-generated event is sent down the event stream to all
-   clients, rather than annotating the join event. The server-generated event 
-   works nicely for Application Services where an entity subscribes to a room 
-   without a join event.
- - This will look like an event for the room, but have a special 
-   "server-generated" event type e.g. ``m.homeserver.scrollback`` with a 
-   ``token`` containing the start token for the room.
-What data flows does it address:
- - Home Screen: Joining a room
- 
-Room History
-------------
-This concerns APIs which return historical events for a room. There are several
-common parameters.
-
-Inputs:
- - Room ID
- - Max number of events to return
- - Filter to apply.
-Outputs:
- - Requested events
- - Chunk token to use to request more events.
-
- 
-Scrollback API ``[Draft]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-.. NOTE::
- - Pagination: Would be nice to have "and X more". It will probably be 
-   Google-style estimates given we can't know the exact number over federation, 
-   but as a purely informational display thing it would be nice.
-
-Additional Inputs:
- - flag to say if the homeserver should do a backfill over federation
-Additional Outputs:
- - whether there are more events on the local HS / over federation.
-What data flows does it address:
- - Chat Screen: Scrolling back (infinite scrolling)
- 
-Contextual windowing API ``[Draft]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This refers to showing a "window" of message events around a given message 
-event. The window provides the "context" for the given message event.
-
-Additional Inputs:
- - Event ID of the message to get the surrounding context for (this specifies 
-   the room to get messages in).
- - Whether to get results before / after / around (mid point) this event
-Additional Outputs:
- - Start / End chunk tokens to go either way (not just one token)
- - Current room state at the end of the chunk as per initial sync.
-
-Room Alias API ``[Draft]``
---------------------------
-This provides mechanisms for creating and removing room aliases for a room on a
-homeserver. Typically, any user in a room can make an alias for that room. The
-alias creator (or anyone in the room?) can delete that alias. Server admins can
-also delete any alias on their server.
-
-Mapping a room alias to a room:
-
-Inputs:
- - Room Alias
-Output:
- - Room ID
- - List of homeservers to join via.
-
-Mapping a room to an alias:
- 
-Inputs:
- - Room ID
- - Desired room alias localpart
- - User ID (for auth)
-Output:
- - Room alias
-Notes:
- - The homeserver may add restrictions e.g. the user must be in the room.
- 
-Deleting a mapping:
-
-Inputs:
- - Room alias
- - User ID (for auth)
-Output:
- - None.
-
-
-Published room list API ``[Draft]``
------------------------------------
-This provides mechanisms for searching for published rooms on a homeserver.
-
-Inputs:
- - Search text (e.g. room alias/name/topic to search on)
- - Homeserver to search on (this may just be the URL hit for HTTP)
- - Any existing pagination token, can be missing if this is the first hit.
- - Limit for pagination
-Output:
- - Pagination token
- - Total number of rooms
- - Which 'page' of results this response represents
- - A list of rooms with:
-    - # users
-    - A set of 'publishable' room state events, presumably ``m.room.name``, 
-      ``m.room.topic`` and ``m.room.aliases``. This cannot be user-configured
-      since the user is not in the room.
-Notes:
- - This API would be hit again for the next page of results, with the pagination
-   token provided from the previous hit.
- - We should probably provide "and X more" estimates for the number of 
-   pagination results. This can be calculated by providing the total number of 
-   rooms e.g. '100' and the page e.g. '3' coupled with the limit parameter (aka
-   the number of results per page) specified e.g. '10'. 
- - In order to prevent the dataset from changing underneath the client whilst
-   they paginate, a request without a pagination token should take a "snapshot"
-   of the underlying data which is then paginated on, rather than the database
-   which is a moving target as other clients add new published rooms.
-
-
-User Profile API ``[Draft]``
-----------------------------
-Every user on a homeserver has a profile. This profile is effectively a
-key-value store scoped to a user ID. It can include an ``avatar_url``, 
-``displayname`` and other metadata. Updates to a profile should propagate to
-other interested users.
-
-Setting display name (strings):
-
-Inputs:
- - User ID
- - New display name
-Output:
- - None.
-Notes:
- - This is a generic problem, so should probably not be special cased for
-   display names. E.g. having an arbitrary key-value store here.
- 
-Setting avatar url (blob data):
- 
-Inputs:
- - User ID
- - New avatar url / file blob?
-Output:
- - None.
-Notes:
- - We may want to provide file uploading on this API for convenience.
-
-Retrieving profile information:
-
-Inputs:
- - User ID
- - Which keys to retrieve
-Output:
- - The key/values specified.
-  
-Propagation ``[Draft]``
-~~~~~~~~~~~~~~~~~~~~~~~
-The goals of propagation are:
-
-- Profile updates should propagate to all rooms the user is in so
-  rooms can display change events. Due to this, profile propagation
-  HAS to be in the event graph for the room, in order to place it in
-  the right position.
-- We should support different kinds of profiles for different rooms. 
-- Propagation should avoid flicker between joining a room and getting
-  profile information.
-
-In v1, this was achieved by sending ``displayname`` and ``avatar_url``
-keys inside the ``content`` of an ``m.room.member`` event. This event
-type was chosen in order to prevent flicker on the client, as all the
-information came down in one lump.
-
-This had a number of problems associated with it:
-
-- It conflated profile info and membership info, simply to avoid client
-  flicker.
-- Name/avatar changes created more ``m.room.member`` events which meant
-  they needed to be included in the auth chains for federation. This
-  created long auth chains which is suboptimal since homeservers need
-  to store the auth chains forever.
-
-These problems can be resolved by creating an ``m.room.member.profile``
-event which contains profile information. This reduces the number of
-``m.room.member`` events over federation, since profile changes are of
-a different event type. This also prevents conflation of profile changes
-and membership changes.
-
-However, this introduces its own set of problems, namely flicker. The
-client would receive the ``m.room.member`` event first, followed by
-the ``m.room.member.profile`` event, which could cause a flicker. In
-addition, federation may not send both events in a single transaction,
-resulting in missing information on the receiving homeserver.
-
-For federation, these problems can be resolved by sending the 
-``m.room.member`` event as they are in v1 (with ``displayname`` and 
-``avatar_url`` in the ``content``). These keys need to be signed so
-they cannot be in the ``unsigned`` part of the event. The receiving home 
-server will then extract these keys and create a server-generated 
-``m.room.member.profile`` event. To avoid confusion with duplicate 
-information, the ``avatar_url`` and ``displayname`` keys should be 
-removed from the ``m.room.member`` event by the receiving homeserver.
-When a client requests these events (either from the event stream
-or from an initial sync), the server will send the generated
-``m.room.member.profile`` event under the ``unsigned.profile`` key of the
-``m.room.member`` event. Subsequent profile updates are just sent as
-``m.room.member.profile`` events.
-
-For clients, profile information is now *entirely* represented in
-``m.room.member.profile`` events. To avoid flicker, this event is 
-combined with the ``m.room.member`` event under an ``unsigned.profile``
-key.
-
-::
-
-   Case #1: @user:domain "User" joins a room
-
-   HS --> HS:
-   {
-     content: {
-       displayname: "User",
-       membership: "join"
-     },
-     type: "m.room.member",
-     [...]
-   }
-   
-   Receiving HS transformation:
-   {
-     content: {
-       <remove displayname key>
-       membership: "join"
-     },
-     type: "m.room.member",
-     [...]
-   }
-   
-   Receiving HS creates new server-generated event:
-   {
-     content: {
-       displayname: "User"
-     },
-     type: "m.room.member.profile",
-     [...]
-   }
-   
-   Client sees: (e.g. from event stream / initial sync)
-   {
-     content: {
-       membership: "join"
-     },
-     type: "m.room.member",
-     unsigned: {
-       profile: {
-         content: {
-           displayname: "User"
-         },
-         type: "m.room.member.profile",
-         [...]
-       }
-     }
-     [...]
-   }
-   
-::
-
-   Case #2: @user:domain "User" updates their display name to "User2"
-            (they are already in the room)
-            
-   HS --> HS:
-   {
-     content: {
-       displayname: "User2"
-     },
-     prev_content: {
-       displayname: "User"
-     },
-     type: "m.room.member.profile",
-     [...]
-   }
-   
-   Client sees:
-   {
-     content: {
-       displayname: "User2"
-     },
-     prev_content: {
-       displayname: "User"
-     },
-     type: "m.room.member.profile",
-     [...]
-   }
-
-The removal of the ``displayname`` and ``avatar_url`` keys from ``m.room.member``
-can only be done if the client trusts their HS, as it will break the sending HS's
-signature. Requesting the "raw" federation event will have to return these keys.
-
-Account Management API ``[Draft]``
-----------------------------------
-The registration and login APIs in v1 do not support specifying device IDs. In v2,
-this will become *mandatory* when sending your initial request. Access tokens will
-be scoped per device, so using the same device ID twice when logging in will 
-clobber the old access token.
-
-In terms of additional APIs, users may wish to delete their account, revoke access 
-tokens, manage their devices, etc. This is achieved using an account management API.
-
-Deleting an account:
-
-Inputs:
- - User ID to delete
- - Auth key (e.g. access_token of user, of server admin, etc)
-Output:
- - None.
- 
-Viewing devices related to this account:
-
-Inputs:
- - User ID
- - Auth key (e.g. access_token of user, of server admin, etc)
-Output:
- - A list of devices (+ last used / access tokens / creation date / device / 
-   user-agent?)
-
-Removing an access token:
-
-Inputs:
- - User ID
- - Auth key (e.g. access_token of user, of server admin, etc)
- - Access token to revoke.
-Output:
- - None.
- 
-Removing a device:
-
-Inputs:
- - User ID
- - Auth key (e.g. access_token of user, of server admin, etc)
- - Device ID to remove.
-Output:
- - None.
-Notes:
- - This revokes all access tokens linked to this device.
-
-Action APIs
------------
-The following APIs are "action APIs". This is defined to be a request which 
-alters the state of a room you are already joined to.
-
-When you perform an action in a room, you immediately want to display the local 
-echo. The client can receive the response to the action either directly or from 
-the event stream. The order in which you receive these responses is undefined. 
-As a result, clients MUST be able to handle all possible orderings::
-
-                 1                           2a                          3
- START ----> REQUEST SENT ---> RESPONSE TO REQUEST RECEIVED --------> GOT BOTH
-                 |                                                       ^
-                 |                      2b                               |
-                 +----------> APPEARS IN EVENT STREAM -------------------+
-                 
-  1: Can display local echo at this point.
-  2a: The request has been successfully processed and can be displayed as Sent.
-  2b/3: The request has been successfully processed and the client knows its 
-        position in the event stream.
-
-When a client sends a request, they can include an "action ID" so that they can 
-match up the event in the event stream to the request which they made. This ID 
-is created by the client. This ID serves as a transaction ID for idempotency 
-as well as a marker to match the response when it appears in the event stream. 
-Events for actions performed by a client in that client's event stream will 
-include the action ID the client submitted when making the request. The 
-action ID will *not* appear in other client's event streams.
-
-Action IDs are optional and are only needed by clients that retransmit their 
-requests or display local echo. An example of a client which may not need the 
-use of action IDs includes bots which operate using basic request/responses 
-in a synchronous fashion.
-
-A client may wish to send multiple actions in parallel. The send event APIs
-support sending multiple events in a batch.
- 
-Inviting a user ``[ONGOING]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.. NOTE::
-  - Clients need to know *why* they are being invited (e.g. a ``reason`` key,
-    just like for kicks/bans). However, this opens up a spam vector where any
-    user can send any other user a string. Do we really want to do that?
-  - It may be useful to send other state information such as the room name,
-    topic, etc. How is this specified in this request? Does the inviter even
-    specify this, or is it a room config option which fields are shared? This
-    has a lot of parallels with the published room API which exposes some state
-    events. How do we prevent spam attacks via the room name/topic?
-  - The spam attack vector may be something we're just going to have to deal 
-    with. Ultimately, we need to expose more data about the room. This data is
-    going to be set by the client. Compromises like "just give the event type"
-    don't really fix the problem "because.my.event.type.could.be.like.this".
-
-Inputs:
- - User ID
- - Room ID
- - Action ID (optional)
-Outputs:
- - Display name / avatar of user invited (if known)
-What data flows does it address:
- - Chat Screen: Invite a user
- 
-Rejecting an invite ``[Final]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Inputs:
- - Event ID (to know which invite you're rejecting)
-Outputs:
- - None.
-Notes:
- - Giving the event ID rather than user ID/room ID combo because mutliple users 
-   can invite the same user into the same room.
- - Rejecting an invite results in the ``m.room.member`` state event being 
-   DELETEd for that user.
-   
-Sending state events ``[Final]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Inputs:
- - Event type[s]
- - State key[s]
- - Room ID
- - Content[s]
-Outputs:
- - None.
-Notes:
- - A batching version of this API needs to be provided.
-   
-Deleting state events ``[Draft]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Inputs:
- - Event type
- - State key
- - Room ID
-Outputs:
- - None.
-Notes:
- - This is represented on the event stream as an event lacking a ``content`` 
-   key (for symmetry with ``prev_content``)
-   
-Patching power levels ``[Draft]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Inputs:
- - Room ID
- - Key to update
- - New value
-Outputs:
- - None.
-Notes:
- - This allows a single key on power levels to be updated e.g. specifying 
-   ``kick`` as the key and ``60`` as the value to change the level required to
-   kick someone.
- - The local HS will take the current ``m.room.power_levels`` event and set the
-   new key before sending it to other HSes *in its full form*. This means HSes
-   will not need to worry about partial power level events.
-   
-Knocking on a room ``[TODO]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-If a room has the right ``join_rule`` e.g. ``knock``, then it should be able
-to send a special knock event to ask to join the room.
-   
-Read-up-to markers ``[ONGOING]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.. NOTE::
-  - Convert to EDUs for markers with periodic PDUs to reduce event graph size?
-
-Inputs:
- - State Event type (``m.room.marker.delivered`` and ``m.room.marker.read``)
- - Event ID to mark up to. This is inclusive of the event ID specified.
-Outputs:
- - None.
-Efficiency notes:
- - Sending "read up to" markers is preferable to sending receipts for every
-   message due to scaling problems on the client with one receipt per message.
-   This results in an ever increasing amount of bandwidth being devoted to 
-   receipts and not messages.
- - For individual receipts, each person would need to send at least 1 receipt 
-   for every message, which would give a total number of ``msgs * num_people`` 
-   receipts per room. Assuming that people in a room generally converse at say 
-   a rate of 1 message per unit time, this scales ``n^2`` on the number of 
-   people in the room.
- - Sending "read up to" markers in contrast allows people to skip some messages
-   entirely. By making them state events, each user would clobber their own 
-   marker, keeping the scaling at ``n``. For scrollback, the event filter would
-   NOT want to retrieve these markers as they will be updated frequently.
- - This primarily benefits clients when doing an initial sync. Event graphs 
-   will still have a lot of events, most of them from clobbering these state 
-   events. Some gains can be made by skipping receipts, but it is difficult to 
-   judge whether this would be substantial.
-Notes:
- - What do you do if you get a marker for an event you don't have? Do you fall
-   back to some kind of ordering heuristic e.g. ``if origin_server_ts > 
-   latest message``. Do you request that event ID directly from the HS? How do
-   you fit that in to the message thread if you did so? Would probably have to
-   fall back to the timestamp heuristic. After all, these markers are only ever
-   going to be heuristics given they are not acknowledging each message event.
- - These markers also allow unread message counts to be kept in sync for multiple
-   devices.
- 
-Kicking a user ``[Final]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-Inputs:
- - User ID
- - Room ID
- - Action ID (optional)
-Outputs:
- - None.
-What data flows does it address:
- - Chat Screen: Kick a user
-
-Leaving a room ``[Final]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-Inputs:
- - Room ID
- - A way of identifying the user (user ID, access token)
- - Action ID (optional)
-Outputs:
- - None.
-What data flows does it address:
- - Chat Screen: Leave a room
- 
-Send a message ``[Draft]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-Inputs:
- - Room ID
- - Message contents
- - Action ID (optional)
- - Whether the full event should be returned, or a compact version 
-   (default=full)
-Outputs:
- - The actual event sent incl content OR:
- - The extra keys added or keys modified e.g. 'content' from a policy server 
-   (if compact=true)
-What data flows does it address:
- - Chat Screen: Send a Message
-E2E Notes:
- - For signing: You send the original message to the HS and it will return the 
-   full event JSON which will be sent. This full event is then signed and sent 
-   to the HS again to send the message.
-Compact flag notes:
- - You need to know information about the event sent, including the event ID,
-   timestamp, etc.
- - Default behaviour will return the entire event JSON sent to make client
-   implementations simple (just clobber it).
- - It sucks to have your own messages echoed back to you in response though.
-   As a result, you can ask for a compact version which just sends down the
-   keys which were added, e.g. timestamp and event ID.
-Notes:
- - A batching version of this API needs to be provided.
-
-Presence API ``[Draft]``
-------------------------
-
-.. FIXME
-  this seems to be ignoring activity timers entirely, which were present on
-  the planning etherpad and are present in the actual HTTP API. Needs attention.
-
-The goals of presence are to:
-
-- Let other users know if someone is "online".
-- Let other users know if someone is likely to respond to any messages.
-- Let other users know specific status information (e.g. "In a Meeting").
-
-"Online" state can be detected by inspecting when the last time the client made
-a request to the server. This could be any request, or a specific kind of 
-request. For connection-orientated protocols, detecting "online" state can be 
-determined by the state of this connection stream. For HTTP, this can be 
-detected via requests to the event stream.
-
-Online state is separate from letting other users know if someone is *likely to
-respond* to messages. This introduces the concept of being "idle", which is
-when the user has not done any "interaction" with the app for a while. The 
-definition of "interaction" and "for a while" varies based on the app, so it is
-up to the app to set when the user is idle.
-
-Letting users know specific status information can be achieved via the same 
-method as v1. Status information should be scoped per *user* and not device as 
-determining a union algorithm between statuses is nonsensical. Passing status 
-information per device to all other users just redirects the union problem to 
-the client, which will commonly be presenting this information as an icon 
-alongside the user.
-
-When a client hits the event stream, the homeserver can treat the user as 
-"online". This behaviour should be able to be overridden to avoid flicker 
-during connection losses when the client is appear offline (e.g. device is
-appear offline > goes into a tunnel > server times out > device regains 
-connection and hits the event stream forcing the device online before the
-"appear offline" state can be set). When the client has not hit the event 
-stream for a certain period of time, the homeserver can treat the user as 
-"offline". The user can also set a global *per-user* appear offline flag.
-
-The user should also be able to set their presence state via a direct API, 
-without having to hit the event stream. The homeserver will set a timer when 
-the connection ends, after which it will set that device to offline.
-
-As the idle flag and online state is determined per device, there needs to be a
-union algorithm to merge these into a single state and flag per user, which will
-be sent to other users. The algorithm is:
-
-- If any device is online and not idle, the user is online.
-- Else if all online devices are idle, the user is idle.
-- Else the user is offline (no online devices).
-
-Changing presence status:
-
-Inputs:
- - User ID
- - Presence status (busy, do not disturb, in a meeting, etc)
-Output:
- - None.
- 
-Setting presence state:
-
-Inputs:
- - User ID
- - Device ID
- - Presence state (online|idle|offline)
-Output:
- - None.
- 
-Setting global appear offline:
-
-Inputs:
- - User ID
- - Should appear offline (boolean)
-Output:
- - None.
- 
-Extra parameters associated with the event stream:
-
-Inputs:
- - Presence state (online, idle, offline)
-Notes:
- - Scoped per device just like the above API, e.g. from the access_token.
-
-
-Typing API ``[Final]``
-------------------------
-.. NOTE::
- - Linking the termination of typing events to the message itself, so you don't 
-   need to send two events and don't get flicker?
-
-The typing API remains unchanged from v1.
- 
-Relates-to pagination API ``[Draft]``
--------------------------------------
-See the "Relates to" section for more info.
-
-Inputs:
- - Event ID
- - Chunk token
- - limit
-Output:
- - A chunk of child events
- - A new chunk token for earlier child events.
- 
-Capabilities API ``[ONGOING]``
-------------------------------
-.. NOTE::
- - Server capabilities: Keep hashing step for consistency or not? Extra request
-   if we do.
- - Client capabilities: Clients which are offline but can be pushed should have 
-   their capabilities visible. How to manage unregistering them e.g. if they 
-   uninstall the app? Have a set of 'offline' capabilities?
-  
-
-How does a client know if the server it is using supports a content repository? 
-How does a client know if another client has VoIP support? This section outlines
-capability publishing for servers, clients and federation.
-
-Server
-~~~~~~
-- List of extensions it supports (e.g. content repo, contact repo, turn servers)
-
-Inputs:
- - User ID (e.g. only @bob can use the content repo)
-Output:
- - Hash of the capabilities::
- 
-    {
-      "sha256": "fD876SFrt3sugh23FWEjio3"
-    }
-
-This hash is fed into another API:
-
-Inputs:
- - The hash of the capabilities
-Output:
- - A list of capabilities::
- 
-    {
-      "custom.feature.v1": {},
-      "m.cap.turnserver.v1": {}
-    }
-
-Client
-~~~~~~
-- e.g. Whether this client supports VoIP
-
-When a client app is launched, the client needs to provide a capability set. The 
-server will take the hashes of all the user's connected clients' capability 
-sets and send the list of hashes as part of presence information 
-(not necesarily as a ``m.presence`` event, but it should act like presence 
-events). It is sent as a list instead of a union of hashes because hashes work
-best when they don't change. A union of many devices' hashes will change 
-frequently when devices come on and offline (``max hashes = 2^num_devices``). 
-In contrast, the size of the list would vary, but the hashes themselves 
-would remain the same for a given device (``max hashes = num_devices``). Keeping
-the hashes the same is the best as that means clients do not need to request
-the capabilities for the given hash.
-
-On first signup, the client will attempt to send the hash and be most likely 
-refused by the homeserver as it does not know the full capability set for that 
-hash. The client will then have to upload the full capability set to the home 
-server. The client will then be able to send the hash as normal.
-
-When a client receives a hash, the client will either recognise the hash or 
-will have to request the capability set from their homeserver:
-
-Inputs:
- - Hash
- - User ID
-Output:
- - A list of capabilities
-
-Federation
-~~~~~~~~~~
-- e.g. Whether you support backfill, hypothetical search/query/threading APIs
-- Same as the server capability API
-
-VoIP ``[TODO]``
----------------
-This addresses one-to-one calling with multiple devices. This uses the 
-``updates`` key to handle signalling.
-
-Event updates
-~~~~~~~~~~~~~
-- Call is placed by caller. Event generated with offer.
-- 1-N callees may pick up or reject this offer.
-- Callees update the event (with sdp answer if they are accepting the call)
-- Caller acknowledges *one* of the callees (either one which picked up or 
-  rejected) by updating the event.
-- Callees who weren't chosen then give up (Answered elsewhere, Rejected 
-  elsewhere, etc)
-- Update with ICE candidates as they appear.
-- ... in call ...
-- Send hangup update when hanging up.
-
-Placing a call
-~~~~~~~~~~~~~~
-::
-
-  caller                callee
-   |-----m.call.invite--->|
-   |                      |
-   |<----m.call.answer----|
-   |     device_id=foo    |
-   |                      |
-   |------m.call.ack----->|
-   |     device_id=foo    |
-   |                      |
-   |<--m.call.candidate---|
-   |---m.call.candidate-->|
-   |                      |
- [...]                  [...]
-   |                      |
-   |<----m.call.hangup----|
-   |     device_id=foo    |
-
-Expiry
-~~~~~~
-- WIP: Of invites
-- WIP: Of calls themselves (as they may never send a ``m.call.hangup``
-
-
-General client changes
-----------------------
-These are changes which do not introduce new APIs, but are required for the new
-APIs in order to fix certain issues.
-
-Updates (Events) ``[Draft]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Events may update other events. This is represented by the ``updates`` key. This
-is a key which contains the event ID for the event it relates to. Events that 
-relate to other events are referred to as "Child Events". The event being 
-related to is referred to as "Parent Events". Child events cannot stand alone as
-a separate entity; they require the parent event in order to make sense.
-
-Bundling updates
-++++++++++++++++
-Events that relate to another event should come down inside that event. That is,
-the top-level event should come down with all the child events at the same time.
-This is called a "bundle" and it is represented as an array of events inside the
-top-level event.There are some issues with this however:
-
-- Scrollback: Should you be told about child events for which you do not know 
-  the parent event? Conclusion: No you shouldn't be told about child events. 
-  You will receive them when you scroll back to the parent event. 
-- Pagination of child events: You don't necessarily want to have 1000000s of 
-  child events with the parent event. We can't reasonably paginate child events
-  because we require all the child events in order to display the event 
-  correctly. Comments on a message should be done via another technique,
-  such as ``relates_to``.
-- Do you allow child events to relate to other child events? There is no 
-  technical reason why we cannot nest child events, however we can't think of 
-  any use cases for it. The behaviour would be to get the child events 
-  recursively from the top-level event. 
-  
-Main use cases for ``updates``:
- - Call signalling (child events are ICE candidates, answer to the offer, and 
-   termination)
- - *Local* Delivery/Read receipts : "Local" means they are not shared with other
-   users on the same homeserver or via federation but *are* shared between 
-   clients for the same user; useful for push notifications, read count markers,
-   etc. This is done to avoid the ``n^2`` problem for sending receipts, where 
-   the vast majority of traffic tends towards sending more receipts.
- - s/foo/bar/ style message edits
- 
-Clients *always* need to know how to apply the deltas because clients may 
-receive the events separately down the event stream. Combining event updates 
-server-side does not make client implementation simpler, as the client still 
-needs to know how to combine the events.
-
-Relates to (Events) ``[ONGOING]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-.. NOTE::
-  - Should be able to specify more relationship info other than just the event
-    type. Forcing that m.room.message A "relates_to" another m.room.message B 
-    means that A is a threaded conversation reply to B is needlessly 
-    restrictive. What if A and B relate to each other by some other metric 
-    (e.g. they are part of a group rather than a thread? or we distinguish 
-    mail-style threading from multithreaded-IM threading for the same set of 
-    messages? etc)? E.g. ``"relates_to" : [["in_reply_to", "$event_id1"], 
-    ["another_type_of_relation", "$event_id2"]]``
-
-Events may be in response to other events, e.g. comments. This is represented 
-by the ``relates_to`` key. This differs from the ``updates`` key as they *do 
-not update the event itself*, and are *not required* in order to display the 
-parent event. Crucially, the child events can be paginated, whereas ``updates`` 
-child events cannot be paginated.
-
-Bundling relations
-++++++++++++++++++
-Child events can be optionally bundled with the parent event, depending on your 
-display mechanism. The number of child events which can be bundled should be 
-limited to prevent events becoming too large. This limit should be set by the 
-client. If the limit is exceeded, then the bundle should also include a 
-chunk token so that the client can request more child events.
-
-Main use cases for ``relates_to``:
- - Comments on a message.
- - Non-local delivery/read receipts : If doing separate receipt events for each 
-   message.
- - Meeting invite responses : Yes/No/Maybe for a meeting.
-
-Like with ``updates``, clients need to know how to apply the deltas because 
-clients may receive the events separately down the event stream.
-
-TODO:
- - Can a child event reply to multiple parent events? Use case?
- - Should a parent event and its children share a thread ID? Does the 
-   originating HS set this ID? Is this thread ID exposed through federation? 
-   e.g. can a HS retrieve all events for a given thread ID from another HS?
-
-   
-Example using 'updates' and 'relates_to'
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Room with a single message.
-- 10 comments are added to the message via ``relates_to``.
-- An edit is made to the original message via ``updates``.
-- An initial sync on this room with a limit of 3 comments, would return the 
-  message with the update event bundled with it and the most recent 3 comments 
-  and a chunk token to request earlier comments
-  
-  .. code :: javascript
-  
-    {
-      content: { body: "I am teh winner!" },
-      updated_by: [
-        { content: { body: "I am the winner!" }, ... }
-      ],
-      replies: {
-        start: "some_token",
-        chunk: [
-          { content: { body: "8th comment" }, ... },
-          { content: { body: "9th comment" }, ... },
-          { content: { body: "10th comment" }, ... }
-        ]
-      },
-      ...
-    }
-    
-Events (breaking changes; event version 2) ``[Draft]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- Prefix the event ``type`` to say if it is a state event, message event or 
-  ephemeral event. Needed because you can't tell the different between message 
-  events and ephemeral ROOM events (e.g. typing).
-- State keys need additional restrictions in order to increase flexibility on 
-  state event permissions. State keys prefixed with an ``_`` have no specific 
-  restrictions. 0-length state keys are now represented by just a single ``_``.
-  State keys prefixed with ``@`` can be modified only by the named user ID *OR* 
-  the room ops. They can have an optional path suffixed to it. State keys that 
-  start with a server name can only be modified by that server name (e.g. 
-  ``some.server.com/some/path`` can only be modified by ``some.server.com``).
-- Do we want to specify what restrictions apply to the state key in the event 
-  type? This would allow HSes to enforce this, making life easier for clients 
-  when dealing with custom event types. E.g. ``_custom.event`` would allow 
-  anything in the state key, ``_@custom.event`` would only allow user IDs in 
-  the state key, etc.
-- s/user_id/sender/g given that homeservers can send events, not just users.
-
-Server-generated events ``[Draft]``
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Homeservers may want to send events to their local clients or to other home
-servers e.g. for server status notifications.
-
-These events look like regular events but have a server domain name as the
-``sender`` and not a user ID. This can be easily detected by clients by the 
-absence of a starting ``@``.
-
-Different types of events (e.g. EDUs, room EDUs) are detected in the same way
-as normal events (as proposed in the ``Events`` section of this document).
-
-
- 
diff --git a/attic/drafts/human-id-rules.rst b/attic/drafts/human-id-rules.rst
deleted file mode 100644
index f66b5544..00000000
--- a/attic/drafts/human-id-rules.rst
+++ /dev/null
@@ -1,133 +0,0 @@
-Abstract
-========
-
-This document outlines a proposed format for human-readable IDs within Matrix.
-For status see https://github.com/matrix-org/matrix-doc/pull/3/files
-
-Background
-----------
-UTF-8 is the dominant character encoding for Unicode on the web. However,
-using Unicode as the character set for human-readable IDs is troublesome. There
-are many different characters which appear identical to each other, but would
-produce different IDs. In addition, there are non-printable characters which
-cannot be rendered by the end-user. This creates an opportunity for
-phishing/spoofing of IDs, commonly known as a homograph attack.
-
-Web browsers encountered this problem when International Domain Names were
-introduced. A variety of checks were put in place in order to protect users. If
-an address failed the check, the raw punycode would be displayed to
-disambiguate the address.
-
-The human-readable IDs in Matrix are Room Aliases and User IDs.
-Room aliases look like ``#localpart:domain``. These aliases point to opaque
-non human-readable room IDs. These pointers can change to point at a different
-room ID at any time. User IDs look like ``@localpart:domain``. These represent
-actual end-users (there is no indirection).
-
-Proposal
-========
-
-User IDs and Room Aliases MUST be Unicode as UTF-8. Checks are performed on
-these IDs by homeservers to protect users from phishing/spoofing attacks.
-These checks are:
-
-User ID Localparts:
- - MUST NOT contain a ``:`` or start with a ``@`` or ``.``
- - MUST NOT contain one of the 107 blacklisted characters on this list:
-     http://kb.mozillazine.org/Network.IDN.blacklist_chars
- - After stripping " 0-9, +, -, [, ], _, and the space character it MUST NOT
-   contain characters from >1 language, defined by the `exemplar characters`_
-   on http://cldr.unicode.org/
-
-.. _exemplar characters: http://cldr.unicode.org/translation/characters#TOC-Exemplar-Characters
-
-Room Alias Localparts:
- - MUST NOT contain a ``:``
- - MUST NOT contain one of the 107 blacklisted characters on this list:
-   http://kb.mozillazine.org/Network.IDN.blacklist_chars
- - After stripping " 0-9, +, -, [, ], _, and the space character it MUST NOT
-   contain characters from >1 language, defined by the `exemplar characters`_
-   on http://cldr.unicode.org/
-
-.. _exemplar characters: http://cldr.unicode.org/translation/characters#TOC-Exemplar-Characters
-
-In the event of a failed user ID check, well behaved homeservers MUST:
- - Rewrite user IDs in the offending events to be punycode with an additional ``@``
-   prefix **before** delivering them to clients. There are no guarantees for
-   consistency between homeserver ID checking implementations. As a result, user
-   IDs MUST be sent in their *original* form over federation. This can be done in
-   a stateless manner as the punycode form has no information loss.
-
-In the event of a failed room alias check, well behaved homeservers MUST:
- - Send an HTTP status code 400 with an ``errcode`` of ``M_FAILED_HUMAN_ID_CHECK``
-   to the client if the client is attempting to *create* this alias.
- - Send an HTTP status code 400 with an ``errcode`` of ``M_FAILED_HUMAN_ID_CHECK``
-   to the client if the client is attempting to *join* a room via this alias.
-
-Examples::
-
-  @ebаy:example.org (Cyrillic 'a', everything else English)
-  @@xn--eby-7cd:example.org (Punycode with additional '@')
-
-Homeservers SHOULD NOT allow two user IDs that differ only by case. This
-SHOULD be applied based on the capitalisation rules in the CLDR dataset:
-http://cldr.unicode.org/
-
-This check SHOULD be applied when the user ID is created, in order to prevent
-registration with the same name and different capitalisations, e.g.
-``@foo:bar`` vs ``@Foo:bar`` vs ``@FOO:bar``. Homeservers MAY canonicalise
-the user ID to be completely lower-case if desired.
-
-Rationale
-=========
-
-Each ID is split into segments (localpart/domain) around the ``:``. For
-this reason, ``:`` is a reserved character and cannot be a localpart character.
-The 107 blacklisted characters are used to prevent non-printable characters and
-spaces from being used. The decision to ban characters from more than 1 language
-matches the behaviour of `Google Chrome for IDN handling`_. This is to protect
-against common homograph attacks such as ebаy.com (Cyrillic "a", rest is
-English). This would always result in a failed check. Even with this though
-there are limitations. For example, сахар is entirely Cyrillic, whereas caxap is
-entirely Latin.
-
-.. _Google Chrome for IDN handling: https://www.chromium.org/developers/design-documents/idn-in-google-chrome
-
-User ID localparts cannot start with ``@`` so that a namespace of localparts
-beginning with ``@`` can be created. This namespace is used for user IDs which
-fail the ID checks. A failed ID could look like ``@@xn--c1yn36f:example.org``.
-
-If a user ID fails the check, the user ID on the event is renamed. This doesn't
-require extra work for clients, and users will see an odd user ID rather than a
-spoofed name. Renaming is done in order to protect users of a given HS, so if a
-malicious HS doesn't rename their IDs, it doesn't affect any other HS.
-
-Room aliases cannot be rewritten as punycode and sent to the HS the alias is
-referring to as the HS will not necessarily understand the rewritten alias.
-
-Other rejected solutions for failed checks
-------------------------------------------
-- Additional key: Informational key on the event attached by HS to say "unsafe
-  ID". Problem: clients can just ignore it, and since it will appear only very
-  rarely, easy to forget when implementing clients.
-- Require client handshake: Forces clients to implement
-  a check, else they cannot communicate with the misleading ID. However, this
-  is extra overhead in both client implementations and round-trips.
-- Reject event: Outright rejection of the ID at the point of creation /
-  receiving event. Point of creation rejection is preferable to avoid the ID
-  entering the system in the first place. However, malicious HSes can just
-  allow the ID. Hence, other homeservers must reject them if they see them in
-  events. Client never sees the problem ID, provided the HS is correctly
-  implemented. However, it is difficult to ensure that ALL HSes will come to the
-  same conclusion (given the CLDR dataset does come out with new versions).
-
-Outstanding Problems
-====================
-
-Capitalisation
---------------
-
-The capitalisation rules outlined above are nice but do not fully resolve issues
-where ``@alice:example.com`` tries to speak with ``@bob:example.org`` using
-``@Bob:example.org``. It is up to ``example.org`` to map ``Bob`` to ``bob`` in
-a sensible way.
diff --git a/attic/drafts/model/presence.rst b/attic/drafts/model/presence.rst
deleted file mode 100644
index c2c88737..00000000
--- a/attic/drafts/model/presence.rst
+++ /dev/null
@@ -1,149 +0,0 @@
-API Efficiency
-==============
-
-A simple implementation of presence messaging has the ability to cause a large
-amount of Internet traffic relating to presence updates. In order to minimise
-the impact of such a feature, the following observations can be made:
-
- * There is no point in a homeserver polling status for peers in a user's
-   presence list if the user has no clients connected that care about it.
-
- * It is highly likely that most presence subscriptions will be symmetric - a
-   given user watching another is likely to in turn be watched by that user.
-
- * It is likely that most subscription pairings will be between users who share
-   at least one Room in common, and so their homeservers are actively
-   exchanging message PDUs or transactions relating to that Room.
-
- * Presence update messages do not need realtime guarantees. It is acceptable to
-   delay delivery of updates for some small amount of time (10 seconds to a
-   minute).
-
-The general model of presence information is that of a HS registering its
-interest in receiving presence status updates from other HSes, which then
-promise to send them when required. Rather than actively polling for the
-current state all the time, HSes can rely on their relative stability to only
-push updates when required.
-
-A homeserver should not rely on the longterm validity of this presence
-information, however, as this would not cover such cases as a user's server
-crashing and thus failing to inform their peers that users it used to host are
-no longer available online. Therefore, each promise of future updates should
-carry with a timeout value (whether explicit in the message, or implicit as some
-defined default in the protocol), after which the receiving HS should consider
-the information potentially stale and request it again.
-
-However, because of the likelihood that two homeservers are exchanging messages
-relating to chat traffic in a room common to both of them, the ongoing receipt
-of these messages can be taken by each server as an implicit notification that
-the sending server is still up and running, and therefore that no status changes
-have happened; because if they had the server would have sent them. A second,
-larger timeout should be applied to this implicit inference however, to protect
-against implementation bugs or other reasons that the presence state cache may
-become invalid; eventually the HS should re-enquire the current state of users
-and update them with its own.
-
-The following workflows can therefore be used to handle presence updates:
-
- 1 When a user first appears online their HS sends a message to each other HS
-   containing at least one user to be watched; each message carrying both a
-   notification of the sender's new online status, and a request to obtain and
-   watch the target users' presence information. This message implicitly
-   promises the sending HS will now push updates to the target HSes.
-
- 2 The target HSes then respond a single message each, containing the current
-   status of the requested user(s). These messages too implicitly promise the
-   target HSes will themselves push updates to the sending HS.
-
-   As these messages arrive at the sending user's HS they can be pushed to the
-   user's client(s), possibly batched again to ensure not too many small
-   messages which add extra protocol overheads.
-
-At this point, all the user's clients now have the current presence status
-information for this moment in time, and have promised to send each other
-updates in future.
-
- 3 The HS maintains two watchdog timers per peer HS it is exchanging presence
-   information with. The first timer should have a relatively small expiry
-   (perhaps 1 minute), and the second timer should have a much longer time
-   (perhaps 1 hour).
-
- 4 Any time any kind of message is received from a peer HS, the short-term
-   presence timer associated with it is reset.
-
- 5 Whenever either of these timers expires, an HS should push a status reminder
-   to the target HS whose timer has now expired, and request again from that
-   server the status of the subscribed users.
-
- 6 On receipt of one of these presence status reminders, an HS can reset both
-   of its presence watchdog timers.
-
-To avoid bursts of traffic, implementations should attempt to stagger the expiry
-of the longer-term watchdog timers for different peer HSes.
-
-When individual users actively change their status (either by explicit requests
-from clients, or inferred changes due to idle timers or client timeouts), the HS
-should batch up any status changes for some reasonable amount of time (10
-seconds to a minute). This allows for reduced protocol overheads in the case of
-multiple messages needing to be sent to the same peer HS; as is the likely
-scenario in many cases, such as a given human user having multiple user
-accounts.
-
-
-API Requirements
-================
-
-The data model presented here puts the following requirements on the APIs:
-
-Client-Server
--------------
-
-Requests that a client can make to its homeserver
-
- * get/set current presence state
-   Basic enumeration + ability to set a custom piece of text
-
- * report per-device idle time
-   After some (configurable?) idle time the device should send a single message
-   to set the idle duration. The HS can then infer a "start of idle" instant and
-   use that to keep the device idleness up to date. At some later point the
-   device can cancel this idleness.
-
- * report per-device type
-   Inform the server that this device is a "mobile" device, or perhaps some
-   other to-be-defined category of reduced capability that could be presented to
-   other users.
-
- * start/stop presence polling for my presence list
-   It is likely that these messages could be implicitly inferred by other
-   messages, though having explicit control is always useful.
-
- * get my presence list
-   [implicit poll start?]
-   It is possible that the HS doesn't yet have current presence information when
-   the client requests this. There should be a "don't know" type too.
-
- * add/remove a user to my presence list
-
-Server-Server
--------------
-
-Requests that homeservers make to others
-
- * request permission to add a user to presence list
-
- * allow/deny a request to add to a presence list
-
- * perform a combined presence state push and subscription request
-   For each sending user ID, the message contains their new status.
-   For each receiving user ID, the message should contain an indication on
-   whether the sending server is also interested in receiving status from that
-   user; either as an immediate update response now, or as a promise to send
-   future updates.
-
-Server to Client
-----------------
-
-[[TODO(paul): There also needs to be some way for a user's HS to push status
-updates of the presence list to clients, but the general server-client event
-model currently lacks a space to do that.]]
diff --git a/attic/drafts/model/profiles.rst b/attic/drafts/model/profiles.rst
deleted file mode 100644
index f81e115e..00000000
--- a/attic/drafts/model/profiles.rst
+++ /dev/null
@@ -1,231 +0,0 @@
-========
-Profiles
-========
-
-A description of Synapse user profile metadata support.
-
-
-Overview
-========
-
-Internally within Synapse users are referred to by an opaque ID, which consists
-of some opaque localpart combined with the domain name of their homeserver.
-Obviously this does not yield a very nice user experience; users would like to
-see readable names for other users that are in some way meaningful to them.
-Additionally, users like to be able to publish "profile" details to inform other
-users of other information about them.
-
-It is also conceivable that since we are attempting to provide a
-worldwide-applicable messaging system, that users may wish to present different
-subsets of information in their profile to different other people, from a
-privacy and permissions perspective.
-
-A Profile consists of a display name, an (optional?) avatar picture, and a set
-of other metadata fields that the user may wish to publish (email address, phone
-numbers, website URLs, etc...). We put no requirements on the display name other
-than it being a valid Unicode string. Since it is likely that users will end up
-having multiple accounts (perhaps by necessity of being hosted in multiple
-places, perhaps by choice of wanting multiple distinct identifies), it would be
-useful that a metadata field type exists that can refer to another Synapse User
-ID, so that clients and HSes can make use of this information.
-
-Metadata Fields
----------------
-
-[[TODO(paul): Likely this list is incomplete; more fields can be defined as we
-think of them. At the very least, any sort of supported ID for the 3rd Party ID
-servers should be accounted for here.]]
-
- * Synapse Directory Server username(s)
-
- * Email address
-
- * Phone number - classify "home"/"work"/"mobile"/custom?
- 
- * Twitter/Facebook/Google+/... social networks
-
- * Location - keep this deliberately vague to allow people to choose how
-     granular it is
- 
- * "Bio" information - date of birth, etc...
-
- * Synapse User ID of another account
-
- * Web URL
-
- * Freeform description text
-
-
-Visibility Permissions
-======================
-
-A homeserver implementation could offer the ability to set permissions on
-limited visibility of those fields. When another user requests access to the
-target user's profile, their own identity should form part of that request. The
-HS implementation can then decide which fields to make available to the
-requestor.
-
-A particular detail of implementation could allow the user to create one or more
-ACLs; where each list is granted permission to see a given set of non-public
-fields (compare to Google+ Circles) and contains a set of other people allowed
-to use it. By giving these ACLs strong identities within the HS, they can be
-referenced in communications with it, granting other users who encounter these
-the "ACL Token" to use the details in that ACL.
-
-If we further allow an ACL Token to be present on Room join requests or stored
-by 3PID servers, then users of these ACLs gain the extra convenience of not
-having to manually curate people in the access list; anyone in the room or with
-knowledge of the 3rd Party ID is automatically granted access. Every HS and
-client implementation would have to be aware of the existence of these ACL
-Token, and include them in requests if present, but not every HS implementation
-needs to actually provide the full permissions model. This can be used as a
-distinguishing feature among competing implementations. However, servers MUST
-NOT serve profile information from a cache if there is a chance that its limited
-understanding could lead to information leakage.
-
-
-Client Concerns of Multiple Accounts
-====================================
-
-Because a given person may want to have multiple Synapse User accounts, client
-implementations should allow the use of multiple accounts simultaneously
-(especially in the field of mobile phone clients, which generally don't support
-running distinct instances of the same application). Where features like address
-books, presence lists or rooms are presented, the client UI should remember to
-make distinct with user account is in use for each.
-
-
-Directory Servers
-=================
-
-Directory Servers can provide a forward mapping from human-readable names to
-User IDs. These can provide a service similar to giving domain-namespaced names
-for Rooms; in this case they can provide a way for a user to reference their
-User ID in some external form (e.g. that can be printed on a business card).
-
-The format for Synapse user name will consist of a localpart specific to the
-directory server, and the domain name of that directory server:
-
-  @localname:some.domain.name
-
-The localname is separated from the domain name using a colon, so as to ensure
-the localname can still contain periods, as users may want this for similarity
-to email addresses or the like, which typically can contain them. The format is
-also visually quite distinct from email addresses, phone numbers, etc... so
-hopefully reasonably "self-describing" when written on e.g. a business card
-without surrounding context.
-
-[[TODO(paul): we might have to think about this one - too close to email?
-  Twitter? Also it suggests a format scheme for room names of
-  #localname:domain.name, which I quite like]]
-
-Directory server administrators should be able to make some kind of policy
-decision on how these are allocated. Servers within some "closed" domain (such
-as company-specific ones) may wish to verify the validity of a mapping using
-their own internal mechanisms; "public" naming servers can operate on a FCFS
-basis. There are overlapping concerns here with the idea of the 3rd party
-identity servers as well, though in this specific case we are creating a new
-namespace to allocate names into.
-
-It would also be nice from a user experience perspective if the profile that a
-given name links to can also declare that name as part of its metadata.
-Furthermore as a security and consistency perspective it would be nice if each
-end (the directory server and the user's homeserver) check the validity of the
-mapping in some way. This needs investigation from a security perspective to
-ensure against spoofing.
-
-One such model may be that the user starts by declaring their intent to use a
-given user name link to their homeserver, which then contacts the directory
-service. At some point later (maybe immediately for "public open FCFS servers",
-maybe after some kind of human intervention for verification) the DS decides to
-honour this link, and includes it in its served output. It should also tell the
-HS of this fact, so that the HS can present this as fact when requested for the
-profile information. For efficiency, it may further wish to provide the HS with
-a cryptographically-signed certificate as proof, so the HS serving the profile
-can provide that too when asked, avoiding requesting HSes from constantly having
-to contact the DS to verify this mapping. (Note: This is similar to the security
-model often applied in DNS to verify PTR <-> A bidirectional mappings).
-
-
-Identity Servers
-================
-
-The identity servers should support the concept of pointing a 3PID being able to
-store an ACL Token as well as the main User ID. It is however, beyond scope to
-do any kind of verification that any third-party IDs that the profile is
-claiming match up to the 3PID mappings.
-
-
-User Interface and Expectations Concerns
-========================================
-
-Given the weak "security" of some parts of this model as compared to what users
-might expect, some care should be taken on how it is presented to users,
-specifically in the naming or other wording of user interface components.
-
-Most notably mere knowledge of an ACL Pointer is enough to read the information
-stored in it. It is possible that Home or Identity Servers could leak this
-information, allowing others to see it. This is a security-vs-convenience
-balancing choice on behalf of the user who would choose, or not, to make use of
-such a feature to publish their information.
-
-Additionally, unless some form of strong end-to-end user-based encryption is
-used, a user of ACLs for information privacy has to trust other homeservers not
-to lie about the identify of the user requesting access to the Profile.
-
-
-API Requirements
-================
-
-The data model presented here puts the following requirements on the APIs:
-
-Client-Server
--------------
-
-Requests that a client can make to its homeserver
-
- * get/set my Display Name
-   This should return/take a simple "text/plain" field
-
- * get/set my Avatar URL
-   The avatar image data itself is not stored by this API; we'll just store a
-   URL to let the clients fetch it. Optionally HSes could integrate this with
-   their generic content attacmhent storage service, allowing a user to set
-   upload their profile Avatar and update the URL to point to it.
-
- * get/add/remove my metadata fields
-   Also we need to actually define types of metadata
-
- * get another user's Display Name / Avatar / metadata fields
-
-TODO(paul): At some later stage we should consider the API for:
-
- * get/set ACL permissions on my metadata fields
-
- * manage my ACL tokens
-
-Server-Server
--------------
-
-Requests that homeservers make to others
-
- * get a user's Display Name / Avatar
-
- * get a user's full profile - name/avatar + MD fields
-   This request must allow for specifying the User ID of the requesting user,
-   for permissions purposes. It also needs to take into account any ACL Tokens
-   the requestor has.
-
- * push a change of Display Name to observers (overlaps with the presence API)
-
-Room Event PDU Types
---------------------
-
-Events that are pushed from homeservers to other homeservers or clients.
-
- * user Display Name change
- 
- * user Avatar change
-   [[TODO(paul): should the avatar image itself be stored in all the room
-   histories? maybe this event should just be a hint to clients that they should
-   re-fetch the avatar image]]
diff --git a/attic/drafts/model/protocol_examples.rst b/attic/drafts/model/protocol_examples.rst
deleted file mode 100644
index d4f9a0a2..00000000
--- a/attic/drafts/model/protocol_examples.rst
+++ /dev/null
@@ -1,68 +0,0 @@
-PUT /send/abc/ HTTP/1.1
-Host: ...
-Content-Length: ...
-Content-Type: application/json
-
-.. code :: javascript
-
-  {
-    "origin": "localhost:5000",
-    "pdus": [
-        {
-            "content": {},
-            "context": "tng",
-            "depth": 12,
-            "is_state": false,
-            "origin": "localhost:5000",
-            "pdu_id": 1404381396854,
-            "pdu_type": "feedback",
-            "prev_pdus": [
-                [
-                    "1404381395883",
-                    "localhost:6000"
-                ]
-            ],
-            "ts": 1404381427581
-        }
-    ],
-    "prev_ids": [
-        "1404381396852"
-    ],
-    "ts": 1404381427823
-  }
-
-HTTP/1.1 200 OK
-
-
-======================================
-
-GET /pull/-1/ HTTP/1.1
-Host: ...
-Content-Length: 0
-
-HTTP/1.1 200 OK
-Content-Length: ...
-Content-Type: application/json
-
-.. code :: javascript
-
-  {
-    origin: ...,
-    prev_ids: ...,
-    data: [
-        {
-            data_id: ...,
-            prev_pdus: [...],
-            depth: ...,
-            ts: ...,
-            context: ...,
-            origin: ...,
-            content: {
-                ...
-            }
-        },
-        ...,
-    ]
-  }
-
-
diff --git a/attic/drafts/model/room-join-workflow.rst b/attic/drafts/model/room-join-workflow.rst
deleted file mode 100644
index ff469740..00000000
--- a/attic/drafts/model/room-join-workflow.rst
+++ /dev/null
@@ -1,113 +0,0 @@
-==================
-Room Join Workflow
-==================
-
-An outline of the workflows required when a user joins a room.
-
-Discovery
-=========
-
-To join a room, a user has to discover the room by some mechanism in order to
-obtain the (opaque) Room ID and a candidate list of likely homeservers that
-contain it.
-
-Sending an Invitation
----------------------
-
-The most direct way a user discovers the existence of a room is from a
-invitation from some other user who is a member of that room.
-
-The inviter's HS sets the membership status of the invitee to "invited" in the
-"m.members" state key by sending a state update PDU. The HS then broadcasts this
-PDU among the existing members in the usual way. An invitation message is also
-sent to the invited user, containing the Room ID and the PDU ID of this
-invitation state change and potentially a list of some other homeservers to use
-to accept the invite. The user's client can then choose to display it in some
-way to alert the user.
-
-[[TODO(paul): At present, no API has been designed or described to actually send
-that invite to the invited user. Likely it will be some facet of the larger
-user-user API required for presence, profile management, etc...]]
-
-Directory Service
------------------
-
-Alternatively, the user may discover the channel via a directory service; either
-by performing a name lookup, or some kind of browse or search acitivty. However
-this is performed, the end result is that the user's homeserver requests the
-Room ID and candidate list from the directory service.
-
-[[TODO(paul): At present, no API has been designed or described for this
-directory service]]
-
-
-Joining
-=======
-
-Once the ID and homeservers are obtained, the user can then actually join the
-room.
-
-Accepting an Invite
--------------------
-
-If a user has received and accepted an invitation to join a room, the invitee's
-homeserver can now send an invite acceptance message to a chosen candidate
-server from the list given in the invitation, citing also the PDU ID of the
-invitation as "proof" of their invite. (This is required as due to late message
-propagation it could be the case that the acceptance is received before the
-invite by some servers). If this message is allowed by the candidate server, it
-generates a new PDU that updates the invitee's membership status to "joined",
-referring back to the acceptance PDU, and broadcasts that as a state change in
-the usual way. The newly-invited user is now a full member of the room, and
-state propagation proceeds as usual.
-
-Joining a Public Room
----------------------
-
-If a user has discovered the existence of a room they wish to join but does not
-have an active invitation, they can request to join it directly by sending a
-join message to a candidate server on the list provided by the directory
-service. As this list may be out of date, the HS should be prepared to retry
-other candidates if the chosen one is no longer aware of the room, because it
-has no users as members in it.
-
-Once a candidate server that is aware of the room has been found, it can
-broadcast an update PDU to add the member into the "m.members" key setting their
-state directly to "joined" (i.e. bypassing the two-phase invite semantics),
-remembering to include the new user's HS in that list.
-
-Knocking on a Semi-Public Room
-------------------------------
-
-If a user requests to join a room but the join mode of the room is "knock", the
-join is not immediately allowed. Instead, if the user wishes to proceed, they
-can instead post a "knock" message, which informs other members of the room that
-the would-be joiner wishes to become a member and sets their membership value to
-"knocked". If any of them wish to accept this, they can then send an invitation
-in the usual way described above. Knowing that the user has already knocked and
-expressed an interest in joining, the invited user's homeserver should
-immediately accept that invitation on the user's behalf, and go on to join the
-room in the usual way.
-
-[[NOTE(Erik): Though this may confuse users who expect 'X has joined' to
-actually be a user initiated action, i.e. they may expect that 'X' is actually
-looking at synapse right now?]]
-
-[[NOTE(paul): Yes, a fair point maybe we should suggest HSes don't do that, and
-just offer an invite to the user as normal]]
-
-Private and Non-Existent Rooms
-------------------------------
-
-If a user requests to join a room but the room is either unknown by the home
-server receiving the request, or is known by the join mode is "invite" and the
-user has not been invited, the server must respond that the room does not exist.
-This is to prevent leaking information about the existence and identity of
-private rooms.
-
-
-Outstanding Questions
-=====================
-
- * Do invitations or knocks time out and expire at some point? If so when? Time
-   is hard in distributed systems.
diff --git a/attic/drafts/model/rooms.rst b/attic/drafts/model/rooms.rst
deleted file mode 100644
index 2f57f2bc..00000000
--- a/attic/drafts/model/rooms.rst
+++ /dev/null
@@ -1,276 +0,0 @@
-===========
-Rooms Model
-===========
-
-A description of the general data model used to implement Rooms, and the
-user-level visible effects and implications.
-
-
-Overview
-========
-
-"Rooms" in Synapse are shared messaging channels over which all the participant
-users can exchange messages. Rooms have an opaque persistent identify, a
-globally-replicated set of state (consisting principly of a membership set of
-users, and other management and miscellaneous metadata), and a message history.
-
-
-Room Identity and Naming
-========================
-
-Rooms can be arbitrarily created by any user on any homeserver; at which point
-the homeserver will sign the message that creates the channel, and the
-fingerprint of this signature becomes the strong persistent identify of the
-room. This now identifies the room to any homeserver in the network regardless
-of its original origin. This allows the identify of the room to outlive any
-particular server. Subject to appropriate permissions [to be discussed later],
-any current member of a room can invite others to join it, can post messages
-that become part of its history, and can change the persistent state of the room
-(including its current set of permissions).
-
-Homeservers can provide a directory service, allowing a lookup from a
-convenient human-readable form of room label to a room ID. This mapping is
-scoped to the particular homeserver domain and so simply represents that server
-administrator's opinion of what room should take that label; it does not have to
-be globally replicated and does not form part of the stored state of that room.
-
-This room name takes the form
-
-  #localname:some.domain.name
-
-for similarity and consistency with user names on directories.
-
-To join a room (and therefore to be allowed to inspect past history, post new
-messages to it, and read its state), a user must become aware of the room's
-fingerprint ID. There are two mechanisms to allow this:
-
- * An invite message from someone else in the room
-
- * A referral from a room directory service
-
-As room IDs are opaque and ephemeral, they can serve as a mechanism to create
-"ad-hoc" rooms deliberately unnamed, for small group-chats or even private
-one-to-one message exchange.
-
-
-Stored State and Permissions
-============================
-
-Every room has a globally-replicated set of stored state. This state is a set of
-key/value or key/subkey/value pairs. The value of every (sub)key is a
-JSON-representable object. The main key of a piece of stored state establishes
-its meaning; some keys store sub-keys to allow a sub-structure within them [more
-detail below]. Some keys have special meaning to Synapse, as they relate to
-management details of the room itself, storing such details as user membership,
-and permissions of users to alter the state of the room itself. Other keys may
-store information to present to users, which the system does not directly rely
-on. The key space itself is namespaced, allowing 3rd party extensions, subject
-to suitable permission.
-
-Permission management is based on the concept of "power-levels". Every user
-within a room has an integer assigned, being their "power-level" within that
-room. Along with its actual data value, each key (or subkey) also stores the
-minimum power-level a user must have in order to write to that key, the
-power-level of the last user who actually did write to it, and the PDU ID of
-that state change.
-
-To be accepted as valid, a change must NOT:
-
- * Be made by a user having a power-level lower than required to write to the
-   state key
-
- * Alter the required power-level for that state key to a value higher than the
-   user has
-
- * Increase that user's own power-level
-
- * Grant any other user a power-level higher than the level of the user making
-   the change
-
-[[TODO(paul): consider if relaxations should be allowed; e.g. is the current
-outright-winner allowed to raise their own level, to allow for "inflation"?]]
-
-
-Room State Keys
-===============
-
-[[TODO(paul): if this list gets too big it might become necessary to move it
-into its own doc]]
-
-The following keys have special semantics or meaning to Synapse itself:
-
-m.member (has subkeys)
-  Stores a sub-key for every Synapse User ID which is currently a member of
-  this room. Its value gives the membership type ("knocked", "invited",
-  "joined").
-
-m.power_levels
-  Stores a mapping from Synapse User IDs to their power-level in the room. If
-  they are not present in this mapping, the default applies.
-
-  The reason to store this as a single value rather than a value with subkeys
-  is that updates to it are atomic; allowing a number of colliding-edit
-  problems to be avoided.
-
-m.default_level
-  Gives the default power-level for members of the room that do not have one
-  specified in their membership key.
-
-m.invite_level
-  If set, gives the minimum power-level required for members to invite others
-  to join, or to accept knock requests from non-members requesting access. If
-  absent, then invites are not allowed. An invitation involves setting their
-  membership type to "invited", in addition to sending the invite message.
-
-m.join_rules
-  Encodes the rules on how non-members can join the room. Has the following
-  possibilities:
-
-    - "public" - a non-member can join the room directly
-    - "knock" - a non-member cannot join the room, but can post a single "knock"
-      message requesting access, which existing members may approve or deny
-    - "invite" - non-members cannot join the room without an invite from an
-      existing member
-    - "private" - nobody who is not in the 'may_join' list or already a member
-      may join by any mechanism
-
-  In any of the first three modes, existing members with sufficient permission
-  can send invites to non-members if allowed by the "m.invite_level" key. A
-  "private" room is not allowed to have the "m.invite_level" set.
-
-  A client may use the value of this key to hint at the user interface
-  expectations to provide; in particular, a private chat with one other use
-  might warrant specific handling in the client.
-
-m.may_join
-  A list of User IDs that are always allowed to join the room, regardless of any
-  of the prevailing join rules and invite levels. These apply even to private
-  rooms. These are stored in a single list with normal update-powerlevel
-  permissions applied; users cannot arbitrarily remove themselves from the list.
-
-m.add_state_level
-  The power-level required for a user to be able to add new state keys.
-
-m.public_history
-  If set and true, anyone can request the history of the room, without needing
-  to be a member of the room.
-
-m.archive_servers
-  For "public" rooms with public history, gives a list of homeservers that
-  should be included in message distribution to the room, even if no users on
-  that server are present. These ensure that a public room can still persist
-  even if no users are currently members of it. This list should be consulted by
-  the dirctory servers as the candidate list they respond with.
-
-The following keys are provided by Synapse for user benefit, but their value is
-not otherwise used by Synapse.
-
-m.name
-  Stores a short human-readable name for the room, such that clients can display
-  to a user to assist in identifying which room is which.
-  
-  This name specifically is not the strong ID used by the message transport
-  system to refer to the room, because it may be changed from time to time.
-
-m.topic
-  Stores the current human-readable topic
-
-
-Room Creation Templates
-=======================
-
-A client (or maybe homeserver?) could offer a few templates for the creation of
-new rooms. For example, for a simple private one-to-one chat the channel could
-assign the creator a power-level of 1, requiring a level of 1 to invite, and
-needing an invite before members can join. An invite is then sent to the other
-party, and if accepted and the other user joins, the creator's power-level can
-now be reduced to 0. This now leaves a room with two participants in it being
-unable to add more.
-
-
-Rooms that Continue History
-===========================
-
-An option that could be considered for room creation, is that when a new room is
-created the creator could specify a PDU ID into an existing room, as the history
-continuation point. This would be stored as an extra piece of meta-data on the
-initial PDU of the room's creation. (It does not appear in the normal previous
-PDU linkage).
-
-This would allow users in rooms to "fork" a room, if it is considered that the
-conversations in the room no longer fit its original purpose, and wish to
-diverge. Existing permissions on the original room would continue to apply of
-course, for viewing that history. If both rooms are considered "public" we might
-also want to define a message to post into the original room to represent this
-fork point, and give a reference to the new room.
-
-
-User Direct Message Rooms
-=========================
-
-There is no need to build a mechanism for directly sending messages between
-users, because a room can handle this ability. To allow direct user-to-user chat
-messaging we simply need to be able to create rooms with specific set of
-permissions to allow this direct messaging.
-
-Between any given pair of user IDs that wish to exchange private messages, there
-will exist a single shared Room, created lazily by either side. These rooms will
-need a certain amount of special handling in both homeservers and display on
-clients, but as much as possible should be treated by the lower layers of code
-the same as other rooms.
-
-Specially, a client would likely offer a special menu choice associated with
-another user (in room member lists, presence list, etc..) as "direct chat". That
-would perform all the necessary steps to create the private chat room. Receiving
-clients should display these in a special way too as the room name is not
-important; instead it should distinguish them on the Display Name of the other
-party.
-
-Homeservers will need a client-API option to request setting up a new user-user
-chat room, which will then need special handling within the server. It will
-create a new room with the following 
-
-  m.member: the proposing user
-  m.join_rules: "private"
-  m.may_join: both users
-  m.power_levels: empty
-  m.default_level: 0
-  m.add_state_level: 0
-  m.public_history: False
-
-Having created the room, it can send an invite message to the other user in the
-normal way - the room permissions state that no users can be set to the invited
-state, but because they're in the may_join list then they'd be allowed to join
-anyway.
-
-In this arrangement there is now a room with both users may join but neither has
-the power to invite any others. Both users now have the confidence that (at
-least within the messaging system itself) their messages remain private and
-cannot later be provably leaked to a third party. They can freely set the topic
-or name if they choose and add or edit any other state of the room. The update
-powerlevel of each of these fixed properties should be 1, to lock out the users
-from being able to alter them.
-
-
-Anti-Glare
-==========
-
-There exists the possibility of a race condition if two users who have no chat
-history with each other simultaneously create a room and invite the other to it.
-This is called a "glare" situation. There are two possible ideas for how to
-resolve this:
-
- * Each homeserver should persist the mapping of (user ID pair) to room ID, so
-   that duplicate requests can be suppressed. On receipt of a room creation
-   request that the HS thinks there already exists a room for, the invitation to
-   join can be rejected if:
-
-      - a) the HS believes the sending user is already a member of the room (and
-        maybe their HS has forgotten this fact), or
-      - b) the proposed room has a lexicographically-higher ID than the existing
-        room (to resolve true race condition conflicts)
-      
- * The room ID for a private 1:1 chat has a special form, determined by
-   concatenting the User IDs of both members in a deterministic order, such that
-   it doesn't matter which side creates it first; the HSes can just ignore
-   (or merge?) received PDUs that create the room twice.
diff --git a/attic/drafts/model/third-party-id.rst b/attic/drafts/model/third-party-id.rst
deleted file mode 100644
index 838a6799..00000000
--- a/attic/drafts/model/third-party-id.rst
+++ /dev/null
@@ -1,108 +0,0 @@
-======================
-Third Party Identities
-======================
-
-A description of how email addresses, mobile phone numbers and other third
-party identifiers can be used to authenticate and discover users in Matrix.
-
-
-Overview
-========
-
-New users need to authenticate their account. An email or SMS text message can 
-be a convenient form of authentication. Users already have email addresses 
-and phone numbers for contacts in their address book. They want to communicate
-with those contacts in Matrix without manually exchanging a Matrix User ID with 
-them.
-
-Third Party IDs
----------------
-
-[[TODO(markjh): Describe the format of a 3PID]]
-
-
-Third Party ID Associations
----------------------------
-
-An Associaton is a binding between a Matrix User ID and a Third Party ID (3PID).
-Each 3PID can be associated with one Matrix User ID at a time.
-
-[[TODO(markjh): JSON format of the association.]]
-
-Verification 
-------------
-
-An Assocation must be verified by a trusted Verification Server. Email 
-addresses and phone numbers can be verified by sending a token to the address 
-which a client can supply to the verifier to confirm ownership.
-
-An email Verification Server may be capable of verifying all email 3PIDs or may
-be restricted to verifying addresses for a particular domain. A phone number
-Verification Server may be capable of verifying all phone numbers or may be
-restricted to verifying numbers for a given country or phone prefix.
-
-Verification Servers fulfil a similar role to Certificate Authorities in PKI so
-a similar level of vetting should be required before clients trust their
-signatures.
-
-A Verification Server may wish to check for existing Associations for a 3PID 
-before creating a new Association.
-
-Discovery
----------
-
-Users can discover Associations using a trusted Identity Server. Each 
-Association will be signed by the Identity Server. An Identity Server may store
-the entire space of Associations or may delegate to other Identity Servers when
-looking up Associations.
-
-Each Association returned from an Identity Server must be signed by a 
-Verification Server. Clients should check these signatures.
-
-Identity Servers fulfil a similar role to DNS servers.
-
-Privacy
--------
-
-A User may publish the association between their phone number and Matrix User ID
-on the Identity Server without publishing the number in their Profile hosted on
-their homeserver.
-
-Identity Servers should refrain from publishing reverse mappings and should 
-take steps, such as rate limiting, to prevent attackers enumerating the space of
-mappings.
-
-Federation
-==========
-
-Delegation
-----------
-
-Verification Servers could delegate signing to another server by issuing 
-certificate to that server allowing it to verify and sign a subset of 3PID on 
-its behalf. It would be necessary to provide a language for describing which
-subset of 3PIDs that server had authority to validate. Alternatively it could 
-delegate the verification step to another server but sign the resulting
-association itself.
-
-The 3PID space will have a heirachical structure like DNS so Identity Servers
-can delegate lookups to other servers. An Identity Server should be prepared 
-to host or delegate any valid association within the subset of the 3PIDs it is 
-resonsible for.
-
-Multiple Root Verification Servers
-----------------------------------
-
-There can be multiple root Verification Servers and an Association could be
-signed by multiple servers if different clients trust different subsets of
-the verification servers.
-
-Multiple Root Identity Servers
-------------------------------
-
-There can be be multiple root Identity Servers. Clients will add each
-Association to all root Identity Servers.
-
-[[TODO(markjh): Describe how clients find the list of root Identity Servers]]
-
-
diff --git a/attic/drafts/object_model.rst b/attic/drafts/object_model.rst
deleted file mode 100644
index 0341d6a5..00000000
--- a/attic/drafts/object_model.rst
+++ /dev/null
@@ -1,27 +0,0 @@
-..TODO
-  What are the start & end tokens doing here?!
-
-::
-
- +---------------+
- | Room          |
- |   "Room-ID"   |
- |   {State}     |         +----------------------+
- |     Name------|-------->| Event m.room.name    |
- |     Topic     |         |   "Name"             |
- |     [Aliases] |         +----------------------+      +-------------+
- |     [Members]-|---+     +----------------------+ <----| Start Token |
- |   [Messages]  |   |     | Event m.room.member  |      +-------------+
- |     |   |     |   +---->|   "invite/join/ban"  |
- +---------------+         |   "User-ID"          |
-       |   |               +----------------------+
-       |   |               +----------------------+
-       |   | Message       | Event m.room.message |
-       |   +-------------->|   {content}          |<--+
-       |                   +----------------------+   |
-       | Comment           +----------------------+   |
-       +------------------>| Event m.room.message |   |
-                           |   {content}          |   |
-                           |   "relates-to"-------|---+  +-------------+
-                           +----------------------+ <----|  End Token  |
-                                                         +-------------+
diff --git a/attic/drafts/pstn_gatewaying.txt b/attic/drafts/pstn_gatewaying.txt
deleted file mode 100644
index 680a8d23..00000000
--- a/attic/drafts/pstn_gatewaying.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-Gatewaying to the PSTN via Matrix Application Services
-======================================================
-
-Matrix Application Services (AS) provides a way for PSTN users to interact
-with Matrix via an AS acting as a gateway. Each PSTN user is represented as a
-virtual user on a specific homeserver maintained by the AS. Typically the AS
-is provisioned on a well-known AS-supplier HS (e.g. matrix.openmarket.com) or
-is a service provisioned on the user's local HS.
-
-In either scenario, the AS maintains virtual users of form
-@.tel.e164:homeserver. These are lazily created (as per the AS spec) when
-matrix users try to contact a user id of form @.tel.*:homeserver, or when the
-AS needs to inject traffic into the HS on behalf of the PSTN user. The reason
-for these being a visible virtual user rather than an invisible user or an
-invisible sniffing AS is because they do represent real physical 3rd party
-endpoints in the PSTN, and need to be able to send return messages.
-
-Communication with an actual PSTN user happens in a normal Matrix room, which
-for 1:1 matrix<->pstn contact will typically store all conversation history
-with that user. On first contact, the matrix user invites the virtual user
-into the room (or vice versa). In the event of switching to another AS-enabled
-HS, the matrix user would kick the old AS and invite the new one. In the event
-of needing loadbalancing between two SMS gateways (for instance), the user
-would set visibility flags (TODO: specify per-message ACLs, or use crypto to
-only sign messages so they're visible to certain other users?) to adjust which
-virtual AS users could see which messages in the room.
-
-For group chat, one or more AS virtual users may be invited to a group chat,
-where-upon they will relay all the traffic in that group chat through to their
-PSTN counterpart (and vice versa). This behaviour requires no additional
-functionality beyond that required to support 1:1 chat.
-
-When contacting a user, Matrix clients should check whether a given E.164
-number is already mapped to a real Matrix user by querying the identity
-servers (or subscribing to identity updates for a given E.164 number. TODO: ID
-server subscriptions). If the E.164 number has a validated mapping in the ID
-server to a Matrix ID, then this target ID should be used instead of
-contacting the virtual user.
-
-It's likely that PSTN gateway ASes will need to charge the end-user for use of
-the gateway. The AS must therefore track credit per matrix ID it interacts
-with, and stop gatewaying as desired once credit is exhausted. The task of
-extracting credit from the end-user and adding it to the AS is not covered by
-the Matrix specification.
-
-For SMS routing, options are:
- * Terminate traffic only (from a shared shortcode originator)
- * Two-way traffic via a VMN. To save allocating huge numbers of VMNs to Matrix users, the VMN can be allocated from a pool such that each {caller,callee} tuple is unique (but the caller number will only work from that specific callee).
diff --git a/attic/drafts/reputation_thoughts.rst b/attic/drafts/reputation_thoughts.rst
deleted file mode 100644
index ae427f2d..00000000
--- a/attic/drafts/reputation_thoughts.rst
+++ /dev/null
@@ -1,76 +0,0 @@
-(a stream of incoherent consciousness from matthew which should go somewhere)
-
-Invite-graph based reputation data:
-
-* Users need a reputation score to issue invites or join public rooms.
-* A user can have many reputation scores in different audiences (and perhaps a global average?)
-* A room (degenerate case: user) can align itself with a given audience in order to consume the reputation data for that audience.
-* The people that a user invites inherits a proportion of their reputation.
-* If your reputation in an audience is ever reduced, it similarly reduces the reputation you have ever conveyed to anyone else (which propagates through the invite graph).
-* Users increase reputation by:
-  * Inviting someone.
-  * Upvoting their messages in a room (i.e. for the suitability of that audience)
-* Users decrease reputation by:
-  * Blocking them.
-  * Downvoting their messages in a room (i.e. for the suitability of that audience)
-
-Need to ensure the accounts are of a decent quality - making it harder to create sockpuppet accounts and associating them with real people is more important than the actual reputation problem.
-
-Build a war game simulation to test?
-
-
-Problems:
- * How are audiences defined?  Just a given unique set of users?  Which then makes inheriting reputation easy between audiences - if the overlap is significant, the chances are the reputation rules are the same. 
-   * But is it possible to have the same set of users in two different rooms have different rules for reputation?  Probably yes, as the potential audience may include future invitees or indeed the general public, so history visibility rules should probably also contribute to this.  But given privacy rules can change over time, each room should effectively define its own audience.  So in the end, an audience === a room.
- * Create a large network of fake users, and go and have them all vote up each other's score for a given audience.
-   * This can be solved if the root inviter is penalised, which then destroys all the reputation they conveyed to their graph.
-
-Could Reputation == Power Level (!?!?!)
-
-Inheritence semantics for reputation between different audiences is hard.
-  * You should base the reputation of a stranger on their reputation in other communities that you or your communities have some overlap with.
-  * Do you consider 2nd hand reputation data at all from private rooms?  Or do you look only at the public reputation data?
-
-How do you do these calculations in a byzantine world?
-
-How do you do these calculations whilst preserving privacy?
-  * Only consider reputation data from rooms you are actually in?
-  * Store reputation data in room state?
-  * Have a function (HS? client? AS? spider?) that aggregates reputation data (and proves that the aggregation is accurate, almost like blockchain mining?)?
-  * Or have a separate reputation global db seperate from room state that people contribute metrics into (which gathers the aggregate data into a single place, and makes it easier to query reputation data for strangers)
-
-How do you avoid backstabbing?  (People maliciously ganging up on someone to downvote them)?
-
-How do you avoid a voting war?  (Community fragments; different factions turn up and try to downvote the other)?
- * This is effectively two different audiences emerging in a single room.
- * Perhaps this means we should model audiences separately from rooms.
- * Perhaps audiences are literally ACL groups?  And eventually, one might change the ACLs of a room to eject one of the groups?
- * Or do you just synthesise audiences based on cliques of people who support each other?  The act of upvoting someone is effectively aligning yourself as being part of the same audience?
-
-
-So:
-  * Gather all public upvote/downvotes/invites/blocks in a global DB.
-  * Partition this into audiences based on who votes on who.  Stuff which is read and not complained about could provide a small implicit approval?  Although this makes it easy to flood content to boost your reputation, so bad idea.
-    * Partitioning algorithm could be quite subtle.
-    * You could end up with lots of small audiences (including invalid ones), and it's fairly unclear how they get aggregated into a single view.  How should you treat a stranger who you have no audience-overlap with at all?  Treat them as effectively having zero reputation from your perspective?
-
-Problem:
-  * If the douchebag who invites spammers never says anything, how do you go vote on their reputation?  Should there be some kind of back-propagation?  Or is there explicitly a "this person invited a douchebag" downvote?  Or hang on - how can they ever get reputation in the first place to invite their sockpuppets if they don't say anything (beyond the initial invite)?
-  * What if users simply don't talk in public?  Is it right that we prevent them issuing invites just because they stick to private rooms?  What about inviting people into those private rooms?  I guess the point is that if these are public invites, then they need to have some kind of public reputation, or rely on out-of-band private invitation to establish trust?
-  * Are we rewarding people who don't change their habits?  There's no time component considered here, and we punish people's entire history of invites and rep if they misbehave.  The only way to escape is to create a new identity atm.  Is this a feature or a bug?
-  * How does this handle people's accounts getting 0wn3d and doing things which wipe out their reputation?  => This is always a risk; ignore it.
-  * Do you need a particular level of reputation to be able to vote on people?
-
-Summary?
- * Partition the global population into multiple overlapping clusters called 'audiences' based on mutual(?) upvote/downvote relationships in public rooms.
- * Clusters of the same people but in different rooms could be modelled as separate (but overlapping) clusters.
- * Each audience builds up a reputation score for the global population, blending in damped scores from overlapping audiences.
- * Anyone can upvote/downvote, but the votes will not contribute to your personal opinion unless the voter overlaps with your audience's scoresheet.
- * A room could adopt a given audience (that of the moderators'?) for considering the reputation of who can join, invite people, etc.
- * A user uses their own 'audience of one' scoresheet to put a threshold on filtering out contact from other users (invites, messages, etc).
- * Their personal scoresheet is presumably a blend of all the audiences they are already in.
- * The act of inviting someone gives them some reputation, within your audiences, proportional to your own.  Similarly blocking reduces reputation.
- * If you are downvoted, it retrospectively reduces the weight of all of your upvote/downvotes (at least for audiences that the downvoter's opinion contributes to).  Similarly for upvoting.
- * This penalisation process is transitive.
-
- Do we even need the penalisation stuff if audience partitioning works?
diff --git a/attic/drafts/url_previews.md b/attic/drafts/url_previews.md
deleted file mode 100644
index 665554e1..00000000
--- a/attic/drafts/url_previews.md
+++ /dev/null
@@ -1,76 +0,0 @@
-URL Previews
-============
-
-Design notes on a URL previewing service for Matrix:
-
-Options are:
-
- 1. Have an AS which listens for URLs, downloads them, and inserts an event that describes their metadata.
-   * Pros:
-     * Decouples the implementation entirely from Synapse.
-     * Uses existing Matrix events & content repo to store the metadata.
-   * Cons:
-     * Which AS should provide this service for a room, and why should you trust it?
-     * Doesn't work well with E2E; you'd have to cut the AS into every room
-     * the AS would end up subscribing to every room anyway.
-
- 2. Have a generic preview API (nothing to do with Matrix) that provides a previewing service:
-   * Pros:
-     * Simple and flexible; can be used by any clients at any point
-   * Cons:
-     * If each HS provides one of these independently, all the HSes in a room may needlessly DoS the target URI
-     * We need somewhere to store the URL metadata rather than just using Matrix itself
-     * We can't piggyback on matrix to distribute the metadata between HSes.
-
- 3. Make the synapse of the sending user responsible for spidering the URL and inserting an event asynchronously which describes the metadata.
-   * Pros:
-     * Works transparently for all clients
-     * Piggy-backs nicely on using Matrix for distributing the metadata.
-     * No confusion as to which AS
-   * Cons:
-     * Doesn't work with E2E
-     * We might want to decouple the implementation of the spider from the HS, given spider behaviour can be quite complicated and evolve much more rapidly than the HS.  It's more like a bot than a core part of the server.
-
- 4. Make the sending client use the preview API and insert the event itself when successful.
-   * Pros:
-      * Works well with E2E
-      * No custom server functionality
-      * Lets the client customise the preview that they send (like on FB)
-   * Cons:
-      * Entirely specific to the sending client, whereas it'd be nice if /any/ URL was correctly previewed if clients support it.
-
- 5. Have the option of specifying a shared (centralised) previewing service used by a room, to avoid all the different HSes in the room DoSing the target.
-
-Best solution is probably a combination of both 2 and 4.
- * Sending clients do their best to create and send a preview at the point of sending the message, perhaps delaying the message until the preview is computed?  (This also lets the user validate the preview before sending)
- * Receiving clients have the option of going and creating their own preview if one doesn't arrive soon enough (or if the original sender didn't create one)
-
-This is a bit magical though in that the preview could come from two entirely different sources - the sending HS or your local one.  However, this can always be exposed to users: "Generate your own URL previews if none are available?"
-
-This is tantamount also to senders calculating their own thumbnails for sending in advance of the main content - we are trusting the sender not to lie about the content in the thumbnail.  Whereas currently thumbnails are calculated by the receiving homeserver to avoid this attack.
-
-However, this kind of phishing attack does exist whether we let senders pick their thumbnails or not, in that a malicious sender can send normal text messages around the attachment claiming it to be legitimate.  We could rely on (future) reputation/abuse management to punish users who phish (be it with bogus metadata or bogus descriptions).   Bogus metadata is particularly bad though, especially if it's avoidable.
-
-As a first cut, let's do #2 and have the receiver hit the API to calculate its own previews (as it does currently for image thumbnails).  We can then extend/optimise this to option 4 as a special extra if needed.
-
-API
----
-
-```
-GET /_matrix/media/r0/preview_url?url=http://wherever.com
-200 OK
-{
-    "og:type"        : "article"
-    "og:url"         : "https://twitter.com/matrixdotorg/status/684074366691356672"
-    "og:title"       : "Matrix on Twitter"
-    "og:image"       : "https://pbs.twimg.com/profile_images/500400952029888512/yI0qtFi7_400x400.png"
-    "og:description" : "“Synapse 0.12 is out! Lots of polishing, performance &amp;amp; bugfixes: /sync API, /r0 prefix, fulltext search, 3PID invites https://t.co/5alhXLLEGP”"
-    "og:site_name"   : "Twitter"
-}
-```
-
-* Downloads the URL
-  * If HTML, just stores it in RAM and parses it for OG meta tags
-    * Download any media OG meta tags to the media repo, and refer to them in the OG via mxc:// URIs.
-  * If a media filetype we know we can thumbnail: store it on disk, and hand it to the thumbnailer. Generate OG meta tags from the thumbnailer contents.
-  * Otherwise, don't bother downloading further.
diff --git a/attic/drafts/use_cases.rst b/attic/drafts/use_cases.rst
deleted file mode 100644
index 09172d49..00000000
--- a/attic/drafts/use_cases.rst
+++ /dev/null
@@ -1,317 +0,0 @@
-General UI/UX requirements:
-===========================
-- Live updates
-- No flicker:
-   * Sending message (local echo)
-   * Receiving images (encoding w/h)
-   * Scrollback
-   * Resolving display names (from user ID)
-- Fast startup times
-- Fast "opening room" times (esp. when clicking through from a notification)
-- Low latency file transfer.
-
-Use cases
----------
-- #1: Lightweight IM client (no perm storage) - e.g. Web client
-- #2: Bug tracking software
-- #3: Forum
-- #4: Google + style communities
-- #5: Email style threading
-- #6: Multi-column threaded IM
-- #7: Mobile IM client (perm storage)
-- #8: MIDI client
-- #9: Animatrix client
-- #10: Unity object trees
-- #11: Social Network ("Walls", PMs, groups)
-- #12: Minecraft-clone
-- #13: Global 'Like' widget, which links through to a room.
-
-
-#1 Web client UI
-================
-
-Model::
-
- Rooms ----< Messages 
- - name     - type (call/image)
- - topic    
-
-Home Screen
- What's visible:
-  - Recent chats ordered by timestamp of latest event (with # users)
-  - Your own display name, user ID and avatar url
-  - A searchable list of public rooms (with # users and alias + room name + room topic)
- What you can do:
-  - Create a room (public/private, with alias)
-  - Join a room from alias
-  - Message a user (with user ID)
-  - Leave a recent room
-  - Open a room
-  - Open a chat history link.
-  - Search for a public room.
-
-Chat Screen
- What's visible:
-  - Enough scrollback to fill a "screen full" of content.
-  - Each message: timestamp, user ID, display name at the time the message was
-    sent, avatar URL at the time the message was sent, whether it was a bing message
-    or not.
-  - User list: for each user: presence, current avatar url in the room, current
-    display name in the room, power level, ordered by when they were last speaking.
-  - Recents list: (same as Home Screen)
-  - Room name
-  - Room topic
-  - Typing notifications
-  - Desktop/Push Notifications for messages
- What you can do:
-  - Invite a user
-  - Kick a user
-  - Ban/Unban a user
-  - Leave the room
-  - Send a message (image/text/emote)
-  - Change someone's power level
-  - Change your own display name
-  - Accept an incoming call
-  - Make an outgoing call
-  - Get older messages by scrolling up (scrollback)
-  - Redact a message
-  - Resend a message which was not sent
- Message sending:
-  - Immediate local echo
-  - Queue up messages which haven't been sent yet
-  - Reordering local echo to where it actually happened
- VoIP:
-  - One entry in your display for a call (which may contain duration, type, status)
-  - Glare resolution
- Scrollback:
-  - Display in reverse chronological order by the originating server's timestamp
-  - Terminates at the start of the room (which then makes it impossible to request
-    more scrollback)
- Local storage:
-  - Driven by desire for fast startup times and minimal network traffic
-  - Display messages from storage and from the network without any gaps in messages.
-  - Persist scrollback if possible: Scrollback from storage first then from the 
-    network.
- Notifications:
-  - Receive notifications for rooms you're interested in (explicitly or from a default)
-  - Maybe per device.
-  - Maybe depending on presence (e.g. idle)
-  - Maybe depending on message volume
-  - Maybe depending on room config options.
- Message contents:
-  - images
-  - video
-  - rich text
-  - audio
-  - arbitrary files
-  - location
-  - vcards (potentially)
-
-Chat History Screen
- What's visible:
-  - The linked message and enough scrollback to fill a "screen full" of content.
-  - Each message: timestamp, user ID, display name at the time the message was
-    sent, avatar URL at the time the message was sent, whether it was a bing message
-    or not.
-  - The historical user list. *TODO: Is this taken at the linked message, or at
-    wherever the user has scrolled to?*
- What you can do:
-  - Get older messages by scrolling up (scrollback)
-  - Get newer messages by scrolling down
-
-Public Room Search Screen
- What's visible:
-  - The current search text.
-  - The homeserver being searched (defaults to the HS the client is connected to).
-  - The results of the current search with enough results to fill the screen
-    with # users and alias + room name + room topic.
- What you can do:
-  - Change what you are searching for.
-  - Change the server that's being searched.
-  - Scroll down to get more search results.
-
-User screen
- What's visible:
-  - Display name
-  - Avatar
-  - User ID
- What you can do:
-  - Start a chat with the user
-
-
-#2 Bug tracking UI
-==================
-
-Model::
-
- Projects ----< Issues ---< Comments
- - key        - summary     - user
- - name       - ID          - message
-  SYN         SYN-52       Fix it nooow!
-
-Landing page
- What's visible:
-  - Issues assigned to me
-  - Issues I'm watching
-  - Recent activity on other issues (not refined to me)
-  - List of projects
- What you can do:
-  - View an issue
-  - Create an issue
-  - Sort issues
-  - View a user
-  - View a project
-  - Search for issues (by name, time, priority, description contents, reporter, etc...)
-
-Issue page
- What's visible:
-  - Summary of issue
-  - Issue key
-  - Project affected
-  - Description
-  - Comments
-  - Priority, labels, type, purpose, etc..
-  - Reporter/assignee
-  - Creation and last updated times
-  - History of issue changes
- What you can do:
-  - Comment on issue
-  - Change issue info (labels, type, purpose, etc..)
-  - Open/Close/Resolve the issue
-  - Edit the issue
-  - Watch/Unwatch the issue
- 
- 
-#3 Forum UI
-===========
-
-Model::
-
- Forum ----< Boards ----< Threads ----< Messages
- - Matrix   - Dev        - HALP!        - please halp!
-
-Main page
- What's visible:
-  - Categories (containing boards)
-  - Boards (with names and # posts and tagline and latest post)
- What you can do:
-  - View a board
-  - View the latest message on a board
- 
-Board page
- What's visible:
-  - Threads (titles, OP, latest post date+author, # replies, # upvotes, whether 
-    the OP contains an image or hyperlink (small icon on title))
-  - Whether the thread is answered (with link to the answer)
-  - Pagination for posts within a thread (1,2,3,4,5...10)
-  - Pagination for threads within a board 
-  - List of threads in chronological order
-  - Stickied threads
- What you can do:
-  - View a user
-  - View a thread on a particular page
-  - View the latest message on a thread
-  - View older threads (pagination)
-  - Search the board
- 
-Thread page
- What's visible:
-  - Messages in chronological order
-  - For each message: author, timestamp, # posts by author, avatar, registration
-    date, status message, message contents, # views of message
- What you can do:
-  - Upvote the message
-  - Flag the message for a mod
-  - Reply to the message
-  - Subscribe to thread or message's RSS feed
-  - Go to previous/next thread
-
- 
-#4 Google+ community
-====================
-
-Model::
-
- Community -----< Categories ----< Posts ---< Comments
- Kerbal SP       Mods, Help        Text        Text
-                                 (no title!)
-
-Communities page
- What's visible:
-  - List of communities
-  - For each community: # users, # posts, group pic, title
- What you can do:
-  - Join a community
-  - View a community
-  
-Community Page
- What's visible:
-  - Title, pic
-  - List of categories
-  - List of members with avatars (+ total #)
-  - Most recent posts with comments (most recent comment if >1)
- What you can do:
-  - Join the group
-  - Post a post (with voting and options)
-  - Report abuse
-  - View member
-  - Expand comments
-  - Infinite scrolling
-  - Add a comment to a post
-  - Share a post
-  - +1 a post
-
-#5 Email style threading
-========================
-
-Chat Screen
- What's visible:
-  - Enough scrollback to fill a "screen full" of content.
-  - Threads:
-
-    - Initially will only display the timestamp and user ID of the *first*
-      message. But can expand to show the entire tree.
-    - Tree of messages indicating which message is a reply to which.
-    - Ordered by the arbitrary field (timestamp of oldest message in thread;
-      newest message in thread; sender id; sender display name; etc)
-    - Each message: timestamp, user ID, display name at the time of the message
-  - Room name
-  - Room topic
-  - Typing notifications
-  - Desktop/Push Notifications for messages
- What you can do:
-  - Send a message in reply to another message:
-
-    - Immediate local echo, may cause messages to re-order
-    - Messages that haven't reached the server are queued.
-    - Thread is displayed where it should be in the thread order once the
-      message is sent.
-  - Start a new thread by sending a message.
-
-#6 Multi-threaded IM
-====================
-
-Chat Screen
- What's visible:
-  - A multi-column grid of threads from a number of chatrooms
-    Each concurrent thread is displayed in a different column.
-    The columns start and end as threads split and rejoin the main conversation
-    The messages for each thread are ordered by how recent they are::
-
-      Room #1        Room # 2           Room # 2
-      +------------+ +----------------+ Side thread.
-      | * Message1 | | * Root         | +--------------+
-      | * Message2 | | * A1 -> Root   | | * B1 -> Root |
-      +------------+ | * A2 -> A1     | | * B2 -> B1   |
-                     | * M -> A2, B2  | +--------------+
-                     +----------------+
-
-  - Typing notifications. Displayed within the correct thread/column.
-
- What you can do:
-   - Send a message into a particular thread/column.
-   - Move an *existing* message into a new thread creating a new column
-   - Move an existing message into an existing thread, causing the threads to
-     reconverge (i.e. provide a route from the sidebar back into the existing
-     thread).  This does not imply terminating the thread, which can continue
-     independently of the merge.
diff --git a/attic/drafts/websockets.rst b/attic/drafts/websockets.rst
deleted file mode 100644
index 0fe8d968..00000000
--- a/attic/drafts/websockets.rst
+++ /dev/null
@@ -1,288 +0,0 @@
-WebSockets API
-==============
-
-Introduction
-------------
-This document is a proposal for a WebSockets-based client-server API. It is not
-intended to replace the REST API, but rather to complement it and provide an
-alternative interface for certain operations.
-
-The primary goal is to offer a more efficient interface than the REST API: by
-using a bidirectional protocol such as WebSockets we can avoid the overheads
-involved in long-polling (SSL negotiation, HTTP headers, etc). In doing so we
-will reduce the latency between server and client by allowing the server to
-send events as soon as they arrive, rather than having to wait for a poll from
-the client.
-
-Note: This proposal got continued in a google document you can find here:
-https://docs.google.com/document/d/104ClehFBgqLQbf4s-AKX2ijr8sOAxcizfcRs_atsB0g
-
-Handshake
----------
-1. Instead of calling ``/sync``, the client makes a websocket request to
-   ``/_matrix/client/rN/stream``, passing the query parameters ``access_token``
-   and ``since``, and optionally ``filter`` - all of which have the same
-   meaning as for ``/sync``.
-
-   * The client sets the ``Sec-WebSocket-Protocol`` to ``m.json``. (Servers may
-     offer alternative encodings; at present only the JSON encoding is
-     specified but in future we will specify alternative encodings.)
-
-#. The server returns the websocket handshake; the socket is then connected.
-
-If the server does not return a valid websocket handshake, this indicates that
-the server or an intermediate proxy does not support WebSockets. In this case,
-the client should fall back to polling the ``/sync`` REST endpoint.
-
-Example
-~~~~~~~
-
-Client request:
-
-.. code:: http
-
-    GET /_matrix/client/v2_alpha/stream?access_token=123456&since=s72594_4483_1934 HTTP/1.1
-    Host: matrix.org
-    Upgrade: websocket
-    Connection: Upgrade
-    Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
-    Sec-WebSocket-Protocol: m.json
-    Sec-WebSocket-Version: 13
-    Origin: https://matrix.org
-
-Server response:
-
-.. code:: http
-
-    HTTP/1.1 101 Switching Protocols
-    Upgrade: websocket
-    Connection: Upgrade
-    Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
-    Sec-WebSocket-Protocol: m.json
-
-
-Update Notifications
---------------------
-Once the socket is connected, the server begins streaming updates over the
-websocket. The server sends Update notifications about new messages or state
-changes. To make it easy for clients to parse, Update notifications have the
-same structure as the response to ``/sync``: an object with the following
-members:
-
-============= ========== ===================================================
-Key           Type       Description
-============= ========== ===================================================
-next_batch    string     The batch token to supply in the ``since`` param of
-                         the next /sync request. This is not required for
-                         streaming of events over the WebSocket, but is
-                         provided so that clients can reconnect if the
-                         socket is disconnected.
-presence      Presence   The updates to the presence status of other users.
-rooms         Rooms      Updates to rooms.
-============= ========== ===================================================
-
-Example
-~~~~~~~
-Message from the server:
-
-.. code:: json
-
-    {
-        "next_batch": "s72595_4483_1934",
-        "presence": {
-            "events": []
-        },
-        "rooms": {
-            "join": {},
-            "invite": {},
-            "leave": {}
-        }
-    }
-
-
-Client-initiated operations
----------------------------
-
-The client can perform certain operations by sending a websocket message to
-the server. Such a "Request" message should be a JSON-encoded object with
-the following members:
-
-============= ========== ===================================================
-Key           Type       Description
-============= ========== ===================================================
-id            string     A unique identifier for this request
-method        string     Specifies the name of the operation to be
-                         performed; see below for available operations
-param         object     The parameters for the requested operation.
-============= ========== ===================================================
-
-The server responds to a client Request with a Response message. This is a
-JSON-encoded object with the following members:
-
-============= ========== ===================================================
-Key           Type       Description
-============= ========== ===================================================
-id            string     The same as the value in the corresponding Request
-                         object. The presence of the ``id`` field
-                         distinguishes a Response message from an Update 
-                         notification.
-result        object     On success, the results of the request.
-error         object     On error, an object giving the resons for the
-                         error. This has the same structure as the "standard
-                         error response" for the Matrix API: an object with
-                         the fields ``errcode`` and ``error``.
-============= ========== ===================================================
-
-Request methods
-~~~~~~~~~~~~~~~
-It is not intended that all operations which are available via the REST API
-will be available via the WebSockets API, but a few simple, common operations
-will be exposed. The initial operations will be as follows.
-
-``ping``
-^^^^^^^^
-This is a no-op which clients may use to keep their connection alive.
-
-The request ``params`` and the response ``result`` should be empty.
-
-``send``
-^^^^^^^^
-Send a message event to a room. The parameters are as follows:
-
-============= ========== ===================================================
-Parameter     Type       Description
-============= ========== ===================================================
-room_id       string     **Required.** The room to send the event to
-event_type    string     **Required.** The type of event to send.
-content       object     **Required.** The content of the event.
-============= ========== ===================================================
-
-The result is as follows:
-
-============= ========== ===================================================
-Key           Type       Description
-============= ========== ===================================================
-event_id      string     A unique identifier for the event.
-============= ========== ===================================================
-
-The ``id`` from the Request message is used as the transaction ID by the
-server.
-
-``state``
-^^^^^^^^^
-Update the state on a room.
-
-============= ========== ===================================================
-Parameter     Type       Description
-============= ========== ===================================================
-room_id       string     **Required.** The room to set the state in
-event_type    string     **Required.** The type of event to send.
-state_key     string     **Required.** The state_key for the state to send.
-content       object     **Required.** The content of the event.
-============= ========== ===================================================
-
-The result is as follows:
-
-============= ========== ===================================================
-Key           Type       Description
-============= ========== ===================================================
-event_id      string     A unique identifier for the event.
-============= ========== ===================================================
-
-
-Example
-~~~~~~~
-Client request:
-
-.. code:: json
-
-    {
-        "id": "12345",
-        "method": "send",
-        "params": {
-            "room_id": "!d41d8cd:matrix.org",
-            "event_type": "m.room.message",
-            "content": {
-                "msgtype": "m.text",
-                "body": "hello"
-            }
-        }
-    }
-
-Server response:
-
-.. code:: json
-
-    {
-        "id": "12345",
-        "result": {
-            "event_id": "$66697273743031:matrix.org"
-        }
-    }
-
-Alternative server response, in case of error:
-
-.. code:: json
-
-    {
-        "id": "12345",
-        "error": {
-           "errcode": "M_MISSING_PARAM",
-           "error": "Missing parameter: event_type"
-        }
-    }
-
-
-Rationale
----------
-Alternatives to WebSockets include HTTP/2, CoAP, and simply rolling our own
-protocol over raw TCP sockets. However, the need to implement browser-based
-clients essentially reduces our choice to WebSockets. HTTP/2 streams will
-probably provide an interesting alternative in the future, but current browsers
-do not appear to give javascript applications low-level access to the protocol.
-
-Concerning the continued use of the JSON encoding: we prefer to focus on the
-transition to WebSockets initially. Replacing JSON with a compact
-representation such as CBOR, MessagePack, or even just compressed JSON will be
-a likely extension for the future. The support for negotiation of subprotocols
-within WebSockets should make this a simple transition once time permits.
-
-The number of methods available for client requests is deliberately limited, as
-each method requires code to be written to map it onto the equivalent REST
-implementation. Some REST methods - for instance, user registration and login -
-would be pointless to expose via WebSockets. It is likely, however, that we
-will increate the number of methods available via the WebSockets API as it
-becomes clear which would be most useful.
-
-Open questions
---------------
-
-Throttling
-~~~~~~~~~~
-At least in v2 sync, clients are inherently self-throttling - if they do not
-poll quickly enough, events will be dropped from the next result. This proposal
-raises the possibility that events will be produced more quickly than they can
-be sent to the client; backlogs will build up on the server and/or in the
-intermediate network, which will not only lead to high latency on events being
-delivered, but will lead to responses to client requests also being delayed.
-
-We may need to implement some sort of throttling mechanism by which the server
-can start to drop events. The difficulty is in knowing when to start dropping
-events. A few ideas:
-
-* Use websocket pings to measure the RTT; if it starts to increase, start
-  dropping events. But this requires knowledge of the base RTT, and a useful
-  model of what constitutes an excessive increase.
-
-* Have the client acknowledge each batch of events, and use a window to ensure
-  the number of outstanding batches is limited. This is annoying as it requires
-  the client to have to acknowledge batches - and it's not clear what the right
-  window size is: we want a big window for long fat networks (think of mobile
-  clients), but a small one for one with lower latency.
-
-* Start dropping events if the server's TCP buffer starts filling up. This has
-  the advantage of delegating the congestion-detection to TCP (which already
-  has a number of algorithms to deal with it, to greater or lesser
-  effectiveness), but relies on homeservers being hosted on OSes which use
-  sensible TCP congestion-avoidance algorithms, and more critically, an ability
-  to read the fill level of the TCP send buffer.
diff --git a/attic/v1_registration_login.rst b/attic/v1_registration_login.rst
deleted file mode 100644
index 1364319b..00000000
--- a/attic/v1_registration_login.rst
+++ /dev/null
@@ -1,343 +0,0 @@
-Registration and Login
-----------------------
-
-Clients must register with a homeserver in order to use Matrix. After
-registering, the client will be given an access token which must be used in ALL
-requests to that homeserver as a query parameter 'access_token'.
-
-If the client has already registered, they need to be able to login to their
-account. The homeserver may provide many different ways of logging in, such as
-user/password auth, login via a social network (OAuth2), login by confirming a
-token sent to their email address, etc. This specification does not define how
-homeservers should authorise their users who want to login to their existing
-accounts, but instead defines the standard interface which implementations
-should follow so that ANY client can login to ANY homeserver. Clients login
-using the |login|_ API. Clients register using the |register|_ API.
-Registration follows the same general procedure as login, but the path requests
-are sent to and the details contained in them are different.
-
-In both registration and login cases, the process takes the form of one or more
-stages, where at each stage the client submits a set of data for a given stage
-type and awaits a response from the server, which will either be a final
-success or a request to perform an additional stage. This exchange continues
-until the final success.
-
-In order to determine up-front what the server's requirements are, the client
-can request from the server a complete description of all of its acceptable
-flows of the registration or login process. It can then inspect the list of
-returned flows looking for one for which it believes it can complete all of the
-required stages, and perform it. As each homeserver may have different ways of
-logging in, the client needs to know how they should login. All distinct login
-stages MUST have a corresponding ``type``. A ``type`` is a namespaced string
-which details the mechanism for logging in.
-
-A client may be able to login via multiple valid login flows, and should choose
-a single flow when logging in. A flow is a series of login stages. The home
-server MUST respond with all the valid login flows when requested by a simple
-``GET`` request directly to the ``/login`` or ``/register`` paths::
-
-  {
-    "flows": [
-      {
-        "type": "<login type1a>",
-        "stages": [ "<login type 1a>", "<login type 1b>" ]
-      },
-      {
-        "type": "<login type2a>",
-        "stages": [ "<login type 2a>", "<login type 2b>" ]
-      },
-      {
-        "type": "<login type3>"
-      }
-    ]
-  }
-
-The client can now select which flow it wishes to use, and begin making
-``POST`` requests to the ``/login`` or ``/register`` paths with JSON body
-content containing the name of the stage as the ``type`` key, along with
-whatever additional parameters are required for that login or registration type
-(see below). After the flow is completed, the client's fully-qualified user
-ID and a new access token MUST be returned::
-
-  {
-    "user_id": "@user:matrix.org",
-    "access_token": "abcdef0123456789"
-  }
-
-The ``user_id`` key is particularly useful if the homeserver wishes to support
-localpart entry of usernames (e.g. "user" rather than "@user:matrix.org"), as
-the client may not be able to determine its ``user_id`` in this case.
-
-If the flow has multiple stages to it, the homeserver may wish to create a
-session to store context between requests. If a homeserver responds with a
-``session`` key to a request, clients MUST submit it in subsequent requests
-until the flow is completed::
-
-  {
-    "session": "<session id>"
-  }
-
-This specification defines the following login types:
- - ``m.login.password``
- - ``m.login.oauth2``
- - ``m.login.email.code``
- - ``m.login.email.url``
- - ``m.login.email.identity``
-
-Password-based
-~~~~~~~~~~~~~~
-:Type:
-  ``m.login.password``
-:Description:
-  Login is supported via a username and password.
-
-To respond to this type, reply with::
-
-  {
-    "type": "m.login.password",
-    "user": "<user_id or user localpart>",
-    "password": "<password>"
-  }
-
-The homeserver MUST respond with either new credentials, the next stage of the
-login process, or a standard error response.
-
-Captcha-based
-~~~~~~~~~~~~~
-:Type:
-  ``m.login.recaptcha``
-:Description:
-  Login is supported by responding to a captcha (in the case of the Synapse
-  implementation, Google's Recaptcha library is used).
-
-To respond to this type, reply with::
-
-  {
-    "type": "m.login.recaptcha",
-    "challenge": "<challenge token>",
-    "response": "<user-entered text>"
-  }
-
-.. NOTE::
-  In Synapse, the Recaptcha parameters can be obtained in Javascript by calling:
-    Recaptcha.get_challenge();
-    Recaptcha.get_response();
-
-The homeserver MUST respond with either new credentials, the next stage of the
-login process, or a standard error response.
-
-OAuth2-based
-~~~~~~~~~~~~
-:Type:
-  ``m.login.oauth2``
-:Description:
-  Login is supported via OAuth2 URLs. This login consists of multiple requests.
-
-To respond to this type, reply with::
-
-  {
-    "type": "m.login.oauth2",
-    "user": "<user_id or user localpart>"
-  }
-
-The server MUST respond with::
-
-  {
-    "uri": <Authorization Request URI OR service selection URI>
-  }
-
-The homeserver acts as a 'confidential' client for the purposes of OAuth2.  If
-the uri is a ``sevice selection URI``, it MUST point to a webpage which prompts
-the user to choose which service to authorize with. On selection of a service,
-this MUST link through to an ``Authorization Request URI``. If there is only 1
-service which the homeserver accepts when logging in, this indirection can be
-skipped and the "uri" key can be the ``Authorization Request URI``.
-
-The client then visits the ``Authorization Request URI``, which then shows the
-OAuth2 Allow/Deny prompt. Hitting 'Allow' returns the ``redirect URI`` with the
-auth code.  Homeservers can choose any path for the ``redirect URI``. The
-client should visit the ``redirect URI``, which will then finish the OAuth2
-login process, granting the homeserver an access token for the chosen service.
-When the homeserver gets this access token, it verifies that the cilent has
-authorised with the 3rd party, and can now complete the login. The OAuth2
-``redirect URI`` (with auth code) MUST respond with either new credentials, the
-next stage of the login process, or a standard error response.
-
-For example, if a homeserver accepts OAuth2 from Google, it would return the
-Authorization Request URI for Google::
-
-  {
-    "uri": "https://accounts.google.com/o/oauth2/auth?response_type=code&
-    client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos"
-  }
-
-The client then visits this URI and authorizes the homeserver. The client then
-visits the REDIRECT_URI with the auth code= query parameter which returns::
-
-  {
-    "user_id": "@user:matrix.org",
-    "access_token": "0123456789abcdef"
-  }
-
-Email-based (code)
-~~~~~~~~~~~~~~~~~~
-:Type:
-  ``m.login.email.code``
-:Description:
-  Login is supported by typing in a code which is sent in an email. This login
-  consists of multiple requests.
-
-To respond to this type, reply with::
-
-  {
-    "type": "m.login.email.code",
-    "user": "<user_id or user localpart>",
-    "email": "<email address>"
-  }
-
-After validating the email address, the homeserver MUST send an email
-containing an authentication code and return::
-
-  {
-    "type": "m.login.email.code",
-    "session": "<session id>"
-  }
-
-The second request in this login stage involves sending this authentication
-code::
-
-  {
-    "type": "m.login.email.code",
-    "session": "<session id>",
-    "code": "<code in email sent>"
-  }
-
-The homeserver MUST respond to this with either new credentials, the next
-stage of the login process, or a standard error response.
-
-Email-based (url)
-~~~~~~~~~~~~~~~~~
-:Type:
-  ``m.login.email.url``
-:Description:
-  Login is supported by clicking on a URL in an email. This login consists of
-  multiple requests.
-
-To respond to this type, reply with::
-
-  {
-    "type": "m.login.email.url",
-    "user": "<user_id or user localpart>",
-    "email": "<email address>"
-  }
-
-After validating the email address, the homeserver MUST send an email
-containing an authentication URL and return::
-
-  {
-    "type": "m.login.email.url",
-    "session": "<session id>"
-  }
-
-The email contains a URL which must be clicked. After it has been clicked, the
-client should perform another request::
-
-  {
-    "type": "m.login.email.url",
-    "session": "<session id>"
-  }
-
-The homeserver MUST respond to this with either new credentials, the next
-stage of the login process, or a standard error response.
-
-A common client implementation will be to periodically poll until the link is
-clicked.  If the link has not been visited yet, a standard error response with
-an errcode of ``M_LOGIN_EMAIL_URL_NOT_YET`` should be returned.
-
-
-Email-based (identity server)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-:Type:
-  ``m.login.email.identity``
-:Description:
-  Login is supported by authorising an email address with an identity server.
-
-Prior to submitting this, the client should authenticate with an identity
-server.  After authenticating, the session information should be submitted to
-the homeserver.
-
-To respond to this type, reply with::
-
-  {
-    "type": "m.login.email.identity",
-    "threepidCreds": [
-      {
-        "sid": "<identity server session id>",
-        "clientSecret": "<identity server client secret>",
-        "idServer": "<url of identity server authed with, e.g. 'matrix.org:8090'>"
-      }
-    ]
-  }
-
-
-
-N-Factor Authentication
-~~~~~~~~~~~~~~~~~~~~~~~
-Multiple login stages can be combined to create N-factor authentication during
-login.
-
-This can be achieved by responding with the ``next`` login type on completion
-of a previous login stage::
-
-  {
-    "next": "<next login type>"
-  }
-
-If a homeserver implements N-factor authentication, it MUST respond with all
-``stages`` when initially queried for their login requirements::
-
-  {
-    "type": "<1st login type>",
-    "stages": [ <1st login type>, <2nd login type>, ... , <Nth login type> ]
-  }
-
-This can be represented conceptually as::
-
-   _______________________
-  |    Login Stage 1      |
-  | type: "<login type1>" |
-  |  ___________________  |
-  | |_Request_1_________| | <-- Returns "session" key which is used throughout.
-  |  ___________________  |
-  | |_Request_2_________| | <-- Returns a "next" value of "login type2"
-  |_______________________|
-            |
-            |
-   _________V_____________
-  |    Login Stage 2      |
-  | type: "<login type2>" |
-  |  ___________________  |
-  | |_Request_1_________| |
-  |  ___________________  |
-  | |_Request_2_________| |
-  |  ___________________  |
-  | |_Request_3_________| | <-- Returns a "next" value of "login type3"
-  |_______________________|
-            |
-            |
-   _________V_____________
-  |    Login Stage 3      |
-  | type: "<login type3>" |
-  |  ___________________  |
-  | |_Request_1_________| | <-- Returns user credentials
-  |_______________________|
-
-Fallback
-~~~~~~~~
-Clients cannot be expected to be able to know how to process every single login
-type. If a client determines it does not know how to handle a given login type,
-it should request a login fallback page::
-
-  GET matrix/client/api/v1/login/fallback
-
-This MUST return an HTML page which can perform the entire login process.
diff --git a/changelogs/README.md b/changelogs/README.md
deleted file mode 100644
index 2e9bdf6e..00000000
--- a/changelogs/README.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Changelogs
-
-[Towncrier](https://github.com/hawkowl/towncrier) is used to manage the changelog and
-keep it up to date. Because of this, updating a changelog is really easy.
-
-## Generating the changelog
-
-Please see the [release docs](../meta/releasing.md) for more information.
-
-## Creating a new changelog
-
-There are a few places you'll have to update:
-* `/layouts/shortcodes/changelog/changelog-changes.html` to account for the new changelog.
-* `/scripts/generate-changelog.sh` to render the changelog for releases.
-* Supporting documentation such as the contributing guidelines.
diff --git a/changelogs/appendices/newsfragments/.gitignore b/changelogs/appendices/newsfragments/.gitignore
deleted file mode 100644
index b722e9e1..00000000
--- a/changelogs/appendices/newsfragments/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-!.gitignore
\ No newline at end of file
diff --git a/changelogs/application_service/newsfragments/.gitignore b/changelogs/application_service/newsfragments/.gitignore
deleted file mode 100644
index b722e9e1..00000000
--- a/changelogs/application_service/newsfragments/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-!.gitignore
\ No newline at end of file
diff --git a/changelogs/client_server/newsfragments/.gitignore b/changelogs/client_server/newsfragments/.gitignore
deleted file mode 100644
index b722e9e1..00000000
--- a/changelogs/client_server/newsfragments/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-!.gitignore
\ No newline at end of file
diff --git a/changelogs/client_server/newsfragments/3669.clarification b/changelogs/client_server/newsfragments/3669.clarification
deleted file mode 100644
index 795c0de9..00000000
--- a/changelogs/client_server/newsfragments/3669.clarification
+++ /dev/null
@@ -1 +0,0 @@
-Remove unenforced size limit on the `name` field of `m.room.name` events.
\ No newline at end of file
diff --git a/changelogs/client_server/newsfragments/3679.clarification b/changelogs/client_server/newsfragments/3679.clarification
deleted file mode 100644
index 93f416fc..00000000
--- a/changelogs/client_server/newsfragments/3679.clarification
+++ /dev/null
@@ -1 +0,0 @@
-Remove erroneous `room_id` field from examples of `m.read`, `m.typing` in `/sync` and `m.fully_read` in room account data.
\ No newline at end of file
diff --git a/changelogs/client_server/newsfragments/3681.clarification b/changelogs/client_server/newsfragments/3681.clarification
deleted file mode 100644
index f7c29003..00000000
--- a/changelogs/client_server/newsfragments/3681.clarification
+++ /dev/null
@@ -1 +0,0 @@
-Fix broken syntax in Server Access Control Lists definition.
\ No newline at end of file
diff --git a/changelogs/client_server/newsfragments/3690.clarification b/changelogs/client_server/newsfragments/3690.clarification
deleted file mode 100644
index acdd558d..00000000
--- a/changelogs/client_server/newsfragments/3690.clarification
+++ /dev/null
@@ -1 +0,0 @@
-Clarify the behaviour of `event_match` in push rule conditions.
diff --git a/changelogs/client_server/newsfragments/3708.clarification b/changelogs/client_server/newsfragments/3708.clarification
deleted file mode 100644
index 3ccb2333..00000000
--- a/changelogs/client_server/newsfragments/3708.clarification
+++ /dev/null
@@ -1 +0,0 @@
-Fix various typos throughout the specification.
diff --git a/changelogs/client_server/newsfragments/3711.clarification b/changelogs/client_server/newsfragments/3711.clarification
deleted file mode 100644
index c3f8d853..00000000
--- a/changelogs/client_server/newsfragments/3711.clarification
+++ /dev/null
@@ -1 +0,0 @@
-Fix incorrectly referenced `m.login.appservice` login identifier, instead using `m.login.application_service`.
diff --git a/changelogs/client_server/newsfragments/3730.clarification b/changelogs/client_server/newsfragments/3730.clarification
deleted file mode 100644
index 823b3403..00000000
--- a/changelogs/client_server/newsfragments/3730.clarification
+++ /dev/null
@@ -1 +0,0 @@
-Fix membership state transitions to denote that `invite->knock` and `external->leave` are valid transitions.
\ No newline at end of file
diff --git a/changelogs/header.md b/changelogs/header.md
deleted file mode 100644
index 2b98c8a1..00000000
--- a/changelogs/header.md
+++ /dev/null
@@ -1,16 +0,0 @@
-<!--
-This is a header file for the generated changelog.
-
-Variables:
-    VERSION  = Replaced by the version number (eg: v1.2)
-    DATE     = Replaced by the date (eg: April 01, 2021)
--->
-
-## VERSION
-
-<table class="release-info">
-<tr><th>Git commit</th><td><a href="https://github.com/matrix-org/matrix-doc/tree/VERSION">https://github.com/matrix-org/matrix-doc/tree/VERSION</a></td>
-<tr><th>Release date</th><td>DATE</td>
-</table>
-
-<!-- Intentionally blank line to ensure headers work in the concatenated changelog -->
diff --git a/changelogs/identity_service/newsfragments/.gitignore b/changelogs/identity_service/newsfragments/.gitignore
deleted file mode 100644
index b722e9e1..00000000
--- a/changelogs/identity_service/newsfragments/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-!.gitignore
\ No newline at end of file
diff --git a/changelogs/legacy/application_service.rst b/changelogs/legacy/application_service.rst
deleted file mode 100644
index 51a97637..00000000
--- a/changelogs/legacy/application_service.rst
+++ /dev/null
@@ -1,26 +0,0 @@
-r0.1.2
-======
-
-Spec Clarifications
--------------------
-
-- Clearer wording for the legacy routes section. (`#2160 <https://github.com/matrix-org/matrix-doc/issues/2160>`_)
-
-
-r0.1.1
-======
-
-Spec Clarifications
--------------------
-
-- Change examples to use example.org instead of a real domain. (`#1650 <https://github.com/matrix-org/matrix-doc/issues/1650>`_)
-- Add missing definition for how appservices verify requests came from a homeserver. (`#2037 <https://github.com/matrix-org/matrix-doc/issues/2037>`_)
-
-
-r0.1.0
-======
-
-This is the first release of the Application Service specification. It
-includes support for application services being able to interact with
-homeservers and bridge third party networks, such as IRC, over to Matrix
-in a standard and accessible way.
diff --git a/changelogs/legacy/client_server.rst b/changelogs/legacy/client_server.rst
deleted file mode 100644
index c5b8fae9..00000000
--- a/changelogs/legacy/client_server.rst
+++ /dev/null
@@ -1,575 +0,0 @@
-r0.6.1
-======
-
-New Endpoints
--------------
-
-- Added ``/rooms/{roomId}/aliases`` for retrieving local aliases for a room. (`#2562 <https://github.com/matrix-org/matrix-doc/issues/2562>`_)
-
-
-Backwards Compatible Changes
-----------------------------
-
-- Added data structures for defining moderation policies in rooms per `MSC2313 <https://github.com/matrix-org/matrix-doc/pull/2313>`_. (`#2434 <https://github.com/matrix-org/matrix-doc/issues/2434>`_)
-- Optionally invalidate other access tokens during password modification per `MSC2457 <https://github.com/matrix-org/matrix-doc/pull/2457>`_. (`#2523 <https://github.com/matrix-org/matrix-doc/issues/2523>`_)
-- Add User-Interactive Authentication for SSO-backed homeserver per `MSC2454 <https://github.com/matrix-org/matrix-doc/pull/2454>`_. (`#2532 <https://github.com/matrix-org/matrix-doc/issues/2532>`_)
-- Add soft-logout support per `MSC1466 <https://github.com/matrix-org/matrix-doc/issues/1466>`_. (`#2546 <https://github.com/matrix-org/matrix-doc/issues/2546>`_)
-- Replaced legacy room alias handling with a more sustainable solution per `MSC2432 <https://github.com/matrix-org/matrix-doc/pull/2432>`_. (`#2562 <https://github.com/matrix-org/matrix-doc/issues/2562>`_)
-
-
-Spec Clarifications
--------------------
-
-- List available enum values for the room versions capability. (`#2245 <https://github.com/matrix-org/matrix-doc/issues/2245>`_)
-- Fix various spelling errors throughout the specification. (`#2351 <https://github.com/matrix-org/matrix-doc/issues/2351>`_, `#2415 <https://github.com/matrix-org/matrix-doc/issues/2415>`_, `#2453 <https://github.com/matrix-org/matrix-doc/issues/2453>`_, `#2524 <https://github.com/matrix-org/matrix-doc/issues/2524>`_, `#2553 <https://github.com/matrix-org/matrix-doc/issues/2553>`_, `#2569 <https://github.com/matrix-org/matrix-doc/issues/2569>`_)
-- Minor clarifications to token-based User-Interactive Authentication. (`#2369 <https://github.com/matrix-org/matrix-doc/issues/2369>`_)
-- Minor clarification for what the user directory searches. (`#2381 <https://github.com/matrix-org/matrix-doc/issues/2381>`_)
-- Fix key export format example to match the specification. (`#2430 <https://github.com/matrix-org/matrix-doc/issues/2430>`_)
-- Clarify the IV data type for encrypted files. (`#2492 <https://github.com/matrix-org/matrix-doc/issues/2492>`_)
-- Fix the ``.m.rule.contains_user_name`` default push rule to set the highlight tweak. (`#2519 <https://github.com/matrix-org/matrix-doc/issues/2519>`_)
-- Clarify that an ``event_id`` is returned when sending events. (`#2525 <https://github.com/matrix-org/matrix-doc/issues/2525>`_)
-- Fix some numbers in the specification to match their explanation text. (`#2554 <https://github.com/matrix-org/matrix-doc/issues/2554>`_)
-- Move redaction algorithm into the room version specifications. (`#2563 <https://github.com/matrix-org/matrix-doc/issues/2563>`_)
-- Clarify signature object structures for encryption. (`#2566 <https://github.com/matrix-org/matrix-doc/issues/2566>`_)
-- Clarify which events are created as part of ``/createRoom``. (`#2571 <https://github.com/matrix-org/matrix-doc/issues/2571>`_)
-- Remove claims that the homeserver is exclusively responsible for profile information in membership events. (`#2574 <https://github.com/matrix-org/matrix-doc/issues/2574>`_)
-
-
-r0.6.0
-======
-
-Breaking Changes
-----------------
-
-- Add ``id_access_token`` as a required request parameter to a few endpoints which require an ``id_server`` parameter as part of `MSC2140 <https://github.com/matrix-org/matrix-doc/pull/2140>`_. (`#2255 <https://github.com/matrix-org/matrix-doc/issues/2255>`_)
-
-
-New Endpoints
--------------
-
-- Add ``POST /account/3pid/unbind`` for removing a 3PID from an identity server. (`#2282 <https://github.com/matrix-org/matrix-doc/issues/2282>`_)
-
-
-Backwards Compatible Changes
-----------------------------
-
-- Add ``M_USER_DEACTIVATED`` error code. (`#2234 <https://github.com/matrix-org/matrix-doc/issues/2234>`_)
-- Remove ``bind_msisdn`` and ``bind_email`` from ``/register`` now that the identity server's bind endpoint requires authentication. (`#2279 <https://github.com/matrix-org/matrix-doc/issues/2279>`_)
-- Add ``m.identity_server`` account data for tracking the user's preferred identity server. (`#2281 <https://github.com/matrix-org/matrix-doc/issues/2281>`_)
-- Deprecate ``id_server`` and make it optional in several places. (`#2310 <https://github.com/matrix-org/matrix-doc/issues/2310>`_)
-
-
-Spec Clarifications
--------------------
-
-- Add missing format fields to ``m.room.message$m.notice`` schema. (`#2125 <https://github.com/matrix-org/matrix-doc/issues/2125>`_)
-- Remove "required" designation from the ``url`` field of certain ``m.room.message`` msgtypes. (`#2129 <https://github.com/matrix-org/matrix-doc/issues/2129>`_)
-- Fix various typos throughout the specification. (`#2131 <https://github.com/matrix-org/matrix-doc/issues/2131>`_, `#2136 <https://github.com/matrix-org/matrix-doc/issues/2136>`_, `#2148 <https://github.com/matrix-org/matrix-doc/issues/2148>`_, `#2215 <https://github.com/matrix-org/matrix-doc/issues/2215>`_)
-- Clarify the distinction between ``m.key.verification.start`` and its ``m.sas.v1`` variant. (`#2132 <https://github.com/matrix-org/matrix-doc/issues/2132>`_)
-- Fix link to Olm signing specification. (`#2133 <https://github.com/matrix-org/matrix-doc/issues/2133>`_)
-- Clarify the conditions for the ``.m.rule.room_one_to_one`` push rule. (`#2152 <https://github.com/matrix-org/matrix-doc/issues/2152>`_)
-- Clarify the encryption algorithms supported by the device of the device keys example. (`#2157 <https://github.com/matrix-org/matrix-doc/issues/2157>`_)
-- Clarify that ``/rooms/:roomId/event/:eventId`` returns a Matrix error. (`#2204 <https://github.com/matrix-org/matrix-doc/issues/2204>`_)
-- Add a missing ``state_key`` check on ``.m.rule.tombstone``. (`#2223 <https://github.com/matrix-org/matrix-doc/issues/2223>`_)
-- Fix the ``m.room_key_request`` ``action`` value, setting it from ``cancel_request`` to ``request_cancellation``. (`#2247 <https://github.com/matrix-org/matrix-doc/issues/2247>`_)
-- Clarify that the ``submit_url`` field is without authentication. (`#2341 <https://github.com/matrix-org/matrix-doc/issues/2341>`_)
-- Clarify the expected phone number format. (`#2342 <https://github.com/matrix-org/matrix-doc/issues/2342>`_)
-- Clarify that clients should consider not requesting URL previews in encrypted rooms. (`#2343 <https://github.com/matrix-org/matrix-doc/issues/2343>`_)
-- Add missing information on how filters are meant to work with ``/context``. (`#2344 <https://github.com/matrix-org/matrix-doc/issues/2344>`_)
-- Clarify what the keys are for rooms in ``/sync``. (`#2345 <https://github.com/matrix-org/matrix-doc/issues/2345>`_)
-
-
-r0.5.0
-======
-
-Breaking Changes
-----------------
-
-- Add a new ``submit_url`` field to the responses of ``/requestToken`` which older clients will not be able to handle correctly. (`#2101 <https://github.com/matrix-org/matrix-doc/issues/2101>`_)
-
-
-Deprecations
-------------
-
-- Remove references to presence lists. (`#1817 <https://github.com/matrix-org/matrix-doc/issues/1817>`_)
-
-
-New Endpoints
--------------
-
-- ``GET /account_data`` routes. (`#1873 <https://github.com/matrix-org/matrix-doc/issues/1873>`_)
-
-
-Backwards Compatible Changes
-----------------------------
-
-- Add megolm session export format. (`#1701 <https://github.com/matrix-org/matrix-doc/issues/1701>`_)
-- Add support for advertising experimental features to clients. (`#1786 <https://github.com/matrix-org/matrix-doc/issues/1786>`_)
-- Add a generic SSO login API. (`#1789 <https://github.com/matrix-org/matrix-doc/issues/1789>`_)
-- Add a mechanism for servers to redirect clients to an alternative homeserver after logging in. (`#1790 <https://github.com/matrix-org/matrix-doc/issues/1790>`_)
-- Add room version upgrades. (`#1791 <https://github.com/matrix-org/matrix-doc/issues/1791>`_, `#1875 <https://github.com/matrix-org/matrix-doc/issues/1875>`_)
-- Support optional features by having clients query for capabilities. (`#1829 <https://github.com/matrix-org/matrix-doc/issues/1829>`_, `#1879 <https://github.com/matrix-org/matrix-doc/issues/1879>`_)
-- Add ``M_RESOURCE_LIMIT_EXCEEDED`` as an error code for when homeservers exceed limits imposed on them. (`#1874 <https://github.com/matrix-org/matrix-doc/issues/1874>`_)
-- Emit ``M_UNSUPPORTED_ROOM_VERSION`` error codes where applicable on ``/createRoom`` and ``/invite`` APIs. (`#1908 <https://github.com/matrix-org/matrix-doc/issues/1908>`_)
-- Add a ``.m.rule.tombstone`` default push rule for room upgrade notifications. (`#2020 <https://github.com/matrix-org/matrix-doc/issues/2020>`_)
-- Add support for sending server notices to clients. (`#2026 <https://github.com/matrix-org/matrix-doc/issues/2026>`_)
-- Add MSISDN (phone number) support to User-Interactive Authentication. (`#2030 <https://github.com/matrix-org/matrix-doc/issues/2030>`_)
-- Add the option to lazy-load room members for increased client performance. (`#2035 <https://github.com/matrix-org/matrix-doc/issues/2035>`_)
-- Add ``id_server`` to ``/deactivate`` and ``/3pid/delete`` endpoints to unbind from a specific identity server. (`#2046 <https://github.com/matrix-org/matrix-doc/issues/2046>`_)
-- Add support for Olm sessions becoming un-stuck. (`#2059 <https://github.com/matrix-org/matrix-doc/issues/2059>`_)
-- Add interactive device verification, including a common framework for device verification. (`#2072 <https://github.com/matrix-org/matrix-doc/issues/2072>`_)
-
-
-Spec Clarifications
--------------------
-
-- Change examples to use example.org instead of a real domain. (`#1650 <https://github.com/matrix-org/matrix-doc/issues/1650>`_)
-- Clarify that ``state_default`` in ``m.room.power_levels`` always defaults to 50. (`#1656 <https://github.com/matrix-org/matrix-doc/issues/1656>`_)
-- Add missing ``status_msg`` to ``m.presence`` schema. (`#1744 <https://github.com/matrix-org/matrix-doc/issues/1744>`_)
-- Fix various spelling mistakes throughout the specification. (`#1838 <https://github.com/matrix-org/matrix-doc/issues/1838>`_, `#1853 <https://github.com/matrix-org/matrix-doc/issues/1853>`_, `#1860 <https://github.com/matrix-org/matrix-doc/issues/1860>`_, `#1933 <https://github.com/matrix-org/matrix-doc/issues/1933>`_, `#1969 <https://github.com/matrix-org/matrix-doc/issues/1969>`_, `#1988 <https://github.com/matrix-org/matrix-doc/issues/1988>`_, `#1989 <https://github.com/matrix-org/matrix-doc/issues/1989>`_, `#1991 <https://github.com/matrix-org/matrix-doc/issues/1991>`_, `#1992 <https://github.com/matrix-org/matrix-doc/issues/1992>`_)
-- Add the missing ``m.push_rules`` event schema. (`#1889 <https://github.com/matrix-org/matrix-doc/issues/1889>`_)
-- Clarify how modern day local echo is meant to be solved by clients. (`#1891 <https://github.com/matrix-org/matrix-doc/issues/1891>`_)
-- Clarify that ``width`` and ``height`` are required parameters on ``/_matrix/media/r0/thumbnail/{serverName}/{mediaId}``. (`#1975 <https://github.com/matrix-org/matrix-doc/issues/1975>`_)
-- Clarify how ``m.login.dummy`` can be used to disambiguate login flows. (`#1999 <https://github.com/matrix-org/matrix-doc/issues/1999>`_)
-- Remove ``prev_content`` from the redaction algorithm's essential keys list. (`#2016 <https://github.com/matrix-org/matrix-doc/issues/2016>`_)
-- Fix the ``third_party_signed`` definitions for the join APIs. (`#2025 <https://github.com/matrix-org/matrix-doc/issues/2025>`_)
-- Clarify why User Interactive Auth is used on password changes and how access tokens are handled. (`#2027 <https://github.com/matrix-org/matrix-doc/issues/2027>`_)
-- Clarify that devices are deleted upon logout. (`#2028 <https://github.com/matrix-org/matrix-doc/issues/2028>`_)
-- Add ``M_NOT_FOUND`` error definition for deleting room aliases. (`#2029 <https://github.com/matrix-org/matrix-doc/issues/2029>`_)
-- Add missing ``reason`` to ``m.call.hangup``. (`#2031 <https://github.com/matrix-org/matrix-doc/issues/2031>`_)
-- Clarify how redactions affect room state. (`#2032 <https://github.com/matrix-org/matrix-doc/issues/2032>`_)
-- Clarify that ``FAIL_ERROR`` in autodiscovery is not limited to just homeservers. (`#2036 <https://github.com/matrix-org/matrix-doc/issues/2036>`_)
-- Fix example ``Content-Type`` for ``/media/upload`` request. (`#2041 <https://github.com/matrix-org/matrix-doc/issues/2041>`_)
-- Clarify that login flows are meant to be completed in order. (`#2042 <https://github.com/matrix-org/matrix-doc/issues/2042>`_)
-- Clarify that clients should not send read receipts for their own messages. (`#2043 <https://github.com/matrix-org/matrix-doc/issues/2043>`_)
-- Use consistent examples of events throughout the specification. (`#2051 <https://github.com/matrix-org/matrix-doc/issues/2051>`_)
-- Clarify which push rule condition kinds exist. (`#2052 <https://github.com/matrix-org/matrix-doc/issues/2052>`_)
-- Clarify the required fields on ``m.file`` (and similar) messages. (`#2053 <https://github.com/matrix-org/matrix-doc/issues/2053>`_)
-- Clarify that User-Interactive Authentication stages cannot be attempted more than once. (`#2054 <https://github.com/matrix-org/matrix-doc/issues/2054>`_)
-- Clarify which parameters apply in what scenarios on ``/register``. (`#2055 <https://github.com/matrix-org/matrix-doc/issues/2055>`_)
-- Clarify how to interpret changes of ``membership`` over time. (`#2056 <https://github.com/matrix-org/matrix-doc/issues/2056>`_)
-- Clarify exactly what invite_room_state consists of. (`#2067 <https://github.com/matrix-org/matrix-doc/issues/2067>`_)
-- Clarify how the content repository works, and what it is used for. (`#2068 <https://github.com/matrix-org/matrix-doc/issues/2068>`_)
-- Clarify the order events in chunk are returned in for ``/messages``. (`#2069 <https://github.com/matrix-org/matrix-doc/issues/2069>`_)
-- Clarify the key object definition for the key management API. (`#2083 <https://github.com/matrix-org/matrix-doc/issues/2083>`_)
-- Reorganize information about events into a common section. (`#2087 <https://github.com/matrix-org/matrix-doc/issues/2087>`_)
-- De-duplicate ``/state/<event_type>`` endpoints, clarifying that the ``<state_key>`` is optional. (`#2088 <https://github.com/matrix-org/matrix-doc/issues/2088>`_)
-- Clarify when and where CORS headers should be returned. (`#2089 <https://github.com/matrix-org/matrix-doc/issues/2089>`_)
-- Clarify when authorization and rate-limiting are not applicable. (`#2090 <https://github.com/matrix-org/matrix-doc/issues/2090>`_)
-- Clarify that ``/register`` must produce valid Matrix User IDs. (`#2091 <https://github.com/matrix-org/matrix-doc/issues/2091>`_)
-- Clarify how ``unread_notifications`` is calculated. (`#2097 <https://github.com/matrix-org/matrix-doc/issues/2097>`_)
-- Clarify what a "module" is and update feature profiles for clients. (`#2098 <https://github.com/matrix-org/matrix-doc/issues/2098>`_)
-
-
-r0.4.0
-======
-
-New Endpoints
--------------
-
-- ``POST /user_directory/search`` (`#1096 <https://github.com/matrix-org/matrix-doc/issues/1096>`_)
-- ``GET /rooms/{roomId}/event/{eventId}`` (`#1110 <https://github.com/matrix-org/matrix-doc/issues/1110>`_)
-- ``POST /delete_devices`` (`#1239 <https://github.com/matrix-org/matrix-doc/issues/1239>`_)
-- ``GET /thirdparty/*`` Endpoints (`#1353 <https://github.com/matrix-org/matrix-doc/issues/1353>`_)
-- ``POST /account/3pid/msisdn/requestToken``, ``POST /register/msisdn/requestToken``, and ``POST /account/password/msisdn/requestToken`` (`#1507 <https://github.com/matrix-org/matrix-doc/issues/1507>`_)
-- ``POST /account/3pid/delete`` (`#1567 <https://github.com/matrix-org/matrix-doc/issues/1567>`_)
-- ``POST /rooms/{roomId}/read_markers`` (`#1635 <https://github.com/matrix-org/matrix-doc/issues/1635>`_)
-
-
-Backwards Compatible Changes
-----------------------------
-
-- Add more presence options to the ``set_presence`` parameter of ``/sync``. (Thanks @mujx!) (`#780 <https://github.com/matrix-org/matrix-doc/issues/780>`_)
-- Add ``token`` parameter to the ``/keys/query`` endpoint (`#1104 <https://github.com/matrix-org/matrix-doc/issues/1104>`_)
-- Add the room visibility options for the room directory (`#1141 <https://github.com/matrix-org/matrix-doc/issues/1141>`_)
-- Add spec for ignoring users (`#1142 <https://github.com/matrix-org/matrix-doc/issues/1142>`_)
-- Add the ``/register/available`` endpoint for username availability (`#1151 <https://github.com/matrix-org/matrix-doc/issues/1151>`_)
-- Add sticker messages (`#1158 <https://github.com/matrix-org/matrix-doc/issues/1158>`_)
-- Specify how to control the power level required for ``@room`` (`#1176 <https://github.com/matrix-org/matrix-doc/issues/1176>`_)
-- Document ``/logout/all`` endpoint (`#1263 <https://github.com/matrix-org/matrix-doc/issues/1263>`_)
-- Add report content API (`#1264 <https://github.com/matrix-org/matrix-doc/issues/1264>`_)
-- Add ``allow_remote`` to the content repo to avoid routing loops (`#1265 <https://github.com/matrix-org/matrix-doc/issues/1265>`_)
-- Document `highlights` field in /search response (`#1274 <https://github.com/matrix-org/matrix-doc/issues/1274>`_)
-- End-to-end encryption for group chats:
-
-  * Olm and Megolm messaging algorithms.
-  * ``m.room.encrypted``, ``m.room.encryption``, ``m.room_key`` events.
-  * Device verification process.
-  * ``device_one_time_keys_count`` sync parameter.
-  * ``device_lists:left`` sync parameter. (`#1284 <https://github.com/matrix-org/matrix-doc/issues/1284>`_)
-- Add ``.well-known`` server discovery method (`#1359 <https://github.com/matrix-org/matrix-doc/issues/1359>`_)
-- Document the GET version of ``/login`` (`#1361 <https://github.com/matrix-org/matrix-doc/issues/1361>`_)
-- Document the ``server_name`` parameter on ``/join/{roomIdOrAlias}`` (`#1364 <https://github.com/matrix-org/matrix-doc/issues/1364>`_)
-- Document the CORS/preflight headers (`#1365 <https://github.com/matrix-org/matrix-doc/issues/1365>`_)
-- Add new user identifier object for logging in (`#1390 <https://github.com/matrix-org/matrix-doc/issues/1390>`_)
-- Document message formats on ``m.text`` and ``m.emote`` messages (`#1397 <https://github.com/matrix-org/matrix-doc/issues/1397>`_)
-- Encrypt file attachments (`#1420 <https://github.com/matrix-org/matrix-doc/issues/1420>`_)
-- Share room decryption keys between devices (`#1465 <https://github.com/matrix-org/matrix-doc/issues/1465>`_)
-- Document and improve client interaction with pushers. (`#1506 <https://github.com/matrix-org/matrix-doc/issues/1506>`_)
-- Add support for Room Versions. (`#1516 <https://github.com/matrix-org/matrix-doc/issues/1516>`_)
-- Guests can now call /context and /event to fetch events (`#1542 <https://github.com/matrix-org/matrix-doc/issues/1542>`_)
-- Add a common standard for user, room, and group mentions in messages. (`#1547 <https://github.com/matrix-org/matrix-doc/issues/1547>`_)
-- Add server ACLs as an option for controlling federation in a room. (`#1550 <https://github.com/matrix-org/matrix-doc/issues/1550>`_)
-- Add new push rules for encrypted events and ``@room`` notifications. (`#1551 <https://github.com/matrix-org/matrix-doc/issues/1551>`_)
-- Add third party network room directories, as provided by application services. (`#1554 <https://github.com/matrix-org/matrix-doc/issues/1554>`_)
-- Document the ``validated_at`` and ``added_at`` fields on ``GET /acount/3pid``. (`#1567 <https://github.com/matrix-org/matrix-doc/issues/1567>`_)
-- Add an ``inhibit_login`` registration option. (`#1589 <https://github.com/matrix-org/matrix-doc/issues/1589>`_)
-- Recommend that servers set a Content Security Policy for the content repository. (`#1600 <https://github.com/matrix-org/matrix-doc/issues/1600>`_)
-- Add "rich replies" - a way for users to better represent the conversation thread they are referencing in their messages. (`#1617 <https://github.com/matrix-org/matrix-doc/issues/1617>`_)
-- Add support for read markers. (`#1635 <https://github.com/matrix-org/matrix-doc/issues/1635>`_)
-
-
-Spec Clarifications
--------------------
-
-- Mark ``home_server`` return field for ``/login`` and ``/register`` endpoints as deprecated (`#1097 <https://github.com/matrix-org/matrix-doc/issues/1097>`_)
-- Fix response format of ``/keys/changes`` endpoint (`#1106 <https://github.com/matrix-org/matrix-doc/issues/1106>`_)
-- Clarify default values for some fields on the ``/search`` API (`#1109 <https://github.com/matrix-org/matrix-doc/issues/1109>`_)
-- Fix the representation of ``m.presence`` events (`#1137 <https://github.com/matrix-org/matrix-doc/issues/1137>`_)
-- Clarify that ``m.tag`` ordering is done with numbers, not strings (`#1139 <https://github.com/matrix-org/matrix-doc/issues/1139>`_)
-- Clarify that ``/account/whoami`` should consider application services (`#1152 <https://github.com/matrix-org/matrix-doc/issues/1152>`_)
-- Update ``ImageInfo`` and ``ThumbnailInfo`` dimension schema descriptions to clarify that they relate to intended display size, as opposed to the intrinsic size of the image file. (`#1158 <https://github.com/matrix-org/matrix-doc/issues/1158>`_)
-- Mark ``GET /rooms/{roomId}/members`` as requiring authentication (`#1245 <https://github.com/matrix-org/matrix-doc/issues/1245>`_)
-- Clarify ``changed`` field behaviour in device tracking process (`#1284 <https://github.com/matrix-org/matrix-doc/issues/1284>`_)
-- Describe ``StateEvent`` for ``/createRoom`` (`#1329 <https://github.com/matrix-org/matrix-doc/issues/1329>`_)
-- Describe how the ``reason`` is handled for kicks/bans (`#1362 <https://github.com/matrix-org/matrix-doc/issues/1362>`_)
-- Mark ``GET /presence/{userId}/status`` as requiring authentication (`#1371 <https://github.com/matrix-org/matrix-doc/issues/1371>`_)
-- Describe the rate limit error response schema (`#1373 <https://github.com/matrix-org/matrix-doc/issues/1373>`_)
-- Clarify that clients must leave rooms before forgetting them (`#1378 <https://github.com/matrix-org/matrix-doc/issues/1378>`_)
-- Document guest access in ``/createRoom`` presets (`#1379 <https://github.com/matrix-org/matrix-doc/issues/1379>`_)
-- Define what a ``RoomEvent`` is on ``/rooms/{roomId}/messages`` (`#1380 <https://github.com/matrix-org/matrix-doc/issues/1380>`_)
-- Clarify the request and result types on ``/search`` (`#1381 <https://github.com/matrix-org/matrix-doc/issues/1381>`_)
-- Clarify some of the properties on the search result (`#1400 <https://github.com/matrix-org/matrix-doc/issues/1400>`_)
-- Clarify how access tokens are meant to be supplied to the homeserver. (`#1517 <https://github.com/matrix-org/matrix-doc/issues/1517>`_)
-- Document additional parameters on the ``/createRoom`` API. (`#1518 <https://github.com/matrix-org/matrix-doc/issues/1518>`_)
-- Clarify that new push rules should be enabled by default, and that unrecognised conditions should not match. (`#1551 <https://github.com/matrix-org/matrix-doc/issues/1551>`_)
-- Update all event examples to be accurate representations of their associated events. (`#1558 <https://github.com/matrix-org/matrix-doc/issues/1558>`_)
-- Clarify the supported HTML features for room messages. (`#1562 <https://github.com/matrix-org/matrix-doc/issues/1562>`_)
-- Move the ``invite_room_state`` definition under ``unsigned`` where it actually resides. (`#1568 <https://github.com/matrix-org/matrix-doc/issues/1568>`_)
-- Clarify the homeserver's behaviour for searching users. (`#1569 <https://github.com/matrix-org/matrix-doc/issues/1569>`_)
-- Clarify the object structures and defaults for Filters. (`#1570 <https://github.com/matrix-org/matrix-doc/issues/1570>`_)
-- Clarify instances of ``type: number`` in the swagger/OpenAPI schema definitions. (`#1571 <https://github.com/matrix-org/matrix-doc/issues/1571>`_)
-- Clarify that left rooms also have account data in ``/sync``. (`#1572 <https://github.com/matrix-org/matrix-doc/issues/1572>`_)
-- Clarify the event fields used in the ``/sync`` response. (`#1573 <https://github.com/matrix-org/matrix-doc/issues/1573>`_)
-- Fix naming of the body field in ``PUT /directory/room``. (`#1574 <https://github.com/matrix-org/matrix-doc/issues/1574>`_)
-- Clarify the filter object schema used in room searching. (`#1577 <https://github.com/matrix-org/matrix-doc/issues/1577>`_)
-- Document the 403 error for sending state events. (`#1590 <https://github.com/matrix-org/matrix-doc/issues/1590>`_)
-- specify how to handle multiple olm sessions with the same device (`#1596 <https://github.com/matrix-org/matrix-doc/issues/1596>`_)
-- Add the other keys that redactions are expected to preserve. (`#1602 <https://github.com/matrix-org/matrix-doc/issues/1602>`_)
-- Clarify that clients should not be generating invalid HTML for formatted events. (`#1605 <https://github.com/matrix-org/matrix-doc/issues/1605>`_)
-- Clarify the room tag structure (thanks @KitsuneRal!) (`#1606 <https://github.com/matrix-org/matrix-doc/issues/1606>`_)
-- Add a note that clients may use the transaction ID to avoid flickering when doing local echo. (`#1619 <https://github.com/matrix-org/matrix-doc/issues/1619>`_)
-- Include the request and response structures for the various ``/requestToken`` endpoints. (`#1636 <https://github.com/matrix-org/matrix-doc/issues/1636>`_)
-- Clarify the available error codes, and when to prefer the HTTP status code over the ``errcode``. (`#1637 <https://github.com/matrix-org/matrix-doc/issues/1637>`_)
-- Clarify and generalise the language used for describing pagination. (`#1642 <https://github.com/matrix-org/matrix-doc/issues/1642>`_)
-
-
-r0.3.0
-======
-
-- Breaking changes:
-
-  - Change the rule kind of ``.m.rule.contains_display_name`` from
-    ``underride`` to ``override``. This works with all known clients
-    which support push rules, but any other clients implementing
-    the push rules API should be aware of this change. This
-    makes it simple to mute rooms correctly in the API
-    (`#373 <https://github.com/matrix-org/matrix-doc/pull/373>`_).
-  - Remove ``/tokenrefresh`` from the API
-    (`#395 <https://github.com/matrix-org/matrix-doc/pull/395>`_).
-  - Remove requirement that tokens used in token-based login be macaroons
-    (`#395 <https://github.com/matrix-org/matrix-doc/pull/395>`_).
-  - Move ``thumbnail_url`` and ``thumbnail_info`` members of json objects
-    for ``m.room.message`` events with msgtypes ``m.image``, ``m.file``
-    and ``m.location``, inside the ``info`` member, to match ``m.video``
-    events
-    (`#723 <https://github.com/matrix-org/matrix-doc/pull/723>`_).
-
-- Changes to the API which will be backwards-compatible for clients:
-
-  - Add ``filename`` parameter to ``POST /_matrix/media/r0/upload``
-    (`#364 <https://github.com/matrix-org/matrix-doc/pull/364>`_).
-  - Document CAS-based client login and the use of ``m.login.token`` in
-    ``/login`` (`#367 <https://github.com/matrix-org/matrix-doc/pull/367>`_).
-  - Make ``origin_server_ts`` a mandatory field of room events
-    (`#379 <https://github.com/matrix-org/matrix-doc/pull/370>`_).
-  - Add top-level ``account_data`` key to the responses to ``GET /sync`` and
-    ``GET /initialSync``
-    (`#380 <https://github.com/matrix-org/matrix-doc/pull/380>`_).
-  - Add ``is_direct`` flag to ``POST /createRoom`` and invite member event.
-    Add 'Direct Messaging' module
-    (`#389 <https://github.com/matrix-org/matrix-doc/pull/389>`_).
-  - Add ``contains_url`` option to ``RoomEventFilter``
-    (`#390 <https://github.com/matrix-org/matrix-doc/pull/390>`_).
-  - Add ``filter`` optional query param to ``/messages``
-    (`#390 <https://github.com/matrix-org/matrix-doc/pull/390>`_).
-  - Add 'Send-to-Device messaging' module
-    (`#386 <https://github.com/matrix-org/matrix-doc/pull/386>`_).
-  - Add 'Device management' module
-    (`#402 <https://github.com/matrix-org/matrix-doc/pull/402>`_).
-  - Require that User-Interactive auth fallback pages call
-    ``window.postMessage`` to notify apps of completion
-    (`#398 <https://github.com/matrix-org/matrix-doc/pull/398>`_).
-  - Add pagination and filter support to ``/publicRooms``. Change response to
-    omit fields rather than return ``null``. Add estimate of total number of
-    rooms in list.
-    (`#388 <https://github.com/matrix-org/matrix-doc/pull/388>`_).
-  - Allow guest accounts to use a number of endpoints which are required for
-    end-to-end encryption.
-    (`#751 <https://github.com/matrix-org/matrix-doc/pull/751>`_).
-  - Add key distribution APIs, for use with end-to-end encryption.
-    (`#894 <https://github.com/matrix-org/matrix-doc/pull/894>`_).
-  - Add ``m.room.pinned_events`` state event for rooms.
-    (`#1007 <https://github.com/matrix-org/matrix-doc/pull/1007>`_).
-  - Add mention of ability to send Access Token via an Authorization Header.
-  - Add ``guest_can_join`` parameter to ``POST /createRoom``
-    (`#1093 <https://github.com/matrix-org/matrix-doc/pull/1093>`_).
-
-  - New endpoints:
-
-    - ``GET /joined_rooms``
-      (`#999 <https://github.com/matrix-org/matrix-doc/pull/999>`_).
-
-    - ``GET /rooms/{roomId}/joined_members``
-      (`#999 <https://github.com/matrix-org/matrix-doc/pull/999>`_).
-
-    - ``GET /account/whoami``
-      (`#1063 <https://github.com/matrix-org/matrix-doc/pull/1063>`_).
-
-    - ``GET /media/{version}/preview_url``
-      (`#1064 <https://github.com/matrix-org/matrix-doc/pull/1064>`_).
-
-- Spec clarifications:
-
-  - Add endpoints and logic for invites and third-party invites to the federation
-    spec and update the JSON of the request sent by the identity server upon 3PID
-    binding
-    (`#997 <https://github.com/matrix-org/matrix-doc/pull/997>`_)
-  - Fix "membership" property on third-party invite upgrade example
-    (`#995 <https://github.com/matrix-org/matrix-doc/pull/995>`_)
-  - Fix response format and 404 example for room alias lookup
-    (`#960 <https://github.com/matrix-org/matrix-doc/pull/960>`_)
-  - Fix examples of ``m.room.member`` event and room state change,
-    and added a clarification on the membership event sent upon profile update
-    (`#950 <https://github.com/matrix-org/matrix-doc/pull/950>`_).
-  - Spell out the way that state is handled by ``POST /createRoom``
-    (`#362 <https://github.com/matrix-org/matrix-doc/pull/362>`_).
-  - Clarify the fields which are applicable to different types of push rule
-    (`#365 <https://github.com/matrix-org/matrix-doc/pull/365>`_).
-  - A number of clarifications to authentication
-    (`#371 <https://github.com/matrix-org/matrix-doc/pull/371>`_).
-  - Correct references to ``user_id`` which should have been ``sender``
-    (`#376 <https://github.com/matrix-org/matrix-doc/pull/376>`_).
-  - Correct inconsistent specification of ``redacted_because`` fields and their
-    values (`#378 <https://github.com/matrix-org/matrix-doc/pull/378>`_).
-  - Mark required fields in response objects as such
-    (`#394 <https://github.com/matrix-org/matrix-doc/pull/394>`_).
-  - Make ``m.notice`` description a bit harder in its phrasing to try to
-    dissuade the same issues that occurred with IRC
-    (`#750 <https://github.com/matrix-org/matrix-doc/pull/750>`_).
-  - ``GET /user/{userId}/filter/{filterId}`` requires authentication
-    (`#1003 <https://github.com/matrix-org/matrix-doc/pull/1003>`_).
-  - Add some clarifying notes on the behaviour of rooms with no
-    ``m.room.power_levels`` event
-    (`#1026 <https://github.com/matrix-org/matrix-doc/pull/1026>`_).
-  - Clarify the relationship between ``username`` and ``user_id`` in the
-    ``/register`` API
-    (`#1032 <https://github.com/matrix-org/matrix-doc/pull/1032>`_).
-  - Clarify rate limiting and security for content repository.
-    (`#1064 <https://github.com/matrix-org/matrix-doc/pull/1064>`_).
-
-r0.2.0
-======
-
-- Spec clarifications:
-
-  - Room aliases (`#337 <https://github.com/matrix-org/matrix-doc/pull/337>`_):
-
-    - Make it clear that ``GET /directory/room/{roomAlias}`` must work for
-      federated aliases.
-
-    - ``GET /directory/room/{roomAlias}`` cannot return a 409; the ``PUT``
-      endpoint can, however.
-
-  - Power levels:
-
-    - Clarify the defaults to be used for various fields of the
-      ``m.room.power_levels`` event
-      (`#286 <https://github.com/matrix-org/matrix-doc/pull/286>`_,
-      `#341 <https://github.com/matrix-org/matrix-doc/pull/341>`_).
-
-    - Add suggestions for mapping of names to power levels
-      (`#336 <https://github.com/matrix-org/matrix-doc/pull/336>`_).
-
-  - Clarify the room naming algorithm in certain edge cases
-    (`#351 <https://github.com/matrix-org/matrix-doc/pull/351>`_).
-
-  - Remove outdated references to the pre-r0 ``/events`` API, and clarify the
-    section on syncing
-    (`#352 <https://github.com/matrix-org/matrix-doc/pull/352>`_).
-
-
-- Changes to the API which will be backwards-compatible for clients:
-
-  - New endpoints:
-
-    - ``POST /register/email/requestToken``
-      (`#343 <https://github.com/matrix-org/matrix-doc/pull/343>`_).
-
-    - ``POST /account/3pid/email/requestToken``
-      (`#346 <https://github.com/matrix-org/matrix-doc/pull/346>`_).
-
-    - ``POST /account/password/email/requestToken``
-      (`#346 <https://github.com/matrix-org/matrix-doc/pull/346>`_).
-
-    - ``POST /account/deactivate``
-      (`#361 <https://github.com/matrix-org/matrix-doc/pull/361>`_).
-
-  - Updates to the Presence module
-    (`#278 <https://github.com/matrix-org/matrix-doc/pull/278>`_,
-    `#342 <https://github.com/matrix-org/matrix-doc/pull/342>`_):
-
-    - Remove unused ``free_for_chat`` presence state
-    - Add ``currently_active`` flag to the ``m.presence`` event and the ``GET
-      /presence/{userId}/status`` response.
-    - Make idle timeout the responsibility of the server
-    - Remove requirements on servers to propagate profile information via
-      ``m.presence`` events.
-
-  - Add new predefined push rules
-    (`#274 <https://github.com/matrix-org/matrix-doc/pull/274>`_,
-    `#340 <https://github.com/matrix-org/matrix-doc/pull/340/files>`_).
-
-  - ``/sync`` should always return a ``prev_batch`` token
-    (`#345 <https://github.com/matrix-org/matrix-doc/pull/345>`_).
-
-  - add ``to`` parameter to ``GET /rooms/{roomId}/messages`` API
-    (`#348 <https://github.com/matrix-org/matrix-doc/pull/348>`_).
-
-r0.1.0
-======
-
-This release includes the following changes since r0.0.1:
-
-- Breaking changes to the API [#]_:
-
-  - ``POST /rooms/{roomId}/join`` no longer permits use of a room alias instead
-    of a room id. (``POST /join/{roomIdOrAlias}`` continues to allow either.)
-  - ``POST /account/3pid``: correct the name of the ``three_pid_creds``
-    parameter
-  - The "Push Rules" module no longer supports device-specific rules:
-
-    - ``GET /pushrules`` no longer returns a ``device`` property
-    - ``device/{profile_tag}`` is no longer a valid ``scope`` for push rules
-    - ``profile_tag`` is no longer a valid kind of condition on push rules.
-
-    (Device-specific push rules will be reintroduced in the future; in the
-    meantime, their specification has been moved to a `draft branch`__.)
-
-    __ https://matrix.org/speculator/spec/drafts%2Freinstate_device_push_rules/
-
-- Changes to the API which will be backwards-compatible for clients:
-
-  - New endpoints:
-
-    - ``POST /logout``
-    - ``POST /rooms/{roomId}/unban``
-    - ``POST /rooms/{roomId}/kick``
-    - ``GET /pushers``
-    - ``GET /pushrules/{scope}/{kind}/{ruleId}/enabled``
-      (previously ``PUT``-only)
-    - ``GET`` and ``PUT /pushrules/{scope}/{kind}/{ruleId}/actions``
-
-  - Add ``third_party_signed`` parameter to ``POST /rooms/{roomId}/join``
-  - Add ``M_INVALID_USERNAME`` as valid response to ``POST /register``
-  - Add ``unread_notifications`` field to ``GET /sync`` response
-  - Add optional ``invite`` property to ``m.room.power_levels`` state event
-  - Add optional ``public_key`` and ``public_keys`` to
-    ``m.room.third_party_invite`` state event
-  - Password-based ``/login`` may now use a third-party identifier instead of
-    a matrix user id.
-
-- Spec clarifications
-
-  - Make the state diagram for room membership explicit
-  - Note that a user may not be invited to a room while banned
-  - Clarify the expected order of events in the response to
-    ``GET /rooms/{roomId}/context/{eventId}``, as well as correcting the
-    example for that API
-  - Clarify the behaviour of the "Room History Visibility" module; in
-    particular, the behaviour of the ``shared`` history visibility, and how
-    events at visibility boundaries should be handled
-  - Separate the "Room Previews" module from "Guest access"
-  - Reword the description of the ``profile_tag`` property in
-    ``PUT /pushers/set``, and note that it is not mandatory.
-
-
-.. [#] Our `versioning policy <../index.html#specification-versions>`_ would
-   strictly require that a breaking change be denoted by a new major
-   specification version. However we are not aware of any clients which
-   rely on the old behaviour here, nor server implementations which offer
-   it, so we have chosen to retain the r0 designation on this occasion.
-
-r0.0.1
-======
-
-This release includes the following changes since r0.0.0:
-
-- API changes:
-  - Added new ``/versions`` API
-  - ``/createRoom`` takes an optional ``invite_3pid`` parameter
-  - ``/publicRooms`` returns an ``avatar_url`` result
-- The following APIs are now deprecated:
-  - ``/initialSync``
-  - ``/events``
-  - ``/events/:eventId``
-  - ``/rooms/:roomId/initialSync``
-- Spec clarifications
-  - Document inter-version compatibility
-  - Document the parameters to the ``/user/:userId/filter`` API
-  - Document the ``next_batch`` parameter on ``/search``
-  - Document the membership states on ``m.room.member`` events
-  - Minor clarifications/corrections to:
-    - Guest access module
-    - Search module
-    - ``/login`` API
-    - ``/rooms/:roomId/send/:eventType/:txnId`` API
-    - ``/rooms/:roomId/context/:eventId`` API
-
-r0.0.0
-======
-
-This is the first release of the client-server specification. It is largely a dump of what has currently been implemented, and there are several inconsistencies.
-
-An upcoming minor release will deprecate many of these inconsistencies, and they will be removed in the next major release.
-
-Since the draft stage, the following major changes have been made:
-- /api/v1 and /v2_alpha path segments have been replaced with the major version of the release (i.e. 'r0').
-- Some POST versions of APIs with both POST and PUT have been removed.
-- The specification has been split into one specification per API. This is the client-server API. The server-server API can be found documented separately.
-- All APIs are now documented using Swagger
-- The following modules have been added:
-  - Content repository
-  - Instant messaging
-  - Push notification
-  - History visibility
-  - Search
-  - Invites based on third party identifiers
-  - Room tagging
-  - Guest access
-  - Client config
-- The following APIs were added:
-  - ``/sync``
-  - ``/publicRooms``
-  - ``/rooms/{roomId}/forget``
-  - ``/admin/whois``
-  - ``/rooms/{roomId}/redact``
-  - ``/user/{userId}/filter``
-- The following APIs have been significantly modified:
-  - Invitations now contain partial room state
-  - Invitations can now be rejected
-  - ``/directory``
-- The following events have been added:
-  - ``m.room.avatar``
-- Example signed json is included for reference
-- Commentary on display name calculation was added
diff --git a/changelogs/legacy/identity_service.rst b/changelogs/legacy/identity_service.rst
deleted file mode 100644
index 7cccc0cf..00000000
--- a/changelogs/legacy/identity_service.rst
+++ /dev/null
@@ -1,54 +0,0 @@
-r0.3.0
-======
-
-New Endpoints
--------------
-
-- Add ``/account``, ``/account/register``, and ``/account/logout`` to authenticate with the identity server. (`#2255 <https://github.com/matrix-org/matrix-doc/issues/2255>`_)
-- Add endpoints for accepting and handling terms of service. (`#2258 <https://github.com/matrix-org/matrix-doc/issues/2258>`_)
-- Add ``/hash_details`` and a new ``/lookup`` endpoint for performing hashed association lookups. (`#2287 <https://github.com/matrix-org/matrix-doc/issues/2287>`_)
-
-
-Backwards Compatible Changes
-----------------------------
-
-- Deprecate the v1 API in favour of an authenticated v2 API. (`#2254 <https://github.com/matrix-org/matrix-doc/issues/2254>`_)
-
-
-r0.2.1
-======
-
-Spec Clarifications
--------------------
-
-- Remove incorrect ``id_server`` parameter from ``/requestToken`` endpoints. (`#2124 <https://github.com/matrix-org/matrix-doc/issues/2124>`_)
-- Clarify that identity servers can return 403 for unbind requests. (`#2126 <https://github.com/matrix-org/matrix-doc/issues/2126>`_)
-
-
-r0.2.0
-======
-
-New Endpoints
--------------
-
-- Add ``/3pid/unbind`` for removing 3PIDs. (`#2046 <https://github.com/matrix-org/matrix-doc/issues/2046>`_)
-
-
-Spec Clarifications
--------------------
-
-- Fix various spelling mistakes throughout the specification. (`#1853 <https://github.com/matrix-org/matrix-doc/issues/1853>`_)
-- Fix route for ``/3pid/bind``. (`#1967 <https://github.com/matrix-org/matrix-doc/issues/1967>`_)
-- Add missing aesthetic parameters to ``/store-invite``. (`#2049 <https://github.com/matrix-org/matrix-doc/issues/2049>`_)
-- Clarify what the client should receive upon sending an identical email validation request multiple times. (`#2057 <https://github.com/matrix-org/matrix-doc/issues/2057>`_)
-- Clarify that the default transport is JSON over HTTP. (`#2086 <https://github.com/matrix-org/matrix-doc/issues/2086>`_)
-
-
-r0.1.0
-======
-
-This is the first release of the Identity Service API. With this API, clients and
-homeservers can store bindings between third party identifiers such as email addresses
-and phone numbers, associating them with Matrix user IDs. Additionally, identity
-servers offer the ability to invite third party users to Matrix rooms by storing
-the invite until the identifier is bound.
diff --git a/changelogs/legacy/push_gateway.rst b/changelogs/legacy/push_gateway.rst
deleted file mode 100644
index 2afb2a9e..00000000
--- a/changelogs/legacy/push_gateway.rst
+++ /dev/null
@@ -1,15 +0,0 @@
-r0.1.1
-======
-
-Spec Clarifications
--------------------
-
-- Fix ``event_id`` field in push request body. (`#2151 <https://github.com/matrix-org/matrix-doc/issues/2151>`_)
-
-
-r0.1.0
-======
-
-The first release of the Push Gateway specification. This release contains
-a single endpoint, ``/notify``, that pushers may use to send push notifications
-to clients.
diff --git a/changelogs/legacy/server_server.rst b/changelogs/legacy/server_server.rst
deleted file mode 100644
index 367fb092..00000000
--- a/changelogs/legacy/server_server.rst
+++ /dev/null
@@ -1,74 +0,0 @@
-r0.1.4
-======
-
-New Endpoints
--------------
-
-- Add new ``POST /publicRooms`` endpoint for filtering the room directory. (`#2305 <https://github.com/matrix-org/matrix-doc/issues/2305>`_)
-- Add new v2 ``/send_join`` and ``/send_leave`` endpoints per `MSC1802 <https://github.com/matrix-org/matrix-doc/pull/1802>`_. (`#2547 <https://github.com/matrix-org/matrix-doc/issues/2547>`_)
-
-
-Removed Endpoints
------------------
-
-- Remove the unused ``query_auth`` API per `MSC2451 <https://github.com/matrix-org/matrix-doc/pull/2451>`_. (`#2470 <https://github.com/matrix-org/matrix-doc/issues/2470>`_)
-
-
-Spec Clarifications
--------------------
-
-- Move auth event selection to a more obvious location. (`#2392 <https://github.com/matrix-org/matrix-doc/issues/2392>`_)
-- Fix typo in Request Authentication python example. (`#2510 <https://github.com/matrix-org/matrix-doc/issues/2510>`_)
-- Clarify which fields are required on the key server endpoints. (`#2527 <https://github.com/matrix-org/matrix-doc/issues/2527>`_)
-- Clarify the limits of ``prev_events`` and ``auth_events`` for PDUs. (`#2538 <https://github.com/matrix-org/matrix-doc/issues/2538>`_)
-- Clarify which events are targeted by backfill. (`#2559 <https://github.com/matrix-org/matrix-doc/issues/2559>`_)
-- Fix the response format of the ``/send`` endpoint. (`#2560 <https://github.com/matrix-org/matrix-doc/issues/2560>`_)
-- Clarify signature object structures for encryption. (`#2566 <https://github.com/matrix-org/matrix-doc/issues/2566>`_)
-- Clarify the server names to use when signing requests. (`#2570 <https://github.com/matrix-org/matrix-doc/issues/2570>`_)
-- Clarify the state/auth chain requirements for ``/send_join``. (`#2575 <https://github.com/matrix-org/matrix-doc/issues/2575>`_)
-- Fix various spelling errors throughout the specification. (`#2577 <https://github.com/matrix-org/matrix-doc/issues/2577>`_)
-
-
-r0.1.3
-======
-
-Spec Clarifications
--------------------
-
-- Clarify the encryption algorithms supported by the device of the user keys query example. (`#2157 <https://github.com/matrix-org/matrix-doc/issues/2157>`_)
-- Clarify the purpose of reference hashes. (`#2159 <https://github.com/matrix-org/matrix-doc/issues/2159>`_)
-
-
-r0.1.2
-======
-
-Spec Clarifications
--------------------
-
-- Change examples to use example.org instead of a real domain. (`#1650 <https://github.com/matrix-org/matrix-doc/issues/1650>`_)
-- Fix the ``access_token`` parameter in the open_id endpoint. (`#1906 <https://github.com/matrix-org/matrix-doc/issues/1906>`_)
-- Fix various spelling mistakes throughout the specification. (`#1991 <https://github.com/matrix-org/matrix-doc/issues/1991>`_)
-- Clarify exactly what invite_room_state consists of. (`#2067 <https://github.com/matrix-org/matrix-doc/issues/2067>`_)
-- Clarify how ``valid_until_ts`` behaves with respect to room version. (`#2080 <https://github.com/matrix-org/matrix-doc/issues/2080>`_)
-- Clarify which servers are supposed to sign events. (`#2081 <https://github.com/matrix-org/matrix-doc/issues/2081>`_)
-- Clarify the key object definition for the key management API. (`#2083 <https://github.com/matrix-org/matrix-doc/issues/2083>`_)
-- Clarify how many PDUs are contained in transaction objects for various endpoints. (`#2095 <https://github.com/matrix-org/matrix-doc/issues/2095>`_)
-- Clarify that the trailing slash is optional on ``/keys/*`` endpoints when no key ID is requested. (`#2097 <https://github.com/matrix-org/matrix-doc/issues/2097>`_)
-
-
-r0.1.1
-======
-
-Spec Clarifications
--------------------
-
-- Remove legacy references to TLS fingerprints. (`#1844 <https://github.com/matrix-org/matrix-doc/issues/1844>`_)
-- Clarify that servers should not fail to contact servers if ``/.well-known`` fails. (`#1855 <https://github.com/matrix-org/matrix-doc/issues/1855>`_)
-
-
-r0.1.0
-======
-
-This is the first release of the Server Server (Federation) specification.
-It includes support for homeservers being able to interact with other
-homeservers in a decentralized and standard way.
diff --git a/changelogs/push_gateway/newsfragments/.gitignore b/changelogs/push_gateway/newsfragments/.gitignore
deleted file mode 100644
index b722e9e1..00000000
--- a/changelogs/push_gateway/newsfragments/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-!.gitignore
\ No newline at end of file
diff --git a/changelogs/pyproject.toml b/changelogs/pyproject.toml
deleted file mode 100644
index f114a178..00000000
--- a/changelogs/pyproject.toml
+++ /dev/null
@@ -1,39 +0,0 @@
-[tool.towncrier]
-    version = "unused"
-    filename = "../rendered.md"
-    issue_format = "[#{issue}](https://github.com/matrix-org/matrix-doc/issues/{issue})"
-    title_format = "### {name}"  # Matches rendered spec, even if awkward
-    underlines = "   "  # 3 spaces intentionally to hide RST headings
-
-    # Note: The names below have the <strong> tag built-in so the rendered spec *and* the generated
-    # changelog can benefit from sane headings.
-
-    [[tool.towncrier.type]]
-        directory = "breaking"
-        name = "<strong>Breaking Changes</strong>"
-        showcontent = true
-
-    [[tool.towncrier.type]]
-        directory = "deprecation"
-        name = "<strong>Deprecations</strong>"
-        showcontent = true
-
-    [[tool.towncrier.type]]
-        directory = "new"
-        name = "<strong>New Endpoints</strong>"
-        showcontent = true
-
-    [[tool.towncrier.type]]
-        directory = "removal"
-        name = "<strong>Removed Endpoints</strong>"
-        showcontent = true
-
-    [[tool.towncrier.type]]
-        directory = "feature"
-        name = "<strong>Backwards Compatible Changes</strong>"
-        showcontent = true
-
-    [[tool.towncrier.type]]
-        directory = "clarification"
-        name = "<strong>Spec Clarifications</strong>"
-        showcontent = true
diff --git a/changelogs/room_versions/3739.feature b/changelogs/room_versions/3739.feature
deleted file mode 100644
index c20ec3ad..00000000
--- a/changelogs/room_versions/3739.feature
+++ /dev/null
@@ -1 +0,0 @@
-Update the default room version to 9.
\ No newline at end of file
diff --git a/changelogs/room_versions/newsfragments/.gitignore b/changelogs/room_versions/newsfragments/.gitignore
deleted file mode 100644
index b722e9e1..00000000
--- a/changelogs/room_versions/newsfragments/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-!.gitignore
\ No newline at end of file
diff --git a/changelogs/room_versions/newsfragments/3737.clarification b/changelogs/room_versions/newsfragments/3737.clarification
deleted file mode 100644
index c3b51679..00000000
--- a/changelogs/room_versions/newsfragments/3737.clarification
+++ /dev/null
@@ -1 +0,0 @@
-Fix join membership auth rules when `join_rule` is `knock`.
diff --git a/changelogs/server_server/newsfragments/.gitignore b/changelogs/server_server/newsfragments/.gitignore
deleted file mode 100644
index b722e9e1..00000000
--- a/changelogs/server_server/newsfragments/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-!.gitignore
\ No newline at end of file
diff --git a/changelogs/server_server/newsfragments/3703.clarification b/changelogs/server_server/newsfragments/3703.clarification
deleted file mode 100644
index 46bb7126..00000000
--- a/changelogs/server_server/newsfragments/3703.clarification
+++ /dev/null
@@ -1 +0,0 @@
-Correct misleading text for `/send_join` response.
diff --git a/changelogs/server_server/newsfragments/3727.clarification b/changelogs/server_server/newsfragments/3727.clarification
deleted file mode 100644
index a20297b7..00000000
--- a/changelogs/server_server/newsfragments/3727.clarification
+++ /dev/null
@@ -1 +0,0 @@
-Clarify that the `content` for `X-Matrix` signature validation is the parsed JSON body.
\ No newline at end of file
diff --git a/config.toml b/config.toml
deleted file mode 100644
index fb4890ae..00000000
--- a/config.toml
+++ /dev/null
@@ -1,84 +0,0 @@
-baseURL = "/"
-title = "Matrix Specification"
-
-# Prepends absolute URLs with the baseURL. Useful when hosting on non-root
-# paths, such as /unstable.
-canonifyURLs = true
-
-enableRobotsTXT = true
-
-# Hugo allows theme composition (and inheritance). The precedence is from left to right.
-theme = ["docsy"]
-
-disableKinds = ["taxonomy", "taxonomyTerm"]
-
-[languages]
-[languages.en]
-title = "Matrix Specification"
-description = "Home of the Matrix specification for decentralised communication"
-languageName ="English"
-# Weight used for sorting.
-weight = 1
-
-[markup]
-  [markup.goldmark]
-    [markup.goldmark.renderer]
-      # Enables us to render raw HTML
-      unsafe = true
-  [markup.highlight]
-      # See a complete list of available styles at https://xyproto.github.io/splash/docs/all.html
-      style = "tango"
-
-# Everything below this are Site Params
-
-[params]
-copyright = "The Matrix.org Foundation CIC"
-privacy_policy = "https://matrix.org/legal/privacy-notice"
-
-[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"
-# 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. CI will set these values here automatically when a release git tag (i.e `v1.5`) is created.
-#major = "1"
-#minor = "2"
-#release_date = "February 02, 2022"
-
-# User interface configuration
-[params.ui]
-# Set to true to disable the About link in the site footer
-footer_about_disable = false
-# Collapse HTTP API and event <details> elements
-rendered_data_collapsed = false
-
-[params.links]
-# End user relevant links. These will show up on left side of footer and in the community page if you have one.
-# [[params.links.user]]
-# 	name = "User mailing list"
-# 	url = "https://example.org/mail"
-# 	icon = "fa fa-envelope"
-#         desc = "Discussion and help from your fellow users"
-# Developer relevant links. These will show up on right side of footer and in the community page if you have one.
-[[params.links.developer]]
-	name = "GitHub"
-	url = "https://github.com/matrix-org"
-	icon = "fab fa-github"
-  desc = "Matrix on GitHub"
-[[params.links.developer]]
-	name = "GitLab"
-	url = "https://gitlab.matrix.org/matrix-org"
-	icon = "fab fa-gitlab"
-  desc = "Matrix on GitLab"
-[[params.links.developer]]
-	name = "YouTube"
-	url = "https://www.youtube.com/channel/UCVFkW-chclhuyYRbmmfwt6w"
-	icon = "fab fa-youtube"
-  desc = "Matrix YouTube channel"
-[[params.links.developer]]
-	name = "Twitter"
-	url = "https://twitter.com/matrixdotorg"
-	icon = "fab fa-twitter"
-  desc = "Matrix on Twitter"
diff --git a/content/_index.md b/content/_index.md
deleted file mode 100644
index 69d7883c..00000000
--- a/content/_index.md
+++ /dev/null
@@ -1,506 +0,0 @@
----
-title: "Matrix Specification"
-type: docs
-weight: 10
----
-
-Matrix defines a set of open APIs for decentralised communication,
-suitable for securely publishing, persisting and subscribing to data
-over a global open federation of servers with no single point of
-control. Uses include Instant Messaging (IM), Voice over IP (VoIP)
-signalling, Internet of Things (IoT) communication, and bridging
-together existing communication silos - providing the basis of a new
-open real-time communication ecosystem.
-
-To propose a change to the Matrix Spec, see the explanations at
-[Proposals for Spec Changes to Matrix](/proposals).
-
-## Matrix APIs
-
-The specification consists of the following parts:
-
-* [Client-Server API](/client-server-api)
-* [Server-Server API](/server-server-api)
-* [Application Service API](/application-service-api)
-* [Identity Service API](/identity-service-api)
-* [Push Gateway API](/push-gateway-api)
-* [Room Versions](/rooms)
-* [Appendices](/appendices)
-
-Additionally, this introduction page contains the key baseline
-information required to understand the specific APIs, including the
-section the [overall architecture](#architecture).
-
-The [Matrix Client-Server API Swagger
-Viewer](https://matrix.org/docs/api/client-server/) is useful for
-browsing the Client-Server API.
-
-## Introduction to the Matrix APIs
-
-Matrix is a set of open APIs for open-federated Instant Messaging (IM),
-Voice over IP (VoIP) and Internet of Things (IoT) communication,
-designed to create and support a new global real-time communication
-ecosystem. The intention is to provide an open decentralised pubsub
-layer for the internet for securely persisting and
-publishing/subscribing JSON objects. This specification is the ongoing
-result of standardising the APIs used by the various components of the
-Matrix ecosystem to communicate with one another.
-
-The principles that Matrix attempts to follow are:
-
--   Pragmatic Web-friendly APIs (i.e. JSON over REST)
--   Keep It Simple & Stupid
-    -   provide a simple architecture with minimal third-party
-        dependencies.
--   Fully open:
-    -   Fully open federation - anyone should be able to participate in
-        the global Matrix network
-    -   Fully open standard - publicly documented standard with no IP or
-        patent licensing encumbrances
-    -   Fully open source reference implementation - liberally-licensed
-        example implementations with no IP or patent licensing
-        encumbrances
--   Empowering the end-user
-    -   The user should be able to choose the server and clients they
-        use
-    -   The user should be able to control how private their
-        communication is
-    -   The user should know precisely where their data is stored
--   Fully decentralised - no single points of control over conversations
-    or the network as a whole
--   Learning from history to avoid repeating it
-    -   Trying to take the best aspects of XMPP, SIP, IRC, SMTP, IMAP
-        and NNTP whilst trying to avoid their failings
-
-The functionality that Matrix provides includes:
-
--   Creation and management of fully distributed chat rooms with no
-    single points of control or failure
--   Eventually-consistent cryptographically secure synchronisation of
-    room state across a global open network of federated servers and
-    services
--   Sending and receiving extensible messages in a room with (optional)
-    end-to-end encryption
--   Extensible user management (inviting, joining, leaving, kicking,
-    banning) mediated by a power-level based user privilege system.
--   Extensible room state management (room naming, aliasing, topics,
-    bans)
--   Extensible user profile management (avatars, display names, etc)
--   Managing user accounts (registration, login, logout)
--   Use of 3rd Party IDs (3PIDs) such as email addresses, phone numbers,
-    Facebook accounts to authenticate, identify and discover users on
-    Matrix.
--   Trusted federation of identity servers for:
-    -   Publishing user public keys for PKI
-    -   Mapping of 3PIDs to Matrix IDs
-
-The end goal of Matrix is to be a ubiquitous messaging layer for
-synchronising arbitrary data between sets of people, devices and
-services - be that for instant messages, VoIP call setups, or any other
-objects that need to be reliably and persistently pushed from A to B in
-an interoperable and federated manner.
-
-### Spec Change Proposals
-
-To propose a change to the Matrix Spec, see the explanations at
-[Proposals for Spec Changes to Matrix](/proposals).
-
-## Architecture
-
-Matrix defines APIs for synchronising extensible JSON objects known as
-"events" between compatible clients, servers and services. Clients are
-typically messaging/VoIP applications or IoT devices/hubs and
-communicate by synchronising communication history with their
-"homeserver" using the "Client-Server API". Each homeserver stores the
-communication history and account information for all of its clients,
-and shares data with the wider Matrix ecosystem by synchronising
-communication history with other homeservers and their clients.
-
-Clients typically communicate with each other by emitting events in the
-context of a virtual "room". Room data is replicated across *all of the
-homeservers* whose users are participating in a given room. As such, *no
-single homeserver has control or ownership over a given room*.
-Homeservers model communication history as a partially ordered graph of
-events known as the room's "event graph", which is synchronised with
-eventual consistency between the participating servers using the
-"Server-Server API". This process of synchronising shared conversation
-history between homeservers run by different parties is called
-"Federation". Matrix optimises for the Availability and Partitioned
-properties of CAP theorem at the expense of Consistency.
-
-For example, for client A to send a message to client B, client A
-performs an HTTP PUT of the required JSON event on its homeserver (HS)
-using the client-server API. A's HS appends this event to its copy of
-the room's event graph, signing the message in the context of the graph
-for integrity. A's HS then replicates the message to B's HS by
-performing an HTTP PUT using the server-server API. B's HS authenticates
-the request, validates the event's signature, authorises the event's
-contents and then adds it to its copy of the room's event graph. Client
-B then receives the message from his homeserver via a long-lived GET
-request.
-
-How data flows between clients:
-
-```
-    { Matrix client A }                             { Matrix client B }
-        ^          |                                    ^          |
-        |  events  |  Client-Server API                 |  events  |
-        |          V                                    |          V
-    +------------------+                            +------------------+
-    |                  |---------( HTTPS )--------->|                  |
-    |   homeserver     |                            |   homeserver     |
-    |                  |<--------( HTTPS )----------|                  |
-    +------------------+      Server-Server API     +------------------+
-                          History Synchronisation
-                              (Federation)
-```
-
-### Users
-
-Each client is associated with a user account, which is identified in
-Matrix using a unique "user ID". This ID is namespaced to the homeserver
-which allocated the account and has the form:
-
-    @localpart:domain
-
-See ['Identifier Grammar' in the
-appendices](/appendices#identifier-grammar) for full details of the
-structure of user IDs.
-
-### Devices
-
-The Matrix specification has a particular meaning for the term "device".
-As a user, I might have several devices: a desktop client, some web
-browsers, an Android device, an iPhone, etc. They broadly relate to a
-real device in the physical world, but you might have several browsers
-on a physical device, or several Matrix client applications on a mobile
-device, each of which would be its own device.
-
-Devices are used primarily to manage the keys used for end-to-end
-encryption (each device gets its own copy of the decryption keys), but
-they also help users manage their access - for instance, by revoking
-access to particular devices.
-
-When a user first uses a client, it registers itself as a new device.
-The longevity of devices might depend on the type of client. A web
-client will probably drop all of its state on logout, and create a new
-device every time you log in, to ensure that cryptography keys are not
-leaked to a new user. In a mobile client, it might be acceptable to
-reuse the device if a login session expires, provided the user is the
-same.
-
-Devices are identified by a `device_id`, which is unique within the
-scope of a given user.
-
-A user may assign a human-readable display name to a device, to help
-them manage their devices.
-
-### Events
-
-All data exchanged over Matrix is expressed as an "event". Typically
-each client action (e.g. sending a message) correlates with exactly one
-event. Each event has a `type` which is used to differentiate different
-kinds of data. `type` values MUST be uniquely globally namespaced
-following Java's [package naming
-conventions](https://en.wikipedia.org/wiki/Java_package#Package_naming_conventions),
-e.g. `com.example.myapp.event`. The special top-level namespace `m.` is
-reserved for events defined in the Matrix specification - for instance
-`m.room.message` is the event type for instant messages. Events are
-usually sent in the context of a "Room".
-
-{{% boxes/warning %}}
-Event bodies are considered untrusted data. This means that any application using
-Matrix must validate that the event body is of the expected shape/schema
-before using the contents verbatim.
-
-**It is not safe to assume that an event body will have all the expected
-fields of the expected types.**
-
-See [MSC2801](https://github.com/matrix-org/matrix-doc/pull/2801) for more
-detail on why this assumption is unsafe.
-{{% /boxes/warning %}}
-
-### Event Graphs
-
-Events exchanged in the context of a room are stored in a directed
-acyclic graph (DAG) called an "event graph". The partial ordering of
-this graph gives the chronological ordering of events within the room.
-Each event in the graph has a list of zero or more "parent" events,
-which refer to any preceding events which have no chronological
-successor from the perspective of the homeserver which created the
-event.
-
-Typically an event has a single parent: the most recent message in the
-room at the point it was sent. However, homeservers may legitimately
-race with each other when sending messages, resulting in a single event
-having multiple successors. The next event added to the graph thus will
-have multiple parents. Every event graph has a single root event with no
-parent.
-
-To order and ease chronological comparison between the events within the
-graph, homeservers maintain a `depth` metadata field on each event. An
-event's `depth` is a positive integer that is strictly greater than the
-depths of any of its parents. The root event should have a depth of 1.
-Thus if one event is before another, then it must have a strictly
-smaller depth.
-
-### Room structure
-
-A room is a conceptual place where users can send and receive events.
-Events are sent to a room, and all participants in that room with
-sufficient access will receive the event. Rooms are uniquely identified
-internally via "Room IDs", which have the form:
-
-    !opaque_id:domain
-
-There is exactly one room ID for each room. Whilst the room ID does
-contain a domain, it is simply for globally namespacing room IDs. The
-room does NOT reside on the domain specified.
-
-See ['Identifier Grammar' in the
-appendices](/appendices#identifier-grammar) for full details of the
-structure of a room ID.
-
-The following conceptual diagram shows an `m.room.message` event being
-sent to the room `!qporfwt:matrix.org`:
-
-    { @alice:matrix.org }                             { @bob:example.org }
-            |                                                 ^
-            |                                                 |
-    [HTTP POST]                                  [HTTP GET]
-    Room ID: !qporfwt:matrix.org                 Room ID: !qporfwt:matrix.org
-    Event type: m.room.message                   Event type: m.room.message
-    Content: { JSON object }                     Content: { JSON object }
-            |                                                 |
-            V                                                 |
-    +------------------+                          +------------------+
-    |   homeserver     |                          |   homeserver     |
-    |   matrix.org     |                          |   example.org    |
-    +------------------+                          +------------------+
-            |                                                 ^
-            |         [HTTP PUT]                              |
-            |         Room ID: !qporfwt:matrix.org            |
-            |         Event type: m.room.message              |
-            |         Content: { JSON object }                |
-            `-------> Pointer to the preceding message  ------`
-                      PKI signature from matrix.org
-                      Transaction-layer metadata
-                      PKI Authorization header
-
-                  ....................................
-                 |           Shared Data              |
-                 | State:                             |
-                 |   Room ID: !qporfwt:matrix.org     |
-                 |   Servers: matrix.org, example.org |
-                 |   Members:                         |
-                 |    - @alice:matrix.org             |
-                 |    - @bob:example.org              |
-                 | Messages:                          |
-                 |   - @alice:matrix.org              |
-                 |     Content: { JSON object }       |
-                 |....................................|
-
-Federation maintains *shared data structures* per-room between multiple
-homeservers. The data is split into `message events` and `state events`.
-
-Message events:
-These describe transient 'one-off' activity in a room such as
-instant messages, VoIP call setups, file transfers, etc. They generally
-describe communication activity.
-
-State events:
-These describe updates to a given piece of persistent information
-('state') related to a room, such as the room's name, topic, membership,
-participating servers, etc. State is modelled as a lookup table of
-key/value pairs per room, with each key being a tuple of `state_key` and
-`event type`. Each state event updates the value of a given key.
-
-The state of the room at a given point is calculated by considering all
-events preceding and including a given event in the graph. Where events
-describe the same state, a merge conflict algorithm is applied. The
-state resolution algorithm is transitive and does not depend on server
-state, as it must consistently select the same event irrespective of the
-server or the order the events were received in. Events are signed by
-the originating server (the signature includes the parent relations,
-type, depth and payload hash) and are pushed over federation to the
-participating servers in a room, currently using full mesh topology.
-Servers may also request backfill of events over federation from the
-other servers participating in a room.
-
-{{% boxes/note %}}
-Events are not limited to the types defined in this specification. New
-or custom event types can be created on a whim using the Java package
-naming convention. For example, a `com.example.game.score` event can be
-sent by clients and other clients would receive it through Matrix,
-assuming the client has access to the `com.example` namespace.
-{{% /boxes/note %}}
-
-#### Room Aliases
-
-Each room can also have multiple "Room Aliases", which look like:
-
-    #room_alias:domain
-
-See ['Identifier Grammar' in the
-appendices](/appendices#identifier-grammar) for full details of the
-structure of a room alias.
-
-A room alias "points" to a room ID and is the human-readable label by
-which rooms are publicised and discovered. The room ID the alias is
-pointing to can be obtained by visiting the domain specified. Note that
-the mapping from a room alias to a room ID is not fixed, and may change
-over time to point to a different room ID. For this reason, Clients
-SHOULD resolve the room alias to a room ID once and then use that ID on
-subsequent requests.
-
-When resolving a room alias the server will also respond with a list of
-servers that are in the room that can be used to join via.
-
-    HTTP GET
-    #matrix:example.org      !aaabaa:matrix.org
-       |                    ^
-       |                    |
-    _______V____________________|____
-    |          example.org           |
-    | Mappings:                      |
-    | #matrix >> !aaabaa:matrix.org  |
-    | #golf   >> !wfeiofh:sport.com  |
-    | #bike   >> !4rguxf:matrix.org  |
-    |________________________________|
-
-### Identity
-
-Users in Matrix are identified via their Matrix user ID. However,
-existing 3rd party ID namespaces can also be used in order to identify
-Matrix users. A Matrix "Identity" describes both the user ID and any
-other existing IDs from third party namespaces *linked* to their
-account. Matrix users can *link* third-party IDs (3PIDs) such as email
-addresses, social network accounts and phone numbers to their user ID.
-Linking 3PIDs creates a mapping from a 3PID to a user ID. This mapping
-can then be used by Matrix users in order to discover the user IDs of
-their contacts. In order to ensure that the mapping from 3PID to user ID
-is genuine, a globally federated cluster of trusted "identity servers"
-(IS) are used to verify the 3PID and persist and replicate the mappings.
-
-Usage of an IS is not required in order for a client application to be
-part of the Matrix ecosystem. However, without one clients will not be
-able to look up user IDs using 3PIDs.
-
-### Profiles
-
-Users may publish arbitrary key/value data associated with their account
-- such as a human-readable display name, a profile photo URL, contact
-information (email address, phone numbers, website URLs etc).
-
-### Private User Data
-
-Users may also store arbitrary private key/value data in their account -
-such as client preferences, or server configuration settings which lack
-any other dedicated API. The API is symmetrical to managing Profile
-data.
-
-## Common concepts
-
-Various things are common throughout all of the Matrix APIs. They are
-documented here.
-
-### Namespacing
-
-Namespacing helps prevent conflicts between multiple applications and
-the specification itself. Where namespacing is used, `m.` prefixes are
-used by the specification to indicate that the field is controlled by
-the specification. Custom or non-specified namespaces used in the wild
-MUST use the Java package naming convention to prevent conflicts.
-
-As an example, event types defined in the specification are namespaced
-under the special `m.` prefix, however any client can send a custom
-event type, such as `com.example.game.score` (assuming the client has
-rights to the `com.example` namespace) without needing to put the event
-into the `m.` namespace.
-
-### Timestamps
-
-Unless otherwise stated, timestamps are measured as milliseconds since
-the Unix epoch. Throughout the specification this may be referred to as
-POSIX, Unix, or just "time in milliseconds".
-
-## Specification Versions
-
-Matrix as a whole is released under a single specification number in the
-form `vX.Y`.
-
-* A change to `X` reflects a breaking or substantially invasive change.
-  When exactly to increment this number is left to the Spec Core Team,
-  however it is intended for changes such as moving away from JSON,
-  altering the signing algorithm, or when a large number of `Y` changes
-  feel deserving of a major version increase.
-* A change to `Y` represents a backwards compatible or "managed" backwards
-  compatible change to the specification, usually in the form of features.
-
-Additionally, the spec version may have arbitrary metadata applied to it
-when followed by a `-`. For example, `v1.1-alpha`. Usage of this is not
-strictly specified but is intended for usage of pre-release builds of the
-specification.
-
-Note that while `v1.2` is meant to be backwards compatible with `v1.1`, it
-is not guaranteed that future versions will be fully backwards compatible
-with `v1.1`. For example, if `/test` were to be introduced in `v1.1` and
-deprecated in `v1.2`, then it can be removed in `v1.3`. More information
-about this is described in the [deprecation policy](#deprecation-policy)
-below.
-
-### Endpoint versioning
-
-All API endpoints within the specification are versioned individually.
-This means that `/v3/sync` (for example) can get deprecated in favour
-of `/v4/sync` without affecting `/v3/profile` at all. A server supporting
-`/v4/sync` would keep serving `/v3/profile` as it always has.
-
-When an MSC proposes a breaking change to an endpoint it should also
-deprecate the existing endpoint. For some endpoints this might be implicit,
-such as `/v4/sync` being introduced (deprecating `/v3/sync`), however
-for more nuanced examples the MSC should deprecate the endpoint explicitly.
-
-### Deprecation policy
-
-An MSC is required to transition something from stable (the default) to
-deprecated. Once something has been deprecated for suitably long enough
-(usually 1 version), it is eligible for removal from the specification
-with another MSC.
-
-Implementations of Matrix are required to implement deprecated functionality
-of the specification, though when the functionality is later removed then
-the implementation is welcome to drop support (if they don't advertise
-support for a version which includes deprecated functionality). For
-example, if `/test` were deprecated in `v1.2` and removed in `v1.3`, then
-an implementation which wants to advertise support for `v1.2` would have
-to implement `/test`, even if the implementation also advertises support
-for `v1.3`. If that implementation *only* advertises support for `v1.3`
-then it would not be required to implement `/test`.
-
-### Legacy versioning
-
-Prior to this system, the different APIs of Matrix were versioned individually.
-This is no longer possible with the new specification versioning approach.
-
-For historical reference, the APIs were versioned as `rX.Y.Z` where `X`
-roughly represents a breaking change, `Y` a backwards-compatible change, and
-`Z` a patch or insignificant alteration to the API.
-
-`v1.0` of Matrix was released on June 10th, 2019 with the following API
-versions:
-
-| API/Specification       | Version |
-|-------------------------|---------|
-| Client-Server API       | r0.5.0  |
-| Server-Server API       | r0.1.2  |
-| Application Service API | r0.1.1  |
-| Identity Service API    | r0.1.1  |
-| Push Gateway API        | r0.1.0  |
-| Room Version            | v5      |
-
-
-## License
-
-The Matrix specification is licensed under the [Apache License, Version
-2.0](http://www.apache.org/licenses/LICENSE-2.0).
diff --git a/content/appendices.md b/content/appendices.md
deleted file mode 100644
index 2b6de33e..00000000
--- a/content/appendices.md
+++ /dev/null
@@ -1,1249 +0,0 @@
----
-title: "Appendices"
-weight: 70
-type: docs
----
-
-## Unpadded Base64
-
-*Unpadded* Base64 refers to 'standard' Base64 encoding as defined in
-[RFC 4648](https://tools.ietf.org/html/rfc4648), without "=" padding.
-Specifically, where RFC 4648 requires that encoded data be padded to a
-multiple of four characters using `=` characters, unpadded Base64 omits
-this padding.
-
-For reference, RFC 4648 uses the following alphabet for Base 64:
-
-    Value Encoding  Value Encoding  Value Encoding  Value Encoding
-        0 A            17 R            34 i            51 z
-        1 B            18 S            35 j            52 0
-        2 C            19 T            36 k            53 1
-        3 D            20 U            37 l            54 2
-        4 E            21 V            38 m            55 3
-        5 F            22 W            39 n            56 4
-        6 G            23 X            40 o            57 5
-        7 H            24 Y            41 p            58 6
-        8 I            25 Z            42 q            59 7
-        9 J            26 a            43 r            60 8
-       10 K            27 b            44 s            61 9
-       11 L            28 c            45 t            62 +
-       12 M            29 d            46 u            63 /
-       13 N            30 e            47 v
-       14 O            31 f            48 w
-       15 P            32 g            49 x
-       16 Q            33 h            50 y
-
-Examples of strings encoded using unpadded Base64:
-
-    UNPADDED_BASE64("") = ""
-    UNPADDED_BASE64("f") = "Zg"
-    UNPADDED_BASE64("fo") = "Zm8"
-    UNPADDED_BASE64("foo") = "Zm9v"
-    UNPADDED_BASE64("foob") = "Zm9vYg"
-    UNPADDED_BASE64("fooba") = "Zm9vYmE"
-    UNPADDED_BASE64("foobar") = "Zm9vYmFy"
-
-When decoding Base64, implementations SHOULD accept input with or
-without padding characters wherever possible, to ensure maximum
-interoperability.
-
-## Binary data
-
-In some cases it is necessary to encapsulate binary data, for example,
-public keys or signatures. Given that JSON cannot safely represent raw
-binary data, all binary values should be encoded and represented in
-JSON as unpadded Base64 strings as described above.
-
-In cases where the Matrix specification refers to either opaque byte
-or opaque Base64 values, the value is considered to be opaque AFTER
-Base64 decoding, rather than the encoded representation itself.
-
-It is safe for a client or homeserver implementation to check for
-correctness of a Base64-encoded value at any point, and to altogether
-reject a value which is not encoded properly. However, this is optional
-and is considered to be an implementation detail.
-
-Special consideration is given for future protocol transformations,
-such as those which do not use JSON, where Base64 encoding may not be
-necessary in order to represent a binary value safely. In these cases,
-Base64 encoding of binary values may be skipped altogether.
-
-## Signing JSON
-
-Various points in the Matrix specification require JSON objects to be
-cryptographically signed. This requires us to encode the JSON as a
-binary string. Unfortunately the same JSON can be encoded in different
-ways by changing how much white space is used or by changing the order
-of keys within objects.
-
-Signing an object therefore requires it to be encoded as a sequence of
-bytes using [Canonical JSON](#canonical-json), computing the signature
-for that sequence and then adding the signature to the original JSON
-object.
-
-### Canonical JSON
-
-We define the canonical JSON encoding for a value to be the shortest
-UTF-8 JSON encoding with dictionary keys lexicographically sorted by
-Unicode codepoint. Numbers in the JSON must be integers in the range
-`[-(2**53)+1, (2**53)-1]`.
-
-We pick UTF-8 as the encoding as it should be available to all platforms
-and JSON received from the network is likely to be already encoded using
-UTF-8. We sort the keys to give a consistent ordering. We force integers
-to be in the range where they can be accurately represented using IEEE
-double precision floating point numbers since a number of JSON libraries
-represent all numbers using this representation.
-
-{{% boxes/warning %}}
-Events in room versions 1, 2, 3, 4, and 5 might not be fully compliant
-with these restrictions. Servers SHOULD be capable of handling JSON
-which is considered invalid by these restrictions where possible.
-
-The most notable consideration is that integers might not be in the
-range specified above.
-{{% /boxes/warning %}}
-
-{{% boxes/note %}}
-Float values are not permitted by this encoding.
-{{% /boxes/note %}}
-
-```py
-import json
-
-def canonical_json(value):
-    return json.dumps(
-        value,
-        # Encode code-points outside of ASCII as UTF-8 rather than \u escapes
-        ensure_ascii=False,
-        # Remove unnecessary white space.
-        separators=(',',':'),
-        # Sort the keys of dictionaries.
-        sort_keys=True,
-        # Encode the resulting Unicode as UTF-8 bytes.
-    ).encode("UTF-8")
-```
-
-#### Grammar
-
-Adapted from the grammar in <http://tools.ietf.org/html/rfc7159>
-removing insignificant whitespace, fractions, exponents and redundant
-character escapes.
-
-    value     = false / null / true / object / array / number / string
-    false     = %x66.61.6c.73.65
-    null      = %x6e.75.6c.6c
-    true      = %x74.72.75.65
-    object    = %x7B [ member *( %x2C member ) ] %7D
-    member    = string %x3A value
-    array     = %x5B [ value *( %x2C value ) ] %5B
-    number    = [ %x2D ] int
-    int       = %x30 / ( %x31-39 *digit )
-    digit     = %x30-39
-    string    = %x22 *char %x22
-    char      = unescaped / %x5C escaped
-    unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
-    escaped   = %x22 ; "    quotation mark  U+0022
-              / %x5C ; \    reverse solidus U+005C
-              / %x62 ; b    backspace       U+0008
-              / %x66 ; f    form feed       U+000C
-              / %x6E ; n    line feed       U+000A
-              / %x72 ; r    carriage return U+000D
-              / %x74 ; t    tab             U+0009
-              / %x75.30.30.30 (%x30-37 / %x62 / %x65-66) ; u000X
-              / %x75.30.30.31 (%x30-39 / %x61-66)        ; u001X
-
-#### Examples
-
-To assist in the development of compatible implementations, the
-following test values may be useful for verifying the canonical
-transformation code.
-
-Given the following JSON object:
-
-```json
-{}
-```
-
-The following canonical JSON should be produced:
-
-```json
-{}
-```
-
-Given the following JSON object:
-
-```json
-{
-    "one": 1,
-    "two": "Two"
-}
-```
-
-The following canonical JSON should be produced:
-
-```json
-{"one":1,"two":"Two"}
-```
-
-Given the following JSON object:
-
-```json
-{
-    "b": "2",
-    "a": "1"
-}
-```
-
-The following canonical JSON should be produced:
-
-```json
-{"a":"1","b":"2"}
-```
-
-Given the following JSON object:
-
-```json
-{"b":"2","a":"1"}
-```
-
-The following canonical JSON should be produced:
-
-```json
-{"a":"1","b":"2"}
-```
-
-Given the following JSON object:
-
-```json
-{
-    "auth": {
-        "success": true,
-        "mxid": "@john.doe:example.com",
-        "profile": {
-            "display_name": "John Doe",
-            "three_pids": [
-                {
-                    "medium": "email",
-                    "address": "john.doe@example.org"
-                },
-                {
-                    "medium": "msisdn",
-                    "address": "123456789"
-                }
-            ]
-        }
-    }
-}
-```
-
-The following canonical JSON should be produced:
-
-```json
-{"auth":{"mxid":"@john.doe:example.com","profile":{"display_name":"John Doe","three_pids":[{"address":"john.doe@example.org","medium":"email"},{"address":"123456789","medium":"msisdn"}]},"success":true}}
-```
-
-Given the following JSON object:
-
-```json
-{
-    "a": "日本語"
-}
-```
-
-The following canonical JSON should be produced:
-
-```json
-{"a":"日本語"}
-```
-
-Given the following JSON object:
-
-```json
-{
-    "本": 2,
-    "日": 1
-}
-```
-
-The following canonical JSON should be produced:
-
-```json
-{"日":1,"本":2}
-```
-
-Given the following JSON object:
-
-```json
-{
-    "a": "\u65E5"
-}
-```
-
-The following canonical JSON should be produced:
-
-```json
-{"a":"日"}
-```
-
-Given the following JSON object:
-
-```json
-{
-    "a": null
-}
-```
-
-The following canonical JSON should be produced:
-
-```json
-{"a":null}
-```
-
-### Signing Details
-
-JSON is signed by encoding the JSON object without `signatures` or keys
-grouped as `unsigned`, using the canonical encoding described above. The
-JSON bytes are then signed using the signature algorithm and the
-signature is encoded using [unpadded Base64](#unpadded-base64). The resulting base64
-signature is added to an object under the *signing key identifier* which
-is added to the `signatures` object under the name of the entity signing
-it which is added back to the original JSON object along with the
-`unsigned` object.
-
-The *signing key identifier* is the concatenation of the *signing
-algorithm* and a *key identifier*. The *signing algorithm* identifies
-the algorithm used to sign the JSON. The currently supported value for
-*signing algorithm* is `ed25519` as implemented by NACL
-(<http://nacl.cr.yp.to/>). The *key identifier* is used to distinguish
-between different signing keys used by the same entity.
-
-The `unsigned` object and the `signatures` object are not covered by the
-signature. Therefore intermediate entities can add unsigned data such as
-timestamps and additional signatures.
-
-```json
-{
-   "name": "example.org",
-   "signing_keys": {
-     "ed25519:1": "XSl0kuyvrXNj6A+7/tkrB9sxSbRi08Of5uRhxOqZtEQ"
-   },
-   "unsigned": {
-      "age_ts": 922834800000
-   },
-   "signatures": {
-      "example.org": {
-         "ed25519:1": "s76RUgajp8w172am0zQb/iPTHsRnb4SkrzGoeCOSFfcBY2V/1c8QfrmdXHpvnc2jK5BD1WiJIxiMW95fMjK7Bw"
-      }
-   }
-}
-```
-
-```py
-def sign_json(json_object, signing_key, signing_name):
-    signatures = json_object.pop("signatures", {})
-    unsigned = json_object.pop("unsigned", None)
-
-    signed = signing_key.sign(encode_canonical_json(json_object))
-    signature_base64 = encode_base64(signed.signature)
-
-    key_id = "%s:%s" % (signing_key.alg, signing_key.version)
-    signatures.setdefault(signing_name, {})[key_id] = signature_base64
-
-    json_object["signatures"] = signatures
-    if unsigned is not None:
-        json_object["unsigned"] = unsigned
-
-    return json_object
-```
-
-### Checking for a Signature
-
-To check if an entity has signed a JSON object an implementation does
-the following:
-
-1.  Checks if the `signatures` member of the object contains an entry
-    with the name of the entity. If the entry is missing then the check
-    fails.
-2.  Removes any *signing key identifiers* from the entry with algorithms
-    it doesn't understand. If there are no *signing key identifiers*
-    left then the check fails.
-3.  Looks up *verification keys* for the remaining *signing key
-    identifiers* either from a local cache or by consulting a trusted
-    key server. If it cannot find a *verification key* then the check
-    fails.
-4.  Decodes the base64 encoded signature bytes. If base64 decoding fails
-    then the check fails.
-5.  Removes the `signatures` and `unsigned` members of the object.
-6.  Encodes the remainder of the JSON object using the [Canonical
-    JSON](#canonical-json) encoding.
-7.  Checks the signature bytes against the encoded object using the
-    *verification key*. If this fails then the check fails. Otherwise
-    the check succeeds.
-
-## Identifier Grammar
-
-Some identifiers are specific to given room versions, please refer to
-the [room versions specification](/rooms) for more
-information.
-
-### Common Namespaced Identifier Grammar
-
-{{% added-in v="1.2" %}}
-
-The specification defines some identifiers to use the *Common Namespaced
-Identifier Grammar*. This is a common grammar intended for non-user-visible
-identifiers, with a defined mechanism for implementations to create new
-identifiers.
-
-The grammar is defined as follows:
-
- * An identifier must be at least one character and at most 255 characters
-   in length.
- * Identifiers must start with one of the characters `[a-z]`, and be entirely
-   composed of the characters `[a-z]`, `[0-9]`, `-`, `_` and `.`.
- * Identifiers starting with the characters `m.` are reserved for use by the
-   official Matrix specification.
- * Identifiers which are not described in the specification should follow the
-   Java Package Naming Convention to namespace their identifier. This is typically
-   a reverse DNS format, such as `com.example.identifier`.
-
-{{% boxes/note %}}
-Identifiers can and do inherit grammar from this specification. For example, "this
-identifier uses the Common Namespaced Identifier Grammar, though without the namespacing
-requirements" - this means that `m.` is still reserved, but that implementations
-do not have to use the reverse DNS scheme to namespace their custom identifier.
-{{% /boxes/note %}}
-
-{{% boxes/rationale %}}
-ASCII characters do not have issues with homoglyphs or alternative encodings which
-might interfere with the identifier's purpose. Additionally, using lowercase
-characters prevents concerns about case sensitivity.
-{{% /boxes/rationale %}}
-
-### Server Name
-
-A homeserver is uniquely identified by its server name. This value is
-used in a number of identifiers, as described below.
-
-The server name represents the address at which the homeserver in
-question can be reached by other homeservers. All valid server names are
-included by the following grammar:
-
-    server_name = hostname [ ":" port ]
-
-    port        = 1*5DIGIT
-
-    hostname    = IPv4address / "[" IPv6address "]" / dns-name
-
-    IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
-
-    IPv6address = 2*45IPv6char
-
-    IPv6char    = DIGIT / %x41-46 / %x61-66 / ":" / "."
-                      ; 0-9, A-F, a-f, :, .
-
-    dns-name    = 1*255dns-char
-
-    dns-char    = DIGIT / ALPHA / "-" / "."
-
-— in other words, the server name is the hostname, followed by an
-optional numeric port specifier. The hostname may be a dotted-quad IPv4
-address literal, an IPv6 address literal surrounded with square
-brackets, or a DNS name.
-
-IPv4 literals must be a sequence of four decimal numbers in the range 0
-to 255, separated by `.`. IPv6 literals must be as specified by
-[RFC3513, section 2.2](https://tools.ietf.org/html/rfc3513#section-2.2).
-
-DNS names for use with Matrix should follow the conventional
-restrictions for internet hostnames: they should consist of a series of
-labels separated by `.`, where each label consists of the alphanumeric
-characters or hyphens.
-
-Examples of valid server names are:
-
--   `matrix.org`
--   `matrix.org:8888`
--   `1.2.3.4` (IPv4 literal)
--   `1.2.3.4:1234` (IPv4 literal with explicit port)
--   `[1234:5678::abcd]` (IPv6 literal)
--   `[1234:5678::abcd]:5678` (IPv6 literal with explicit port)
-
-{{% boxes/note %}}
-This grammar is based on the standard for internet host names, as
-specified by [RFC1123, section
-2.1](https://tools.ietf.org/html/rfc1123#page-13), with an extension for
-IPv6 literals.
-{{% /boxes/note %}}
-
-Server names must be treated case-sensitively: in other words,
-`@user:matrix.org` is a different person from `@user:MATRIX.ORG`.
-
-Some recommendations for a choice of server name follow:
-
--   The length of the complete server name should not exceed 230
-    characters.
--   Server names should not use upper-case characters.
-
-### Common Identifier Format
-
-The Matrix protocol uses a common format to assign unique identifiers to
-a number of entities, including users, events and rooms. Each identifier
-takes the form:
-
-    &string
-
-where `&` represents a 'sigil' character; `string` is the string which
-makes up the identifier.
-
-The sigil characters are as follows:
-
--   `@`: User ID
--   `!`: Room ID
--   `$`: Event ID
--   `+`: Group ID
--   `#`: Room alias
-
-User IDs, group IDs, room IDs, room aliases, and sometimes event IDs
-take the form:
-
-    &localpart:domain
-
-where `domain` is the [server name](#server-name) of the homeserver
-which allocated the identifier, and `localpart` is an identifier
-allocated by that homeserver.
-
-The precise grammar defining the allowable format of an identifier
-depends on the type of identifier. For example, event IDs can sometimes
-be represented with a `domain` component under some conditions - see the
-[Event IDs](#room-ids-and-event-ids) section below for more information.
-
-#### User Identifiers
-
-Users within Matrix are uniquely identified by their Matrix user ID. The
-user ID is namespaced to the homeserver which allocated the account and
-has the form:
-
-    @localpart:domain
-
-The `localpart` of a user ID is an opaque identifier for that user. It
-MUST NOT be empty, and MUST contain only the characters `a-z`, `0-9`,
-`.`, `_`, `=`, `-`, and `/`.
-
-The `domain` of a user ID is the [server name](#server-name) of the
-homeserver which allocated the account.
-
-The length of a user ID, including the `@` sigil and the domain, MUST
-NOT exceed 255 characters.
-
-The complete grammar for a legal user ID is:
-
-    user_id = "@" user_id_localpart ":" server_name
-    user_id_localpart = 1*user_id_char
-    user_id_char = DIGIT
-                 / %x61-7A                   ; a-z
-                 / "-" / "." / "=" / "_" / "/"
-
-{{% boxes/rationale %}}
-A number of factors were considered when defining the allowable
-characters for a user ID.
-
-Firstly, we chose to exclude characters outside the basic US-ASCII
-character set. User IDs are primarily intended for use as an identifier
-at the protocol level, and their use as a human-readable handle is of
-secondary benefit. Furthermore, they are useful as a last-resort
-differentiator between users with similar display names. Allowing the
-full Unicode character set would make very difficult for a human to
-distinguish two similar user IDs. The limited character set used has the
-advantage that even a user unfamiliar with the Latin alphabet should be
-able to distinguish similar user IDs manually, if somewhat laboriously.
-
-We chose to disallow upper-case characters because we do not consider it
-valid to have two user IDs which differ only in case: indeed it should
-be possible to reach `@user:matrix.org` as `@USER:matrix.org`. However,
-user IDs are necessarily used in a number of situations which are
-inherently case-sensitive (notably in the `state_key` of `m.room.member`
-events). Forbidding upper-case characters (and requiring homeservers to
-downcase usernames when creating user IDs for new users) is a relatively
-simple way to ensure that `@USER:matrix.org` cannot refer to a different
-user to `@user:matrix.org`.
-
-Finally, we decided to restrict the allowable punctuation to a very
-basic set to reduce the possibility of conflicts with special characters
-in various situations. For example, "\*" is used as a wildcard in some
-APIs (notably the filter API), so it cannot be a legal user ID
-character.
-
-The length restriction is derived from the limit on the length of the
-`sender` key on events; since the user ID appears in every event sent by
-the user, it is limited to ensure that the user ID does not dominate
-over the actual content of the events.
-{{% /boxes/rationale %}}
-
-Matrix user IDs are sometimes informally referred to as MXIDs.
-
-##### Historical User IDs
-
-Older versions of this specification were more tolerant of the
-characters permitted in user ID localparts. There are currently active
-users whose user IDs do not conform to the permitted character set, and
-a number of rooms whose history includes events with a `sender` which
-does not conform. In order to handle these rooms successfully, clients
-and servers MUST accept user IDs with localparts from the expanded
-character set:
-
-    extended_user_id_char = %x21-39 / %x3B-7E  ; all ASCII printing chars except :
-
-##### Mapping from other character sets
-
-In certain circumstances it will be desirable to map from a wider
-character set onto the limited character set allowed in a user ID
-localpart. Examples include a homeserver creating a user ID for a new
-user based on the username passed to `/register`, or a bridge mapping
-user ids from another protocol.
-
-Implementations are free to do this mapping however they choose. Since
-the user ID is opaque except to the implementation which created it, the
-only requirement is that the implementation can perform the mapping
-consistently. However, we suggest the following algorithm:
-
-1.  Encode character strings as UTF-8.
-2.  Convert the bytes `A-Z` to lower-case.
-    -   In the case where a bridge must be able to distinguish two
-        different users with ids which differ only by case, escape
-        upper-case characters by prefixing with `_` before downcasing.
-        For example, `A` becomes `_a`. Escape a real `_` with a second
-        `_`.
-3.  Encode any remaining bytes outside the allowed character set, as
-    well as `=`, as their hexadecimal value, prefixed with `=`. For
-    example, `#` becomes `=23`; `á` becomes `=c3=a1`.
-
-{{% boxes/rationale %}}
-The suggested mapping is an attempt to preserve human-readability of
-simple ASCII identifiers (unlike, for example, base-32), whilst still
-allowing representation of *any* character (unlike punycode, which
-provides no way to encode ASCII punctuation).
-{{% /boxes/rationale %}}
-
-#### Room IDs and Event IDs
-
-A room has exactly one room ID. A room ID has the format:
-
-    !opaque_id:domain
-
-An event has exactly one event ID. The format of an event ID depends
-upon the [room version specification](/rooms).
-
-The `domain` of a room ID is the [server name](#server-name) of the
-homeserver which created the room/event. The domain is used only for
-namespacing to avoid the risk of clashes of identifiers between
-different homeservers. There is no implication that the room or event in
-question is still available at the corresponding homeserver.
-
-Event IDs and Room IDs are case-sensitive. They are not meant to be
-human-readable. They are intended to be treated as fully opaque strings
-by clients.
-
-#### Room Aliases
-
-A room may have zero or more aliases. A room alias has the format:
-
-    #room_alias:domain
-
-The `domain` of a room alias is the [server name](#server-name) of the
-homeserver which created the alias. Other servers may contact this
-homeserver to look up the alias.
-
-Room aliases MUST NOT exceed 255 bytes (including the `#` sigil and the
-domain).
-
-#### URIs
-
-There are two major kinds of referring to a resource in Matrix: matrix.to
-and `matrix:` URI. The specification currently defines both as active/valid
-ways to refer to entities/resources.
-
-Rooms, users, and aliases may be represented as a URI. This URI can
-be used to reference particular objects in a given context, such as mentioning
-a user in a message or linking someone to a particular point in the room's
-history (a permalink).
-
-##### Matrix URI scheme
-
-{{% added-in v="1.2" %}}
-
-The Matrix URI scheme is defined as follows (`[]` enclose optional parts, `{}`
-enclose variables):
-```
-matrix:[//{authority}/]{type}/{id without sigil}[/{type}/{id without sigil}...][?{query}][#{fragment}]
-```
-
-As a schema, this can be represented as:
-
-```
-MatrixURI = "matrix:" hier-part [ "?" query ] [ "#" fragment ]
-hier-part = [ "//" authority "/" ] path
-path = entity-descriptor ["/" entity-descriptor]
-entity-descriptor = nonid-segment / type-qualifier id-without-sigil
-nonid-segment = segment-nz ; as defined in RFC 3986
-type-qualifier = segment-nz "/" ; as defined in RFC 3986
-id-without-sigil = string ; as defined in Matrix identifier spec above
-query = query-element *( "&" query-item )
-query-item = action / routing / custom-query-item
-action = "action=" ( "join" / "chat" )
-routing = "via=” authority
-custom-query-item = custom-item-name "=" custom-item-value
-custom-item-name = 1*unreserved ; reverse-DNS name
-custom-item-value =
-```
-
-Note that this format is deliberately following [RFC 3986](https://tools.ietf.org/html/rfc3986)
-to ensure maximum compatibility with existing tooling. The scheme name (`matrix`) is
-registered alongside other schemes by the IANA [here](https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml).
-
-Currently, the `authority` and `fragment` are unused by this specification,
-though are reserved for future use. Matrix does not have a central authority which
-could reasonably fill the `authority` role. `nonid-segment` in the schema is
-additionally reserved for future use.
-
-The `type` denotes the kind of entity which is described by `id without sigil`.
-Specifically, the following mappings are used:
-
-* `r` for room aliases.
-* `u` for users.
-* `roomid` for room IDs (note the distinction from room aliases).
-* `e` for events, when after a room reference (`r` or `roomid`).
-
-{{% boxes/note %}}
-During development of this URI format, types of `user`, `room`, and `event`
-were used: these MUST NOT be produced any further, though implementations might
-wish to consider handling them as `u`, `r`, and `e` respectively.
-
-`roomid` was otherwise unchanged.
-{{% /boxes/note %}}
-
-The `id without sigil` is simply the identifier for the entity without the defined
-sigil. For example, `!room:example.org` becomes `room:example.org` (`!` is the sigil
-for room IDs). The sigils are described under the
-[Common Identifier Format](#common-identifier-format).
-
-The `query` is optional and helps clients with processing the URI's intent. In
-this specification are the following:
-
-* `action` - Helps provide intent for what the client should do specifically with
-  the URI. Lack of an `action` simply indicates that the URI is identifying a resource
-  and has no suggested action associated with it - clients could treat this as
-  navigating the user to an informational page, for example.
-  * `action=join` - Describes an intent for the client to join the room described
-    by the URI and thus is only valid on URIs which are referring to a room (it
-    has no meaning and is ignored otherwise). The client should prompt for confirmation
-    prior to joining the room, if the user isn't already part of the room.
-  * `action=chat` - Describes an intent for the client to start/open a DM with
-    the user described by the URI and thus is only valid on URIs which are referring
-    to a user (it has no meaning and is ignored otherwise). Clients supporting a
-    form of Canonical DMs should reuse existing DMs instead of creating new ones
-    if available. The client should prompt for confirmation prior to creating the
-    DM, if the user isn't being redirected to an existing canonical DM.
-* `via` - Can be used to denote which servers (`authority` grammar) to attempt to resolve
-  the resource through, or take `action` through. An example of using `via` for
-  routing Room IDs is described [below](#routing), and is encouraged for use in
-  Matrix URIs referring to a room ID. Matrix URIs can additionally use this `via`
-  parameter for non-public federation resolution of identifiers (i.e.: listing a
-  server which might have information about the given user) while a more comprehensive
-  way is being worked out, such as one proposed by [MSC3020](https://github.com/matrix-org/matrix-doc/pull/3020).
-
-Custom query parameters can be specified using the
-[Common Namespaced Identifier format](#common-namespaced-identifier-grammar) and
-appropriately encoding their values. Specifically, "percent encoding" and encoding
-of the `&` are required. Where custom parameters conflict with specified ones,
-clients should prefer the specified parameters. Clients should strive to maintain
-consistency across custom parameters as users might be using multiple different
-clients across multiple different authors. Useful and mission-aligned custom
-parameters should be proposed to be included in this specification.
-
-Examples of common URIs are:
-
-<!-- Author's note: These examples should be consistent with the matrix.to counterparts. -->
-* Link to `#somewhere:example.org`: `matrix:r/somewhere:example.org`
-* Link to `!somewhere:example.org`: `matrix:roomid/somewhere:example.org?via=elsewhere.ca`
-* Link to `$event` in `#somewhere:example.org`: `matrix:r/somewhere:example.org/e/event`
-* Link to `$event` in `!somewhere:example.org`: `matrix:roomid/somewhere:example.org/e/event?via=elsewhere.ca`
-* Link to chat with `@alice:example.org`: `matrix:u/alice:example.org?action=chat`
-
-A suggested client implementation algorithm is available in the
-[original MSC](https://github.com/matrix-org/matrix-doc/blob/main/proposals/2312-matrix-uri.md#recommended-implementation).
-
-##### matrix.to navigation
-
-{{% boxes/note %}}
-This namespacing existed prior to a `matrix:` scheme. This is **not**
-meant to be interpreted as an available web service - see below for more
-details.
-{{% /boxes/note %}}
-
-A matrix.to URI has the following format, based upon the specification
-defined in [RFC 3986](https://tools.ietf.org/html/rfc3986):
-
-```
-https://matrix.to/#/<identifier>/<extra parameter>?<additional arguments>
-```
-
-The identifier may be a room ID, room alias, user ID, or group ID. The
-extra parameter is only used in the case of permalinks where an event ID
-is referenced. The matrix.to URI, when referenced, must always start
-with `https://matrix.to/#/` followed by the identifier.
-
-The `<additional arguments>` and the preceding question mark are
-optional and only apply in certain circumstances, documented below.
-
-Clients should not rely on matrix.to URIs falling back to a web server
-if accessed and instead should perform some sort of action within the
-client. For example, if the user were to click on a matrix.to URI for a
-room alias, the client may open a view for the user to participate in
-the room.
-
-The components of the matrix.to URI (`<identifier>` and
-`<extra parameter>`) are to be percent-encoded as per RFC 3986.
-
-Examples of matrix.to URIs are:
-
-<!-- Author's note: These examples should be consistent with the matrix scheme counterparts. -->
-* Link to `#somewhere:example.org`: `https://matrix.to/#/%23somewhere%3Aexample.org`
-* Link to `!somewhere:example.org`: `https://matrix.to/#/!somewhere%3Aexample.org?via=elsewhere.ca`
-* Link to `$event` in `#somewhere:example.org`: `https://matrix.to/#/%23somewhere:example.org/%24event%3Aexample.org`
-* Link to `$event` in `!somewhere:example.org`: `https://matrix.to/#/!somewhere%3Aexample.org/%24event%3Aexample.org?via=elsewhere.ca`
-* Link to `@alice:example.org`: `https://matrix.to/#/%40alice%3Aexample.org`
-
-{{% boxes/note %}}
-Historically, clients have not produced URIs which are fully encoded.
-Clients should try to interpret these cases to the best of their
-ability. For example, an unencoded room alias should still work within
-the client if possible.
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-Clients should be aware that decoding a matrix.to URI may result in
-extra slashes appearing due to some [room
-versions](/rooms). These slashes should normally be
-encoded when producing matrix.to URIs, however.
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-<!-- TODO: @@TravisR: Make "Spaces" a link when that specification exists -->
-In prior versions of this specification, a concept of "groups" were mentioned
-to organize rooms. This functionality did not properly get introduced into
-the specification and is subsequently replaced with "Spaces". Historical
-matrix.to URIs pointing to groups might still exist: they take the form
-`https://matrix.to/#/%2Bexample%3Aexample.org` (where the `+` sigil may or
-may not be encoded).
-{{% /boxes/note %}}
-
-##### Routing
-
-Room IDs are not routable on their own as there is no reliable domain to
-send requests to. This is partially mitigated with the addition of a
-`via` argument on a URI, however the problem of routability is
-still present. Clients should do their best to route Room IDs to where
-they need to go, however they should also be aware of [issue
-\#1579](https://github.com/matrix-org/matrix-doc/issues/1579).
-
-A room (or room permalink) which isn't using a room alias should supply
-at least one server using `via` in the URI's query string. Multiple servers
-can be specified by including multuple `via` parameters.
-
-The values of `via` are intended to be passed along as the `server_name`
-parameters on the [Client Server `/join/{roomIdOrAlias}` API](/client-server-api/#post_matrixclientv3joinroomidoralias).
-
-When generating room links and permalinks, the application should pick
-servers which have a high probability of being in the room in the
-distant future. How these servers are picked is left as an
-implementation detail, however the current recommendation is to pick 3
-unique servers based on the following criteria:
-
--   The first server should be the server of the highest power level
-    user in the room, provided they are at least power level 50. If no
-    user meets this criterion, pick the most popular server in the room
-    (most joined users). The rationale for not picking users with power
-    levels under 50 is that they are unlikely to be around into the
-    distant future while higher ranking users (and therefore servers)
-    are less likely to give up their power and move somewhere else. Most
-    rooms in the public federation have a power level 100 user and have
-    not deviated from the default structure where power level 50 users
-    have moderator-style privileges.
--   The second server should be the next highest server by population,
-    or the first highest by population if the first server was based on
-    a user's power level. The rationale for picking popular servers is
-    that the server is unlikely to be removed as the room naturally
-    grows in membership due to that server joining users. The server
-    could be refused participation in the future due to server ACLs or
-    similar, however the chance of that happening to a server which is
-    organically joining the room is unlikely.
--   The third server should be the next highest server by population.
--   Servers which are blocked due to server ACLs should never be chosen.
--   Servers which are IP addresses should never be chosen. Servers which
-    use a domain name are less likely to be unroutable in the future
-    whereas IP addresses cannot be pointed to a different location and
-    therefore higher risk options.
--   All 3 servers should be unique from each other. If the room does not
-    have enough users to supply 3 servers, the application should only
-    specify the servers it can. For example, a room with only 2 users in
-    it would result in maximum 2 `via` parameters.
-
-## 3PID Types
-
-Third Party Identifiers (3PIDs) represent identifiers on other
-namespaces that might be associated with a particular person. They
-comprise a tuple of `medium` which is a string that identifies the
-namespace in which the identifier exists, and an `address`: a string
-representing the identifier in that namespace. This must be a canonical
-form of the identifier, *i.e.* if multiple strings could represent the
-same identifier, only one of these strings must be used in a 3PID
-address, in a well-defined manner.
-
-For example, for e-mail, the `medium` is 'email' and the `address` would
-be the email address, *e.g.* the string `bob@example.com`. Since domain
-resolution is case-insensitive, the email address `bob@Example.com` is
-also has the 3PID address of `bob@example.com` (without the capital 'e')
-rather than `bob@Example.com`.
-
-The namespaces defined by this specification are listed below. More
-namespaces may be defined in future versions of this specification.
-
-### E-Mail
-
-Medium: `email`
-
-Represents E-Mail addresses. The `address` is the raw email address in
-`user@domain` form with the domain in lowercase. It must not contain
-other text such as real name, angle brackets or a mailto: prefix.
-
-In addition to lowercasing the domain component of an email address,
-implementations are expected to apply the unicode case-folding algorithm
-as described under "Caseless Matching" in
-[chapter 5 of the unicode standard](https://www.unicode.org/versions/Unicode13.0.0/ch05.pdf#G21790).
-For example, `Strauß@Example.com` must be considered to be `strauss@example.com`
-while processing the email address.
-
-### PSTN Phone numbers
-
-Medium: `msisdn`
-
-Represents telephone numbers on the public switched telephone network.
-The `address` is the telephone number represented as a MSISDN (Mobile
-Station International Subscriber Directory Number) as defined by the
-E.164 numbering plan. Note that MSISDNs do not include a leading '+'.
-
-## Security Threat Model
-
-### Denial of Service
-
-The attacker could attempt to prevent delivery of messages to or from
-the victim in order to:
-
--   Disrupt service or marketing campaign of a commercial competitor.
--   Censor a discussion or censor a participant in a discussion.
--   Perform general vandalism.
-
-#### Threat: Resource Exhaustion
-
-An attacker could cause the victim's server to exhaust a particular
-resource (e.g. open TCP connections, CPU, memory, disk storage)
-
-#### Threat: Unrecoverable Consistency Violations
-
-An attacker could send messages which created an unrecoverable
-"split-brain" state in the cluster such that the victim's servers could
-no longer derive a consistent view of the chatroom state.
-
-#### Threat: Bad History
-
-An attacker could convince the victim to accept invalid messages which
-the victim would then include in their view of the chatroom history.
-Other servers in the chatroom would reject the invalid messages and
-potentially reject the victims messages as well since they depended on
-the invalid messages.
-
-#### Threat: Block Network Traffic
-
-An attacker could try to firewall traffic between the victim's server
-and some or all of the other servers in the chatroom.
-
-#### Threat: High Volume of Messages
-
-An attacker could send large volumes of messages to a chatroom with the
-victim making the chatroom unusable.
-
-#### Threat: Banning users without necessary authorisation
-
-An attacker could attempt to ban a user from a chatroom without the
-necessary authorisation.
-
-### Spoofing
-
-An attacker could try to send a message claiming to be from the victim
-without the victim having sent the message in order to:
-
--   Impersonate the victim while performing illicit activity.
--   Obtain privileges of the victim.
-
-#### Threat: Altering Message Contents
-
-An attacker could try to alter the contents of an existing message from
-the victim.
-
-#### Threat: Fake Message "origin" Field
-
-An attacker could try to send a new message purporting to be from the
-victim with a phony "origin" field.
-
-### Spamming
-
-The attacker could try to send a high volume of solicited or unsolicited
-messages to the victim in order to:
-
--   Find victims for scams.
--   Market unwanted products.
-
-#### Threat: Unsolicited Messages
-
-An attacker could try to send messages to victims who do not wish to
-receive them.
-
-#### Threat: Abusive Messages
-
-An attacker could send abusive or threatening messages to the victim
-
-### Spying
-
-The attacker could try to access message contents or metadata for
-messages sent by the victim or to the victim that were not intended to
-reach the attacker in order to:
-
--   Gain sensitive personal or commercial information.
--   Impersonate the victim using credentials contained in the messages.
-    (e.g. password reset messages)
--   Discover who the victim was talking to and when.
-
-#### Threat: Disclosure during Transmission
-
-An attacker could try to expose the message contents or metadata during
-transmission between the servers.
-
-#### Threat: Disclosure to Servers Outside Chatroom
-
-An attacker could try to convince servers within a chatroom to send
-messages to a server it controls that was not authorised to be within
-the chatroom.
-
-#### Threat: Disclosure to Servers Within Chatroom
-
-An attacker could take control of a server within a chatroom to expose
-message contents or metadata for messages in that room.
-
-## Cryptographic Test Vectors
-
-To assist in the development of compatible implementations, the
-following test values may be useful for verifying the cryptographic
-event signing code.
-
-### Signing Key
-
-The following test vectors all use the 32-byte value given by the
-following Base64-encoded string as the seed for generating the `ed25519`
-signing key:
-
-    SIGNING_KEY_SEED = decode_base64(
-        "YJDBA9Xnr2sVqXD9Vj7XVUnmFZcZrlw8Md7kMW+3XA1"
-    )
-
-In each case, the server name and key ID are as follows:
-
-    SERVER_NAME = "domain"
-
-    KEY_ID = "ed25519:1"
-
-### JSON Signing
-
-Given an empty JSON object:
-
-```json
-{}
-```
-
-The JSON signing algorithm should emit the following signed data:
-
-```json
-{
-    "signatures": {
-        "domain": {
-            "ed25519:1": "K8280/U9SSy9IVtjBuVeLr+HpOB4BQFWbg+UZaADMtTdGYI7Geitb76LTrr5QV/7Xg4ahLwYGYZzuHGZKM5ZAQ"
-        }
-    }
-}
-```
-
-Given the following JSON object with data values in it:
-
-```json
-{
-    "one": 1,
-    "two": "Two"
-}
-```
-
-The JSON signing algorithm should emit the following signed JSON:
-
-```json
-{
-    "one": 1,
-    "signatures": {
-        "domain": {
-            "ed25519:1": "KqmLSbO39/Bzb0QIYE82zqLwsA+PDzYIpIRA2sRQ4sL53+sN6/fpNSoqE7BP7vBZhG6kYdD13EIMJpvhJI+6Bw"
-        }
-    },
-    "two": "Two"
-}
-```
-
-### Event Signing
-
-Given the following minimally-sized event:
-
-```json
-{
-    "room_id": "!x:domain",
-    "sender": "@a:domain",
-    "origin": "domain",
-    "origin_server_ts": 1000000,
-    "signatures": {},
-    "hashes": {},
-    "type": "X",
-    "content": {},
-    "prev_events": [],
-    "auth_events": [],
-    "depth": 3,
-    "unsigned": {
-        "age_ts": 1000000
-    }
-}
-```
-
-The event signing algorithm should emit the following signed event:
-
-```json
-{
-    "auth_events": [],
-    "content": {},
-    "depth": 3,
-    "hashes": {
-        "sha256": "5jM4wQpv6lnBo7CLIghJuHdW+s2CMBJPUOGOC89ncos"
-    },
-    "origin": "domain",
-    "origin_server_ts": 1000000,
-    "prev_events": [],
-    "room_id": "!x:domain",
-    "sender": "@a:domain",
-    "signatures": {
-        "domain": {
-            "ed25519:1": "KxwGjPSDEtvnFgU00fwFz+l6d2pJM6XBIaMEn81SXPTRl16AqLAYqfIReFGZlHi5KLjAWbOoMszkwsQma+lYAg"
-        }
-    },
-    "type": "X",
-    "unsigned": {
-        "age_ts": 1000000
-    }
-}
-```
-
-Given the following event containing redactable content:
-
-```json
-{
-    "content": {
-        "body": "Here is the message content"
-    },
-    "event_id": "$0:domain",
-    "origin": "domain",
-    "origin_server_ts": 1000000,
-    "type": "m.room.message",
-    "room_id": "!r:domain",
-    "sender": "@u:domain",
-    "signatures": {},
-    "unsigned": {
-        "age_ts": 1000000
-    }
-}
-```
-
-The event signing algorithm should emit the following signed event:
-
-```json
-{
-    "content": {
-        "body": "Here is the message content"
-    },
-    "event_id": "$0:domain",
-    "hashes": {
-        "sha256": "onLKD1bGljeBWQhWZ1kaP9SorVmRQNdN5aM2JYU2n/g"
-    },
-    "origin": "domain",
-    "origin_server_ts": 1000000,
-    "type": "m.room.message",
-    "room_id": "!r:domain",
-    "sender": "@u:domain",
-    "signatures": {
-        "domain": {
-            "ed25519:1": "Wm+VzmOUOz08Ds+0NTWb1d4CZrVsJSikkeRxh6aCcUwu6pNC78FunoD7KNWzqFn241eYHYMGCA5McEiVPdhzBA"
-        }
-    },
-    "unsigned": {
-        "age_ts": 1000000
-    }
-}
-```
-
-## Conventions for Matrix APIs
-
-This section is intended primarily to guide API designers when adding to Matrix,
-setting guidelines to follow for how those APIs should work. This is important to
-maintain consistency with the Matrix protocol, and thus improve developer
-experience.
-
-### HTTP endpoint and JSON property naming
-
-The names of the API endpoints for the HTTP transport follow a convention of
-using underscores to separate words (for example `/delete_devices`).
-
-The key names in JSON objects passed over the API also follow this convention.
-
-{{% boxes/note %}}
-There are a few historical exceptions to this rule, such as `/createRoom`.
-These inconsistencies may be addressed in future versions of this specification.
-{{% /boxes/note %}}
-
-### Pagination
-
-REST API endpoints which can return multiple "pages" of results should adopt the
-following conventions.
-
- * If more results are available, the endpoint should return a property named
-   `next_batch`. The value should be a string token which can be passed into
-   a subsequent call to the endpoint to retrieve the next page of results.
-
-   If no more results are available, this is indicated by *omitting* the
-   `next_batch` property from the results.
-
- * The endpoint should accept a query-parameter named `from` which the client
-   is expected to set to the value of a previous `next_batch`.
-
- * Some endpoints might support pagination in two directions (example:
-   `/messages`, which can be used to move forward or backwards in the timeline
-   from a known point). In this case, the endpoint should return a `prev_batch`
-   property which can be passed into `from` to receive the previous page of
-   results.
-
-   Avoid having a separate "direction" parameter, which is generally redundant:
-   the tokens returned by `next_batch` and `prev_batch` should contain enough
-   information for subsequent calls to the API to know which page of results
-   they should return.
diff --git a/content/application-service-api.md b/content/application-service-api.md
deleted file mode 100644
index 99ae4d54..00000000
--- a/content/application-service-api.md
+++ /dev/null
@@ -1,397 +0,0 @@
----
-title: "Application Service API"
-weight: 30
-type: docs
----
-
-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
-homeserver. They can inject events into rooms they are participating in.
-They cannot prevent events from being sent, nor can they modify the
-content of the event being sent. In order to observe events from a
-homeserver, the homeserver needs to be configured to pass certain types
-of traffic to the application service. This is achieved by manually
-configuring the homeserver with information about the application
-service.
-
-### Registration
-
-{{% boxes/note %}}
-Previously, application services could register with a homeserver via
-HTTP APIs. This was removed as it was seen as a security risk. A
-compromised application service could re-register for a global `*` regex
-and sniff *all* traffic on the homeserver. To protect against this,
-application services now have to register via configuration files which
-are linked to the homeserver configuration file. The addition of
-configuration files allows homeserver admins to sanity check the
-registration for suspicious regex strings.
-{{% /boxes/note %}}
-
-Application services register "namespaces" of user IDs, room aliases and
-room IDs. These namespaces are represented as regular expressions. An
-application service is said to be "interested" in a given event if one
-of the IDs in the event match the regular expression provided by the
-application service, such as the room having an alias or ID in the
-relevant namespaces. Similarly, the application service is said to be
-interested in a given event if one of the application service's
-namespaced users is the target of the event, or is a joined member of
-the room where the event occurred.
-
-An application service can also state whether they should be the only
-ones who can manage a specified namespace. This is referred to as an
-"exclusive" namespace. An exclusive namespace prevents humans and other
-application services from creating/deleting entities in that namespace.
-Typically, exclusive namespaces are used when the rooms represent real
-rooms on another service (e.g. IRC). Non-exclusive namespaces are used
-when the application service is merely augmenting the room itself (e.g.
-providing logging or searching facilities). Namespaces are represented
-by POSIX extended regular expressions and look like:
-
-    users:
-      - exclusive: true
-        regex: "@_irc_bridge_.*"
-
-Application services may define the following namespaces (with none
-being explicitly required):
-
-| Name     | Description                                                |
-|----------|------------------------------------------------------------|
-| users    | Events which are sent from certain users.                  |
-| aliases  | Events which are sent in rooms with certain room aliases.  |
-| rooms    | Events which are sent in rooms with certain room IDs.      |
-
-Each individual namespace MUST declare the following fields:
-
-| Name       | Description                                                                                                                        |
-|------------|------------------------------------------------------------------------------------------------------------------------------------|
-| exclusive  | **Required** A true or false value stating whether this application service has exclusive access to events within this namespace.  |
-| regex      | **Required** A regular expression defining which values this namespace includes.                                                   |
-
-Exclusive user and alias namespaces should begin with an underscore
-after the sigil to avoid collisions with other users on the homeserver.
-Application services should additionally attempt to identify the service
-they represent in the reserved namespace. For example, `@_irc_.*` would
-be a good namespace to register for an application service which deals
-with IRC.
-
-The registration is represented by a series of key-value pairs, which
-this specification will present as YAML. See below for the possible
-options along with their explanation:
-
-
-| Name              | Description                                                                                                                                   |
-|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|
-| id                | **Required** A unique, user-defined ID of the application service which will never change.                                                    |
-| url               | **Required** 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          | **Required** A unique token for application services to use to authenticate requests to Homeservers.                                          |
-| hs_token          | **Required** A unique token for Homeservers to use to authenticate requests to application services.                                          |
-| sender_localpart  | **Required** The localpart of the user associated with the application service.                                                               |
-| namespaces        | **Required** A list of `users`, `aliases` and `rooms` namespaces that the application service controls.                                       |
-| rate_limited      | Whether requests from masqueraded users are rate-limited. The sender is excluded.                                                             |
-| protocols         | The external protocols which the application service provides (e.g. IRC).                                                                     |
-
-An example registration file for an IRC-bridging application service is
-below:
-
-    id: "IRC Bridge"
-    url: "http://127.0.0.1:1234"
-    as_token: "30c05ae90a248a4188e620216fa72e349803310ec83e2a77b34fe90be6081f46"
-    hs_token: "312df522183efd404ec1cd22d2ffa4bbc76a8c1ccf541dd692eef281356bb74e"
-    sender_localpart: "_irc_bot" # Will result in @_irc_bot:example.org
-    namespaces:
-      users:
-        - exclusive: true
-          regex: "@_irc_bridge_.*"
-      aliases:
-        - exclusive: false
-          regex: "#_irc_bridge_.*"
-      rooms: []
-
-{{% boxes/warning %}}
-If the homeserver in question has multiple application services, each
-`as_token` and `id` MUST be unique per application service as these are
-used to identify the application service. The homeserver MUST enforce
-this.
-{{% /boxes/warning %}}
-
-### Homeserver -&gt; Application Service API
-
-#### Authorization
-
-Homeservers MUST include a query parameter named `access_token`
-containing the `hs_token` from the application service's registration
-when making requests to the application service. Application services
-MUST verify the provided `access_token` matches their known `hs_token`,
-failing the request with an `M_FORBIDDEN` error if it does not match.
-
-#### Legacy routes
-
-Previous drafts of the application service specification had a mix of
-endpoints that have been used in the wild for a significant amount of
-time. The application service specification now defines a version on all
-endpoints to be more compatible with the rest of the Matrix
-specification and the future.
-
-Homeservers should attempt to use the specified endpoints first when
-communicating with application services. However, if the application
-service receives an HTTP status code that does not indicate success
-(i.e.: 404, 500, 501, etc) then the homeserver should fall back to the
-older endpoints for the application service.
-
-The older endpoints have the exact same request body and response
-format, they just belong at a different path. The equivalent path for
-each is as follows:
-
--   `/_matrix/app/v1/transactions/{txnId}` should fall back to
-    `/transactions/{txnId}`
--   `/_matrix/app/v1/users/{userId}` should fall back to
-    `/users/{userId}`
--   `/_matrix/app/v1/rooms/{roomAlias}` should fall back to
-    `/rooms/{roomAlias}`
--   `/_matrix/app/v1/thirdparty/protocol/{protocol}` should fall back to
-    `/_matrix/app/unstable/thirdparty/protocol/{protocol}`
--   `/_matrix/app/v1/thirdparty/user/{user}` should fall back to
-    `/_matrix/app/unstable/thirdparty/user/{user}`
--   `/_matrix/app/v1/thirdparty/location/{location}` should fall back to
-    `/_matrix/app/unstable/thirdparty/location/{location}`
--   `/_matrix/app/v1/thirdparty/user` should fall back to
-    `/_matrix/app/unstable/thirdparty/user`
--   `/_matrix/app/v1/thirdparty/location` should fall back to
-    `/_matrix/app/unstable/thirdparty/location`
-
-Homeservers should periodically try again for the newer endpoints
-because the application service may have been updated.
-
-#### Pushing events
-
-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:
-
-```
-    Typical
-    HS ---> AS : Homeserver sends events with transaction ID T.
-       <---    : Application Service sends back 200 OK.
-```
-
-```
-    AS ACK Lost
-    HS ---> AS : Homeserver sends events with transaction ID T.
-       <-/-    : AS 200 OK is lost.
-    HS ---> AS : Homeserver retries with the same transaction ID of T.
-       <---    : Application Service sends back 200 OK. If the AS had processed these
-                 events already, it can NO-OP this request (and it knows if it is the
-                 same events based on the transaction ID).
-```
-
-The events sent to the application service should be linearised, as if
-they were from the event stream. The homeserver MUST maintain a queue of
-transactions to send to the application service. If the application
-service cannot be reached, the homeserver SHOULD backoff exponentially
-until the application service is reachable again. As application
-services cannot *modify* the events in any way, these requests can be
-made without blocking other aspects of the homeserver. Homeservers MUST
-NOT alter (e.g. add more) events they were going to send within that
-transaction ID on retries, as the application service may have already
-processed the events.
-
-{{% http-api spec="application-service" api="transactions" %}}
-
-#### Querying
-
-The application service API includes two querying APIs: for room aliases
-and for user IDs. The application service SHOULD create the queried
-entity if it desires. During this process, the application service is
-blocking the homeserver until the entity is created and configured. If
-the homeserver does not receive a response to this request, the
-homeserver should retry several times before timing out. This should
-result in an HTTP status 408 "Request Timeout" on the client which
-initiated this request (e.g. to join a room alias).
-
-{{% boxes/rationale %}}
-Blocking the homeserver and expecting the application service to create
-the entity using the client-server API is simpler and more flexible than
-alternative methods such as returning an initial sync style JSON blob
-and get the HS to provision the room/user. This also meant that there
-didn't need to be a "backchannel" to inform the application service
-about information about the entity such as room ID to room alias
-mappings.
-{{% /boxes/rationale %}}
-
-{{% http-api spec="application-service" api="query_user" %}}
-
-{{% http-api spec="application-service" api="query_room" %}}
-
-#### Third party networks
-
-Application services may declare which protocols they support via their
-registration configuration for the homeserver. These networks are
-generally for third party services such as IRC that the application
-service is managing. Application services may populate a Matrix room
-directory for their registered protocols, as defined in the
-Client-Server API Extensions.
-
-Each protocol may have several "locations" (also known as "third party
-locations" or "3PLs"). A location within a protocol is a place in the
-third party network, such as an IRC channel. Users of the third party
-network may also be represented by the application service.
-
-Locations and users can be searched by fields defined by the application
-service, such as by display name or other attribute. When clients
-request the homeserver to search in a particular "network" (protocol),
-the search fields will be passed along to the application service for
-filtering.
-
-{{% http-api spec="application-service" api="protocols" %}}
-
-### Client-Server API Extensions
-
-Application services can use a more powerful version of the
-client-server API by identifying itself as an application service to the
-homeserver.
-
-Endpoints defined in this section MUST be supported by homeservers in
-the client-server API as accessible only by application services.
-
-#### Identity assertion
-
-The client-server API infers the user ID from the `access_token`
-provided in every request. To avoid the application service from having
-to keep track of each user's access token, the application service
-should identify itself to the Client-Server API by providing its
-`as_token` for the `access_token` alongside the user the application
-service would like to masquerade as.
-
-Inputs:
--   Application service token (`as_token`)
--   User ID in the AS namespace to act as.
-
-Notes:
--   This applies to all aspects of the Client-Server API, except for
-    Account Management.
--   The `as_token` is inserted into `access_token` which is usually
-    where the client token is, such as via the query string or
-    `Authorization` header. This is done on purpose to allow application
-    services to reuse client SDKs.
--   The `access_token` should be supplied through the `Authorization`
-    header where possible to prevent the token appearing in HTTP request
-    logs by accident.
-
-The application service may specify the virtual user to act as through
-use of a `user_id` query string parameter on the request. The user
-specified in the query string must be covered by one of the application
-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.
-
-An example request would be:
-
-    GET /_matrix/client/v3/account/whoami?user_id=@_irc_user:example.org
-    Authorization: Bearer YourApplicationServiceTokenHere
-
-#### Timestamp massaging
-
-Previous drafts of the Application Service API permitted application
-services to alter the timestamp of their sent events by providing a `ts`
-query parameter when sending an event. This API has been excluded from
-the first release due to design concerns, however some servers may still
-support the feature. Please visit [issue
-\#1585](https://github.com/matrix-org/matrix-doc/issues/1585) for more
-information.
-
-#### Server admin style permissions
-
-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
-changes need to be made in order for control of room aliases to be
-granted to the AS.
-
-Creation of users needs API changes in order to:
-
--   Work around captchas.
--   Have a 'passwordless' user.
-
-This involves bypassing the registration flows entirely. This is
-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
-    Authorization: Bearer YourApplicationServiceTokenHere
-
-    Content:
-    {
-      type: "m.login.application_service",
-      username: "_irc_example"
-    }
-
-Similarly, logging in as users 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/%CLIENT_MAJOR_VERSION%/login
-    Authorization: Bearer YourApplicationServiceTokenHere
-
-    Content:
-    {
-      type: "m.login.application_service",
-      "identifier": {
-        "type": "m.id.user",
-        "user": "_irc_example"
-      }
-    }
-
-Application services which attempt to create users or aliases *outside*
-of their defined namespaces, or log in as users outside of their defined
-namespaces will receive an error code `M_EXCLUSIVE`.
-Similarly, normal users who attempt to create users or aliases *inside*
-an application service-defined namespace will receive the same
-`M_EXCLUSIVE` error code, but only if the application service has
-defined the namespace as `exclusive`.
-
-#### Using `/sync` and `/events`
-
-Application services wishing to use `/sync` or `/events` from the
-Client-Server API MUST do so with a virtual user (provide a `user_id`
-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`.
-
-#### Application service room directories
-
-Application services can maintain their own room directories for their
-defined third party protocols. These room directories may be accessed by
-clients through additional parameters on the `/publicRooms`
-client-server endpoint.
-
-{{% http-api spec="client-server" api="appservice_room_directory" %}}
-
-### Referencing messages from a third party network
-
-Application services should include an `external_url` in the `content`
-of events it emits to indicate where the message came from. This
-typically applies to application services that bridge other networks
-into Matrix, such as IRC, where an HTTP URL may be available to
-reference.
-
-Clients should provide users with a way to access the `external_url` if
-it is present. Clients should additionally ensure the URL has a scheme
-of `https` or `http` before making use of it.
-
-The presence of an `external_url` on an event does not necessarily mean
-the event was sent from an application service. Clients should be wary
-of the URL contained within, as it may not be a legitimate reference to
-the event's source.
diff --git a/content/changelog.md b/content/changelog.md
deleted file mode 100644
index 104e19dd..00000000
--- a/content/changelog.md
+++ /dev/null
@@ -1,51 +0,0 @@
----
-title: Changelog
-type: docs
-weight: 1000
----
-
-{{% changelog/changelog-description %}}
-
-{{% changelog/changelog-changes %}}
-
-<!-- DO NOT REMOVE OR CHANGE - Release script puts next release here -->
-{{% changelog/changelog-rendered p="changelogs/v1.2.md" %}}
-{{% changelog/changelog-rendered p="changelogs/v1.1.md" %}}
-
-<h2 id="historical-versions" class="no-numbers">Historical versions</h2>
-
-Before version 1.1, versioning was applied at the level of individual API specifications. This section includes links to these versions of the APIs.
-
-* **Client-Server API**
-  -   [r0.6.1](https://matrix.org/docs/spec/client_server/r0.6.1.html)
-  -   [r0.6.0](https://matrix.org/docs/spec/client_server/r0.6.0.html)
-  -   [r0.5.0](https://matrix.org/docs/spec/client_server/r0.5.0.html)
-  -   [r0.4.0](https://matrix.org/docs/spec/client_server/r0.4.0.html)
-  -   [r0.3.0](https://matrix.org/docs/spec/client_server/r0.3.0.html)
-  -   [r0.2.0](https://matrix.org/docs/spec/client_server/r0.2.0.html)
-  -   [r0.1.0](https://matrix.org/docs/spec/client_server/r0.1.0.html)
-  -   [r0.0.1](https://matrix.org/docs/spec/r0.0.1/client_server.html)
-  -   [r0.0.0](https://matrix.org/docs/spec/r0.0.0/client_server.html)
-  -   [Legacy](https://matrix.org/docs/spec/legacy/#client-server-api):
-      The last draft before the spec was formally released in version
-      r0.0.0.
-
-* **Server-Server API**
-  -   [r0.1.4](https://matrix.org/docs/spec/server_server/r0.1.4.html)
-  -   [r0.1.3](https://matrix.org/docs/spec/server_server/r0.1.3.html)
-  -   [r0.1.2](https://matrix.org/docs/spec/server_server/r0.1.2.html)
-  -   [r0.1.1](https://matrix.org/docs/spec/server_server/r0.1.1.html)
-  -   [r0.1.0](https://matrix.org/docs/spec/server_server/r0.1.0.html)
-
-* **Application Service API**
-  -   [r0.1.1](https://matrix.org/docs/spec/application_service/r0.1.1.html)
-  -   [r0.1.0](https://matrix.org/docs/spec/application_service/r0.1.0.html)
-
-* **Identity Service API**
-  -   [r0.3.0](https://matrix.org/docs/spec/identity_service/r0.3.0.html)
-  -   [r0.2.1](https://matrix.org/docs/spec/identity_service/r0.2.1.html)
-  -   [r0.2.0](https://matrix.org/docs/spec/identity_service/r0.2.0.html)
-  -   [r0.1.0](https://matrix.org/docs/spec/identity_service/r0.1.0.html)
-
-* **Push Gateway API**
-  -   [r0.1.0](https://matrix.org/docs/spec/push_gateway/r0.1.0.html)
diff --git a/content/client-server-api/_index.md b/content/client-server-api/_index.md
deleted file mode 100644
index 679358a0..00000000
--- a/content/client-server-api/_index.md
+++ /dev/null
@@ -1,2326 +0,0 @@
----
-title: "Client-Server API"
-weight: 10
-type: docs
----
-
-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
-
-The mandatory baseline for client-server communication in Matrix is
-exchanging JSON objects over HTTP APIs. HTTPS is recommended for
-communication, although HTTP may be supported as a fallback to support
-basic HTTP clients. More efficient optional transports will in future be
-supported as optional extensions - e.g. a packed binary encoding over
-stream-cipher encrypted TCP socket for low-bandwidth/low-roundtrip
-mobile usage. For the default HTTP transport, all API calls use a
-Content-Type of `application/json`. In addition, all strings MUST be
-encoded as UTF-8.
-
-Clients are authenticated using opaque `access_token` strings (see [Client
-Authentication](#client-authentication) for details).
-
-See also [Conventions for Matrix APIs](/appendices#conventions-for-matrix-apis)
-in the Appendices for conventions which all Matrix APIs are expected to follow.
-
-### Standard error response
-
-Any errors which occur at the Matrix API level MUST return a "standard
-error response". This is a JSON object which looks like:
-
-```json
-{
-  "errcode": "<error code>",
-  "error": "<error message>"
-}
-```
-
-The `error` string will be a human-readable error message, usually a
-sentence explaining what went wrong.
-
-The `errcode` string will be a unique string which can be used to handle an
-error message e.g.  `M_FORBIDDEN`. Error codes should have their namespace
-first in ALL CAPS, followed by a single `_`. For example, if there was a custom
-namespace `com.mydomain.here`, and a `FORBIDDEN` code, the error code should
-look like `COM.MYDOMAIN.HERE_FORBIDDEN`. Error codes defined by this
-specification should start `M_`.
-
-Some `errcode`s define additional keys which should be present in the error
-response object, but the keys `error` and `errcode` MUST always be present.
-
-Errors are generally best expressed by their error code rather than the
-HTTP status code returned. When encountering the error code `M_UNKNOWN`,
-clients should prefer the HTTP status code as a more reliable reference
-for what the issue was. For example, if the client receives an error
-code of `M_NOT_FOUND` but the request gave a 400 Bad Request status
-code, the client should treat the error as if the resource was not
-found. However, if the client were to receive an error code of
-`M_UNKNOWN` with a 400 Bad Request, the client should assume that the
-request being made was invalid.
-
-#### Common error codes
-
-These error codes can be returned by any API endpoint:
-
-`M_FORBIDDEN`
-Forbidden access, e.g. joining a room without permission, failed login.
-
-`M_UNKNOWN_TOKEN`
-The access token specified was not recognised.
-
-An additional response parameter, `soft_logout`, might be present on the
-response for 401 HTTP status codes. See [the soft logout
-section](#soft-logout) for more information.
-
-`M_MISSING_TOKEN`
-No access token was specified for the request.
-
-`M_BAD_JSON`
-Request contained valid JSON, but it was malformed in some way, e.g.
-missing required keys, invalid values for keys.
-
-`M_NOT_JSON`
-Request did not contain valid JSON.
-
-`M_NOT_FOUND`
-No resource was found for this request.
-
-`M_LIMIT_EXCEEDED`
-Too many requests have been sent in a short period of time. Wait a while
-then try again.
-
-`M_UNKNOWN`
-An unknown error has occurred.
-
-#### Other error codes
-
-The following error codes are specific to certain endpoints.
-
-<!-- TODO: move them to the endpoints that return them -->.
-
-`M_UNRECOGNIZED`
-The server did not understand the request.
-
-`M_UNAUTHORIZED`
-The request was not correctly authorized. Usually due to login failures.
-
-`M_USER_DEACTIVATED`
-The user ID associated with the request has been deactivated. Typically
-for endpoints that prove authentication, such as `/login`.
-
-`M_USER_IN_USE`
-Encountered when trying to register a user ID which has been taken.
-
-`M_INVALID_USERNAME`
-Encountered when trying to register a user ID which is not valid.
-
-`M_ROOM_IN_USE`
-Sent when the room alias given to the `createRoom` API is already in
-use.
-
-`M_INVALID_ROOM_STATE`
-Sent when the initial state given to the `createRoom` API is invalid.
-
-`M_THREEPID_IN_USE`
-Sent when a threepid given to an API cannot be used because the same
-threepid is already in use.
-
-`M_THREEPID_NOT_FOUND`
-Sent when a threepid given to an API cannot be used because no record
-matching the threepid was found.
-
-`M_THREEPID_AUTH_FAILED`
-Authentication could not be performed on the third party identifier.
-
-`M_THREEPID_DENIED`
-The server does not permit this third party identifier. This may happen
-if the server only permits, for example, email addresses from a
-particular domain.
-
-`M_SERVER_NOT_TRUSTED`
-The client's request used a third party server, e.g. identity server,
-that this server does not trust.
-
-`M_UNSUPPORTED_ROOM_VERSION`
-The client's request to create a room used a room version that the
-server does not support.
-
-`M_INCOMPATIBLE_ROOM_VERSION`
-The client attempted to join a room that has a version the server does
-not support. Inspect the `room_version` property of the error response
-for the room's version.
-
-`M_BAD_STATE`
-The state change requested cannot be performed, such as attempting to
-unban a user who is not banned.
-
-`M_GUEST_ACCESS_FORBIDDEN`
-The room or resource does not permit guests to access it.
-
-`M_CAPTCHA_NEEDED`
-A Captcha is required to complete the request.
-
-`M_CAPTCHA_INVALID`
-The Captcha provided did not match what was expected.
-
-`M_MISSING_PARAM`
-A required parameter was missing from the request.
-
-`M_INVALID_PARAM`
-A parameter that was specified has the wrong value. For example, the
-server expected an integer and instead received a string.
-
-`M_TOO_LARGE`
-The request or entity was too large.
-
-`M_EXCLUSIVE`
-The resource being requested is reserved by an application service, or
-the application service making the request has not created the resource.
-
-`M_RESOURCE_LIMIT_EXCEEDED`
-The request cannot be completed because the homeserver has reached a
-resource limit imposed on it. For example, a homeserver held in a shared
-hosting environment may reach a resource limit if it starts using too
-much memory or disk space. The error MUST have an `admin_contact` field
-to provide the user receiving the error a place to reach out to.
-Typically, this error will appear on routes which attempt to modify
-state (e.g.: sending messages, account data, etc) and not routes which
-only read state (e.g.: `/sync`, get account data, etc).
-
-`M_CANNOT_LEAVE_SERVER_NOTICE_ROOM`
-The user is unable to reject an invite to join the server notices room.
-See the [Server Notices](#server-notices) module for more information.
-
-The client-server API typically uses `HTTP PUT` to submit requests with
-a client-generated transaction identifier. This means that these
-requests are idempotent. The scope of a transaction identifier is a
-particular access token. It **only** serves to identify new requests
-from retransmits. After the request has finished, the `{txnId}` value
-should be changed (how is not specified; a monotonically increasing
-integer is recommended).
-
-Some API endpoints may allow or require the use of `POST` requests
-without a transaction ID. Where this is optional, the use of a `PUT`
-request is strongly recommended.
-
-{{% http-api spec="client-server" api="versions" %}}
-
-## Web Browser Clients
-
-It is realistic to expect that some clients will be written to be run
-within a web browser or similar environment. In these cases, the
-homeserver should respond to pre-flight requests and supply Cross-Origin
-Resource Sharing (CORS) headers on all requests.
-
-Servers MUST expect that clients will approach them with `OPTIONS`
-requests, allowing clients to discover the CORS headers. All endpoints
-in this specification support the `OPTIONS` method, however the server
-MUST NOT perform any logic defined for the endpoints when approached
-with an `OPTIONS` request.
-
-When a client approaches the server with a request, the server should
-respond with the CORS headers for that route. The recommended CORS
-headers to be returned by servers on all requests are:
-
-    Access-Control-Allow-Origin: *
-    Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
-    Access-Control-Allow-Headers: X-Requested-With, Content-Type, Authorization
-
-## Server Discovery
-
-In order to allow users to connect to a Matrix server without needing to
-explicitly specify the homeserver's URL or other parameters, clients
-SHOULD use an auto-discovery mechanism to determine the server's URL
-based on a user's Matrix ID. Auto-discovery should only be done at login
-time.
-
-In this section, the following terms are used with specific meanings:
-
-`PROMPT`
-Retrieve the specific piece of information from the user in a way which
-fits within the existing client user experience, if the client is
-inclined to do so. Failure can take place instead if no good user
-experience for this is possible at this point.
-
-`IGNORE`
-Stop the current auto-discovery mechanism. If no more auto-discovery
-mechanisms are available, then the client may use other methods of
-determining the required parameters, such as prompting the user, or
-using default values.
-
-`FAIL_PROMPT`
-Inform the user that auto-discovery failed due to invalid/empty data and
-`PROMPT` for the parameter.
-
-`FAIL_ERROR`
-Inform the user that auto-discovery did not return any usable URLs. Do
-not continue further with the current login process. At this point,
-valid data was obtained, but no server is available to serve the client.
-No further guess should be attempted and the user should make a
-conscientious decision what to do next.
-
-### Well-known URI
-
-{{% boxes/note %}}
-Servers hosting the `.well-known` JSON file SHOULD offer CORS headers,
-as per the [CORS](#web-browser-clients) section in this specification.
-{{% /boxes/note %}}
-
-The `.well-known` method uses a JSON file at a predetermined location to
-specify parameter values. The flow for this method is as follows:
-
-1.  Extract the server name from the user's Matrix ID by splitting the
-    Matrix ID at the first colon.
-2.  Extract the hostname from the server name.
-3.  Make a GET request to `https://hostname/.well-known/matrix/client`.
-    1.  If the returned status code is 404, then `IGNORE`.
-    2.  If the returned status code is not 200, or the response body is
-        empty, then `FAIL_PROMPT`.
-    3.  Parse the response body as a JSON object
-        1.  If the content cannot be parsed, then `FAIL_PROMPT`.
-    4.  Extract the `base_url` value from the `m.homeserver` property.
-        This value is to be used as the base URL of the homeserver.
-        1. If this value is not provided, then `FAIL_PROMPT`.
-    5.  Validate the homeserver base URL:
-        1. Parse it as a URL. If it is not a URL, then `FAIL_ERROR`.
-        2. Clients SHOULD validate that the URL points to a valid
-            homeserver before accepting it by connecting to the
-            [`/_matrix/client/versions`](/client-server-api/#get_matrixclientversions) endpoint, ensuring that it does
-            not return an error, and parsing and validating that the
-            data conforms with the expected response format. If any step
-            in the validation fails, then `FAIL_ERROR`. Validation is
-            done as a simple check against configuration errors, in
-            order to ensure that the discovered address points to a
-            valid homeserver.
-        3. It is important to note that the `base_url` value might include
-           a trailing `/`. Consumers should be prepared to handle both cases.
-    6.  If the `m.identity_server` property is present, extract the
-        `base_url` value for use as the base URL of the identity server.
-        Validation for this URL is done as in the step above, but using
-        `/_matrix/identity/v2` as the endpoint to connect to. If the
-        `m.identity_server` property is present, but does not have a
-        `base_url` value, then `FAIL_PROMPT`.
-
-{{% http-api spec="client-server" api="wellknown" %}}
-
-## Client Authentication
-
-Most API endpoints require the user to identify themselves by presenting
-previously obtained credentials in the form of an `access_token` query
-parameter or through an Authorization Header of `Bearer $access_token`.
-An access token is typically obtained via the [Login](#login) or
-[Registration](#account-registration-and-management) processes.
-
-{{% boxes/note %}}
-This specification does not mandate a particular format for the access
-token. Clients should treat it as an opaque byte sequence. Servers are
-free to choose an appropriate format. Server implementors may like to
-investigate [macaroons](http://research.google.com/pubs/pub41892.html).
-{{% /boxes/note %}}
-
-### Using access tokens
-
-Access tokens may be provided in two ways, both of which the homeserver
-MUST support:
-
-1.  Via a query string parameter, `access_token=TheTokenHere`.
-2.  Via a request header, `Authorization: Bearer TheTokenHere`.
-
-Clients are encouraged to use the `Authorization` header where possible
-to prevent the access token being leaked in access/HTTP logs. The query
-string should only be used in cases where the `Authorization` header is
-inaccessible for the client.
-
-When credentials are required but missing or invalid, the HTTP call will
-return with a status of 401 and the error code, `M_MISSING_TOKEN` or
-`M_UNKNOWN_TOKEN` respectively.
-
-### Relationship between access tokens and devices
-
-Client [devices](../index.html#devices) are closely related to access
-tokens. Matrix servers should record which device each access token is
-assigned to, so that subsequent requests can be handled correctly.
-
-By default, the [Login](#login) and [Registration](#account-registration-and-management)
-processes auto-generate a new `device_id`. A client is also free to
-generate its own `device_id` or, provided the user remains the same,
-reuse a device: in either case the client should pass the `device_id` in
-the request body. If the client sets the `device_id`, the server will
-invalidate any access token previously assigned to that device. There is
-therefore at most one active access token assigned to each device at any
-one time.
-
-### Soft logout
-
-When a request fails due to a 401 status code per above, the server can
-include an extra response parameter, `soft_logout`, to indicate if the
-client's persisted information can be retained. This defaults to
-`false`, indicating that the server has destroyed the session. Any
-persisted state held by the client, such as encryption keys and device
-information, must not be reused and must be discarded.
-
-When `soft_logout` is true, the client can acquire a new access token by
-specifying the device ID it is already using to the login API. In most
-cases a `soft_logout: true` response indicates that the user's session
-has expired on the server-side and the user simply needs to provide
-their credentials again.
-
-In either case, the client's previously known access token will no
-longer function.
-
-### User-Interactive Authentication API
-
-#### Overview
-
-Some API endpoints require authentication that interacts with the user.
-The homeserver may provide many different ways of authenticating, such
-as user/password auth, login via a single-sign-on server (SSO), etc.
-This specification does not define how homeservers should authorise
-their users but instead defines the standard interface which
-implementations should follow so that ANY client can log in to ANY
-homeserver.
-
-The process takes the form of one or more 'stages'. At each stage the
-client submits a set of data for a given authentication type and awaits
-a response from the server, which will either be a final success or a
-request to perform an additional stage. This exchange continues until
-the final success.
-
-For each endpoint, a server offers one or more 'flows' that the client
-can use to authenticate itself. Each flow comprises a series of stages,
-as described above. The client is free to choose which flow it follows,
-however the flow's stages must be completed in order. Failing to follow
-the flows in order must result in an HTTP 401 response, as defined
-below. When all stages in a flow are complete, authentication is
-complete and the API call succeeds.
-
-#### User-interactive API in the REST API
-
-In the REST API described in this specification, authentication works by
-the client and server exchanging JSON dictionaries. The server indicates
-what authentication data it requires via the body of an HTTP 401
-response, and the client submits that authentication data via the `auth`
-request parameter.
-
-A client should first make a request with no `auth` parameter.
-The homeserver returns an HTTP 401 response, with a JSON body, as follows:
-
-    HTTP/1.1 401 Unauthorized
-    Content-Type: application/json
-
-```json
-{
-  "flows": [
-    {
-      "stages": [ "example.type.foo", "example.type.bar" ]
-    },
-    {
-      "stages": [ "example.type.foo", "example.type.baz" ]
-    }
-  ],
-  "params": {
-      "example.type.baz": {
-          "example_key": "foobar"
-      }
-  },
-  "session": "xxxxxx"
-}
-```
-
-In addition to the `flows`, this object contains some extra information:
-
-* `params`: This section contains any information that the client will
-need to know in order to use a given type of authentication. For each
-authentication type presented, that type may be present as a key in this
-dictionary. For example, the public part of an OAuth client ID could be
-given here.
-
-* `session`: This is a session identifier that the client must pass back
-to the homeserver, if one is provided, in subsequent attempts to authenticate
-in the same API call.
-
-The client then chooses a flow and attempts to complete the first stage.
-It does this by resubmitting the same request with the addition of an
-`auth` key in the object that it submits. This dictionary contains a
-`type` key whose value is the name of the authentication type that the
-client is attempting to complete. It must also contain a `session` key
-with the value of the session key given by the homeserver, if one was
-given. It also contains other keys dependent on the auth type being
-attempted. For example, if the client is attempting to complete auth
-type `example.type.foo`, it might submit something like this:
-
-    POST /_matrix/client/v3/endpoint HTTP/1.1
-    Content-Type: application/json
-
-```json
-{
-  "a_request_parameter": "something",
-  "another_request_parameter": "something else",
-  "auth": {
-      "type": "example.type.foo",
-      "session": "xxxxxx",
-      "example_credential": "verypoorsharedsecret"
-  }
-}
-```
-
-If the homeserver deems the authentication attempt to be successful but
-still requires more stages to be completed, it returns HTTP status 401
-along with the same object as when no authentication was attempted, with
-the addition of the `completed` key which is an array of auth types the
-client has completed successfully:
-
-    HTTP/1.1 401 Unauthorized
-    Content-Type: application/json
-
-```json
-{
-  "completed": [ "example.type.foo" ],
-  "flows": [
-    {
-      "stages": [ "example.type.foo", "example.type.bar" ]
-    },
-    {
-      "stages": [ "example.type.foo", "example.type.baz" ]
-    }
-  ],
-  "params": {
-      "example.type.baz": {
-          "example_key": "foobar"
-      }
-  },
-  "session": "xxxxxx"
-}
-```
-
-Individual stages may require more than one request to complete, in
-which case the response will be as if the request was unauthenticated
-with the addition of any other keys as defined by the auth type.
-
-If the homeserver decides that an attempt on a stage was unsuccessful,
-but the client may make a second attempt, it returns the same HTTP
-status 401 response as above, with the addition of the standard
-`errcode` and `error` fields describing the error. For example:
-
-    HTTP/1.1 401 Unauthorized
-    Content-Type: application/json
-
-```json
-{
-  "errcode": "M_FORBIDDEN",
-  "error": "Invalid password",
-  "completed": [ "example.type.foo" ],
-  "flows": [
-    {
-      "stages": [ "example.type.foo", "example.type.bar" ]
-    },
-    {
-      "stages": [ "example.type.foo", "example.type.baz" ]
-    }
-  ],
-  "params": {
-      "example.type.baz": {
-          "example_key": "foobar"
-      }
-  },
-  "session": "xxxxxx"
-}
-```
-
-If the request fails for a reason other than authentication, the server
-returns an error message in the standard format. For example:
-
-    HTTP/1.1 400 Bad request
-    Content-Type: application/json
-
-```json
-{
-  "errcode": "M_EXAMPLE_ERROR",
-  "error": "Something was wrong"
-}
-```
-
-If the client has completed all stages of a flow, the homeserver
-performs the API call and returns the result as normal. Completed stages
-cannot be retried by clients, therefore servers must return either a 401
-response with the completed stages, or the result of the API call if all
-stages were completed when a client retries a stage.
-
-Some authentication types may be completed by means other than through
-the Matrix client, for example, an email confirmation may be completed
-when the user clicks on the link in the email. In this case, the client
-retries the request with an auth dict containing only the session key.
-The response to this will be the same as if the client were attempting
-to complete an auth state normally, i.e. the request will either
-complete or request auth, with the presence or absence of that auth type
-in the 'completed' array indicating whether that stage is complete.
-
-{{% boxes/note %}}
-A request to an endpoint that uses User-Interactive Authentication never
-succeeds without auth. Homeservers may allow requests that don't require
-auth by offering a stage with only the `m.login.dummy` auth type, but they
-must still give a 401 response to requests with no auth data.
-{{% /boxes/note %}}
-
-#### Example
-
-At a high level, the requests made for an API call completing an auth
-flow with three stages will resemble the following diagram:
-
-```
-    _______________________
-    |       Stage 0         |
-    | No auth               |
-    |  ___________________  |
-    | |_Request_1_________| | <-- Returns "session" key which is used throughout.
-    |_______________________|
-             |
-             |
-    _________V_____________
-    |       Stage 1         |
-    | type: "<auth type1>"  |
-    |  ___________________  |
-    | |_Request_1_________| |
-    |_______________________|
-             |
-             |
-    _________V_____________
-    |       Stage 2         |
-    | type: "<auth type2>"  |
-    |  ___________________  |
-    | |_Request_1_________| |
-    |  ___________________  |
-    | |_Request_2_________| |
-    |  ___________________  |
-    | |_Request_3_________| |
-    |_______________________|
-             |
-             |
-    _________V_____________
-    |       Stage 3         |
-    | type: "<auth type3>"  |
-    |  ___________________  |
-    | |_Request_1_________| | <-- Returns API response
-    |_______________________|
-```
-
-#### Authentication types
-
-This specification defines the following auth types:
--   `m.login.password`
--   `m.login.recaptcha`
--   `m.login.sso`
--   `m.login.email.identity`
--   `m.login.msisdn`
--   `m.login.dummy`
--   `m.login.registration_token`
-
-##### Password-based
-
-
-| Type               | Description                                                                    |
-|--------------------|--------------------------------------------------------------------------------|
-| `m.login.password` | The client submits an identifier and secret password, both sent in plain-text. |
-
-To use this authentication type, clients should submit an auth dict as
-follows:
-
-```
-{
-  "type": "m.login.password",
-  "identifier": {
-    ...
-  },
-  "password": "<password>",
-  "session": "<session ID>"
-}
-```
-
-where the `identifier` property is a user identifier object, as
-described in [Identifier types](#identifier-types).
-
-For example, to authenticate using the user's Matrix ID, clients would
-submit:
-
-```json
-{
-  "type": "m.login.password",
-  "identifier": {
-    "type": "m.id.user",
-    "user": "<user_id or user localpart>"
-  },
-  "password": "<password>",
-  "session": "<session ID>"
-}
-```
-
-Alternatively reply using a 3PID bound to the user's account on the
-homeserver using the `/account/3pid`\_ API rather than giving the `user`
-explicitly as follows:
-
-```json
-{
-  "type": "m.login.password",
-  "identifier": {
-    "type": "m.id.thirdparty",
-    "medium": "<The medium of the third party identifier.>",
-    "address": "<The third party address of the user>"
-  },
-  "password": "<password>",
-  "session": "<session ID>"
-}
-```
-
-In the case that the homeserver does not know about the supplied 3PID,
-the homeserver must respond with 403 Forbidden.
-
-##### Google ReCaptcha
-
-| Type                | Description                                          |
-|---------------------|------------------------------------------------------|
-| `m.login.recaptcha` | The user completes a Google ReCaptcha 2.0 challenge. |
-
-To use this authentication type, clients should submit an auth dict as
-follows:
-
-```json
-{
-  "type": "m.login.recaptcha",
-  "response": "<captcha response>",
-  "session": "<session ID>"
-}
-```
-
-##### Single Sign-On
-
-| Type          | Description                                                                          |
-|---------------|--------------------------------------------------------------------------------------|
-| `m.login.sso` | Authentication is supported by authorising with an external single sign-on provider. |
-
-A client wanting to complete authentication using SSO should use the
-[Fallback](#fallback) mechanism. See [SSO during User-Interactive
-Authentication](#sso-during-user-interactive-authentication) for more information.
-
-##### Email-based (identity / homeserver)
-
-| Type                     | Description                                                                                                      |
-|--------------------------|------------------------------------------------------------------------------------------------------------------|
-| `m.login.email.identity` | Authentication is supported by authorising an email address with an identity server, or homeserver if supported. |
-
-Prior to submitting this, the client should authenticate with an
-identity server (or homeserver). After authenticating, the session
-information should be submitted to the homeserver.
-
-To use this authentication type, clients should submit an auth dict as
-follows:
-
-```json
-{
-  "type": "m.login.email.identity",
-  "threepid_creds": {
-    "sid": "<identity server session id>",
-    "client_secret": "<identity server client secret>",
-    "id_server": "<url of identity server authed with, e.g. 'matrix.org:8090'>",
-    "id_access_token": "<access token previously registered with the identity server>"
-  },
-  "session": "<session ID>"
-}
-```
-
-Note that `id_server` (and therefore `id_access_token`) is optional if
-the `/requestToken` request did not include them.
-
-##### Phone number/MSISDN-based (identity / homeserver)
-
-| Type             | Description                                                                                                    |
-|------------------|----------------------------------------------------------------------------------------------------------------|
-| `m.login.msisdn` | Authentication is supported by authorising a phone number with an identity server, or homeserver if supported. |
-
-Prior to submitting this, the client should authenticate with an
-identity server (or homeserver). After authenticating, the session
-information should be submitted to the homeserver.
-
-To use this authentication type, clients should submit an auth dict as
-follows:
-
-```json
-{
-  "type": "m.login.msisdn",
-  "threepid_creds": {
-    "sid": "<identity server session id>",
-    "client_secret": "<identity server client secret>",
-    "id_server": "<url of identity server authed with, e.g. 'matrix.org:8090'>",
-    "id_access_token": "<access token previously registered with the identity server>"
-  },
-  "session": "<session ID>"
-}
-```
-
-Note that `id_server` (and therefore `id_access_token`) is optional if
-the `/requestToken` request did not include them.
-
-##### Dummy Auth
-
-| Type             | Description                                                            |
-|------------------|------------------------------------------------------------------------|
-| `m.login.dummy`  | Dummy authentication always succeeds and requires no extra parameters. |
-
-The purpose of dummy authentication is to allow servers to not require any form of
-User-Interactive Authentication to perform a request. It can also be
-used to differentiate flows where otherwise one flow would be a subset
-of another flow. e.g. if a server offers flows `m.login.recaptcha` and
-`m.login.recaptcha, m.login.email.identity` and the client completes the
-recaptcha stage first, the auth would succeed with the former flow, even
-if the client was intending to then complete the email auth stage. A
-server can instead send flows `m.login.recaptcha, m.login.dummy` and
-`m.login.recaptcha, m.login.email.identity` to fix the ambiguity.
-
-To use this authentication type, clients should submit an auth dict with
-just the type and session, if provided:
-
-```json
-{
-  "type": "m.login.dummy",
-  "session": "<session ID>"
-}
-```
-
-##### Token-authenticated registration
-
-{{% added-in v="1.2" %}}
-
-| Type                          | Description                                                       |
-|-------------------------------|-------------------------------------------------------------------|
-| `m.login.registration_token`  | Registers an account with a pre-shared token for authentication   |
-
-{{% boxes/note %}}
-The `m.login.registration_token` authentication type is only valid on the
-[`/register`](#post_matrixclientv3register) endpoint.
-{{% /boxes/note %}}
-
-This authentication type provides homeservers the ability to allow registrations
-to a limited set of people instead of either offering completely open registrations
-or completely closed registration (where the homeserver administrators create
-and distribute accounts).
-
-The token required for this authentication type is shared out of band from
-Matrix and is an opaque string with maximum length of 64 characters in the
-range `[A-Za-z0-9._~-]`. The server can keep any number of tokens for any
-length of time/validity. Such cases might be a token limited to 100 uses or
-for the next 2 hours - after the tokens expire, they can no longer be used
-to create accounts.
-
-To use this authentication type, clients should submit an auth dict with just
-the type, token, and session:
-
-```json
-{
-  "type": "m.login.registration_token",
-  "token": "fBVFdqVE",
-  "session": "<session ID>"
-}
-```
-
-To determine if a token is valid before attempting to use it, the client can
-use the `/validity` API defined below. The API doesn't guarantee that a token
-will be valid when used, but does avoid cases where the user finds out late
-in the registration process that their token has expired.
-
-{{% http-api spec="client-server" api="registration_tokens" %}}
-
-#### Fallback
-
-Clients cannot be expected to be able to know how to process every
-single login type. If a client does not know how to handle a given login
-type, it can direct the user to a web browser with the URL of a fallback
-page which will allow the user to complete that login step out-of-band
-in their web browser. The URL it should open is:
-
-    /_matrix/client/v3/auth/<auth type>/fallback/web?session=<session ID>
-
-Where `auth type` is the type name of the stage it is attempting and
-`session ID` is the ID of the session given by the homeserver.
-
-This MUST return an HTML page which can perform this authentication
-stage. This page must use the following JavaScript when the
-authentication has been completed:
-
-```js
-if (window.onAuthDone) {
-    window.onAuthDone();
-} else if (window.opener && window.opener.postMessage) {
-    window.opener.postMessage("authDone", "*");
-}
-```
-
-This allows the client to either arrange for the global function
-`onAuthDone` to be defined in an embedded browser, or to use the HTML5
-[cross-document
-messaging](https://www.w3.org/TR/webmessaging/#web-messaging) API, to
-receive a notification that the authentication stage has been completed.
-
-Once a client receives the notification that the authentication stage
-has been completed, it should resubmit the request with an auth dict
-with just the session ID:
-
-```json
-{
-  "session": "<session ID>"
-}
-```
-
-##### Example
-
-A client webapp might use the following JavaScript to open a popup
-window which will handle unknown login types:
-
-```js
-/**
- * Arguments:
- *     homeserverUrl: the base url of the homeserver (e.g. "https://matrix.org")
- *
- *     apiEndpoint: the API endpoint being used (e.g.
- *        "/_matrix/client/v3/account/password")
- *
- *     loginType: the loginType being attempted (e.g. "m.login.recaptcha")
- *
- *     sessionID: the session ID given by the homeserver in earlier requests
- *
- *     onComplete: a callback which will be called with the results of the request
- */
-function unknownLoginType(homeserverUrl, apiEndpoint, loginType, sessionID, onComplete) {
-    var popupWindow;
-
-    var eventListener = function(ev) {
-        // check it's the right message from the right place.
-        if (ev.data !== "authDone" || ev.origin !== homeserverUrl) {
-            return;
-        }
-
-        // close the popup
-        popupWindow.close();
-        window.removeEventListener("message", eventListener);
-
-        // repeat the request
-        var requestBody = {
-            auth: {
-                session: sessionID,
-            },
-        };
-
-        request({
-            method:'POST', url:apiEndpoint, json:requestBody,
-        }, onComplete);
-    };
-
-    window.addEventListener("message", eventListener);
-
-    var url = homeserverUrl +
-        "/_matrix/client/v3/auth/" +
-        encodeURIComponent(loginType) +
-        "/fallback/web?session=" +
-        encodeURIComponent(sessionID);
-
-   popupWindow = window.open(url);
-}
-```
-
-#### Identifier types
-
-Some authentication mechanisms use a user identifier object to identify
-a user. The user identifier object has a `type` field to indicate the
-type of identifier being used, and depending on the type, has other
-fields giving the information required to identify the user as described
-below.
-
-This specification defines the following identifier types:
--   `m.id.user`
--   `m.id.thirdparty`
--   `m.id.phone`
-
-##### Matrix User ID
-
-| Type        | Description                                |
-|-------------|--------------------------------------------|
-| `m.id.user` | The user is identified by their Matrix ID. |
-
-A client can identify a user using their Matrix ID. This can either be
-the fully qualified Matrix user ID, or just the localpart of the user
-ID.
-
-```json
-"identifier": {
-  "type": "m.id.user",
-  "user": "<user_id or user localpart>"
-}
-```
-
-##### Third-party ID
-
-| Type              | Description                                                               |
-|-------------------|---------------------------------------------------------------------------|
-| `m.id.thirdparty` | The user is identified by a third-party identifier in canonicalised form. |
-
-A client can identify a user using a 3PID associated with the user's
-account on the homeserver, where the 3PID was previously associated
-using the `/account/3pid`\_ API. See the [3PID
-Types](/appendices#3pid-types) Appendix for a list of Third-party
-ID media.
-
-```json
-"identifier": {
-  "type": "m.id.thirdparty",
-  "medium": "<The medium of the third party identifier>",
-  "address": "<The canonicalised third party address of the user>"
-}
-```
-
-##### Phone number
-
-| Type         | Description                               |
-|--------------|-------------------------------------------|
-| `m.id.phone` | The user is identified by a phone number. |
-
-A client can identify a user using a phone number associated with the
-user's account, where the phone number was previously associated using
-the `/account/3pid`\_ API. The phone number can be passed in as entered
-by the user; the homeserver will be responsible for canonicalising it.
-If the client wishes to canonicalise the phone number, then it can use
-the `m.id.thirdparty` identifier type with a `medium` of `msisdn`
-instead.
-
-```json
-"identifier": {
-  "type": "m.id.phone",
-  "country": "<The country that the phone number is from>",
-  "phone": "<The phone number>"
-}
-```
-
-The `country` is the two-letter uppercase ISO-3166-1 alpha-2 country
-code that the number in `phone` should be parsed as if it were dialled
-from.
-
-### Login
-
-A client can obtain access tokens using the `/login` API.
-
-Note that this endpoint does <span class="title-ref">not</span>
-currently use the [User-Interactive Authentication
-API](#user-interactive-authentication-api).
-
-For a simple username/password login, clients should submit a `/login`
-request as follows:
-
-```json
-{
-  "type": "m.login.password",
-  "identifier": {
-    "type": "m.id.user",
-    "user": "<user_id or user localpart>"
-  },
-  "password": "<password>"
-}
-```
-
-Alternatively, a client can use a 3PID bound to the user's account on
-the homeserver using the `/account/3pid`\_ API rather than giving the
-`user` explicitly, as follows:
-
-```json
-{
-  "type": "m.login.password",
-  "identifier": {
-    "medium": "<The medium of the third party identifier>",
-    "address": "<The canonicalised third party address of the user>"
-  },
-  "password": "<password>"
-}
-```
-
-In the case that the homeserver does not know about the supplied 3PID,
-the homeserver must respond with `403 Forbidden`.
-
-To log in using a login token, clients should submit a `/login` request
-as follows:
-
-```json
-{
-  "type": "m.login.token",
-  "token": "<login token>"
-}
-```
-
-As with [token-based]() interactive login, the `token` must encode the
-user ID. In the case that the token is not valid, the homeserver must
-respond with `403 Forbidden` and an error code of `M_FORBIDDEN`.
-
-If the homeserver advertises `m.login.sso` as a viable flow, and the
-client supports it, the client should redirect the user to the
-`/redirect` endpoint for [client login via SSO](#client-login-via-sso). After authentication
-is complete, the client will need to submit a `/login` request matching
-`m.login.token`.
-
-#### Appservice Login
-
-{{% added-in v="1.2" %}}
-
-An appservice can log in by providing a valid appservice token and a user within the appservice's
-namespace.
-
-{{% boxes/note %}}
-Appservices do not need to log in as individual users in all cases, as they
-can perform [Identity Assertion](/application-service-api#identity-assertion)
-using the appservice token. However, if the appservice needs a scoped token
-for a single user then they can use this API instead.
-{{% /boxes/note %}}
-
-This request must be authenticated by the [appservice `as_token`](/application-service-api#registration)
-(see [Client Authentication](#client-authentication) on how to provide the token).
-
-To use this login type, clients should submit a `/login` request as follows:
-
-```json
-{
-  "type": "m.login.application_service",
-  "identifier": {
-    "type": "m.id.user",
-    "user": "<user_id or user localpart>"
-  }
-}
-```
-
-If the access token is not valid, does not correspond to an appservice
-or the user has not previously been registered then the homeserver will
-respond with an errcode of `M_FORBIDDEN`.
-
-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`.
-
-{{% http-api spec="client-server" api="login" %}}
-
-{{% http-api spec="client-server" api="logout" %}}
-
-#### Login Fallback
-
-If a client does not recognize any or all login flows it can use the
-fallback login API:
-
-    GET /_matrix/static/client/login/
-
-This returns an HTML and JavaScript page which can perform the entire
-login process. The page will attempt to call the JavaScript function
-`window.onLogin` when login has been successfully completed.
-
-{{% added-in v="1.1" %}} Non-credential parameters valid for the `/login`
-endpoint can be provided as query string parameters here. These are to be
-forwarded to the login endpoint during the login process. For example:
-
-    GET /_matrix/static/client/login/?device_id=GHTYAJCE
-
-### Account registration and management
-
-{{% http-api spec="client-server" api="registration" %}}
-
-#### Notes on password management
-
-{{% boxes/warning %}}
-Clients SHOULD enforce that the password provided is suitably complex.
-The password SHOULD include a lower-case letter, an upper-case letter, a
-number and a symbol and be at a minimum 8 characters in length. Servers
-MAY reject weak passwords with an error code `M_WEAK_PASSWORD`.
-{{% /boxes/warning %}}
-
-### Adding Account Administrative Contact Information
-
-A homeserver may keep some contact information for administrative use.
-This is independent of any information kept by any identity servers,
-though can be proxied (bound) to the identity server in many cases.
-
-{{% boxes/note %}}
-This section deals with two terms: "add" and "bind". Where "add" (or
-"remove") is used, it is speaking about an identifier that was not bound
-to an identity server. As a result, "bind" (or "unbind") references an
-identifier that is found in an identity server. Note that an identifier
-can be added and bound at the same time, depending on context.
-{{% /boxes/note %}}
-
-{{% http-api spec="client-server" api="administrative_contact" %}}
-
-### Current account information
-
-{{% http-api spec="client-server" api="whoami" %}}
-
-#### Notes on identity servers
-
-Identity servers in Matrix store bindings (relationships) between a
-user's third party identifier, typically email or phone number, and
-their user ID. Once a user has chosen an identity server, that identity
-server should be used by all clients.
-
-Clients can see which identity server the user has chosen through the
-`m.identity_server` account data event, as described below. Clients
-SHOULD refrain from making requests to any identity server until the
-presence of `m.identity_server` is confirmed as (not) present. If
-present, the client SHOULD check for the presence of the `base_url`
-property in the event's content. If the `base_url` is present, the
-client SHOULD use the identity server in that property as the identity
-server for the user. If the `base_url` is missing, or the account data
-event is not present, the client SHOULD use whichever default value it
-normally would for an identity server, if applicable. Clients SHOULD NOT
-update the account data with the default identity server when the user
-is missing an identity server in their account data.
-
-Clients SHOULD listen for changes to the `m.identity_server` account
-data event and update the identity server they are contacting as a
-result.
-
-If the client offers a way to set the identity server to use, it MUST
-update the value of `m.identity_server` accordingly. A `base_url` of
-`null` MUST be treated as though the user does not want to use an
-identity server, disabling all related functionality as a result.
-
-Clients SHOULD refrain from populating the account data as a migration
-step for users who are lacking the account data, unless the user sets
-the identity server within the client to a value. For example, a user
-which has no `m.identity_server` account data event should not end up
-with the client's default identity server in their account data, unless
-the user first visits their account settings to set the identity server.
-
-{{% event event="m.identity_server" %}}
-
-## Capabilities negotiation
-
-A homeserver may not support certain operations and clients must be able
-to query for what the homeserver can and can't offer. For example, a
-homeserver may not support users changing their password as it is
-configured to perform authentication against an external system.
-
-The capabilities advertised through this system are intended to
-advertise functionality which is optional in the API, or which depend in
-some way on the state of the user or server. This system should not be
-used to advertise unstable or experimental features - this is better
-done by the `/versions` endpoint.
-
-Some examples of what a reasonable capability could be are:
-
--   Whether the server supports user presence.
--   Whether the server supports optional features, such as the user or
-    room directories.
--   The rate limits or file type restrictions imposed on clients by the
-    server.
-
-Some examples of what should **not** be a capability are:
-
--   Whether the server supports a feature in the `unstable`
-    specification.
--   Media size limits - these are handled by the
-    [`/config`](#get_matrixmediav3config) API.
--   Optional encodings or alternative transports for communicating with
-    the server.
-
-Capabilities prefixed with `m.` are reserved for definition in the
-Matrix specification while other values may be used by servers using the
-Java package naming convention. The capabilities supported by the Matrix
-specification are defined later in this section.
-
-{{% http-api spec="client-server" api="capabilities" %}}
-
-### `m.change_password` capability
-
-This capability has a single flag, `enabled`, which indicates whether or
-not the user can use the `/account/password` API to change their
-password. If not present, the client should assume that password changes
-are possible via the API. When present, clients SHOULD respect the
-capability's `enabled` flag and indicate to the user if they are unable
-to change their password.
-
-An example of the capability API's response for this capability is:
-
-```json
-{
-  "capabilities": {
-    "m.change_password": {
-      "enabled": false
-    }
-  }
-}
-```
-
-### `m.room_versions` capability
-
-This capability describes the default and available room versions a
-server supports, and at what level of stability. Clients should make use
-of this capability to determine if users need to be encouraged to
-upgrade their rooms.
-
-An example of the capability API's response for this capability is:
-
-```json
-{
-  "capabilities": {
-    "m.room_versions": {
-      "default": "1",
-      "available": {
-        "1": "stable",
-        "2": "stable",
-        "3": "unstable",
-        "custom-version": "unstable"
-      }
-    }
-  }
-}
-```
-
-This capability mirrors the same restrictions of [room
-versions](/rooms) to describe which versions are
-stable and unstable. Clients should assume that the `default` version is
-`stable`. Any version not explicitly labelled as `stable` in the
-`available` versions is to be treated as `unstable`. For example, a
-version listed as `future-stable` should be treated as `unstable`.
-
-The `default` version is the version the server is using to create new
-rooms. Clients should encourage users with sufficient permissions in a
-room to upgrade their room to the `default` version when the room is
-using an `unstable` version.
-
-When this capability is not listed, clients should use `"1"` as the
-default and only stable `available` room version.
-
-### `m.set_displayname` capability
-
-This capability has a single flag, `enabled`, to denote whether the user
-is able to change their own display name via profile endpoints. Cases for
-disabling might include users mapped from external identity/directory
-services, such as LDAP.
-
-Note that this is well paired with the `m.set_avatar_url` capability.
-
-When not listed, clients should assume the user is able to change their
-display name.
-
-An example of the capability API's response for this capability is:
-
-```json
-{
-  "capabilities": {
-    "m.set_displayname": {
-      "enabled": false
-    }
-  }
-}
-```
-
-### `m.set_avatar_url` capability
-
-This capability has a single flag, `enabled`, to denote whether the user
-is able to change their own avatar via profile endpoints. Cases for
-disabling might include users mapped from external identity/directory
-services, such as LDAP.
-
-Note that this is well paired with the `m.set_displayname` capability.
-
-When not listed, clients should assume the user is able to change their
-avatar.
-
-An example of the capability API's response for this capability is:
-
-```json
-{
-  "capabilities": {
-    "m.set_avatar_url": {
-      "enabled": false
-    }
-  }
-}
-```
-
-### `m.3pid_changes` capability
-
-This capability has a single flag, `enabled`, to denote whether the user
-is able to add, remove, or change 3PID associations on their account. Note
-that this only affects a user's ability to use the
-[Admin Contact Information](#adding-account-administrative-contact-information)
-API, not endpoints exposed by an Identity Service. Cases for disabling
-might include users mapped from external identity/directory  services,
-such as LDAP.
-
-When not listed, clients should assume the user is able to modify their 3PID
-associations.
-
-An example of the capability API's response for this capability is:
-
-```json
-{
-  "capabilities": {
-    "m.3pid_changes": {
-      "enabled": false
-    }
-  }
-}
-```
-
-## Filtering
-
-Filters can be created on the server and can be passed as a parameter to
-APIs which return events. These filters alter the data returned from
-those APIs. Not all APIs accept filters.
-
-### Lazy-loading room members
-
-Membership events often take significant resources for clients to track.
-In an effort to reduce the number of resources used, clients can enable
-"lazy-loading" for room members. By doing this, servers will attempt to
-only send membership events which are relevant to the client.
-
-It is important to understand that lazy-loading is not intended to be a
-perfect optimisation, and that it may not be practical for the server to
-calculate precisely which membership events are relevant to the client.
-As a result, it is valid for the server to send redundant membership
-events to the client to ease implementation, although such redundancy
-should be minimised where possible to conserve bandwidth.
-
-In terms of filters, lazy-loading is enabled by enabling
-`lazy_load_members` on a `RoomEventFilter` (or a `StateFilter` in the
-case of `/sync` only). When enabled, lazy-loading aware endpoints (see
-below) will only include membership events for the `sender` of events
-being included in the response. For example, if a client makes a `/sync`
-request with lazy-loading enabled, the server will only return
-membership events for the `sender` of events in the timeline, not all
-members of a room.
-
-When processing a sequence of events (e.g. by looping on `/sync` or
-paginating `/messages`), it is common for blocks of events in the
-sequence to share a similar set of senders. Rather than responses in the
-sequence sending duplicate membership events for these senders to the
-client, the server MAY assume that clients will remember membership
-events they have already been sent, and choose to skip sending
-membership events for members whose membership has not changed. These
-are called 'redundant membership events'. Clients may request that
-redundant membership events are always included in responses by setting
-`include_redundant_members` to true in the filter.
-
-The expected pattern for using lazy-loading is currently:
-
--   Client performs an initial /sync with lazy-loading enabled, and
-    receives only the membership events which relate to the senders of
-    the events it receives.
--   Clients which support display-name tab-completion or other
-    operations which require rapid access to all members in a room
-    should call /members for the currently selected room, with an `?at`
-    parameter set to the /sync response's from token. The member list
-    for the room is then maintained by the state in subsequent
-    incremental /sync responses.
--   Clients which do not support tab-completion may instead pull in
-    profiles for arbitrary users (e.g. read receipts, typing
-    notifications) on demand by querying the room state or `/profile`.
-
-The current endpoints which support lazy-loading room members are:
-
--   [`/sync`](/client-server-api/#get_matrixclientv3sync)
--   [`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages)
--   [`/rooms/{roomId}/context/{eventId}`](/client-server-api/#get_matrixclientv3roomsroomidcontexteventid)
-
-### API endpoints
-
-{{% http-api spec="client-server" api="filter" %}}
-
-## Events
-
-The model of conversation history exposed by the client-server API can
-be considered as a list of events. The server 'linearises' the
-eventually-consistent event graph of events into an 'event stream' at
-any given point in time:
-
-    [E0]->[E1]->[E2]->[E3]->[E4]->[E5]
-
-### Types of room events
-
-Room events are split into two categories:
-
-* **State events**: These are events which update the metadata state of the room (e.g. room
-topic, room membership etc). State is keyed by a tuple of event `type`
-and a `state_key`. State in the room with the same key-tuple will be
-overwritten.
-
-* **Message events**: These are events which describe transient "once-off" activity in a room:
-typically communication such as sending an instant message or setting up
-a VoIP call.
-
-This specification outlines several events, all with the event type
-prefix `m.`. (See [Room Events](#room-events) for the m. event
-specification.) However, applications may wish to add their own type of
-event, and this can be achieved using the REST API detailed in the
-following sections. If new events are added, the event `type` key SHOULD
-follow the Java package naming convention, e.g.
-`com.example.myapp.event`. This ensures event types are suitably
-namespaced for each application and reduces the risk of clashes.
-
-{{% boxes/note %}}
-Events are not limited to the types defined in this specification. New
-or custom event types can be created on a whim using the Java package
-naming convention. For example, a `com.example.game.score` event can be
-sent by clients and other clients would receive it through Matrix,
-assuming the client has access to the `com.example` namespace.
-{{% /boxes/note %}}
-
-### Room event format
-
-The "federation" format of a room event, which is used internally by homeservers
-and between homeservers via the Server-Server API, depends on the ["room
-version"](/rooms) in use by the room. See, for example, the definitions
-in [room version 1](/rooms/v1#event-format) and [room version
-3](/rooms/v3#event-format).
-
-However, it is unusual that a Matrix client would encounter this event
-format. Instead, homeservers are responsible for converting events into the
-format shown below so that they can be easily parsed by clients.
-
-{{% boxes/warning %}}
-Event bodies are considered untrusted data. This means that any application using
-Matrix must validate that the event body is of the expected shape/schema
-before using the contents verbatim.
-
-**It is not safe to assume that an event body will have all the expected
-fields of the expected types.**
-
-See [MSC2801](https://github.com/matrix-org/matrix-doc/pull/2801) for more
-detail on why this assumption is unsafe.
-{{% /boxes/warning %}}
-
-{{% definition path="api/client-server/definitions/client_event" %}}
-
-### Stripped state
-
-Stripped state events are simplified state events to help a potential
-joiner identify the room. These state events can only have the `sender`,
-`type`, `state_key` and `content` keys present.
-
-These stripped state events typically appear on invites, knocks, and in
-other places where a user *could* join the room under the conditions
-available (such as a [`restricted` room](#restricted-rooms)).
-
-Clients should only use stripped state events so long as they don't have
-access to the proper state of the room. Once the state of the room is
-available, all stripped state should be discarded. In cases where the
-client has an archived state of the room (such as after being kicked)
-and the client is receiving stripped state for the room, such as from an
-invite or knock, then the stripped state should take precedence until
-fresh state can be acquired from a join.
-
-The following state events should be represented as stripped state when
-possible:
-
-* [`m.room.create`](#mroomcreate)
-* [`m.room.name`](#mroomname)
-* [`m.room.avatar`](#mroomavatar)
-* [`m.room.topic`](#mroomtopic)
-* [`m.room.join_rules`](#mroomjoin_rules)
-* [`m.room.canonical_alias`](#mroomcanonical_alias)
-* [`m.room.encryption`](#mroomencryption)
-
-{{% boxes/note %}}
-Clients should inspect the list of stripped state events and not assume any
-particular event is present. The server might include events not described
-here as well.
-{{% /boxes/note %}}
-
-{{% boxes/rationale %}}
-The name, avatar, topic, and aliases are presented as aesthetic information
-about the room, allowing users to make decisions about whether or not they
-want to join the room.
-
-The join rules are given to help the client determine *why* it is able to
-potentially join. For example, annotating the room decoration with iconography
-consistent with the respective join rule for the room.
-
-The create event can help identify what kind of room is being joined, as it
-may be a Space or other kind of room. The client might choose to render the
-invite in a different area of the application as a result.
-
-Similar to join rules, the encryption information is given to help clients
-decorate the room with appropriate iconography or messaging.
-{{% /boxes/rationale %}}
-
-{{% boxes/warning %}}
-Although stripped state is usually generated and provided by the server, it
-is still possible to be incorrect on the receiving end. The stripped state
-events are not signed and could theoretically be modified, or outdated due to
-updates not being sent.
-{{% /boxes/warning %}}
-
-{{% event-fields event_type="stripped_state" %}}
-
-### Size limits
-
-The complete event MUST NOT be larger than 65536 bytes, when formatted
-with the [federation event format](#room-event-format), including any
-signatures, and encoded as [Canonical
-JSON](/appendices#canonical-json).
-
-There are additional restrictions on sizes per key:
-
--   `sender` MUST NOT exceed 255 bytes (including domain).
--   `room_id` MUST NOT exceed 255 bytes.
--   `state_key` MUST NOT exceed 255 bytes.
--   `type` MUST NOT exceed 255 bytes.
--   `event_id` MUST NOT exceed 255 bytes.
-
-Some event types have additional size restrictions which are specified
-in the description of the event. Additional keys have no limit other
-than that implied by the total 64 KiB limit on events.
-
-### Room Events
-
-{{% boxes/note %}}
-This section is a work in progress.
-{{% /boxes/note %}}
-
-This specification outlines several standard event types, all of which
-are prefixed with `m.`
-
-{{% event event="m.room.canonical_alias" %}}
-
-{{% event event="m.room.create" %}}
-
-{{% event event="m.room.join_rules" %}}
-
-{{% event event="m.room.member" %}}
-
-{{% event event="m.room.power_levels" %}}
-
-#### Historical events
-
-Some events within the `m.` namespace might appear in rooms, however
-they serve no significant meaning in this version of the specification.
-They are:
-
--   `m.room.aliases`
-
-Previous versions of the specification have more information on these
-events.
-
-### Syncing
-
-To read events, the intended flow of operation is for clients to first
-call the [`/sync`](/client-server-api/#get_matrixclientv3sync) API without a `since` parameter. This returns the
-most recent message events for each room, as well as the state of the
-room at the start of the returned timeline. The response also includes a
-`next_batch` field, which should be used as the value of the `since`
-parameter in the next call to `/sync`. Finally, the response includes,
-for each room, a `prev_batch` field, which can be passed as a `start`
-parameter to the [`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages) API to retrieve earlier
-messages.
-
-For example, a `/sync` request might return a range of four events
-`E2`, `E3`, `E4` and `E5` within a given room, omitting two prior events
-`E0` and `E1`. This can be visualised as follows:
-
-```
-    [E0]->[E1]->[E2]->[E3]->[E4]->[E5]
-               ^                      ^
-               |                      |
-         prev_batch: '1-2-3'        next_batch: 'a-b-c'
-```
-
-Clients then receive new events by "long-polling" the homeserver via the
-`/sync` API, passing the value of the `next_batch` field from the
-response to the previous call as the `since` parameter. The client
-should also pass a `timeout` parameter. The server will then hold open
-the HTTP connection for a short period of time waiting for new events,
-returning early if an event occurs. Only the `/sync` API (and the
-deprecated `/events` API) support long-polling in this way.
-
-Continuing the example above, an incremental sync might report
-a single new event `E6`. The response can be visualised as:
-
-```
-    [E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6]
-                                      ^     ^
-                                      |     |
-                                      |  next_batch: 'x-y-z'
-                                    prev_batch: 'a-b-c'
-```
-
-Normally, all new events which are visible to the client will appear in
-the response to the `/sync` API. However, if a large number of events
-arrive between calls to `/sync`, a "limited" timeline is returned,
-containing only the most recent message events. A state "delta" is also
-returned, summarising any state changes in the omitted part of the
-timeline. The client may therefore end up with "gaps" in its knowledge
-of the message timeline. The client can fill these gaps using the
-[`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages) API.
-
-Continuing our example, suppose we make a third `/sync` request asking for
-events since the last sync, by passing the `next_batch` token `x-y-z` as
-the `since` parameter. The server knows about four new events, `E7`, `E8`,
-`E9` and `E10`, but decides this is too many to report at once. Instead,
-the server sends a `limited` response containing `E8`, `E9` and `E10`but
-omitting `E7`. This forms a gap, which we can see in the visualisation:
-
-```
-                                            | gap |
-                                            | <-> |
-    [E0]->[E1]->[E2]->[E3]->[E4]->[E5]->[E6]->[E7]->[E8]->[E9]->[E10]
-                                            ^     ^                  ^
-                                            |     |                  |
-                                 since: 'x-y-z'   |                  |
-                                       prev_batch: 'd-e-f'       next_batch: 'u-v-w'
-```
-
-The limited response includes a state delta which describes how the state
-of the room changes over the gap. This delta explains how to build the state
-prior to returned timeline (i.e. at `E7`) from the state the client knows
-(i.e. at `E6`). To close the gap, the client should make a request to
-[`/rooms/<room_id>/messages`](/client-server-api/#get_matrixclientv3roomsroomidmessages)
-with the query parameters `from=x-y-z` and `to=d-e-f`.
-
-{{% boxes/warning %}}
-Events are ordered in this API according to the arrival time of the
-event on the homeserver. This can conflict with other APIs which order
-events based on their partial ordering in the event graph. This can
-result in duplicate events being received (once per distinct API
-called). Clients SHOULD de-duplicate events based on the event ID when
-this happens.
-{{% /boxes/warning %}}
-
-{{% boxes/note %}}
-The `/sync` API returns a `state` list which is separate from the
-`timeline`. This `state` list allows clients to keep their model of the
-room state in sync with that on the server. In the case of an initial
-(`since`-less) sync, the `state` list represents the complete state of
-the room at the **start** of the returned timeline (so in the case of a
-recently-created room whose state fits entirely in the `timeline`, the
-`state` list will be empty).
-
-In the case of an incremental sync, the `state` list gives a delta
-between the state of the room at the `since` parameter and that at the
-start of the returned `timeline`. (It will therefore be empty unless the
-timeline was `limited`.)
-
-In both cases, it should be noted that the events returned in the
-`state` list did **not** necessarily take place just before the returned
-`timeline`, so clients should not display them to the user in the
-timeline.
-{{% /boxes/note %}}
-
-{{% boxes/rationale %}}
-An early design of this specification made the `state` list represent
-the room state at the end of the returned timeline, instead of the
-start. This was unsatisfactory because it led to duplication of events
-between the `state` list and the `timeline`, but more importantly, it
-made it difficult for clients to show the timeline correctly.
-
-In particular, consider a returned timeline \[M0, S1, M2\], where M0 and
-M2 are both messages sent by the same user, and S1 is a state event
-where that user changes their displayname. If the `state` list
-represents the room state at the end of the timeline, the client must
-take a copy of the state dictionary, and *rewind* S1, in order to
-correctly calculate the display name for M0.
-{{% /boxes/rationale %}}
-
-{{% http-api spec="client-server" api="sync" %}}
-
-{{% http-api spec="client-server" api="old_sync" %}}
-
-### Getting events for a room
-
-There are several APIs provided to `GET` events for a room:
-
-{{% http-api spec="client-server" api="rooms" %}}
-
-{{% http-api spec="client-server" api="message_pagination" %}}
-
-{{% http-api spec="client-server" api="room_initial_sync" %}}
-
-### Sending events to a room
-
-{{% http-api spec="client-server" api="room_state" %}}
-
-**Examples**
-
-Valid requests look like:
-
-```
-PUT /rooms/!roomid:domain/state/m.example.event
-{ "key" : "without a state key" }
-```
-```
-PUT /rooms/!roomid:domain/state/m.another.example.event/foo
-{ "key" : "with 'foo' as the state key" }
-```
-
-In contrast, these requests are invalid:
-
-```
-POST /rooms/!roomid:domain/state/m.example.event/
-{ "key" : "cannot use POST here" }
-```
-```
-PUT /rooms/!roomid:domain/state/m.another.example.event/foo/11
-{ "key" : "txnIds are not supported" }
-```
-
-Care should be taken to avoid setting the wrong `state key`:
-
-```
-PUT /rooms/!roomid:domain/state/m.another.example.event/11
-{ "key" : "with '11' as the state key, but was probably intended to be a txnId" }
-```
-
-The `state_key` is often used to store state about individual users, by
-using the user ID as the `state_key` value. For example:
-
-```
-PUT /rooms/!roomid:domain/state/m.favorite.animal.event/%40my_user%3Aexample.org
-{ "animal" : "cat", "reason": "fluffy" }
-```
-
-In some cases, there may be no need for a `state_key`, so it can be
-omitted:
-
-```
-PUT /rooms/!roomid:domain/state/m.room.bgd.color
-{ "color": "red", "hex": "#ff0000" }
-```
-
-{{% http-api spec="client-server" api="room_send" %}}
-
-### Redactions
-
-Since events are extensible it is possible for malicious users and/or
-servers to add keys that are, for example offensive or illegal. Since
-some events cannot be simply deleted, e.g. membership events, we instead
-'redact' events. This involves removing all keys from an event that are
-not required by the protocol. This stripped down event is thereafter
-returned anytime a client or remote server requests it. Redacting an
-event cannot be undone, allowing server owners to delete the offending
-content from the databases. Servers should include a copy of the
-`m.room.redaction` event under `unsigned` as `redacted_because`
-when serving the redacted event to clients.
-
-The exact algorithm to apply against an event is defined in the [room
-version specification](/rooms), as are the criteria homeservers should
-use when deciding whether to accept a redaction event from a remote
-homeserver.
-
-When a client receives an `m.room.redaction` event, it should change
-the affected event in the same way a server does.
-
-{{% boxes/note %}}
-Redacted events can still affect the state of the room. When redacted,
-state events behave as though their properties were simply not
-specified, except those protected by the redaction algorithm. For
-example, a redacted `join` event will still result in the user being
-considered joined. Similarly, a redacted topic does not necessarily
-cause the topic to revert to what it was prior to the event - it causes
-the topic to be removed from the room.
-{{% /boxes/note %}}
-
-#### Events
-
-{{% event event="m.room.redaction" %}}
-
-#### Client behaviour
-
-{{% http-api spec="client-server" api="redaction" %}}
-
-## Rooms
-
-### Types
-
-{{% added-in v="1.2" %}}
-
-Optionally, rooms can have types to denote their intended function. A room
-without a type does not necessarily mean it has a specific default function,
-though commonly these rooms will be for conversational purposes.
-
-Room types are best applied when a client might need to differentiate between
-two different rooms, such as conversation-holding and data-holding. If a room
-has a type, it is specified in the `type` key of an [`m.room.create`](#mroomcreate)
-event. To specify a room's type, provide it as part of `creation_content` on
-the create room request.
-
-In this specification the following room types are specified:
-
-* [`m.space`](#spaces)
-
-Unspecified room types are permitted through the use of
-[Namespaced Identifiers](/appendices/#common-namespaced-identifier-grammar).
-
-### Creation
-
-The homeserver will create an `m.room.create` event when a room is
-created, which serves as the root of the event graph for this room. This
-event also has a `creator` key which contains the user ID of the room
-creator. It will also generate several other events in order to manage
-permissions in this room. This includes:
-
--   `m.room.power_levels` : Sets the power levels of users and required power
-    levels for various actions within the room such as sending events.
-
--   `m.room.join_rules` : Whether the room is "invite-only" or not.
-
-See [Room Events](#room-events) for more information on these events. To
-create a room, a client has to use the following API.
-
-{{% http-api spec="client-server" api="create_room" %}}
-
-### Room aliases
-
-Servers may host aliases for rooms with human-friendly names. Aliases
-take the form `#friendlyname:server.name`.
-
-As room aliases are scoped to a particular homeserver domain name, it is
-likely that a homeserver will reject attempts to maintain aliases on
-other domain names. This specification does not provide a way for
-homeservers to send update requests to other servers. However,
-homeservers MUST handle `GET` requests to resolve aliases on other
-servers; they should do this using the federation API if necessary.
-
-Rooms do not store a list of all aliases present on a room, though
-members of the room with relevant permissions may publish preferred
-aliases through the `m.room.canonical_alias` state event. The aliases in
-the state event should point to the room ID they are published within,
-however room aliases can and do drift to other room IDs over time.
-Clients SHOULD NOT treat the aliases as accurate. They SHOULD be checked
-before they are used or shared with another user. If a room appears to
-have a room alias of `#alias:example.com`, this SHOULD be checked to
-make sure that the room's ID matches the `room_id` returned from the
-request.
-
-{{% http-api spec="client-server" api="directory" %}}
-
-### Permissions
-
-{{% boxes/note %}}
-This section is a work in progress.
-{{% /boxes/note %}}
-
-Permissions for rooms are done via the concept of power levels - to do
-any action in a room a user must have a suitable power level. Power
-levels are stored as state events in a given room. The power levels
-required for operations and the power levels for users are defined in
-`m.room.power_levels`, where both a default and specific users' power
-levels can be set. By default all users have a power level of 0, other
-than the room creator whose power level defaults to 100. Users can grant
-other users increased power levels up to their own power level. For
-example, user A with a power level of 50 could increase the power level
-of user B to a maximum of level 50. Power levels for users are tracked
-per-room even if the user is not present in the room. The keys contained
-in `m.room.power_levels` determine the levels required for certain
-operations such as kicking, banning and sending state events. See
-[m.room.power\_levels](#room-events) for more information.
-
-Clients may wish to assign names to particular power levels. A suggested
-mapping is as follows: - 0 User - 50 Moderator - 100 Admin
-
-### Room membership
-
-Users need to be a member of a room in order to send and receive events
-in that room. There are several states in which a user may be, in
-relation to a room:
-
--   Unrelated (the user cannot send or receive events in the room)
--   Knocking (the user has requested to participate in the room, but has
-    not yet been allowed to)
--   Invited (the user has been invited to participate in the room, but
-    is not yet participating)
--   Joined (the user can send and receive events in the room)
--   Banned (the user is not allowed to join the room)
-
-There are a few notable exceptions which allow non-joined members of the
-room to send events in the room:
-
-- Users wishing to reject an invite would send `m.room.member` events with
-  `content.membership` of `leave`. They must have been invited first.
-
-- If the room allows, users can send `m.room.member` events with `content.membership`
-  of `knock` to knock on the room. This is a request for an invite by the user.
-
-- To retract a previous knock, a user would send a `leave` event similar to
-  rejecting an invite.
-
-Some rooms require that users be invited to it before they can join;
-others allow anyone to join. Whether a given room is an "invite-only"
-room is determined by the room config key `m.room.join_rules`. It can
-have one of the following values:
-
-`public`
-This room is free for anyone to join without an invite.
-
-`invite`
-This room can only be joined if you were invited.
-
-`knock`
-This room can only be joined if you were invited, and allows anyone to
-request an invite to the room. Note that this join rule is only available
-in room versions [which support knocking](/rooms/#feature-matrix).
-
-{{% added-in v="1.2" %}} `restricted`
-This room can be joined if you were invited or if you are a member of another
-room listed in the join rules. If the server cannot verify membership for any
-of the listed rooms then you can only join with an invite. Note that this rule
-is only expected to work in room versions [which support it](/rooms/#feature-matrix).
-
-The allowable state transitions of membership are:
-
-![membership-flow-diagram](/diagrams/membership.png)
-
-{{% http-api spec="client-server" api="list_joined_rooms" %}}
-
-#### Joining rooms
-
-{{% http-api spec="client-server" api="inviting" %}}
-
-{{% http-api spec="client-server" api="joining" %}}
-
-##### Knocking on rooms
-
-{{% added-in v="1.1" %}}
-
-<!--
-This section is here because it's most similar to being invited/joining a
-room, though has added complexity which needs to be explained. Otherwise
-this will have been just the API definition and nothing more (like invites).
--->
-
-If the join rules allow, external users to the room can `/knock` on it to
-request permission to join. Users with appropriate permissions within the
-room can then approve (`/invite`) or deny (`/kick`, `/ban`, or otherwise
-set membership to `leave`) the knock. Knocks can be retracted by calling
-`/leave` or otherwise setting membership to `leave`.
-
-Users who are currently in the room, already invited, or banned cannot
-knock on the room.
-
-To accept another user's knock, the user must have permission to invite
-users to the room. To reject another user's knock, the user must have
-permission to either kick or ban users (whichever is being performed).
-Note that setting another user's membership to `leave` is kicking them.
-
-The knocking homeserver should assume that an invite to the room means
-that the knock was accepted, even if the invite is not explicitly related
-to the knock.
-
-Homeservers are permitted to automatically accept invites as a result of
-knocks as they should be aware of the user's intent to join the room. If
-the homeserver is not auto-accepting invites (or there was an unrecoverable
-problem with accepting it), the invite is expected to be passed down normally
-to the client to handle. Clients can expect to see the join event if the
-server chose to auto-accept.
-
-{{% http-api spec="client-server" api="knocking" %}}
-
-##### Restricted rooms
-
-{{% added-in v="1.2" %}}
-
-Restricted rooms are rooms with a `join_rule` of `restricted`. These rooms
-are accompanied by "allow conditions" as described in the
-[`m.room.join_rules`](#mroomjoin_rules) state event.
-
-If the user has an invite to the room then the restrictions will not affect
-them. They should be able to join by simply accepting the invite.
-
-When joining without an invite, the server MUST verify that the requesting
-user meets at least one of the conditions. If no conditions can be verified
-or no conditions are satisfied, the user will not be able to join. When the
-join is happening over federation, the remote server will check the conditions
-before accepting the join. See the [Server-Server Spec](/server-server-api/#restricted-rooms)
-for more information.
-
-If the room is `restricted` but no valid conditions are presented then the
-room is effectively invite only.
-
-The user does not need to maintain the conditions in order to stay a member
-of the room: the conditions are only checked/evaluated during the join process.
-
-###### Conditions
-
-Currently there is only one condition available: `m.room_membership`. This
-condition requires the user trying to join the room to be a *joined* member
-of another room (specifically, the `room_id` accompanying the condition). For
-example, if `!restricted:example.org` wanted to allow joined members of
-`!other:example.org` to join, `!restricted:example.org` would have the following
-`content` for [`m.room.join_rules`](#mroomjoin_rules):
-
-```json
-{
-  "join_rule": "restricted",
-  "allow": [
-    {
-      "room_id": "!other:example.org",
-      "type": "m.room_membership"
-    }
-  ]
-}
-```
-
-#### Leaving rooms
-
-A user can leave a room to stop receiving events for that room. A user
-must have been invited to or have joined the room before they are
-eligible to leave the room. Leaving a room to which the user has been
-invited rejects the invite, and can retract a knock. Once a user leaves
-a room, it will no longer appear in the response to the
-[`/sync`](/client-server-api/#get_matrixclientv3sync) API unless it is
-explicitly requested via a filter with the `include_leave` field set
-to `true`.
-
-Whether or not they actually joined the room, if the room is an
-"invite-only" room the user will need to be re-invited before they can
-re-join the room.
-
-A user can also forget a room which they have left. Rooms which have
-been forgotten will never appear the response to the [`/sync`](/client-server-api/#get_matrixclientv3sync) API,
-until the user re-joins, is re-invited, or knocks.
-
-A user may wish to force another user to leave a room. This can be done
-by 'kicking' the other user. To do so, the user performing the kick MUST
-have the required power level. Once a user has been kicked, the
-behaviour is the same as if they had left of their own accord. In
-particular, the user is free to re-join if the room is not
-"invite-only".
-
-{{% http-api spec="client-server" api="leaving" %}}
-
-{{% http-api spec="client-server" api="kicking" %}}
-
-##### Banning users in a room
-
-A user may decide to ban another user in a room. 'Banning' forces the
-target user to leave the room and prevents them from re-joining the
-room. A banned user will not be treated as a joined user, and so will
-not be able to send or receive events in the room. In order to ban
-someone, the user performing the ban MUST have the required power level.
-To ban a user, a request should be made to [`/rooms/<room_id>/ban`](/client-server-api/#post_matrixclientv3roomsroomidban)
-with:
-
-```json
-{
-  "user_id": "<user id to ban>",
-  "reason": "string: <reason for the ban>"
-}
-````
-
-Banning a user adjusts the banned member's membership state to `ban`.
-Like with other membership changes, a user can directly adjust the
-target member's state, by making a request to
-`/rooms/<room id>/state/m.room.member/<user id>`:
-
-```json
-{
-  "membership": "ban"
-}
-```
-
-A user must be explicitly unbanned with a request to
-[`/rooms/<room_id>/unban`](/client-server-api/#post_matrixclientv3roomsroomidunban) before they can re-join the room or be
-re-invited.
-
-{{% http-api spec="client-server" api="banning" %}}
-
-### Listing rooms
-
-{{% http-api spec="client-server" api="list_public_rooms" %}}
-
-## User Data
-
-### User Directory
-
-{{% http-api spec="client-server" api="users" %}}
-
-### Profiles
-
-{{% http-api spec="client-server" api="profile" %}}
-
-#### Events on Change of Profile Information
-
-Because the profile display name and avatar information are likely to be
-used in many places of a client's display, changes to these fields cause
-an automatic propagation event to occur, informing likely-interested
-parties of the new values. This change is conveyed using two separate
-mechanisms:
-
--   an `m.room.member` event (with a `join` membership) is sent to every
-    room the user is a member of, to update the `displayname` and
-    `avatar_url`.
--   an `m.presence` presence status update is sent, again containing the
-    new values of the `displayname` and `avatar_url` keys, in addition
-    to the required `presence` key containing the current presence state
-    of the user.
-
-Both of these should be done automatically by the homeserver when a user
-successfully changes their display name or avatar URL fields.
-
-Additionally, when homeservers emit room membership events for their own
-users, they should include the display name and avatar URL fields in
-these events so that clients already have these details to hand, and do
-not have to perform extra round trips to query it.
-
-## Security
-
-### Rate limiting
-
-Homeservers SHOULD implement rate limiting to reduce the risk of being
-overloaded. If a request is refused due to rate limiting, it should
-return a standard error response of the form:
-
-```json
-{
-  "errcode": "M_LIMIT_EXCEEDED",
-  "error": "string",
-  "retry_after_ms": integer (optional)
-}
-```
-
-The `retry_after_ms` key SHOULD be included to tell the client how long
-they have to wait in milliseconds before they can try again.
-
-## Modules
-
-Modules are parts of the Client-Server API which are not universal to
-all endpoints. Modules are strictly defined within this specification
-and should not be mistaken for experimental extensions or optional
-features. A compliant server implementation MUST support all modules and
-supporting specification (unless the implementation only targets clients
-of certain profiles, in which case only the required modules for those
-feature profiles MUST be implemented). A compliant client implementation
-MUST support all the required modules and supporting specification for
-the [Feature Profile](#feature-profiles) it targets.
-
-### Feature Profiles
-
-Matrix supports many different kinds of clients: from embedded IoT
-devices to desktop clients. Not all clients can provide the same feature
-sets as other clients e.g. due to lack of physical hardware such as not
-having a screen. Clients can fall into one of several profiles and each
-profile contains a set of features that the client MUST support. This
-section details a set of "feature profiles". Clients are expected to
-implement a profile in its entirety in order for it to be classified as
-that profile.
-
-#### Summary
-
-| Module / Profile                                           | Web       | Mobile   | Desktop  | CLI      | Embedded |
-|------------------------------------------------------------|-----------|----------|----------|----------|----------|
-| [Instant Messaging](#instant-messaging)                    | Required  | Required | Required | Required | Optional |
-| [Direct Messaging](#direct-messaging)                      | Required  | Required | Required | Required | Optional |
-| [Mentions](#user-room-and-group-mentions)                  | Required  | Required | Required | Optional | Optional |
-| [Presence](#presence)                                      | Required  | Required | Required | Required | Optional |
-| [Push Notifications](#push-notifications)                  | Optional  | Required | Optional | Optional | Optional |
-| [Receipts](#receipts)                                      | Required  | Required | Required | Required | Optional |
-| [Fully read markers](#fully-read-markers)                  | Optional  | Optional | Optional | Optional | Optional |
-| [Typing Notifications](#typing-notifications)              | Required  | Required | Required | Required | Optional |
-| [VoIP](#voice-over-ip)                                     | Required  | Required | Required | Optional | Optional |
-| [Ignoring Users](#ignoring-users)                          | Required  | Required | Required | Optional | Optional |
-| [Reporting Content](#reporting-content)                    | Optional  | Optional | Optional | Optional | Optional |
-| [Content Repository](#content-repository)                  | Required  | Required | Required | Optional | Optional |
-| [Managing History Visibility](#room-history-visibility)    | Required  | Required | Required | Required | Optional |
-| [Server Side Search](#server-side-search)                  | Optional  | Optional | Optional | Optional | Optional |
-| [Room Upgrades](#room-upgrades)                            | Required  | Required | Required | Required | Optional |
-| [Server Administration](#server-administration)            | Optional  | Optional | Optional | Optional | Optional |
-| [Event Context](#event-context)                            | Optional  | Optional | Optional | Optional | Optional |
-| [Third Party Networks](#third-party-networks)              | Optional  | Optional | Optional | Optional | Optional |
-| [Send-to-Device Messaging](#send-to-device-messaging)      | Optional  | Optional | Optional | Optional | Optional |
-| [Device Management](#device-management)                    | Optional  | Optional | Optional | Optional | Optional |
-| [End-to-End Encryption](#end-to-end-encryption)            | Optional  | Optional | Optional | Optional | Optional |
-| [Guest Accounts](#guest-access)                            | Optional  | Optional | Optional | Optional | Optional |
-| [Room Previews](#room-previews)                            | Optional  | Optional | Optional | Optional | Optional |
-| [Client Config](#client-config)                            | Optional  | Optional | Optional | Optional | Optional |
-| [SSO Login](#sso-client-loginauthentication)               | Optional  | Optional | Optional | Optional | Optional |
-| [OpenID](#openid)                                          | Optional  | Optional | Optional | Optional | Optional |
-| [Stickers](#sticker-messages)                              | Optional  | Optional | Optional | Optional | Optional |
-| [Server ACLs](#server-access-control-lists-acls-for-rooms) | Optional  | Optional | Optional | Optional | Optional |
-| [Server Notices](#server-notices)                          | Optional  | Optional | Optional | Optional | Optional |
-| [Moderation policies](#moderation-policy-lists)            | Optional  | Optional | Optional | Optional | Optional |
-| [Spaces](#spaces)                                          | Optional  | Optional | Optional | Optional | Optional |
-
-*Please see each module for more details on what clients need to
-implement.*
-
-#### Clients
-
-##### Stand-alone web (`Web`)
-
-This is a web page which heavily uses Matrix for communication.
-Single-page web apps would be classified as a stand-alone web client, as
-would multi-page web apps which use Matrix on nearly every page.
-
-##### Mobile (`Mobile`)
-
-This is a Matrix client specifically designed for consumption on mobile
-devices. This is typically a mobile app but need not be so provided the
-feature set can be reached (e.g. if a mobile site could display push
-notifications it could be classified as a mobile client).
-
-##### Desktop (`Desktop`)
-
-This is a native GUI application which can run in its own environment
-outside a browser.
-
-##### Command Line Interface (`CLI`)
-
-This is a client which is used via a text-based terminal.
-
-##### Embedded (`Embedded`)
-
-This is a client which is embedded into another application or an
-embedded device.
-
-###### Application
-
-This is a Matrix client which is embedded in another website, e.g. using
-iframes. These embedded clients are typically for a single purpose
-related to the website in question, and are not intended to be
-fully-fledged communication apps.
-
-###### Device
-
-This is a client which is typically running on an embedded device such
-as a kettle, fridge or car. These clients tend to perform a few
-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="voip_events" %}}
-{{% cs-module name="typing_notifications" %}}
-{{% cs-module name="receipts" %}}
-{{% cs-module name="read_markers" %}}
-{{% cs-module name="presence" %}}
-{{% cs-module name="content_repo" %}}
-{{% cs-module name="send_to_device" %}}
-{{% cs-module name="device_management" %}}
-{{% cs-module name="end_to_end_encryption" %}}
-{{% cs-module name="secrets" %}}
-{{% cs-module name="history_visibility" %}}
-{{% cs-module name="push" %}}
-{{% cs-module name="third_party_invites" %}}
-{{% cs-module name="search" %}}
-{{% cs-module name="guest_access" %}}
-{{% cs-module name="room_previews" %}}
-{{% cs-module name="tags" %}}
-{{% cs-module name="account_data" %}}
-{{% cs-module name="admin" %}}
-{{% cs-module name="event_context" %}}
-{{% cs-module name="sso_login" %}}
-{{% cs-module name="dm" %}}
-{{% cs-module name="ignore_users" %}}
-{{% cs-module name="stickers" %}}
-{{% cs-module name="report_content" %}}
-{{% cs-module name="third_party_networks" %}}
-{{% cs-module name="openid" %}}
-{{% cs-module name="server_acls" %}}
-{{% cs-module name="mentions" %}}
-{{% cs-module name="room_upgrades" %}}
-{{% cs-module name="server_notices" %}}
-{{% cs-module name="moderation_policies" %}}
-{{% cs-module name="spaces" %}}
diff --git a/content/client-server-api/modules/account_data.md b/content/client-server-api/modules/account_data.md
deleted file mode 100644
index 500e2bbb..00000000
--- a/content/client-server-api/modules/account_data.md
+++ /dev/null
@@ -1,31 +0,0 @@
----
-type: module
----
-
-### Client Config
-
-Clients can store custom config data for their account on their
-homeserver. This account data will be synced between different devices
-and can persist across installations on a particular device. Users may
-only view the account data for their own account
-
-The account\_data may be either global or scoped to a particular rooms.
-
-#### Events
-
-The client receives the account data as events in the `account_data`
-sections of a `/sync`.
-
-These events can also be received in a `/events` response or in the
-`account_data` section of a room in `/sync`. `m.tag` events appearing in
-`/events` will have a `room_id` with the room the tags are for.
-
-#### Client Behaviour
-
-{{% http-api spec="client-server" api="account-data" %}}
-
-#### Server Behaviour
-
-Servers MUST reject clients from setting account data for event types
-that the server manages. Currently, this only includes
-[m.fully\_read](#mfully_read).
diff --git a/content/client-server-api/modules/admin.md b/content/client-server-api/modules/admin.md
deleted file mode 100644
index 6dd32fed..00000000
--- a/content/client-server-api/modules/admin.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-type: module
----
-
-### Server Administration
-
-This module adds capabilities for server administrators to inspect
-server state and data.
-
-#### Client Behaviour
-
-{{% http-api spec="client-server" api="admin" %}}
diff --git a/content/client-server-api/modules/content_repo.md b/content/client-server-api/modules/content_repo.md
deleted file mode 100644
index 467065a5..00000000
--- a/content/client-server-api/modules/content_repo.md
+++ /dev/null
@@ -1,117 +0,0 @@
----
-type: module
----
-
-### Content repository
-
-The content repository (or "media repository") allows users to upload
-files to their homeserver for later use. For example, files which the
-user wants to send to a room would be uploaded here, as would an avatar
-the user wants to use.
-
-Uploads are POSTed to a resource on the user's local homeserver which
-returns a MXC URI which can later be used to GET the download. Content
-is downloaded from the recipient's local homeserver, which must first
-transfer the content from the origin homeserver using the same API
-(unless the origin and destination homeservers are the same).
-
-When serving content, the server SHOULD provide a
-`Content-Security-Policy` header. The recommended policy is
-`sandbox; default-src 'none'; script-src 'none'; plugin-types application/pdf; style-src 'unsafe-inline'; object-src 'self';`.
-
-#### Matrix Content (MXC) URIs
-
-Content locations are represented as Matrix Content (MXC) URIs. They
-look like:
-
-    mxc://<server-name>/<media-id>
-
-    <server-name> : The name of the homeserver where this content originated, e.g. matrix.org
-    <media-id> : An opaque ID which identifies the content.
-
-#### Client behaviour
-
-Clients can upload and download content using the following HTTP APIs.
-
-{{% http-api spec="client-server" api="content-repo" %}}
-
-##### Thumbnails
-
-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
-information.
-
-The thumbnail methods are "crop" and "scale". "scale" tries to return an
-image where either the width or the height is smaller than the requested
-size. The client should then scale and letterbox the image if it needs
-to fit within a given rectangle. "crop" tries to return an image where
-the width and height are close to the requested size and the aspect
-matches the requested size. The client should scale the image if it
-needs to fit within a given rectangle.
-
-The dimensions given to the thumbnail API are the minimum size the
-client would prefer. Servers must never return thumbnails smaller than
-the client's requested dimensions, unless the content being thumbnailed
-is smaller than the dimensions. When the content is smaller than the
-requested dimensions, servers should return the original content rather
-than thumbnail it.
-
-Servers SHOULD produce thumbnails with the following dimensions and
-methods:
-
--   32x32, crop
--   96x96, crop
--   320x240, scale
--   640x480, scale
--   800x600, scale
-
-In summary:
--   "scale" maintains the original aspect ratio of the image
--   "crop" provides an image in the aspect ratio of the sizes given in
-    the request
--   The server will return an image larger than or equal to the
-    dimensions requested where possible.
-
-Servers MUST NOT upscale thumbnails under any circumstance. Servers MUST
-NOT return a smaller thumbnail than requested, unless the original
-content makes that impossible.
-
-#### Security considerations
-
-The HTTP GET endpoint does not require any authentication. Knowing the
-URL of the content is sufficient to retrieve the content, even if the
-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 allowing only alphanumeric
-(`A-Za-z0-9`), `_` and `-` characters in the `server-name` and
-`media-id` values. This 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,
-UTF-8 encoded traversals, etc).
-
-Homeservers have additional content-specific concerns:
-
--   Clients may try to upload very large files. Homeservers should not
-    store files that are too large and should not serve them to clients,
-    returning a HTTP 413 error with the `M_TOO_LARGE` code.
--   Clients may try to upload very large images. Homeservers should not
-    attempt to generate thumbnails for images that are too large,
-    returning a HTTP 413 error with the `M_TOO_LARGE` code.
--   Remote homeservers may host very large files or images. Homeservers
-    should not proxy or thumbnail large files or images from remote
-    homeservers, returning a HTTP 502 error with the `M_TOO_LARGE` code.
--   Clients may try to upload a large number of files. Homeservers
-    should limit the number and total size of media that can be uploaded
-    by clients, returning a HTTP 403 error with the `M_FORBIDDEN` code.
--   Clients may try to access a large number of remote files through a
-    homeserver. Homeservers should restrict the number and size of
-    remote files that it caches.
--   Clients or remote homeservers may try to upload malicious files
-    targeting vulnerabilities in either the homeserver thumbnailing or
-    the client decoders.
diff --git a/content/client-server-api/modules/device_management.md b/content/client-server-api/modules/device_management.md
deleted file mode 100644
index c27d0fc1..00000000
--- a/content/client-server-api/modules/device_management.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-type: module
----
-
-### Device Management
-
-This module provides a means for a user to manage their [devices](/#devices).
-
-#### Client behaviour
-
-Clients that implement this module should offer the user a list of
-registered devices, as well as the means to update their display names.
-Clients should also allow users to delete disused devices.
-
-{{% http-api spec="client-server" api="device_management" %}}
-
-#### Security considerations
-
-Deleting devices has security implications: it invalidates the
-access\_token assigned to the device, so an attacker could use it to log
-out the real user (and do it repeatedly every time the real user tries
-to log in to block the attacker). Servers should require additional
-authentication beyond the access token when deleting devices (for
-example, requiring that the user resubmit their password).
-
-The display names of devices are publicly visible. Clients should
-consider advising the user of this.
diff --git a/content/client-server-api/modules/dm.md b/content/client-server-api/modules/dm.md
deleted file mode 100644
index b86fde94..00000000
--- a/content/client-server-api/modules/dm.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-type: module
----
-
-### Direct Messaging
-
-All communication over Matrix happens within a room. It is sometimes
-desirable to offer users the concept of speaking directly to one
-particular person. This module defines a way of marking certain rooms as
-'direct chats' with a given person. This does not restrict the chat to
-being between exactly two people since this would preclude the presence
-of automated 'bot' users or even a 'personal assistant' who is able to
-answer direct messages on behalf of the user in their absence.
-
-A room may not necessarily be considered 'direct' by all members of the
-room, but a signalling mechanism exists to propagate the information of
-whether a chat is 'direct' to an invitee.
-
-#### Events
-
-{{% event event="m.direct" %}}
-
-#### Client behaviour
-
-To start a direct chat with another user, the inviting user's client
-should set the `is_direct` flag to [`/createRoom`](/client-server-api/#post_matrixclientv3createroom). The client should do this
-whenever the flow the user has followed is one where their intention is
-to speak directly with another person, as opposed to bringing that
-person in to a shared room. For example, clicking on 'Start Chat' beside
-a person's profile picture would imply the `is_direct` flag should be
-set.
-
-The invitee's client may use the `is_direct` flag in the
-[m.room.member](#mroommember) event to automatically mark the room as a direct chat
-but this is not required: it may for example, prompt the user, or ignore
-the flag altogether.
-
-Both the inviting client and the invitee's client should record the fact
-that the room is a direct chat by storing an `m.direct` event in the
-account data using [`/user/<user_id>/account_data/<type>`](/client-server-api/#put_matrixclientv3useruseridaccount_datatype).
-
-#### Server behaviour
-
-When the `is_direct` flag is given to [`/createRoom`](/client-server-api/#post_matrixclientv3createroom), the home server must set the
-`is_direct` flag in the invite member event for any users invited in the
-[`/createRoom`](/client-server-api/#post_matrixclientv3createroom) call.
diff --git a/content/client-server-api/modules/end_to_end_encryption.md b/content/client-server-api/modules/end_to_end_encryption.md
deleted file mode 100644
index fb94f03f..00000000
--- a/content/client-server-api/modules/end_to_end_encryption.md
+++ /dev/null
@@ -1,1712 +0,0 @@
----
-type: module
----
-
-### End-to-End Encryption
-
-Matrix optionally supports end-to-end encryption, allowing rooms to be
-created whose conversation contents are not decryptable or interceptable
-on any of the participating homeservers.
-
-#### Key Distribution
-
-Encryption and Authentication in Matrix is based around public-key
-cryptography. The Matrix protocol provides a basic mechanism for
-exchange of public keys, though an out-of-band channel is required to
-exchange fingerprints between users to build a web of trust.
-
-##### Overview
-
-1) Bob publishes the public keys and supported algorithms for his
-device. This may include long-term identity keys, and/or one-time
-keys.
-
-```
-      +----------+  +--------------+
-      | Bob's HS |  | Bob's Device |
-      +----------+  +--------------+
-            |              |
-            |<=============|
-              /keys/upload
-```
-
-2) Alice requests Bob's public identity keys and supported algorithms.
-
-```
-      +----------------+  +------------+  +----------+
-      | Alice's Device |  | Alice's HS |  | Bob's HS |
-      +----------------+  +------------+  +----------+
-             |                  |               |
-             |=================>|==============>|
-               /keys/query        <federation>
-```
-
-3) Alice selects an algorithm and claims any one-time keys needed.
-
-```
-      +----------------+  +------------+  +----------+
-      | Alice's Device |  | Alice's HS |  | Bob's HS |
-      +----------------+  +------------+  +----------+
-             |                  |               |
-             |=================>|==============>|
-               /keys/claim         <federation>
-```
-
-##### Key algorithms
-
-The name `ed25519` corresponds to the
-[Ed25519](http://ed25519.cr.yp.to/) signature algorithm. The key is a
-32-byte Ed25519 public key, encoded using [unpadded Base64](/appendices/#unpadded-base64). Example:
-
-    "SogYyrkTldLz0BXP+GYWs0qaYacUI0RleEqNT8J3riQ"
-
-The name `curve25519` corresponds to the
-[Curve25519](https://cr.yp.to/ecdh.html) ECDH algorithm. The key is a
-32-byte Curve25519 public key, encoded using [unpadded Base64](/appendices/#unpadded-base64).
-Example:
-
-    "JGLn/yafz74HB2AbPLYJWIVGnKAtqECOBf11yyXac2Y"
-
-The name `signed_curve25519` also corresponds to the Curve25519
-algorithm, but a key using this algorithm is represented by an object
-with the following properties:
-
-`KeyObject`
-
-| Parameter  | Type       | Description                                                                                                                                       |
-|------------|------------|---------------------------------------------------------------------------------------------------------------------------------------------------|
-| key        | string     | **Required.** The unpadded Base64-encoded 32-byte Curve25519 public key.                                                                          |
-| signatures | Signatures | **Required.** Signatures of the key object. The signature is calculated using the process described at [Signing JSON](/appendices/#signing-json). |
-
-Example:
-
-```json
-{
-  "key":"06UzBknVHFMwgi7AVloY7ylC+xhOhEX4PkNge14Grl8",
-  "signatures": {
-    "@user:example.com": {
-      "ed25519:EGURVBUNJP": "YbJva03ihSj5mPk+CHMJKUKlCXCPFXjXOK6VqBnN9nA2evksQcTGn6hwQfrgRHIDDXO2le49x7jnWJHMJrJoBQ"
-    }
-  }
-}
-```
-
-##### Device keys
-
-Each device should have one Ed25519 signing key. This key should be
-generated on the device from a cryptographically secure source, and the
-private part of the key should never be exported from the device. This
-key is used as the fingerprint for a device by other clients.
-
-A device will generally need to generate a number of additional keys.
-Details of these will vary depending on the messaging algorithm in use.
-
-Algorithms generally require device identity keys as well as signing
-keys. Some algorithms also require one-time keys to improve their
-secrecy and deniability. These keys are used once during session
-establishment, and are then thrown away.
-
-For Olm version 1, each device requires a single Curve25519 identity
-key, and a number of signed Curve25519 one-time keys.
-
-##### Uploading keys
-
-A device uploads the public parts of identity keys to their homeserver
-as a signed JSON object, using the [`/keys/upload`](/client-server-api/#post_matrixclientv3keysupload) API. The JSON object
-must include the public part of the device's Ed25519 key, and must be
-signed by that key, as described in [Signing
-JSON](/appendices/#signing-json).
-
-One-time and fallback keys are also uploaded to the homeserver using the
-[`/keys/upload`](/client-server-api/#post_matrixclientv3keysupload) API.
-
-{{% added-in v="1.2" %}} Fallback keys are similar to one-time keys, but
-are not consumed once used. They are only used when the device has run out
-of one-time keys, and can be replaced by a new fallback key.
-
-Devices must store the private part of each key they upload. They can
-discard the private part of a one-time key when they receive a message
-using that key. However it's possible that a one-time key given out by a
-homeserver will never be used, so the device that generates the key will
-never know that it can discard the key. Therefore a device could end up
-trying to store too many private keys. A device that is trying to store
-too many private keys may discard keys starting with the oldest.
-
-{{% boxes/warning %}}
-Fallback keys are used to prevent one-time key exhaustion when devices
-are offline/unable to upload additional keys, though sessions started using
-fallback keys could be vulnerable to replay attacks.
-{{% /boxes/warning %}}
-
-{{% boxes/warning %}}
-Clients should not store the private half of fallback keys indefinitely
-to avoid situations where attackers can decrypt past messages sent using
-that fallback key.
-
-Instead, clients should keep the private keys for at most 2 fallback keys:
-the current, unused, fallback key and the key immediately preceding it.
-Once the client is reasonably certain it has received all messages that
-used the old fallback key, such as after an hour since the first message,
-it should remove that fallback key.
-{{% /boxes/warning %}}
-
-##### Tracking the device list for a user
-
-Before Alice can send an encrypted message to Bob, she needs a list of
-each of his devices and the associated identity keys, so that she can
-establish an encryption session with each device. This list can be
-obtained by calling [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery), passing Bob's user ID in the
-`device_keys` parameter.
-
-From time to time, Bob may add new devices, and Alice will need to know
-this so that she can include his new devices for later encrypted
-messages. A naive solution to this would be to call [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery)
-before sending each message -however, the number of users and devices
-may be large and this would be inefficient.
-
-It is therefore expected that each client will maintain a list of
-devices for a number of users (in practice, typically each user with
-whom we share an encrypted room). Furthermore, it is likely that this
-list will need to be persisted between invocations of the client
-application (to preserve device verification data and to alert Alice if
-Bob suddenly gets a new device).
-
-Alice's client can maintain a list of Bob's devices via the following
-process:
-
-1.  It first sets a flag to record that it is now tracking Bob's device
-    list, and a separate flag to indicate that its list of Bob's devices
-    is outdated. Both flags should be in storage which persists over
-    client restarts.
-2.  It then makes a request to [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery), passing Bob's user ID in
-    the `device_keys` parameter. When the request completes, it stores
-    the resulting list of devices in persistent storage, and clears the
-    'outdated' flag.
-3.  During its normal processing of responses to [`/sync`](/client-server-api/#get_matrixclientv3sync), Alice's client
-    inspects the `changed` property of the [`device_lists`](/client-server-api/#extensions-to-sync-1) field. If it
-    is tracking the device lists of any of the listed users, then it
-    marks the device lists for those users outdated, and initiates
-    another request to [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery) for them.
-4.  Periodically, Alice's client stores the `next_batch` field of the
-    result from [`/sync`](/client-server-api/#get_matrixclientv3sync) in persistent storage. If Alice later restarts her
-    client, it can obtain a list of the users who have updated their
-    device list while it was offline by calling [`/keys/changes`](/client-server-api/#get_matrixclientv3keyschanges),
-    passing the recorded `next_batch` field as the `from` parameter. If
-    the client is tracking the device list of any of the users listed in
-    the response, it marks them as outdated. It combines this list with
-    those already flagged as outdated, and initiates a [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery)
-    request for all of them.
-
-{{% boxes/warning %}}
-Bob may update one of his devices while Alice has a request to
-`/keys/query` in flight. Alice's client may therefore see Bob's user ID
-in the `device_lists` field of the `/sync` response while the first
-request is in flight, and initiate a second request to `/keys/query`.
-This may lead to either of two related problems.
-
-The first problem is that, when the first request completes, the client
-will clear the 'outdated' flag for Bob's devices. If the second request
-fails, or the client is shut down before it completes, this could lead
-to Alice using an outdated list of Bob's devices.
-
-The second possibility is that, under certain conditions, the second
-request may complete *before* the first one. When the first request
-completes, the client could overwrite the later results from the second
-request with those from the first request.
-
-Clients MUST guard against these situations. For example, a client could
-ensure that only one request to `/keys/query` is in flight at a time for
-each user, by queuing additional requests until the first completes.
-Alternatively, the client could make a new request immediately, but
-ensure that the first request's results are ignored (possibly by
-cancelling the request).
-{{% /boxes/warning %}}
-
-{{% boxes/note %}}
-When Bob and Alice share a room, with Bob tracking Alice's devices, she
-may leave the room and then add a new device. Bob will not be notified
-of this change, as he doesn't share a room anymore with Alice. When they
-start sharing a room again, Bob has an out-of-date list of Alice's
-devices. In order to address this issue, Bob's homeserver will add
-Alice's user ID to the `changed` property of the `device_lists` field,
-thus Bob will update his list of Alice's devices as part of his normal
-processing. Note that Bob can also be notified when he stops sharing any
-room with Alice by inspecting the `left` property of the `device_lists`
-field, and as a result should remove her from its list of tracked users.
-{{% /boxes/note %}}
-
-##### Sending encrypted attachments
-
-When encryption is enabled in a room, files should be uploaded encrypted
-on the homeserver.
-
-In order to achieve this, a client should generate a single-use 256-bit
-AES key, and encrypt the file using AES-CTR. The counter should be
-64-bit long, starting at 0 and prefixed by a random 64-bit
-Initialization Vector (IV), which together form a 128-bit unique counter
-block.
-
-{{% boxes/warning %}}
-An IV must never be used multiple times with the same key. This implies
-that if there are multiple files to encrypt in the same message,
-typically an image and its thumbnail, the files must not share both the
-same key and IV.
-{{% /boxes/warning %}}
-
-Then, the encrypted file can be uploaded to the homeserver. The key and
-the IV must be included in the room event along with the resulting
-`mxc://` in order to allow recipients to decrypt the file. As the event
-containing those will be Megolm encrypted, the server will never have
-access to the decrypted file.
-
-A hash of the ciphertext must also be included, in order to prevent the
-homeserver from changing the file content.
-
-A client should send the data as an encrypted `m.room.message` event,
-using either `m.file` as the msgtype, or the appropriate msgtype for the
-file type. The key is sent using the [JSON Web
-Key](https://tools.ietf.org/html/rfc7517#appendix-A.3) format, with a
-[W3C extension](https://w3c.github.io/webcrypto/#iana-section-jwk).
-
-###### Extensions to `m.room.message` msgtypes
-
-This module adds `file` and `thumbnail_file` properties, of type
-`EncryptedFile`, to `m.room.message` msgtypes that reference files, such
-as [m.file](#mfile) and [m.image](#mimage), replacing the `url` and `thumbnail_url`
-properties.
-
-`EncryptedFile`
-
-| Parameter | Type             | Description                                                                                    |
-|-----------|------------------|------------------------------------------------------------------------------------------------|
-| url       | string           | **Required.** The URL to the file.                                                             |
-| key       | JWK              | **Required.** A [JSON Web Key](https://tools.ietf.org/html/rfc7517#appendix-A.3) object.       |
-| iv        | string           | **Required.** The 128-bit unique counter block used by AES-CTR, encoded as unpadded base64.    |
-| hashes    | {string: string} | **Required.** A map from an algorithm name to a hash of the ciphertext, encoded as unpadded base64. Clients should support the SHA-256 hash, which uses the key `sha256`. |
-| v         | string           | **Required.** Version of the encrypted attachments protocol. Must be `v2`.                     |
-
-`JWK`
-
-| Parameter | Type     | Description                                                                                                              |
-| --------- |----------|--------------------------------------------------------------------------------------------------------------------------|
-| kty       | string   | **Required.** Key type. Must be `oct`.                                                                                   |
-| key_ops   | [string] | **Required.** Key operations. Must at least contain `encrypt` and `decrypt`.                                             |
-| alg       | string   | **Required.** Algorithm. Must be `A256CTR`.                                                                              |
-| k         | string   | **Required.** The key, encoded as urlsafe unpadded base64.                                                               |
-| ext       | boolean  | **Required.** Extractable. Must be `true`. This is a [W3C extension](https://w3c.github.io/webcrypto/#iana-section-jwk). |
-
-Example:
-
-```json
-{
-  "content": {
-    "body": "something-important.jpg",
-    "file": {
-      "url": "mxc://example.org/FHyPlCeYUSFFxlgbQYZmoEoe",
-      "v": "v2",
-      "key": {
-        "alg": "A256CTR",
-        "ext": true,
-        "k": "aWF6-32KGYaC3A_FEUCk1Bt0JA37zP0wrStgmdCaW-0",
-        "key_ops": ["encrypt","decrypt"],
-        "kty": "oct"
-      },
-      "iv": "w+sE15fzSc0AAAAAAAAAAA",
-      "hashes": {
-        "sha256": "fdSLu/YkRx3Wyh3KQabP3rd6+SFiKg5lsJZQHtkSAYA"
-      }
-    },
-    "info": {
-      "mimetype": "image/jpeg",
-      "h": 1536,
-      "size": 422018,
-      "thumbnail_file": {
-        "hashes": {
-          "sha256": "/NogKqW5bz/m8xHgFiH5haFGjCNVmUIPLzfvOhHdrxY"
-        },
-        "iv": "U+k7PfwLr6UAAAAAAAAAAA",
-        "key": {
-          "alg": "A256CTR",
-          "ext": true,
-          "k": "RMyd6zhlbifsACM1DXkCbioZ2u0SywGljTH8JmGcylg",
-          "key_ops": ["encrypt", "decrypt"],
-          "kty": "oct"
-        },
-        "url": "mxc://example.org/pmVJxyxGlmxHposwVSlOaEOv",
-        "v": "v2"
-      },
-      "thumbnail_info": {
-        "h": 768,
-        "mimetype": "image/jpeg",
-        "size": 211009,
-        "w": 432
-      },
-      "w": 864
-    },
-    "msgtype": "m.image"
-  },
-  "event_id": "$143273582443PhrSn:example.org",
-  "origin_server_ts": 1432735824653,
-  "room_id": "!jEsUZKDJdhlrceRyVU:example.org",
-  "sender": "@example:example.org",
-  "type": "m.room.message",
-  "unsigned": {
-      "age": 1234
-  }
-}
-```
-
-##### Claiming one-time keys
-
-A client wanting to set up a session with another device can claim a
-one-time key for that device. This is done by making a request to the
-[`/keys/claim`](/client-server-api/#post_matrixclientv3keysclaim) API.
-
-A homeserver should rate-limit the number of one-time keys that a given
-user or remote server can claim. A homeserver should discard the public
-part of a one time key once it has given that key to another user.
-
-{{% added-in v="1.2" %}} If the device has run out of one-time keys which
-can be claimed, the homeserver will return the fallback key (if one was
-uploaded). Fallback keys are not deleted once used and should be replaced
-by the device when they are able to upload more one-time keys.
-
-#### Device verification
-
-Before Alice sends Bob encrypted data, or trusts data received from him,
-she may want to verify that she is actually communicating with him,
-rather than a man-in-the-middle. This verification process requires an
-out-of-band channel: there is no way to do it within Matrix without
-trusting the administrators of the homeservers.
-
-In Matrix, verification works by Alice meeting Bob in person, or
-contacting him via some other trusted medium, and using one of the
-verification methods defined below to interactively verify Bob's devices.
-Alice and Bob may also read aloud their unpadded base64 encoded Ed25519
-public key, as returned by `/keys/query`.
-
-Device verification may reach one of several conclusions. For example:
-
--   Alice may "accept" the device. This means that she is satisfied that
-    the device belongs to Bob. She can then encrypt sensitive material
-    for that device, and knows that messages received were sent from
-    that device.
--   Alice may "reject" the device. She will do this if she knows or
-    suspects that Bob does not control that device (or equivalently,
-    does not trust Bob). She will not send sensitive material to that
-    device, and cannot trust messages apparently received from it.
--   Alice may choose to skip the device verification process. She is not
-    able to verify that the device actually belongs to Bob, but has no
-    reason to suspect otherwise. The encryption protocol continues to
-    protect against passive eavesdroppers.
-
-{{% boxes/note %}}
-Once the signing key has been verified, it is then up to the encryption
-protocol to verify that a given message was sent from a device holding
-that Ed25519 private key, or to encrypt a message so that it may only be
-decrypted by such a device. For the Olm protocol, this is documented at
-<https://matrix.org/docs/olm_signing.html>.
-{{% /boxes/note %}}
-
-##### Key verification framework
-
-Verifying keys manually by reading out the Ed25519 key is not very
-user-friendly, and can lead to errors. In order to help mitigate errors,
-and to make the process easier for users, some verification methods are
-supported by the specification and use messages exchanged by the user's devices
-to assist in the verification. The methods all use a common framework
-for negotiating the key verification.
-
-Verification messages can be sent either in a room shared by the two parties,
-which should be a [direct messaging](#direct-messaging) room between the two
-parties, or by using [to-device](#send-to-device-messaging) messages sent
-directly between the two devices involved.  In both cases, the messages
-exchanged are similar, with minor differences as detailed below. Verifying
-between two different users should be performed using in-room messages, whereas
-verifying two devices belonging to the same user should be performed using
-to-device messages.
-
-A key verification session is identified by an ID that is established by the
-first message sent in that session. For verifications using in-room messages,
-the ID is the event ID of the initial message, and for verifications using
-to-device messages, the first message contains a `transaction_id` field that is
-shared by the other messages of that session.
-
-In general, verification operates as follows:
-
-- Alice requests a key verification with Bob by sending an
-  `m.key.verification.request` event. This event indicates the verification
-  methods that Alice's client supports. (Note that "Alice" and "Bob" may in
-  fact be the same user, in the case where a user is verifying their own
-  devices.)
-- Bob's client prompts Bob to accept the key verification. When Bob accepts
-  the verification, Bob's client sends an `m.key.verification.ready` event.
-  This event indicates the verification methods, corresponding to the
-  verification methods supported by Alice's client, that Bob's client supports.
-- Alice's or Bob's devices allow their users to select one of the verification
-  methods supported by both devices to use for verification. When Alice or Bob
-  selects a verification method, their device begins the verification by
-  sending an `m.key.verification.start` event, indicating the selected
-  verification method. Note that if there is only one verification method in
-  common between the devices then the receiver's device (Bob) can auto-select
-  it.
-- Alice and Bob complete the verification as defined by the selected
-  verification method. This could involve their clients exchanging messages,
-  Alice and Bob exchanging information out-of-band, and/or Alice and Bob
-  interacting with their devices.
-- Alice's and Bob's clients send `m.key.verification.done` events to indicate
-  that the verification was successful.
-
-Verifications can be cancelled by either device at any time by sending an
-`m.key.verification.cancel` event with a `code` field that indicates the reason
-it was cancelled.
-
-When using to-device messages, Alice may not know which of Bob's devices to
-verify, or may not want to choose a specific device. In this case, Alice will
-send `m.key.verification.request` events to all of Bob's devices. All of these
-events will use the same transaction ID. When Bob accepts or declines the
-verification on one of his devices (sending either an
-`m.key.verification.ready` or `m.key.verification.cancel` event), Alice will
-send an `m.key.verification.cancel` event to Bob's other devices with a `code`
-of `m.accepted` in the case where Bob accepted the verification, or `m.user` in
-the case where Bob rejected the verification. This yields the following
-handshake when using to-device messages, assuming both Alice and Bob each have
-2 devices, Bob's first device accepts the key verification request, and Alice's
-second device initiates the request. Note how Alice's first device is not
-involved in the request or verification process. Also note that, although in
-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.
-
-```
-    +---------------+ +---------------+                    +-------------+ +-------------+
-    | AliceDevice1  | | AliceDevice2  |                    | BobDevice1  | | BobDevice2  |
-    +---------------+ +---------------+                    +-------------+ +-------------+
-            |                 |                                   |               |
-            |                 | m.key.verification.request        |               |
-            |                 |---------------------------------->|               |
-            |                 |                                   |               |
-            |                 | m.key.verification.request        |               |
-            |                 |-------------------------------------------------->|
-            |                 |                                   |               |
-            |                 |          m.key.verification.ready |               |
-            |                 |<----------------------------------|               |
-            |                 |                                   |               |
-            |                 | m.key.verification.cancel         |               |
-            |                 |-------------------------------------------------->|
-            |                 |                                   |               |
-            |                 |          m.key.verification.start |               |
-            |                 |<----------------------------------|               |
-            |                 |                                   |               |
-            .
-            .                       (verification messages)
-            .
-            |                 |                                   |               |
-            |                 |           m.key.verification.done |               |
-            |                 |<----------------------------------|               |
-            |                 |                                   |               |
-            |                 | m.key.verification.done           |               |
-            |                 |---------------------------------->|               |
-            |                 |                                   |               |
-```
-
-When using in-room messages and the room has encryption enabled, clients should
-ensure that encryption does not hinder the verification. For example, if the
-verification messages are encrypted, clients must ensure that all the
-recipient's unverified devices receive the keys necessary to decrypt the
-messages, even if they would normally not be given the keys to decrypt messages
-in the room. Alternatively, verification messages may be sent unencrypted,
-though this is not encouraged.
-
-Upon receipt of Alice's `m.key.verification.request` message, if Bob's device
-does not understand any of the methods, it should not cancel the request as one
-of his other devices may support the request. Instead, Bob's device should tell
-Bob that no supported method was found, and allow him to manually reject the
-request.
-
-The prompt for Bob to accept/reject Alice's request (or the unsupported method
-prompt) should be automatically dismissed 10 minutes after the `timestamp` (in
-the case of to-device messages) or `origin_ts` (in the case of in-room
-messages) field or 2 minutes after Bob's client receives the message, whichever
-comes first, if Bob does not interact with the prompt. The prompt should
-additionally be hidden if an appropriate `m.key.verification.cancel` message is
-received.
-
-If Bob rejects the request, Bob's client must send an
-`m.key.verification.cancel` event with `code` set to `m.user`. Upon receipt,
-Alice's device should tell her that Bob does not want to verify her device and,
-if the request was sent as a to-device message, send
-`m.key.verification.cancel` messages to all of Bob's devices to notify them
-that the request was rejected.
-
-If Alice's and Bob's clients both send an `m.key.verification.start` message,
-and both specify the same verification method, then the
-`m.key.verification.start` message sent by the user whose ID is the
-lexicographically largest user ID should be ignored, and the situation should
-be treated the same as if only the user with the lexicographically smallest
-user ID had sent the `m.key.verification.start` message.  In the case where the
-user IDs are the same (that is, when a user is verifying their own device),
-then the device IDs should be compared instead.  If the two
-`m.key.verification.start` messages do not specify the same verification
-method, then the verification should be cancelled with a `code` of
-`m.unexpected_message`.
-
-An `m.key.verification.start` message can also be sent independently of any
-request, specifying the verification method to use. This behaviour is
-deprecated, and new clients should not begin verifications in this way.
-However, clients should handle such verifications started by other clients.
-
-Individual verification methods may add additional steps, events, and
-properties to the verification messages. Event types for methods defined
-in this specification must be under the `m.key.verification` namespace
-and any other event types must be namespaced according to the Java
-package naming convention.
-
-{{% event event="m.key.verification.request" %}}
-
-{{% event event="m.key.verification.ready" %}}
-
-{{% event event="m.key.verification.start" %}}
-
-{{% event event="m.key.verification.done" %}}
-
-{{% event event="m.key.verification.cancel" %}}
-
-##### Short Authentication String (SAS) verification
-
-SAS verification is a user-friendly key verification process built off
-the common framework outlined above. SAS verification is intended to be
-a highly interactive process for users, and as such exposes verification
-methods which are easier for users to use.
-
-The verification process is heavily inspired by Phil Zimmermann's ZRTP
-key agreement handshake. A key part of key agreement in ZRTP is the hash
-commitment: the party that begins the Diffie-Hellman key sharing sends a
-hash of their part of the Diffie-Hellman exchange, and does not send
-their part of the Diffie-Hellman exchange until they have received the
-other party's part. Thus an attacker essentially only has one attempt to
-attack the Diffie-Hellman exchange, and hence we can verify fewer bits
-while still achieving a high degree of security: if we verify n bits,
-then an attacker has a 1 in 2<sup>n</sup> chance of success. For
-example, if we verify 40 bits, then an attacker has a 1 in
-1,099,511,627,776 chance (or less than 1 in 10<sup>12</sup> chance) of
-success. A failed attack would result in a mismatched Short
-Authentication String, alerting users to the attack.
-
-To advertise support for this method, clients use the name `m.sas.v1` in the
-`methods` fields of the `m.key.verification.request` and
-`m.key.verification.ready` events.
-
-The verification process takes place in two phases:
-
-1.  Key agreement phase (based on [ZRTP key
-    agreement](https://tools.ietf.org/html/rfc6189#section-4.4.1)).
-2.  Key verification phase (based on HMAC).
-
-The process between Alice and Bob verifying each other would be:
-
-1.  Alice and Bob establish a secure out-of-band connection, such as
-    meeting in-person or a video call. "Secure" here means that either
-    party cannot be impersonated, not explicit secrecy.
-2.  Alice and Bob begin a key verification using the key verification
-    framework as described above.
-3.  Alice's device sends Bob's device an `m.key.verification.start`
-    message. Alice's device ensures it has a copy of Bob's device key.
-4.  Bob's device receives the message and selects a key agreement
-    protocol, hash algorithm, message authentication code, and SAS
-    method supported by Alice's device.
-5.  Bob's device ensures it has a copy of Alice's device key.
-6.  Bob's device creates an ephemeral Curve25519 key pair
-    (*K<sub>B</sub><sup>private</sup>*, *K<sub>B</sub><sup>public</sup>*),
-    and calculates the hash (using the chosen algorithm) of the public
-    key *K<sub>B</sub><sup>public</sup>*.
-7.  Bob's device replies to Alice's device with an
-    `m.key.verification.accept` message.
-8.  Alice's device receives Bob's message and stores the commitment hash
-    for later use.
-9.  Alice's device creates an ephemeral Curve25519 key pair
-    (*K<sub>A</sub><sup>private</sup>*, *K<sub>A</sub><sup>public</sup>*)
-    and replies to Bob's device with an `m.key.verification.key`,
-    sending only the public key
-    *K<sub>A</sub><sup>public</sup>*.
-10. Bob's device receives Alice's message and replies with its own
-    `m.key.verification.key` message containing its public key
-    *K<sub>B</sub><sup>public</sup>*.
-11. Alice's device receives Bob's message and verifies the commitment
-    hash from earlier matches the hash of the key Bob's device just sent
-    and the content of Alice's `m.key.verification.start` message.
-12. Both Alice and Bob's devices perform an Elliptic-curve
-    Diffie-Hellman
-    (*ECDH(K<sub>A</sub><sup>private</sup>*, *K<sub>B</sub><sup>public</sup>*)),
-    using the result as the shared secret.
-13. Both Alice and Bob's devices display a SAS to their users, which is
-    derived from the shared key using one of the methods in this
-    section. If multiple SAS methods are available, clients should allow
-    the users to select a method.
-14. Alice and Bob compare the strings shown by their devices, and tell
-    their devices if they match or not.
-15. Assuming they match, Alice and Bob's devices calculate the HMAC of
-    their own device keys and a comma-separated sorted list of the key
-    IDs that they wish the other user to verify, using SHA-256 as the
-    hash function. HMAC is defined in [RFC
-    2104](https://tools.ietf.org/html/rfc2104). The key for the HMAC is
-    different for each item and is calculated by generating 32 bytes
-    (256 bits) using [the key verification HKDF](#hkdf-calculation).
-16. Alice's device sends Bob's device an `m.key.verification.mac`
-    message containing the MAC of Alice's device keys and the MAC of her
-    key IDs to be verified. Bob's device does the same for Bob's device
-    keys and key IDs concurrently with Alice.
-17. When the other device receives the `m.key.verification.mac` message,
-    the device calculates the HMAC of its copies of the other device's
-    keys given in the message, as well as the HMAC of the
-    comma-separated, sorted, list of key IDs in the message. The device
-    compares these with the HMAC values given in the message, and if
-    everything matches then the device keys are verified.
-18. Alice and Bob's devices send `m.key.verification.done` messages to complete
-    the verification.
-
-The wire protocol looks like the following between Alice and Bob's
-devices:
-
-```
-    +-------------+                    +-----------+
-    | AliceDevice |                    | BobDevice |
-    +-------------+                    +-----------+
-          |                                 |
-          | m.key.verification.start        |
-          |-------------------------------->|
-          |                                 |
-          |       m.key.verification.accept |
-          |<--------------------------------|
-          |                                 |
-          | m.key.verification.key          |
-          |-------------------------------->|
-          |                                 |
-          |          m.key.verification.key |
-          |<--------------------------------|
-          |                                 |
-          | m.key.verification.mac          |
-          |-------------------------------->|
-          |                                 |
-          |          m.key.verification.mac |
-          |<--------------------------------|
-          |                                 |
-```
-
-###### Error and exception handling
-
-At any point the interactive verification can go wrong. The following
-describes what to do when an error happens:
-
--   Alice or Bob can cancel the verification at any time. An
-    `m.key.verification.cancel` message must be sent to signify the
-    cancellation.
--   The verification can time out. Clients should time out a
-    verification that does not complete within 10 minutes. Additionally,
-    clients should expire a `transaction_id` which goes unused for 10
-    minutes after having last sent/received it. The client should inform
-    the user that the verification timed out, and send an appropriate
-    `m.key.verification.cancel` message to the other device.
--   When the same device attempts to initiate multiple verification
-    attempts, the recipient should cancel all attempts with that device.
--   When a device receives an unknown `transaction_id`, it should send
-    an appropriate `m.key.verification.cancel` message to the other
-    device indicating as such. This does not apply for inbound
-    `m.key.verification.start` or `m.key.verification.cancel` messages.
--   If the two devices do not share a common key share, hash, HMAC, or
-    SAS method then the device should notify the other device with an
-    appropriate `m.key.verification.cancel` message.
--   If the user claims the Short Authentication Strings do not match,
-    the device should send an appropriate `m.key.verification.cancel`
-    message to the other device.
--   If the device receives a message out of sequence or that it was not
-    expecting, it should notify the other device with an appropriate
-    `m.key.verification.cancel` message.
-
-###### Verification messages specific to SAS
-
-Building off the common framework, the following events are involved in
-SAS verification.
-
-The `m.key.verification.cancel` event is unchanged, however the
-following error codes are used in addition to those already specified:
-
--   `m.unknown_method`: The devices are unable to agree on the key
-    agreement, hash, MAC, or SAS method.
--   `m.mismatched_commitment`: The hash commitment did not match.
--   `m.mismatched_sas`: The SAS did not match.
-
-{{% event event="m.key.verification.start$m.sas.v1" %}}
-
-{{% event event="m.key.verification.accept" %}}
-
-{{% event event="m.key.verification.key" %}}
-
-{{% event event="m.key.verification.mac" %}}
-
-###### HKDF calculation
-
-In all of the SAS methods, HKDF is as defined in [RFC
-5869](https://tools.ietf.org/html/rfc5869) and uses the previously
-agreed-upon hash function for the hash function. The shared secret is
-supplied as the input keying material. No salt is used. When the
-`key_agreement_protocol` is `curve25519-hkdf-sha256`, the info parameter
-is the concatenation of:
-
--   The string `MATRIX_KEY_VERIFICATION_SAS|`.
--   The Matrix ID of the user who sent the `m.key.verification.start`
-    message, followed by `|`.
--   The Device ID of the device which sent the
-    `m.key.verification.start` message, followed by `|`.
--   The public key from the `m.key.verification.key` message sent by
-    the device which sent the `m.key.verification.start` message,
-    followed by `|`.
--   The Matrix ID of the user who sent the `m.key.verification.accept`
-    message, followed by `|`.
--   The Device ID of the device which sent the
-    `m.key.verification.accept` message, followed by `|`.
--   The public key from the `m.key.verification.key` message sent by
-    the device which sent the `m.key.verification.accept` message,
-    followed by `|`.
--   The `transaction_id` being used.
-
-When the `key_agreement_protocol` is the deprecated method `curve25519`,
-the info parameter is the concatenation of:
-
--   The string `MATRIX_KEY_VERIFICATION_SAS`.
--   The Matrix ID of the user who sent the `m.key.verification.start`
-    message.
--   The Device ID of the device which sent the
-    `m.key.verification.start` message.
--   The Matrix ID of the user who sent the `m.key.verification.accept`
-    message.
--   The Device ID of the device which sent the
-    `m.key.verification.accept` message.
--   The `transaction_id` being used.
-
-New implementations are discouraged from implementing the `curve25519`
-method.
-
-{{% boxes/rationale %}}
-HKDF is used over the plain shared secret as it results in a harder
-attack as well as more uniform data to work with.
-{{% /boxes/rationale %}}
-
-For verification of each party's device keys, HKDF is as defined in RFC
-5869 and uses SHA-256 as the hash function. The shared secret is
-supplied as the input keying material. No salt is used, and in the info
-parameter is the concatenation of:
-
--   The string `MATRIX_KEY_VERIFICATION_MAC`.
--   The Matrix ID of the user whose key is being MAC-ed.
--   The Device ID of the device sending the MAC.
--   The Matrix ID of the other user.
--   The Device ID of the device receiving the MAC.
--   The `transaction_id` being used.
--   The Key ID of the key being MAC-ed, or the string `KEY_IDS` if the
-    item being MAC-ed is the list of key IDs.
-
-###### SAS method: `decimal`
-
-Generate 5 bytes using [HKDF](#hkdf-calculation) then take sequences of 13 bits
-to convert to decimal numbers (resulting in 3 numbers between 0 and 8191
-inclusive each). Add 1000 to each calculated number.
-
-The bitwise operations to get the numbers given the 5 bytes
-*B<sub>0</sub>*, *B<sub>1</sub>*, *B<sub>2</sub>*, *B<sub>3</sub>*, *B<sub>4</sub>*
-would be:
-
--   First: (*B<sub>0</sub>* ≪ 5|*B<sub>1</sub>* ≫ 3) + 1000
--   Second:
-    ((*B<sub>1</sub>*&0x7) ≪ 10|*B<sub>2</sub>* ≪ 2|*B<sub>3</sub>* ≫ 6) + 1000
--   Third: ((*B<sub>3</sub>*&0x3F) ≪ 7|*B<sub>4</sub>* ≫ 1) + 1000
-
-The digits are displayed to the user either with an appropriate
-separator, such as dashes, or with the numbers on individual lines.
-
-###### SAS method: `emoji`
-
-Generate 6 bytes using [HKDF](#hkdf-calculation) then split the first 42 bits
-into 7 groups of 6 bits, similar to how one would base64 encode
-something. Convert each group of 6 bits to a number and use the
-following table to get the corresponding emoji:
-
-{{% sas-emojis %}}
-
-{{% boxes/note %}}
-This table is available as JSON at
-<https://github.com/matrix-org/matrix-doc/blob/master/data-definitions/sas-emoji.json>
-{{% /boxes/note %}}
-
-{{% boxes/rationale %}}
-The emoji above were chosen to:
-
--   Be recognisable without colour.
--   Be recognisable at a small size.
--   Be recognisable by most cultures.
--   Be distinguishable from each other.
--   Easily described by a few words.
--   Avoid symbols with negative connotations.
--   Be likely similar across multiple platforms.
-{{% /boxes/rationale %}}
-
-Clients SHOULD show the emoji with the descriptions from the table, or
-appropriate translation of those descriptions. Client authors SHOULD
-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/>
-and can be translated online:
-<https://translate.riot.im/projects/matrix-doc/sas-emoji-v1>
-{{% /boxes/note %}}
-
-##### Cross-signing
-
-Rather than requiring Alice to verify each of Bob's devices with each of
-her own devices and vice versa, the cross-signing feature allows users
-to sign their device keys such that Alice and Bob only need to verify
-once. With cross-signing, each user has a set of cross-signing keys that
-are used to sign their own device keys and other users' keys, and can be
-used to trust device keys that were not verified directly.
-
-Each user has three ed25519 key pairs for cross-signing:
-
--   a master key (MSK) that serves as the user's identity in
-    cross-signing and signs their other cross-signing keys;
--   a user-signing key (USK) -- only visible to the user that it belongs
-    to --that signs other users' master keys; and
--   a self-signing key (SSK) that signs the user's own device keys.
-
-The master key may also be used to sign other items such as the backup
-key. The master key may also be signed by the user's own device keys to
-aid in migrating from device verifications: if Alice's device had
-previously verified Bob's device and Bob's device has signed his master
-key, then Alice's device can trust Bob's master key, and she can sign it
-with her user-signing key.
-
-Users upload their cross-signing keys to the server using [POST
-/\_matrix/client/v3/keys/device\_signing/upload](/client-server-api/#post_matrixclientv3keysdevice_signingupload). When Alice uploads
-new cross-signing keys, her user ID will appear in the `changed`
-property of the `device_lists` field of the `/sync` of response of all
-users who share an encrypted room with her. When Bob sees Alice's user
-ID in his `/sync`, he will call [POST /\_matrix/client/v3/keys/query](/client-server-api/#post_matrixclientv3keysquery)
-to retrieve Alice's device and cross-signing keys.
-
-If Alice has a device and wishes to send an encrypted message to Bob,
-she can trust Bob's device if:
-
--   Alice's device is using a master key that has signed her
-    user-signing key,
--   Alice's user-signing key has signed Bob's master key,
--   Bob's master key has signed Bob's self-signing key, and
--   Bob's self-signing key has signed Bob's device key.
-
-The following diagram illustrates how keys are signed:
-
-```
-    +------------------+                ..................   +----------------+
-    | +--------------+ |   ..................            :   | +------------+ |
-    | |              v v   v            :   :            v   v v            | |
-    | |           +-----------+         :   :         +-----------+         | |
-    | |           | Alice MSK |         :   :         |  Bob MSK  |         | |
-    | |           +-----------+         :   :         +-----------+         | |
-    | |             |       :           :   :           :       |           | |
-    | |          +--+       :...        :   :        ...:       +--+        | |
-    | |          v             v        :   :        v             v        | |
-    | |    +-----------+ .............  :   :  ............. +-----------+  | |
-    | |    | Alice SSK | : Alice USK :  :   :  :  Bob USK  : |  Bob SSK  |  | |
-    | |    +-----------+ :...........:  :   :  :...........: +-----------+  | |
-    | |      |  ...  |         :        :   :        :         |  ...  |    | |
-    | |      V       V         :........:   :........:         V       V    | |
-    | | +---------+   -+                                  +---------+   -+  | |
-    | | | Devices | ...|                                  | Devices | ...|  | |
-    | | +---------+   -+                                  +---------+   -+  | |
-    | |      |  ...  |                                         |  ...  |    | |
-    | +------+       |                                         |       +----+ |
-    +----------------+                                         +--------------+
-```
-
-In the diagram, boxes represent keys and lines represent signatures with
-the arrows pointing from the signing key to the key being signed. Dotted
-boxes and lines represent keys and signatures that are only visible to
-the user who created them.
-
-The following diagram illustrates Alice's view, hiding the keys and
-signatures that she cannot see:
-
-```
-    +------------------+                +----------------+   +----------------+
-    | +--------------+ |                |                |   | +------------+ |
-    | |              v v                |                v   v v            | |
-    | |           +-----------+         |             +-----------+         | |
-    | |           | Alice MSK |         |             |  Bob MSK  |         | |
-    | |           +-----------+         |             +-----------+         | |
-    | |             |       |           |                       |           | |
-    | |          +--+       +--+        |                       +--+        | |
-    | |          v             v        |                          v        | |
-    | |    +-----------+ +-----------+  |                    +-----------+  | |
-    | |    | Alice SSK | | Alice USK |  |                    |  Bob SSK  |  | |
-    | |    +-----------+ +-----------+  |                    +-----------+  | |
-    | |      |  ...  |         |        |                      |  ...  |    | |
-    | |      V       V         +--------+                      V       V    | |
-    | | +---------+   -+                                  +---------+   -+  | |
-    | | | Devices | ...|                                  | Devices | ...|  | |
-    | | +---------+   -+                                  +---------+   -+  | |
-    | |      |  ...  |                                         |  ...  |    | |
-    | +------+       |                                         |       +----+ |
-    +----------------+                                         +--------------+
-```
-
-[Verification methods](#device-verification) can be used to verify a
-user's master key by using the master public key, encoded using unpadded
-base64, as the device ID, and treating it as a normal device. For
-example, if Alice and Bob verify each other using SAS, Alice's
-`m.key.verification.mac` message to Bob may include
-`"ed25519:alices+master+public+key": "alices+master+public+key"` in the
-`mac` property. Servers therefore must ensure that device IDs will not
-collide with cross-signing public keys.
-
-The cross-signing private keys can be stored on the server or shared with other
-devices using the [Secrets](#secrets) module.  When doing so, the master,
-user-signing, and self-signing keys are identified using the names
-`m.cross_signing.master`, `m.cross_signing.user_signing`, and
-`m.cross_signing.self_signing`, respectively, and the keys are base64-encoded
-before being encrypted.
-
-###### Key and signature security
-
-A user's master key could allow an attacker to impersonate that user to
-other users, or other users to that user. Thus clients must ensure that
-the private part of the master key is treated securely. If clients do
-not have a secure means of storing the master key (such as a secret
-storage system provided by the operating system), then clients must not
-store the private part.
-
-If a user's client sees that any other user has changed their master
-key, that client must notify the user about the change before allowing
-communication between the users to continue.
-
-A user's user-signing and self-signing keys are intended to be easily
-replaceable if they are compromised by re-issuing a new key signed by
-the user's master key and possibly by re-verifying devices or users.
-However, doing so relies on the user being able to notice when their
-keys have been compromised, and it involves extra work for the user, and
-so although clients do not have to treat the private parts as
-sensitively as the master key, clients should still make efforts to
-store the private part securely, or not store it at all. Clients will
-need to balance the security of the keys with the usability of signing
-users and devices when performing key verification.
-
-To avoid leaking of social graphs, servers will only allow users to see:
-
--   signatures made by the user's own master, self-signing or
-    user-signing keys,
--   signatures made by the user's own devices about their own master
-    key,
--   signatures made by other users' self-signing keys about their
-    respective devices,
--   signatures made by other users' master keys about their respective
-    self-signing key, or
--   signatures made by other users' devices about their respective
-    master keys.
-
-Users will not be able to see signatures made by other users'
-user-signing keys.
-
-{{% http-api spec="client-server" api="cross_signing" %}}
-
-##### QR codes
-
-{{% added-in v="1.1" %}}
-
-Verifying by QR codes provides a quick way to verify when one of the parties
-has a device capable of scanning a QR code. The QR code encodes both parties'
-master signing keys as well as a random shared secret that is used to allow
-bi-directional verification from a single scan.
-
-To advertise the ability to show a QR code, clients use the names
-`m.qr_code.show.v1` and `m.reciprocate.v1` in the `methods` fields of the
-`m.key.verification.request` and `m.key.verification.ready` events. To
-advertise the ability to scan a QR code, clients use the names
-`m.qr_code.scan.v1` and `m.reciprocate.v1` in the `methods` fields of the
-`m.key.verification.request` and `m.key.verification.ready` events.
-Clients that support both showing and scanning QR codes would advertise
-`m.qr_code.show.v1`, `m.qr_code.scan.v1`, and `m.reciprocate.v1` as
-methods.
-
-The process between Alice and Bob verifying each other would be:
-
-1. Alice and Bob meet in person, and want to verify each other's keys.
-2. Alice and Bob begin a key verification using the key verification
-   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 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,
-   can be presented alongside the QR code if the devices have appropriate
-   support.
-5. Alice scans Bob's QR code.
-6. Alice's device ensures that the keys encoded in the QR code match the
-   expected values for the keys. If not, Alice's device displays an error
-   message indicating that the code is incorrect, and sends a
-   `m.key.verification.cancel` message to Bob's device.
-
-   Otherwise, at this point:
-   - Alice's device has now verified Bob's key, and
-   - Alice's device knows that Bob has the correct key for her.
-
-   Thus for Bob to verify Alice's key, Alice needs to tell Bob that he has the
-   right key.
-7. Alice's device displays a message saying that the verification was
-   successful because the QR code's keys will have matched the keys
-   expected for Bob. Bob's device hasn't had a chance to verify Alice's
-   keys yet so wouldn't show the same message. Bob will know that
-   he has the right key for Alice because Alice's device will have shown
-   this message, as otherwise the verification would be cancelled.
-8. Alice's device sends an `m.key.verification.start` message with `method` set
-   to `m.reciprocate.v1` to Bob (see below).  The message includes the shared
-   secret from the QR code.  This signals to Bob's device that Alice has
-   scanned Bob's QR code.
-
-   This message is merely a signal for Bob's device to proceed to the next
-   step, and is not used for verification purposes.
-9. Upon receipt of the `m.key.verification.start` message, Bob's device ensures
-   that the shared secret matches.
-
-   If the shared secret does not match, it should display an error message
-   indicating that an attack was attempted.  (This does not affect Alice's
-   verification of Bob's keys.)
-
-   If the shared secret does match, it asks Bob to confirm that Alice
-   has scanned the QR code.
-10. Bob sees Alice's device confirm that the key matches, and presses the button
-    on his device to indicate that Alice's key is verified.
-
-    Bob's verification of Alice's key hinges on Alice telling Bob the result of
-    her scan.  Since the QR code includes what Bob thinks Alice's key is,
-    Alice's device can check whether Bob has the right key for her.  Alice has
-    no motivation to lie about the result, as getting Bob to trust an incorrect
-    key would only affect communications between herself and Bob.  Thus Alice
-    telling Bob that the code was scanned successfully is sufficient for Bob to
-    trust Alice's key, under the assumption that this communication is done
-    over a trusted medium (such as in-person).
-11. Both devices send an `m.key.verification.done` message.
-
-###### QR code format
-
-The QR codes to be displayed and scanned using this format will encode binary
-strings in the general form:
-
-- the ASCII string `MATRIX`
-- one byte indicating the QR code version (must be `0x02`)
-- one byte indicating the QR code verification mode.  Should be one of the
-  following values:
-  - `0x00` verifying another user with cross-signing
-  - `0x01` self-verifying in which the current device does trust the master key
-  - `0x02` self-verifying in which the current device does not yet trust the
-    master key
-- the event ID or `transaction_id` of the associated verification
-  request event, encoded as:
-  - two bytes in network byte order (big-endian) indicating the length in
-    bytes of the ID as a UTF-8 string
-  - the ID as a UTF-8 string
-- the first key, as 32 bytes.  The key to use depends on the mode field:
-  - if `0x00` or `0x01`, then the current user's own master cross-signing public key
-  - if `0x02`, then the current device's device key
-- the second key, as 32 bytes.  The key to use depends on the mode field:
-  - if `0x00`, then what the device thinks the other user's master
-    cross-signing key is
-  - if `0x01`, then what the device thinks the other device's device key is
-  - if `0x02`, then what the device thinks the user's master cross-signing key
-    is
-- a random shared secret, as a byte string.  It is suggested to use a secret
-  that is about 8 bytes long.  Note: as we do not share the length of the
-  secret, and it is not a fixed size, clients will just use the remainder of
-  binary string as the shared secret.
-
-For example, if Alice displays a QR code encoding the following binary string:
-
-```
-      "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
-  00 01 02 03 04 05 06 07 ...   10 11 12 13 14 15 16 17 ...      20 21 22 23 24 25 26 27
-```
-
-this indicates that Alice is verifying another user (say Bob), in response to
-the request from event "$ABCD...", her cross-signing key is
-`0001020304050607...` (which is "AAECAwQFBg..." in base64), she thinks that
-Bob's cross-signing key is `1011121314151617...` (which is "EBESExQVFh..." in
-base64), and the shared secret is `2021222324252627` (which is "ICEiIyQlJic" in
-base64).
-
-###### Verification messages specific to QR codes
-
-{{% event event="m.key.verification.start$m.reciprocate.v1" %}}
-
-#### Sharing keys between devices
-
-If Bob has an encrypted conversation with Alice on his computer, and
-then logs in through his phone for the first time, he may want to have
-access to the previously exchanged messages. To address this issue,
-several methods are provided to allow users to transfer keys from one
-device to another.
-
-##### Key requests
-
-When a device is missing keys to decrypt messages, it can request the
-keys by sending [m.room\_key\_request](#mroom_key_request) to-device messages to other
-devices with `action` set to `request`.
-
-If a device wishes to share the keys with that device, it can forward
-the keys to the first device by sending an encrypted
-[m.forwarded\_room\_key](#mforwarded_room_key) to-device message. The first device should
-then send an [m.room\_key\_request](#mroom_key_request) to-device message with `action`
-set to `request_cancellation` to the other devices that it had
-originally sent the key request to; a device that receives a
-`request_cancellation` should disregard any previously-received
-`request` message with the same `request_id` and `requesting_device_id`.
-
-If a device does not wish to share keys with that device, it can
-indicate this by sending an [m.room\_key.withheld](#mroom_keywithheld) to-device message,
-as described in [Reporting that decryption keys are
-withheld](#reporting-that-decryption-keys-are-withheld).
-
-{{% boxes/note %}}
-Key sharing can be a big attack vector, thus it must be done very
-carefully. A reasonable strategy is for a user's client to only send
-keys requested by the verified devices of the same user.
-{{% /boxes/note %}}
-
-##### Server-side key backups
-
-Devices may upload encrypted copies of keys to the server. When a device
-tries to read a message that it does not have keys for, it may request
-the key from the server and decrypt it. Backups are per-user, and users
-may replace backups with new backups.
-
-In contrast with [Key requests](#key-requests), Server-side key backups
-do not require another device to be online from which to request keys.
-However, as the session keys are stored on the server encrypted, it
-requires users to enter a decryption key to decrypt the session keys.
-
-To create a backup, a client will call [POST
-/\_matrix/client/v3/room\_keys/version](#post_matrixclientv3room_keysversion) and define how the keys are to
-be encrypted through the backup's `auth_data`; other clients can
-discover the backup by calling [GET
-/\_matrix/client/v3/room\_keys/version](#get_matrixclientv3room_keysversion). Keys are encrypted according
-to the backup's `auth_data` and added to the backup by calling [PUT
-/\_matrix/client/v3/room\_keys/keys](#put_matrixclientv3room_keyskeys) or one of its variants, and can
-be retrieved by calling [GET /\_matrix/client/v3/room\_keys/keys](#get_matrixclientv3room_keyskeys) or
-one of its variants. Keys can only be written to the most recently
-created version of the backup. Backups can also be deleted using [DELETE
-/\_matrix/client/v3/room\_keys/version/{version}](#delete_matrixclientv3room_keysversionversion), or individual keys
-can be deleted using [DELETE /\_matrix/client/v3/room\_keys/keys](#delete_matrixclientv3room_keyskeys) or
-one of its variants.
-
-Clients must only store keys in backups after they have ensured that the
-`auth_data` is trusted, either by checking the signatures on it, or by
-deriving the public key from a private key that it obtained from a
-trusted source.
-
-When a client uploads a key for a session that the server already has a
-key for, the server will choose to either keep the existing key or
-replace it with the new key based on the key metadata as follows:
-
--   if the keys have different values for `is_verified`, then it will
-    keep the key that has `is_verified` set to `true`;
--   if they have the same values for `is_verified`, then it will keep
-    the key with a lower `first_message_index`;
--   and finally, is `is_verified` and `first_message_index` are equal,
-    then it will keep the key with a lower `forwarded_count`.
-
-###### Recovery key
-
-If the recovery key (the private half of the backup encryption key) is
-presented to the user to save, it is presented as a string constructed
-as follows:
-
-1.  The 256-bit curve25519 private key is prepended by the bytes `0x8B`
-    and `0x01`
-2.  All the bytes in the string above, including the two header bytes,
-    are XORed together to form a parity byte. This parity byte is
-    appended to the byte string.
-3.  The byte string is encoded using base58, using the same [mapping as
-    is used for Bitcoin
-    addresses](https://en.bitcoin.it/wiki/Base58Check_encoding#Base58_symbol_chart),
-    that is, using the alphabet
-    `123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz`.
-4.  A space should be added after every 4th character.
-
-When reading in a recovery key, clients must disregard whitespace, and
-perform the reverse of steps 1 through 3.
-
-The recovery key can also be stored on the server or shared with other devices
-using the [Secrets](#secrets) module. When doing so, it is identified using the
-name `m.megolm_backup.v1`, and the key is base64-encoded before being
-encrypted.
-
-###### Backup algorithm: `m.megolm_backup.v1.curve25519-aes-sha2`
-
-When a backup is created with the `algorithm` set to
-`m.megolm_backup.v1.curve25519-aes-sha2`, the `auth_data` should have
-the following format:
-
-`AuthData`
-
-| Parameter  | Type       | Description                                                                                      |
-| -----------| -----------|--------------------------------------------------------------------------------------------------|
-| public_key | string     | **Required.** The curve25519 public key used to encrypt the backups, encoded in unpadded base64. |
-| signatures | Signatures | Optional. Signatures of the ``auth_data``, as Signed JSON                                        |
-
-The `session_data` field in the backups is constructed as follows:
-
-1.  Encode the session key to be backed up as a JSON object with the
-    properties:
-
-| Parameter                       | Type              | Description                                                                                                                                                                 |
-| --------------------------------|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| algorithm                       | string            | **Required.** The end-to-end message encryption algorithm that the key is for.  Must be `m.megolm.v1.aes-sha2`.                                                             |
-| forwarding_curve25519_key_chain | [string]          | **Required.** Chain of Curve25519 keys through which this session was forwarded, via [m.forwarded_room_key](#mforwarded_room_key) events.                                   |
-| sender_key                      | string            | **Required.** Unpadded base64-encoded device curve25519 key.                                                                                                                |
-| sender_claimed_keys             | {string: string}  | **Required.** A map from algorithm name (`ed25519`) to the identity key for the sending device.                                                                             |
-| session_key                     | string            | **Required.** Unpadded base64-encoded session key in [session-sharing format](https://gitlab.matrix.org/matrix-org/olm/blob/master/docs/megolm.md#session-sharing-format).  |
-
-2.  Generate an ephemeral curve25519 key, and perform an ECDH with the
-    ephemeral key and the backup's public key to generate a shared
-    secret. The public half of the ephemeral key, encoded using unpadded
-    base64, becomes the `ephemeral` property of the `session_data`.
-
-3.  Using the shared secret, generate 80 bytes by performing an HKDF
-    using SHA-256 as the hash, with a salt of 32 bytes of 0, and with
-    the empty string as the info. The first 32 bytes are used as the AES
-    key, the next 32 bytes are used as the MAC key, and the last 16
-    bytes are used as the AES initialization vector.
-
-4.  Stringify the JSON object, and encrypt it using AES-CBC-256 with
-    PKCS\#7 padding. This encrypted data, encoded using unpadded base64,
-    becomes the `ciphertext` property of the `session_data`.
-
-5.  Pass the raw encrypted data (prior to base64 encoding) through
-    HMAC-SHA-256 using the MAC key generated above. The first 8 bytes of
-    the resulting MAC are base64-encoded, and become the `mac` property
-    of the `session_data`.
-
-{{% http-api spec="client-server" api="key_backup" %}}
-
-##### Key exports
-
-Keys can be manually exported from one device to an encrypted file,
-copied to another device, and imported. The file is encrypted using a
-user-supplied passphrase, and is created as follows:
-
-1.  Encode the sessions as a JSON object, formatted as described in [Key
-    export format](#key-export-format).
-
-2.  Generate a 512-bit key from the user-entered passphrase by computing
-    [PBKDF2](https://tools.ietf.org/html/rfc2898#section-5.2)(HMAC-SHA-512,
-    passphrase, S, N, 512), where S is a 128-bit
-    cryptographically-random salt and N is the number of rounds. N
-    should be at least 100,000. The keys K and K' are set to the first
-    and last 256 bits of this generated key, respectively. K is used as
-    an AES-256 key, and K' is used as an HMAC-SHA-256 key.
-
-3.  Serialize the JSON object as a UTF-8 string, and encrypt it using
-    AES-CTR-256 with the key K generated above, and with a 128-bit
-    cryptographically-random initialization vector, IV, that has bit 63
-    set to zero. (Setting bit 63 to zero in IV is needed to work around
-    differences in implementations of AES-CTR.)
-
-4.  Concatenate the following data:
-
-| Size (bytes)| Description                                                                             |
-| ------------|-----------------------------------------------------------------------------------------|
-| 1           | Export format version, which must be `0x01`.                                            |
-| 16          | The salt S.                                                                             |
-| 16          | The initialization vector IV.                                                           |
-| 4           | The number of rounds N, as a big-endian unsigned 32-bit integer.                        |
-| variable    | The encrypted JSON object.                                                              |
-| 32          | The HMAC-SHA-256 of all the above string concatenated together, using K' as the key.    |
-
-5.  Base64-encode the string above. Newlines may be added to avoid
-    overly long lines.
-
-6.  Prepend the resulting string with
-    `-----BEGIN MEGOLM SESSION DATA-----`, with a trailing newline, and
-    append `-----END MEGOLM SESSION DATA-----`, with a leading and
-    trailing newline.
-
-###### Key export format
-
-The exported sessions are formatted as a JSON array of `SessionData`
-objects described as follows:
-
-`SessionData`
-
-| Parameter                         | Type             | Description                                                                                                                           |
-|-----------------------------------|------------------|---------------------------------------------------------------------------------------------------------------------------------------|
-| algorithm                         | string           | Required. The encryption algorithm that the session uses. Must be `m.megolm.v1.aes-sha2`.                                             |
-| forwarding_curve25519_key_chain   | [string]         | Required. Chain of Curve25519 keys through which this session was forwarded, via [m.forwarded_room_key](#mforwarded_room_key) events. |
-| room_id                           | string           | Required. The room where the session is used.                                                                                         |
-| sender_key                        | string           | Required. The Curve25519 key of the device which initiated the session originally.                                                    |
-| sender_claimed_keys               | {string: string} | Required. The Ed25519 key of the device which initiated the session originally.                                                       |
-| session_id                        | string           | Required. The ID of the session.                                                                                                      |
-| session_key                       | string           | Required. The key for the session.                                                                                                    |
-
-This is similar to the format before encryption used for the session
-keys in [Server-side key backups](#server-side-key-backups) but adds the
-`room_id` and `session_id` fields.
-
-Example:
-
-```
-[
-    {
-        "algorithm": "m.megolm.v1.aes-sha2",
-        "forwarding_curve25519_key_chain": [
-            "hPQNcabIABgGnx3/ACv/jmMmiQHoeFfuLB17tzWp6Hw"
-        ],
-        "room_id": "!Cuyf34gef24t:localhost",
-        "sender_key": "RF3s+E7RkTQTGF2d8Deol0FkQvgII2aJDf3/Jp5mxVU",
-        "sender_claimed_keys": {
-            "ed25519": "<device ed25519 identity key>",
-        },
-        "session_id": "X3lUlvLELLYxeTx4yOVu6UDpasGEVO0Jbu+QFnm0cKQ",
-        "session_key": "AgAAAADxKHa9uFxcXzwYoNueL5Xqi69IkD4sni8Llf..."
-    },
-    ...
-]
-```
-
-#### Messaging Algorithms
-
-##### Messaging Algorithm Names
-
-Messaging algorithm names use the extensible naming scheme used
-throughout this specification. Algorithm names that start with `m.` are
-reserved for algorithms defined by this specification. Implementations
-wanting to experiment with new algorithms must be uniquely globally
-namespaced following Java's package naming conventions.
-
-Algorithm names should be short and meaningful, and should list the
-primitives used by the algorithm so that it is easier to see if the
-algorithm is using a broken primitive.
-
-A name of `m.olm.v1` is too short: it gives no information about the
-primitives in use, and is difficult to extend for different primitives.
-However a name of
-`m.olm.v1.ecdh-curve25519-hdkfsha256.hmacsha256.hkdfsha256-aes256-cbc-hmac64sha256`
-is too long despite giving a more precise description of the algorithm:
-it adds to the data transfer overhead and sacrifices clarity for human
-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](http://matrix.org/docs/spec/olm.html). This uses:
-
--   Curve25519 for the initial key agreement.
--   HKDF-SHA-256 for ratchet key derivation.
--   Curve25519 for the root key ratchet.
--   HMAC-SHA-256 for the chain key ratchet.
--   HKDF-SHA-256, AES-256 in CBC mode, and 8 byte truncated HMAC-SHA-256
-    for authenticated encryption.
-
-Devices that support Olm must include "m.olm.v1.curve25519-aes-sha2" in
-their list of supported messaging algorithms, must list a Curve25519
-device key, and must publish Curve25519 one-time keys.
-
-An event encrypted using Olm has the following format:
-
-```json
-{
-  "type": "m.room.encrypted",
-  "content": {
-    "algorithm": "m.olm.v1.curve25519-aes-sha2",
-    "sender_key": "<sender_curve25519_key>",
-    "ciphertext": {
-      "<device_curve25519_key>": {
-        "type": 0,
-        "body": "<encrypted_payload_base_64>"
-      }
-    }
-  }
-}
-```
-
-`ciphertext` is a mapping from device Curve25519 key to an encrypted
-payload for that device. `body` is a Base64-encoded Olm message body.
-`type` is an integer indicating the type of the message body: 0 for the
-initial pre-key message, 1 for ordinary messages.
-
-Olm sessions will generate messages with a type of 0 until they receive
-a message. Once a session has decrypted a message it will produce
-messages with a type of 1.
-
-When a client receives a message with a type of 0 it must first check if
-it already has a matching session. If it does then it will use that
-session to try to decrypt the message. If there is no existing session
-then the client must create a new session and use the new session to
-decrypt the message. A client must not persist a session or remove
-one-time keys used by a session until it has successfully decrypted a
-message using that session.
-
-Messages with type 1 can only be decrypted with an existing session. If
-there is no matching session, the client must treat this as an invalid
-message.
-
-The plaintext payload is of the form:
-
-```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` and the `ed25519` field value
-under the `keys` property match the keys returned by [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery) for
-the given user, and 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
-any messages should use its creation time as the time that it last
-received a message. A client may expire old sessions by defining a
-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.
-
-###### Recovering from undecryptable messages
-
-Occasionally messages may be undecryptable by clients due to a variety
-of reasons. When this happens to an Olm-encrypted message, the client
-should assume that the Olm session has become corrupted and create a new
-one to replace it.
-
-{{% boxes/note %}}
-Megolm-encrypted messages generally do not have the same problem.
-Usually the key for an undecryptable Megolm-encrypted message will come
-later, allowing the client to decrypt it successfully. Olm does not have
-a way to recover from the failure, making this session replacement
-process required.
-{{% /boxes/note %}}
-
-To establish a new session, the client sends an [m.dummy](#mdummy)
-to-device event to the other party to notify them of the new session
-details.
-
-Clients should rate-limit the number of sessions it creates per device
-that it receives a message from. Clients should not create a new session
-with another device if it has already created one for that given device
-in the past 1 hour.
-
-Clients should attempt to mitigate loss of the undecryptable messages.
-For example, Megolm sessions that were sent using the old session would
-have been lost. The client can attempt to retrieve the lost sessions
-through `m.room_key_request` messages.
-
-##### `m.megolm.v1.aes-sha2`
-
-The name `m.megolm.v1.aes-sha2` corresponds to version 1 of the Megolm
-ratchet, as defined by the [Megolm
-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
-    for authenticated encryption.
--   Ed25519 for message authenticity.
-
-Devices that support Megolm must support Olm, and include
-"m.megolm.v1.aes-sha2" in their list of supported messaging algorithms.
-
-An event encrypted using Megolm has the following format:
-
-```json
-{
-  "type": "m.room.encrypted",
-  "content": {
-    "algorithm": "m.megolm.v1.aes-sha2",
-    "sender_key": "<sender_curve25519_key>",
-    "device_id": "<sender_device_id>",
-    "session_id": "<outbound_group_session_id>",
-    "ciphertext": "<encrypted_payload_base_64>"
-  }
-}
-```
-
-The encrypted payload can contain any message event. The plaintext is of
-the form:
-
-```json
-{
-  "type": "<event_type>",
-  "content": "<event_content>",
-  "room_id": "<the room_id>"
-}
-```
-
-We include the room ID in the payload, because otherwise the homeserver
-would be able to change the room a message was sent in.
-
-Clients must guard against replay attacks by keeping track of the
-ratchet indices of Megolm sessions. They should reject messages with a
-ratchet index that they have already decrypted. Care should be taken in
-order to avoid false positives, as a client may decrypt the same event
-twice as part of its normal processing.
-
-As with Olm events, clients must confirm that the `sender_key` belongs
-to the user who sent the message. The same reasoning applies, but the
-sender ed25519 key has to be inferred from the `keys.ed25519` property
-of the event which established the Megolm session.
-
-In order to enable end-to-end encryption in a room, clients can send an
-`m.room.encryption` state event specifying `m.megolm.v1.aes-sha2` as its
-`algorithm` property.
-
-When creating a Megolm session in a room, clients must share the
-corresponding session key using Olm with the intended recipients, so
-that they can decrypt future messages encrypted using this session. An
-`m.room_key` event is used to do this. Clients must also handle
-`m.room_key` events sent by other devices in order to decrypt their
-messages.
-
-#### Protocol definitions
-
-##### Events
-
-{{% event event="m.room.encryption" %}}
-
-{{% event event="m.room.encrypted" %}}
-
-{{% event event="m.room_key" %}}
-
-{{% event event="m.room_key_request" %}}
-
-{{% event event="m.forwarded_room_key" %}}
-
-{{% event event="m.dummy" %}}
-
-##### Key management API
-
-{{% http-api spec="client-server" api="keys" %}}
-
-##### Extensions to /sync
-
-This module adds an optional `device_lists` property to the [`/sync`](/client-server-api/#get_matrixclientv3sync)  response,
-as specified below. The server need only populate this property for an
-incremental `/sync` (i.e., one where the `since` parameter was
-specified). The client is expected to use [`/keys/query`](/client-server-api/#post_matrixclientv3keysquery) or
-[`/keys/changes`](/client-server-api/#get_matrixclientv3keyschanges) for the equivalent functionality after an initial
-sync, as documented in [Tracking the device list for a
-user](#tracking-the-device-list-for-a-user).
-
-It also adds a `one_time_keys_count` property. Note the spelling
-difference with the `one_time_key_counts` property in the
-[`/keys/upload`](/client-server-api/#post_matrixclientv3keysupload) response.
-
-
-{{% added-in v="1.2" %}} Finally, a `device_unused_fallback_key_types` property
-is added to list the key algorithms where the device has a fallback key that
-*has not* been used in a [`/keys/claim`](/client-server-api/#post_matrixclientv3keysclaim)
-response. When a previously uploaded fallback key's algorithm is missing
-from this list, the device should upload a replacement key alongside any
-necessary one-time keys to avoid the fallback key's further usage. This
-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                                                                                                            |
-|----------------------------------|--------------------|------------------------------------------------------------------------------------------------------------------------|
-| device_lists                     | DeviceLists        | Optional. Information on e2e device updates. Note: only present on an incremental sync.                                |
-| 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                                                                                                                                                      |
-|------------|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| 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.                                                            |
-
-{{% boxes/note %}}
-For optimal performance, Alice should be added to `changed` in Bob's
-sync only when she updates her devices or cross-signing keys, or when
-Alice and Bob now share a room but didn't share any room previously.
-However, for the sake of simpler logic, a server may add Alice to
-`changed` when Alice and Bob share a new room, even if they previously
-already shared a room.
-{{% /boxes/note %}}
-
-Example response:
-
-```json
-{
-  "next_batch": "s72595_4483_1934",
-  "rooms": {"leave": {}, "join": {}, "invite": {}},
-  "device_lists": {
-    "changed": [
-       "@alice:example.com",
-    ],
-    "left": [
-       "@bob:example.com",
-    ],
-  },
-  "device_one_time_keys_count": {
-    "curve25519": 10,
-    "signed_curve25519": 20
-  }
-}
-```
-
-#### Reporting that decryption keys are withheld
-
-When sending an encrypted event to a room, a client can optionally
-signal to other devices in that room that it is not sending them the
-keys needed to decrypt the event. In this way, the receiving client can
-indicate to the user why it cannot decrypt the event, rather than just
-showing a generic error message.
-
-In the same way, when one device requests keys from another using [Key
-requests](#key-requests), the device from which the key is being
-requested may want to tell the requester that it is purposely not
-sharing the key.
-
-If Alice withholds a megolm session from Bob for some messages in a
-room, and then later on decides to allow Bob to decrypt later messages,
-she can send Bob the megolm session, ratcheted up to the point at which
-she allows Bob to decrypt the messages. If Bob logs into a new device
-and uses key sharing to obtain the decryption keys, the new device will
-be sent the megolm sessions that have been ratcheted up. Bob's old
-device can include the reason that the session was initially not shared
-by including a `withheld` property in the `m.forwarded_room_key` message
-that is an object with the `code` and `reason` properties from the
-`m.room_key.withheld` message.
-
-{{% event event="m.room_key.withheld" %}}
diff --git a/content/client-server-api/modules/event_context.md b/content/client-server-api/modules/event_context.md
deleted file mode 100644
index 7bd678f5..00000000
--- a/content/client-server-api/modules/event_context.md
+++ /dev/null
@@ -1,20 +0,0 @@
----
-type: module
----
-
-### Event Context
-
-This API returns a number of events that happened just before and after
-the specified event. This allows clients to get the context surrounding
-an event.
-
-#### Client behaviour
-
-There is a single HTTP API for retrieving event context, documented
-below.
-
-{{% http-api spec="client-server" api="event_context" %}}
-
-#### Security considerations
-
-The server must only return results that the user has permission to see.
diff --git a/content/client-server-api/modules/guest_access.md b/content/client-server-api/modules/guest_access.md
deleted file mode 100644
index 2cfe1789..00000000
--- a/content/client-server-api/modules/guest_access.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-type: module
----
-
-### Guest Access
-
-There are times when it is desirable for clients to be able to interact
-with rooms without having to fully register for an account on a
-homeserver or join the room. This module specifies how these clients
-should interact with servers in order to participate in rooms as guests.
-
-Guest users retrieve access tokens from a homeserver using the ordinary
-[register
-endpoint](#post_matrixclientv3register),
-specifying the `kind` parameter as `guest`. They may then interact with
-the client-server API as any other user would, but will only have access
-to a subset of the API as described the Client behaviour subsection
-below. Homeservers may choose not to allow this access at all to their
-local users, but have no information about whether users on other
-homeservers are guests or not.
-
-Guest users can also upgrade their account by going through the ordinary
-`register` flow, but specifying the additional POST parameter
-`guest_access_token` containing the guest's access token. They are also
-required to specify the `username` parameter to the value of the local
-part of their username, which is otherwise optional.
-
-This module does not fully factor in federation; it relies on individual
-homeservers properly adhering to the rules set out in this module,
-rather than allowing all homeservers to enforce the rules on each other.
-
-#### Events
-
-{{% event event="m.room.guest_access" %}}
-
-#### Client behaviour
-
-The following API endpoints are allowed to be accessed by guest accounts
-for retrieving events:
-
-* [GET /rooms/{roomId}/state](#get_matrixclientv3roomsroomidstate)
-* [GET /rooms/{roomId}/context/{eventId}](#get_matrixclientv3roomsroomidcontexteventid)
-* [GET /rooms/{roomId}/event/{eventId}](#get_matrixclientv3roomsroomideventeventid)
-* [GET /rooms/{roomId}/state/{eventType}/{stateKey}](#get_matrixclientv3roomsroomidstateeventtypestatekey)
-* [GET /rooms/{roomId}/messages](#get_matrixclientv3roomsroomidmessages)
-* {{< added-in v="1.1" >}} [GET /rooms/{roomId}/members](#get_matrixclientv3roomsroomidmembers)
-* [GET /rooms/{roomId}/initialSync](#get_matrixclientv3roomsroomidinitialsync)
-* [GET /sync](#get_matrixclientv3sync)
-* [GET /events](#get_matrixclientv3events) as used for room previews.
-
-The following API endpoints are allowed to be accessed by guest accounts
-for sending events:
-
-* [POST /rooms/{roomId}/join](#post_matrixclientv3roomsroomidjoin)
-* [POST /rooms/{roomId}/leave](#post_matrixclientv3roomsroomidleave)
-* [PUT /rooms/{roomId}/send/{eventType}/{txnId}](#put_matrixclientv3roomsroomidsendeventtypetxnid)
-
-    * {{< changed-in v="1.2" >}} Guests can now send *any* event type rather than just `m.room.message` events.
-
-* {{< added-in v="1.2" >}} [PUT /rooms/{roomId}/state/{eventType}/{stateKey}](#put_matrixclientv3roomsroomidstateeventtypestatekey)
-* [PUT /sendToDevice/{eventType}/{txnId}](#put_matrixclientv3sendtodeviceeventtypetxnid)
-
-The following API endpoints are allowed to be accessed by guest accounts
-for their own account maintenance:
-
-* [PUT /profile/{userId}/displayname](#put_matrixclientv3profileuseriddisplayname)
-* [GET /devices](#get_matrixclientv3devices)
-* [GET /devices/{deviceId}](#get_matrixclientv3devicesdeviceid)
-* [PUT /devices/{deviceId}](#put_matrixclientv3devicesdeviceid)
-* {{< added-in v="1.2" >}} [GET /account/whoami](#get_matrixclientv3accountwhoami)
-
-The following API endpoints are allowed to be accessed by guest accounts
-for end-to-end encryption:
-
-* [POST /keys/upload](#post_matrixclientv3keysupload)
-* [POST /keys/query](#post_matrixclientv3keysquery)
-* [POST /keys/claim](#post_matrixclientv3keysclaim)
-
-#### Server behaviour
-
-Servers MUST only allow guest users to join rooms if the
-`m.room.guest_access` state event is present on the room, and has the
-`guest_access` value `can_join`. If the `m.room.guest_access` event is
-changed to stop this from being the case, the server MUST set those
-users' `m.room.member` state to `leave`.
-
-#### Security considerations
-
-Each homeserver manages its own guest accounts itself, and whether an
-account is a guest account or not is not information passed from server
-to server. Accordingly, any server participating in a room is trusted to
-properly enforce the permissions outlined in this section.
-
-Homeservers may want to enable protections such as captchas for guest
-registration to prevent spam, denial of service, and similar attacks.
-
-Homeservers may want to put stricter rate limits on guest accounts,
-particularly for sending state events.
diff --git a/content/client-server-api/modules/history_visibility.md b/content/client-server-api/modules/history_visibility.md
deleted file mode 100644
index 175171f8..00000000
--- a/content/client-server-api/modules/history_visibility.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-type: module
----
-
-### Room History Visibility
-
-This module adds support for controlling the visibility of previous
-events in a room.
-
-In all cases except `world_readable`, a user needs to join a room to
-view events in that room. Once they have joined a room, they will gain
-access to a subset of events in the room. How this subset is chosen is
-controlled by the `m.room.history_visibility` event outlined below.
-After a user has left a room, they may see any events which they were
-allowed to see before they left the room, but no events received after
-they left.
-
-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 anyone, regardless of whether they have ever joined
-    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.
--   `invited` - Events are accessible to newly joined members from the
-    point they were invited onwards. Events stop being accessible when
-    the member's state changes to something other than `invite` or
-    `join`.
--   `joined` - Events are accessible to newly joined members from the
-    point they joined the room onwards. Events stop being accessible
-    when the member's state changes to something other than `join`.
-
-{{% boxes/warning %}}
-These options are applied at the point an event is *sent*. Checks are
-performed with the state of the `m.room.history_visibility` event when
-the event in question is added to the DAG. This means clients cannot
-retrospectively choose to show or hide history to new users if the
-setting at that time was more restrictive.
-{{% /boxes/warning %}}
-
-#### Events
-
-{{% event event="m.room.history_visibility" %}}
-
-#### Client behaviour
-
-Clients that implement this module MUST present to the user the possible
-options for setting history visibility when creating a room.
-
-Clients may want to display a notice that their events may be read by
-non-joined people if the value is set to `world_readable`.
-
-#### Server behaviour
-
-By default if no `history_visibility` is set, or if the value is not
-understood, the visibility is assumed to be `shared`. The rules
-governing whether a user is allowed to see an event depend on the state
-of the room *at that event*.
-
-1.  If the `history_visibility` was set to `world_readable`, allow.
-2.  If the user's `membership` was `join`, allow.
-3.  If `history_visibility` was set to `shared`, and the user joined the
-    room at any point after the event was sent, allow.
-4.  If the user's `membership` was `invite`, and the
-    `history_visibility` was set to `invited`, allow.
-5.  Otherwise, deny.
-
-For `m.room.history_visibility` events themselves, the user should be
-allowed to see the event if the `history_visibility` before *or* after
-the event would allow them to see it. (For example, a user should be
-able to see `m.room.history_visibility` events which change the
-`history_visibility` from `world_readable` to `joined` *or* from
-`joined` to `world_readable`, even if that user was not a member of the
-room.)
-
-Likewise, for the user's own `m.room.member` events, the user should be
-allowed to see the event if their `membership` before *or* after the
-event would allow them to see it. (For example, a user can always see
-`m.room.member` events which set their membership to `join`, or which
-change their membership from `join` to any other value, even if
-`history_visibility` is `joined`.)
-
-#### Security considerations
-
-The default value for `history_visibility` is `shared` for
-backwards-compatibility reasons. Clients need to be aware that by not
-setting this event they are exposing all of their room history to anyone
-in the room.
diff --git a/content/client-server-api/modules/ignore_users.md b/content/client-server-api/modules/ignore_users.md
deleted file mode 100644
index 6e67008e..00000000
--- a/content/client-server-api/modules/ignore_users.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-type: module
----
-
-### Ignoring Users
-
-With all the communication through Matrix it may be desirable to ignore
-a particular user for whatever reason. This module defines how clients
-and servers can implement the ignoring of users.
-
-#### Events
-
-{{% event event="m.ignored_user_list" %}}
-
-#### Client behaviour
-
-To ignore a user, effectively blocking them, the client should add the
-target user to the `m.ignored_user_list` event in their account data
-using [`/user/<user_id>/account_data/<type>`](/client-server-api/#put_matrixclientv3useruseridaccount_datatype). Once ignored, the client will no longer receive events sent by
-that user, with the exception of state events. The client should either
-hide previous content sent by the newly ignored user or perform a new
-`/sync` with no previous token.
-
-Invites to new rooms by ignored users will not be sent to the client.
-The server may optionally reject the invite on behalf of the client.
-
-State events will still be sent to the client, even if the user is
-ignored. This is to ensure parts, such as the room name, do not appear
-different to the user just because they ignored the sender.
-
-To remove a user from the ignored users list, remove them from the
-account data event. The server will resume sending events from the
-previously ignored user, however it should not send events that were
-missed while the user was ignored. To receive the events that were sent
-while the user was ignored the client should perform a fresh sync. The
-client may also un-hide any events it previously hid due to the user
-becoming ignored.
-
-#### Server behaviour
-
-Following an update of the `m.ignored_user_list`, the sync API for all
-clients should immediately start ignoring (or un-ignoring) the user.
-Clients are responsible for determining if they should hide previously
-sent events or to start a new sync stream.
-
-Servers must still send state events sent by ignored users to clients.
-
-Servers must not send room invites from ignored users to clients.
-Servers may optionally decide to reject the invite, however.
diff --git a/content/client-server-api/modules/instant_messaging.md b/content/client-server-api/modules/instant_messaging.md
deleted file mode 100644
index 3ca5668d..00000000
--- a/content/client-server-api/modules/instant_messaging.md
+++ /dev/null
@@ -1,525 +0,0 @@
----
-type: module
----
-
-### Instant Messaging
-
-This module adds support for sending human-readable messages to a room.
-It also adds support for associating human-readable information with the
-room itself such as a room name and topic.
-
-#### Events
-
-{{% event event="m.room.message" %}}
-
-{{% event event="m.room.message.feedback" %}}
-
-Usage of this event is discouraged for several reasons:
--   The number of feedback events will grow very quickly with the number
-    of users in the room. This event provides no way to "batch"
-    feedback, unlike the [receipts module](#receipts).
--   Pairing feedback to messages gets complicated when paginating as
-    feedback arrives before the message it is acknowledging.
--   There are no guarantees that the client has seen the event ID being
-    acknowledged.
-
-{{% event event="m.room.name" %}}
-
-{{% event event="m.room.topic" %}}
-
-{{% event event="m.room.avatar" %}}
-
-{{% event event="m.room.pinned_events" %}}
-
-##### m.room.message msgtypes
-
-Each [m.room.message](#mroommessage) MUST have a `msgtype` key which identifies the
-type of message being sent. Each type has their own required and
-optional keys, as outlined below. If a client cannot display the given
-`msgtype` then it SHOULD display the fallback plain text `body` key
-instead.
-
-Some message types support HTML in the event content that clients should
-prefer to display if available. Currently `m.text`, `m.emote`, and
-`m.notice` support an additional `format` parameter of
-`org.matrix.custom.html`. When this field is present, a `formatted_body`
-with the HTML must be provided. The plain text version of the HTML
-should be provided in the `body`.
-
-Clients should limit the HTML they render to avoid Cross-Site Scripting,
-HTML injection, and similar attacks. The strongly suggested set of HTML
-tags to permit, denying the use and rendering of anything else, is:
-`font`, `del`, `h1`, `h2`, `h3`, `h4`, `h5`, `h6`, `blockquote`, `p`,
-`a`, `ul`, `ol`, `sup`, `sub`, `li`, `b`, `i`, `u`, `strong`, `em`,
-`strike`, `code`, `hr`, `br`, `div`, `table`, `thead`, `tbody`, `tr`,
-`th`, `td`, `caption`, `pre`, `span`, `img`, `details`, `summary`.
-
-Not all attributes on those tags should be permitted as they may be
-avenues for other disruption attempts, such as adding `onclick` handlers
-or excessively large text. Clients should only permit the attributes
-listed for the tags below. Where `data-mx-bg-color` and `data-mx-color`
-are listed, clients should translate the value (a 6-character hex color
-code) to the appropriate CSS/attributes for the tag.
-
-`font`
-`data-mx-bg-color`, `data-mx-color`, `color`
-
-`span`
-`data-mx-bg-color`, `data-mx-color`, `data-mx-spoiler` (see
-[spoiler messages](#spoiler-messages))
-
-`a`
-`name`, `target`, `href` (provided the value is not relative and has a
-scheme matching one of: `https`, `http`, `ftp`, `mailto`, `magnet`)
-
-`img`
-`width`, `height`, `alt`, `title`, `src` (provided it is a [Matrix
-Content (MXC) URI](#matrix-content-mxc-uris))
-
-`ol`
-`start`
-
-`code`
-`class` (only classes which start with `language-` for syntax
-highlighting)
-
-Additionally, web clients should ensure that *all* `a` tags get a
-`rel="noopener"` to prevent the target page from referencing the
-client's tab/window.
-
-Tags must not be nested more than 100 levels deep. Clients should only
-support the subset of tags they can render, falling back to other
-representations of the tags where possible. For example, a client may
-not be able to render tables correctly and instead could fall back to
-rendering tab-delimited text.
-
-In addition to not rendering unsafe HTML, clients should not emit unsafe
-HTML in events. Likewise, clients should not generate HTML that is not
-needed, such as extra paragraph tags surrounding text due to Rich Text
-Editors. HTML included in events should otherwise be valid, such as
-having appropriate closing tags, appropriate attributes (considering the
-custom ones defined in this specification), and generally valid
-structure.
-
-A special tag, `mx-reply`, may appear on rich replies (described below)
-and should be allowed if, and only if, the tag appears as the very first
-tag in the `formatted_body`. The tag cannot be nested and cannot be
-located after another tag in the tree. Because the tag contains HTML, an
-`mx-reply` is expected to have a partner closing tag and should be
-treated similar to a `div`. Clients that support rich replies will end
-up stripping the tag and its contents and therefore may wish to exclude
-the tag entirely.
-
-{{% boxes/note %}}
-A future iteration of the specification will support more powerful and
-extensible message formatting options, such as the proposal
-[MSC1767](https://github.com/matrix-org/matrix-doc/pull/1767).
-{{% /boxes/note %}}
-
-{{% msgtypes %}}
-
-#### Client behaviour
-
-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
-the redacted message can be removed entirely from the messages view.
-
-Events which have attachments (e.g. `m.image`, `m.file`) SHOULD be
-uploaded using the [content repository module](#content-repository)
-where available. The resulting `mxc://` URI can then be used in the `url`
-key.
-
-Clients MAY include a client generated thumbnail image for an attachment
-under a `info.thumbnail_url` key. The thumbnail SHOULD also be a
-`mxc://` URI. Clients displaying events with attachments can either use
-the client generated thumbnail or ask its homeserver to generate a
-thumbnail from the original attachment using the [content repository
-module](#content-repository).
-
-##### Recommendations when sending messages
-
-In the event of send failure, clients SHOULD retry requests using an
-exponential-backoff algorithm for a certain amount of time T. It is
-recommended that T is no longer than 5 minutes. After this time, the
-client should stop retrying and mark the message as "unsent". Users
-should be able to manually resend unsent messages.
-
-Users may type several messages at once and send them all in quick
-succession. Clients SHOULD preserve the order in which they were sent by
-the user. This means that clients should wait for the response to the
-previous request before sending the next request. This can lead to
-head-of-line blocking. In order to reduce the impact of head-of-line
-blocking, clients should use a queue per room rather than a global
-queue, as ordering is only relevant within a single room rather than
-between rooms.
-
-##### Local echo
-
-Messages SHOULD appear immediately in the message view when a user
-presses the "send" button. This should occur even if the message is
-still sending. This is referred to as "local echo". Clients SHOULD
-implement "local echo" of messages. Clients MAY display messages in a
-different format to indicate that the server has not processed the
-message. This format should be removed when the server responds.
-
-Clients need to be able to match the message they are sending with the
-same message which they receive from the event stream. The echo of the
-same message from the event stream is referred to as "remote echo". Both
-echoes need to be identified as the same message in order to prevent
-duplicate messages being displayed. Ideally this pairing would occur
-transparently to the user: the UI would not flicker as it transitions
-from local to remote. Flickering can be reduced through clients making
-use of the transaction ID they used to send a particular event. The
-transaction ID used will be included in the event's `unsigned` data as
-`transaction_id` when it arrives through the event stream.
-
-Clients unable to make use of the transaction ID are likely to
-experience flickering when the remote echo arrives on the event stream
-*before* the request to send the message completes. In that case the
-event arrives before the client has obtained an event ID, making it
-impossible to identify it as a remote echo. This results in the client
-displaying the message twice for some time (depending on the server
-responsiveness) before the original request to send the message
-completes. Once it completes, the client can take remedial actions to
-remove the duplicate event by looking for duplicate event IDs.
-
-##### Calculating the display name for a user
-
-Clients may wish to show the human-readable display name of a room
-member as part of a membership list, or when they send a message.
-However, different members may have conflicting display names. Display
-names MUST be disambiguated before showing them to the user, in order to
-prevent spoofing of other users.
-
-To ensure this is done consistently across clients, clients SHOULD use
-the following algorithm to calculate a disambiguated display name for a
-given user:
-
-1.  Inspect the `m.room.member` state event for the relevant user id.
-2.  If the `m.room.member` state event has no `displayname` field, or if
-    that field has a `null` value, use the raw user id as the display
-    name. Otherwise:
-3.  If the `m.room.member` event has a `displayname` which is unique
-    among members of the room with `membership: join` or
-    `membership: invite`, use the given `displayname` as the
-    user-visible display name. Otherwise:
-4.  The `m.room.member` event has a non-unique `displayname`. This
-    should be disambiguated using the user id, for example "display name
-    (@id:homeserver.org)".
-
-Developers should take note of the following when implementing the above
-algorithm:
-
--   The user-visible display name of one member can be affected by
-    changes in the state of another member. For example, if
-    `@user1:matrix.org` is present in a room, with `displayname: Alice`,
-    then when `@user2:example.com` joins the room, also with
-    `displayname: Alice`, *both* users must be given disambiguated
-    display names. Similarly, when one of the users then changes their
-    display name, there is no longer a clash, and *both* users can be
-    given their chosen display name. Clients should be alert to this
-    possibility and ensure that all affected users are correctly
-    renamed.
--   The display name of a room may also be affected by changes in the
-    membership list. This is due to the room name sometimes being based
-    on user display names (see [Calculating the display name for a
-    room](#calculating-the-display-name-for-a-room)).
--   If the entire membership list is searched for clashing display
-    names, this leads to an O(N^2) implementation for building the list
-    of room members. This will be very inefficient for rooms with large
-    numbers of members. It is recommended that client implementations
-    maintain a hash table mapping from `displayname` to a list of room
-    members using that name. Such a table can then be used for efficient
-    calculation of whether disambiguation is needed.
-
-##### Displaying membership information with messages
-
-Clients may wish to show the display name and avatar URL of the room
-member who sent a message. This can be achieved by inspecting the
-`m.room.member` state event for that user ID (see [Calculating the
-display name for a user](#calculating-the-display-name-for-a-user)).
-
-When a user paginates the message history, clients may wish to show the
-**historical** display name and avatar URL for a room member. This is
-possible because older `m.room.member` events are returned when
-paginating. This can be implemented efficiently by keeping two sets of
-room state: old and current. As new events arrive and/or the user
-paginates back in time, these two sets of state diverge from each other.
-New events update the current state and paginated events update the old
-state. When paginated events are processed sequentially, the old state
-represents the state of the room *at the time the event was sent*. This
-can then be used to set the historical display name and avatar URL.
-
-##### Calculating the display name for a room
-
-Clients may wish to show a human-readable name for a room. There are a
-number of possibilities for choosing a useful name. To ensure that rooms
-are named consistently across clients, clients SHOULD use the following
-algorithm to choose a name:
-
-1.  If the room has an [m.room.name](#mroomname) state event with a non-empty
-    `name` field, use the name given by that field.
-2.  If the room has an [m.room.canonical\_alias](#mroomcanonical_alias) state event with a
-    valid `alias` field, use the alias given by that field as the name.
-    Note that clients should avoid using `alt_aliases` when calculating
-    the room name.
-3.  If none of the above conditions are met, a name should be composed
-    based on the members of the room. Clients should consider
-    [m.room.member](#mroommember) events for users other than the logged-in user, as
-    defined below.
-    1.  If the number of `m.heroes` for the room are greater or equal to
-        `m.joined_member_count + m.invited_member_count - 1`, then use
-        the membership events for the heroes to calculate display names
-        for the users ([disambiguating them if
-        required](#calculating-the-display-name-for-a-user)) and
-        concatenating them. For example, the client may choose to show
-        "Alice, Bob, and Charlie (@charlie:example.org)" as the room
-        name. The client may optionally limit the number of users it
-        uses to generate a room name.
-    2.  If there are fewer heroes than
-        `m.joined_member_count + m.invited_member_count - 1`, and
-        `m.joined_member_count + m.invited_member_count` is greater than
-        1, the client should use the heroes to calculate display names
-        for the users ([disambiguating them if
-        required](#calculating-the-display-name-for-a-user)) and
-        concatenating them alongside a count of the remaining users. For
-        example, "Alice, Bob, and 1234 others".
-    3.  If `m.joined_member_count + m.invited_member_count` is less than
-        or equal to 1 (indicating the member is alone), the client
-        should use the rules above to indicate that the room was empty.
-        For example, "Empty Room (was Alice)", "Empty Room (was Alice
-        and 1234 others)", or "Empty Room" if there are no heroes.
-
-Clients SHOULD internationalise the room name to the user's language
-when using the `m.heroes` to calculate the name. Clients SHOULD use
-minimum 5 heroes to calculate room names where possible, but may use
-more or less to fit better with their user experience.
-
-##### Rich replies
-
-In some cases, events may wish to reference other events. This could be
-to form a thread of messages for the user to follow along with, or to
-provide more context as to what a particular event is describing.
-Currently, the only kind of relation defined is a "rich reply" where a
-user may reference another message to create a thread-like conversation.
-
-Relationships are defined under an `m.relates_to` key in the event's
-`content`. If the event is of the type `m.room.encrypted`, the
-`m.relates_to` key MUST NOT be covered by the encryption and instead be
-put alongside the encryption information held in the `content`.
-
-A rich reply is formed through use of an `m.relates_to` relation for
-`m.in_reply_to` where a single key, `event_id`, is used to reference the
-event being replied to. The referenced event ID SHOULD belong to the
-same room where the reply is being sent. Clients should be cautious of
-the event ID belonging to another room, or being invalid entirely. Rich
-replies can only be constructed in the form of `m.room.message` events
-with a `msgtype` of `m.text` or `m.notice`. Due to the fallback
-requirements, rich replies cannot be constructed for types of `m.emote`,
-`m.file`, etc. Rich replies may reference any other `m.room.message`
-event, however. Rich replies may reference another event which also has
-a rich reply, infinitely.
-
-An `m.in_reply_to` relationship looks like the following:
-
-```
-{
-  ...
-  "type": "m.room.message",
-  "content": {
-    "msgtype": "m.text",
-    "body": "<body including fallback>",
-    "format": "org.matrix.custom.html",
-    "formatted_body": "<HTML including fallback>",
-    "m.relates_to": {
-      "m.in_reply_to": {
-        "event_id": "$another:event.com"
-      }
-    }
-  }
-}
-```
-
-##### Fallbacks for rich replies
-
-Some clients may not have support for rich replies and therefore need a
-fallback to use instead. Clients that do not support rich replies should
-render the event as if rich replies were not special.
-
-Clients that do support rich replies MUST provide the fallback format on
-replies, and MUST strip the fallback before rendering the reply. Rich
-replies MUST have a `format` of `org.matrix.custom.html` and therefore a
-`formatted_body` alongside the `body` and appropriate `msgtype`. The
-specific fallback text is different for each `msgtype`, however the
-general format for the `body` is:
-
-    > <@alice:example.org> This is the original body
-
-    This is where the reply goes
-
-The `formatted_body` should use the following template:
-
-    <mx-reply>
-      <blockquote>
-        <a href="https://matrix.to/#/!somewhere:example.org/$event:example.org">In reply to</a>
-        <a href="https://matrix.to/#/@alice:example.org">@alice:example.org</a>
-        <br />
-        <!-- This is where the related event's HTML would be. -->
-      </blockquote>
-    </mx-reply>
-    This is where the reply goes.
-
-If the related event does not have a `formatted_body`, the event's
-`body` should be considered after encoding any HTML special characters.
-Note that the `href` in both of the anchors use a [matrix.to
-URI](/appendices#matrixto-navigation).
-
-###### Stripping the fallback
-
-Clients which support rich replies MUST strip the fallback from the
-event before rendering the event. This is because the text provided in
-the fallback cannot be trusted to be an accurate representation of the
-event. After removing the fallback, clients are recommended to represent
-the event referenced by `m.in_reply_to` similar to the fallback's
-representation, although clients do have creative freedom for their user
-interface. Clients should prefer the `formatted_body` over the `body`,
-just like with other `m.room.message` events.
-
-To strip the fallback on the `body`, the client should iterate over each
-line of the string, removing any lines that start with the fallback
-prefix ("&gt; ", including the space, without quotes) and stopping when
-a line is encountered without the prefix. This prefix is known as the
-"fallback prefix sequence".
-
-To strip the fallback on the `formatted_body`, the client should remove
-the entirety of the `mx-reply` tag.
-
-###### Fallback for `m.text`, `m.notice`, and unrecognised message types
-
-Using the prefix sequence, the first line of the related event's `body`
-should be prefixed with the user's ID, followed by each line being
-prefixed with the fallback prefix sequence. For example:
-
-    > <@alice:example.org> This is the first line
-    > This is the second line
-
-    This is the reply
-
-The `formatted_body` uses the template defined earlier in this section.
-
-###### Fallback for `m.emote`
-
-Similar to the fallback for `m.text`, each line gets prefixed with the
-fallback prefix sequence. However an asterisk should be inserted before
-the user's ID, like so:
-
-    > * <@alice:example.org> feels like today is going to be a great day
-
-    This is the reply
-
-The `formatted_body` has a subtle difference for the template where the
-asterisk is also inserted ahead of the user's ID:
-
-    <mx-reply>
-      <blockquote>
-        <a href="https://matrix.to/#/!somewhere:example.org/$event:example.org">In reply to</a>
-        * <a href="https://matrix.to/#/@alice:example.org">@alice:example.org</a>
-        <br />
-        <!-- This is where the related event's HTML would be. -->
-      </blockquote>
-    </mx-reply>
-    This is where the reply goes.
-
-###### Fallback for `m.image`, `m.video`, `m.audio`, and `m.file`
-
-The related event's `body` would be a file name, which may not be very
-descriptive. The related event should additionally not have a `format`
-or `formatted_body` in the `content` - if the event does have a `format`
-and/or `formatted_body`, those fields should be ignored. Because the
-filename alone may not be descriptive, the related event's `body` should
-be considered to be `"sent a file."` such that the output looks similar
-to the following:
-
-    > <@alice:example.org> sent a file.
-
-    This is the reply
-
-    <mx-reply>
-      <blockquote>
-        <a href="https://matrix.to/#/!somewhere:example.org/$event:example.org">In reply to</a>
-        <a href="https://matrix.to/#/@alice:example.org">@alice:example.org</a>
-        <br />
-        sent a file.
-      </blockquote>
-    </mx-reply>
-    This is where the reply goes.
-
-For `m.image`, the text should be `"sent an image."`. For `m.video`, the
-text should be `"sent a video."`. For `m.audio`, the text should be
-`"sent an audio file"`.
-
-##### Spoiler messages
-
-{{% added-in v="1.1" %}}
-
-Parts of a message can be hidden visually from the user through use of spoilers.
-This does not affect the server's representation of the event content - it
-is simply a visual cue to the user that the message may reveal important
-information about something, spoiling any relevant surprise.
-
-To send spoilers clients MUST use the `formatted_body` and therefore the
-`org.matrix.custom.html` format, described above. This makes spoilers valid on
-any `msgtype` which can support this format appropriately.
-
-Spoilers themselves are contained with `span` tags, with the reason (optionally)
-being in the `data-mx-spoiler` attribute. Spoilers without a reason must at least
-specify the attribute, though the value may be empty/undefined.
-
-An example of a spoiler is:
-
-```json
-{
-  "msgtype": "m.text",
-  "format": "org.matrix.custom.html",
-  "body": "Alice [Spoiler](mxc://example.org/abc123) in the movie.",
-  "formatted_body": "Alice <span data-mx-spoiler>lived happily ever after</span> in the movie."
-}
-```
-
-If a reason were to be supplied, it would look like:
-
-```json
-{
-  "msgtype": "m.text",
-  "format": "org.matrix.custom.html",
-  "body": "Alice [Spoiler for health of Alice](mxc://example.org/abc123) in the movie.",
-  "formatted_body": "Alice <span data-mx-spoiler='health of alice'>lived happily ever after</span> in the movie."
-}
-```
-
-When sending a spoiler, clients SHOULD provide the plain text fallback in the `body`
-as shown above (including the reason). The fallback SHOULD omit the spoiler text verbatim
-since `body` might show up in text-only clients or in notifications. To prevent spoilers
-showing up in such situations, clients are strongly encouraged to first upload the plaintext
-to the media repository then reference the MXC URI in a markdown-style link, as shown above.
-
-Clients SHOULD render spoilers differently with some sort of disclosure. For example, the
-client could blur the actual text and ask the user to click on it for it to be revealed.
-
-#### Server behaviour
-
-Homeservers SHOULD reject `m.room.message` events which don't have a
-`msgtype` key, or which don't have a textual `body` key, with an HTTP
-status code of 400.
-
-#### Security considerations
-
-Messages sent using this module are not encrypted, although end to end
-encryption is in development (see [E2E module](#end-to-end-encryption)).
-
-Clients should sanitise **all displayed keys** for unsafe HTML to
-prevent Cross-Site Scripting (XSS) attacks. This includes room names and
-topics.
diff --git a/content/client-server-api/modules/mentions.md b/content/client-server-api/modules/mentions.md
deleted file mode 100644
index 65e2adab..00000000
--- a/content/client-server-api/modules/mentions.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-type: module
----
-
-### User and room mentions
-
-This module allows users to mention other users and rooms within a room message.
-This is achieved by including a [Matrix URI](/appendices/#uris) in the HTML body of
-an [m.room.message](#mroommessage) event. This module does not have any server-specific
-behaviour to it.
-
-Mentions apply only to [m.room.message](#mroommessage) events where the `msgtype` is
-`m.text`, `m.emote`, or `m.notice`. The `format` for the event must be
-`org.matrix.custom.html` and therefore requires a `formatted_body`.
-
-To make a mention, reference the entity being mentioned in the
-`formatted_body` using an anchor, like so:
-
-```json
-{
-    "body": "Hello Alice!",
-    "msgtype": "m.text",
-    "format": "org.matrix.custom.html",
-    "formatted_body": "Hello <a href='https://matrix.to/#/@alice:example.org'>Alice</a>!"
-}
-```
-
-#### Client behaviour
-
-In addition to using the appropriate `Matrix URI` for the mention,
-clients should use the following guidelines when making mentions in
-events to be sent:
-
--   When mentioning users, use the user's potentially ambiguous display
-    name for the anchor's text. If the user does not have a display
-    name, use the user's ID.
--   When mentioning rooms, use the canonical alias for the room. If the
-    room does not have a canonical alias, prefer one of the aliases
-    listed on the room. If no alias can be found, fall back to the room
-    ID. In all cases, use the alias/room ID being linked to as the
-    anchor's text.
-
-The text component of the anchor should be used in the event's `body`
-where the mention would normally be represented, as shown in the example
-above.
-
-Clients should display mentions differently from other elements. For
-example, this may be done by changing the background color of the
-mention to indicate that it is different from a normal link.
-
-If the current user is mentioned in a message (either by a mention as
-defined in this module or by a push rule), the client should show that
-mention differently from other mentions, such as by using a red
-background color to signify to the user that they were mentioned.
-
-When clicked, the mention should navigate the user to the appropriate
-user or room information.
-
-{{% boxes/note %}}
-Similar to legacy [matrix.to URLs](/appendices/#matrixto-navigation),
-groups used to be representable by mentions. They follow a similar format
-to room mentions, though using the group ID in both the link and anchor
-text.
-{{% /boxes/note %}}
\ No newline at end of file
diff --git a/content/client-server-api/modules/moderation_policies.md b/content/client-server-api/modules/moderation_policies.md
deleted file mode 100644
index ee649e03..00000000
--- a/content/client-server-api/modules/moderation_policies.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-type: module
----
-
-### Moderation policy lists
-
-With Matrix being an open network where anyone can participate, a very
-wide range of content exists and it is important that users are
-empowered to select which content they wish to see, and which content
-they wish to block. By extension, room moderators and server admins
-should also be able to select which content they do not wish to host in
-their rooms and servers.
-
-The protocol's position on this is one of neutrality: it should not be
-deciding what content is undesirable for any particular entity and
-should instead be empowering those entities to make their own decisions.
-As such, a generic framework for communicating "moderation policy lists"
-or "moderation policy rooms" is described. Note that this module only
-describes the data structures and not how they should be interpreting:
-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 (they could be public,
-private, encrypted, etc).
-
-There are currently 3 kinds of entities which can be affected by rules:
-`user`, `server`, and `room`. All 3 are described with
-`m.policy.rule.<kind>` state events. The `state_key` for a policy rule
-is an arbitrary string decided by the sender of the rule.
-
-Rules contain recommendations and reasons for the rule existing. The
-`reason` is a human-readable string which describes the
-`recommendation`. Currently only one recommendation, `m.ban`, is
-specified.
-
-#### `m.ban` recommendation
-
-When this recommendation is used, the entities affected by the rule
-should be banned from participation where possible. The enforcement of
-this is deliberately left as an implementation detail to avoid the
-protocol imposing its opinion on how the policy list is to be
-interpreted. However, a suggestion for a simple implementation is as
-follows:
-
--   Is a `user` rule...
-    -   Applied to a user: The user should be added to the subscriber's
-        ignore list.
-    -   Applied to a room: The user should be banned from the room
-        (either on sight or immediately).
-    -   Applied to a server: The user should not be allowed to send
-        invites to users on the server.
--   Is a `room` rule...
-    -   Applied to a user: The user should leave the room and not join
-        it
-        ([MSC2270](https://github.com/matrix-org/matrix-doc/pull/2270)-style
-        ignore).
-    -   Applied to a room: No-op because a room cannot ban itself.
-    -   Applied to a server: The server should prevent users from
-        joining the room and from receiving invites to it.
--   Is a `server` rule...
-    -   Applied to a user: The user should not receive events or invites
-        from the server.
-    -   Applied to a room: The server is added as a denied server in the
-        ACLs.
-    -   Applied to a server: The subscriber should avoid federating with
-        the server as much as possible by blocking invites from the
-        server and not sending traffic unless strictly required (no
-        outbound invites).
-
-#### Subscribing to policy lists
-
-This is deliberately left as an implementation detail. For
-implementations using the Client-Server API, this could be as easy as
-joining or peeking the room. Joining or peeking is not required,
-however: an implementation could poll for updates or use a different
-technique for receiving updates to the policy's rules.
-
-#### Sharing
-
-In addition to sharing a direct reference to the room which contains the
-policy's rules, plain http or https URLs can be used to share links to
-the list. When the URL is approached with a `Accept: application/json`
-header or has `.json` appended to the end of the URL, it should return a
-JSON object containing a `room_uri` property which references the room.
-Currently this would be a `matrix.to` URI, however in future it could be
-a Matrix-schemed URI instead. When not approached with the intent of
-JSON, the service could return a user-friendly page describing what is
-included in the ban list.
-
-#### Events
-
-The `entity` described by the state events can contain `*` and `?` to
-match zero or more and one or more characters respectively. Note that
-rules against rooms can describe a room ID or room alias - the
-subscriber is responsible for resolving the alias to a room ID if
-desired.
-
-{{% event event="m.policy.rule.user" %}}
-
-{{% event event="m.policy.rule.room" %}}
-
-{{% event event="m.policy.rule.server" %}}
-
-#### Client behaviour
-
-As described above, the client behaviour is deliberately left undefined.
-
-#### Server behaviour
-
-Servers have no additional requirements placed on them by this module.
-
-#### Security considerations
-
-This module could be used to build a system of shared blacklists, which
-may create a divide within established communities if not carefully
-deployed. This may well not be a suitable solution for all communities.
-
-Depending on how implementations handle subscriptions, user IDs may be
-linked to policy lists and therefore expose the views of that user. For
-example, a client implementation which joins the user to the policy room
-would expose the user's ID to observers of the policy room. In future,
-[MSC1228](https://github.com/matrix-org/matrix-doc/pulls/1228) and
-[MSC1777](https://github.com/matrix-org/matrix-doc/pulls/1777) (or
-similar) could help solve this concern.
diff --git a/content/client-server-api/modules/openid.md b/content/client-server-api/modules/openid.md
deleted file mode 100644
index e7cadcfc..00000000
--- a/content/client-server-api/modules/openid.md
+++ /dev/null
@@ -1,12 +0,0 @@
----
-type: module
----
-
-### OpenID
-
-This module allows users to verify their identity with a third party
-service. The third party service does need to be matrix-aware in that it
-will need to know to resolve matrix homeservers to exchange the user's
-token for identity information.
-
-{{% http-api spec="client-server" api="openid" %}}
diff --git a/content/client-server-api/modules/presence.md b/content/client-server-api/modules/presence.md
deleted file mode 100644
index 96cff115..00000000
--- a/content/client-server-api/modules/presence.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-type: module
----
-
-### Presence
-
-Each user has the concept of presence information. This encodes:
-
--   Whether the user is currently online
--   How recently the user was last active (as seen by the server)
--   Whether a given client considers the user to be currently idle
--   Arbitrary information about the user's current status (e.g. "in a
-    meeting").
-
-This information is collated from both per-device (`online`, `idle`,
-`last_active`) and per-user (status) data, aggregated by the user's
-homeserver and transmitted as an `m.presence` event. Presence events are
-sent to interested parties where users share a room membership.
-
-User's presence state is represented by the `presence` key, which is an
-enum of one of the following:
-
--   `online` : The default state when the user is connected to an event
-    stream.
--   `unavailable` : The user is not reachable at this time e.g. they are
-    idle.
--   `offline` : The user is not connected to an event stream or is
-    explicitly suppressing their profile information from being sent.
-
-#### Events
-
-{{% event-group group_name="m.presence" %}}
-
-#### Client behaviour
-
-Clients can manually set/get their presence using the HTTP APIs listed
-below.
-
-{{% http-api spec="client-server" api="presence" %}}
-
-##### Last active ago
-
-The server maintains a timestamp of the last time it saw a pro-active
-event from the user. A pro-active event may be sending a message to a
-room or changing presence state to `online`. This timestamp is presented
-via a key called `last_active_ago` which gives the relative number of
-milliseconds since the pro-active event.
-
-To reduce the number of presence updates sent to clients the server may
-include a `currently_active` boolean field when the presence state is
-`online`. When true, the server will not send further updates to the
-last active time until an update is sent to the client with either a)
-`currently_active` set to false or b) a presence state other than
-`online`. During this period clients must consider the user to be
-currently active, irrespective of the last active time.
-
-The last active time must be up to date whenever the server gives a
-presence event to the client. The `currently_active` mechanism should
-purely be used by servers to stop sending continuous presence updates,
-as opposed to disabling last active tracking entirely. Thus clients can
-fetch up to date last active times by explicitly requesting the presence
-for a given user.
-
-##### Idle timeout
-
-The server will automatically set a user's presence to `unavailable` if
-their last active time was over a threshold value (e.g. 5 minutes).
-Clients can manually set a user's presence to `unavailable`. Any
-activity that bumps the last active time on any of the user's clients
-will cause the server to automatically set their presence to `online`.
-
-#### Security considerations
-
-Presence information is shared with all users who share a room with the
-target user. In large public rooms this could be undesirable.
diff --git a/content/client-server-api/modules/push.md b/content/client-server-api/modules/push.md
deleted file mode 100644
index bd7be800..00000000
--- a/content/client-server-api/modules/push.md
+++ /dev/null
@@ -1,824 +0,0 @@
----
-type: module
----
-
-### Push Notifications
-
-```
-                                   +--------------------+  +-------------------+
-                  Matrix HTTP      |                    |  |                   |
-             Notification Protocol |   App Developer    |  |   Device Vendor   |
-                                   |                    |  |                   |
-           +-------------------+   | +----------------+ |  | +---------------+ |
-           |                   |   | |                | |  | |               | |
-           | Matrix homeserver +----->  Push Gateway  +------> Push Provider | |
-           |                   |   | |                | |  | |               | |
-           +-^-----------------+   | +----------------+ |  | +----+----------+ |
-             |                     |                    |  |      |            |
-    Matrix   |                     |                    |  |      |            |
- Client/Server API  +              |                    |  |      |            |
-             |      |              +--------------------+  +-------------------+
-             |   +--+-+                                           |
-             |   |    <-------------------------------------------+
-             +---+    |
-                 |    |          Provider Push Protocol
-                 +----+
-          Mobile Device or Client
-```
-
-This module adds support for push notifications. Homeservers send
-notifications of events to user-configured HTTP endpoints. Users may
-also configure a number of rules that determine which events generate
-notifications. These are all stored and managed by the user's
-homeserver. This allows user-specific push settings to be reused between
-client applications.
-
-The above diagram shows the flow of push notifications being sent to a
-handset where push notifications are submitted via the handset vendor,
-such as Apple's APNS or Google's GCM. This happens as follows:
-
-1.  The client app signs in to a homeserver.
-2.  The client app registers with its vendor's Push Provider and obtains
-    a routing token of some kind.
-3.  The mobile app uses the Client/Server API to add a 'pusher',
-    providing the URL of a specific Push Gateway which is configured for
-    that application. It also provides the routing token it has acquired
-    from the Push Provider.
-4.  The homeserver starts sending HTTP requests to the Push Gateway
-    using the supplied URL. The Push Gateway relays this notification to
-    the Push Provider, passing the routing token along with any
-    necessary private credentials the provider requires to send push
-    notifications.
-5.  The Push Provider sends the notification to the device.
-
-Definitions for terms used in this section are below:
-
-Push Provider
-A push provider is a service managed by the device vendor which can send
-notifications directly to the device. Google Cloud Messaging (GCM) and
-Apple Push Notification Service (APNS) are two examples of push
-providers.
-
-Push Gateway
-A push gateway is a server that receives HTTP event notifications from
-homeservers and passes them on to a different protocol such as APNS for
-iOS devices or GCM for Android devices. Clients inform the homeserver
-which Push Gateway to send notifications to when it sets up a Pusher.
-
-Pusher
-A pusher is a worker on the homeserver that manages the sending of HTTP
-notifications for a user. A user can have multiple pushers: one per
-device.
-
-Push Rule
-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. These rules are stored on the user's homeserver.
-They are manually configured by the user, who can create and view them
-via the Client/Server API.
-
-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 scopes and rules.
-
-#### Client behaviour
-
-Clients MUST configure a Pusher before they will receive push
-notifications. There is a single API endpoint for this, as described
-below.
-
-{{% http-api spec="client-server" api="pusher" %}}
-
-##### Listing Notifications
-
-A client can retrieve a list of events that it has been notified about.
-This may be useful so that users can see a summary of what important
-messages they have received.
-
-{{% http-api spec="client-server" api="notifications" %}}
-
-##### Receiving notifications
-
-Servers MUST include the number of unread notifications in a client's
-`/sync` stream, and MUST update it as it changes. Notifications are
-determined by the push rules which apply to an event.
-
-When the user updates their read receipt (either by using the API or by
-sending an event), notifications prior to and including that event MUST
-be marked as read.
-
-##### Push Rules
-
-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 and
-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:
-
-Override Rules `override`
-The highest priority rules are user-configured overrides.
-
-Content-specific Rules `content`
-These configure behaviour for (unencrypted) messages that match certain
-patterns. Content rules take one parameter: `pattern`, that gives the
-glob pattern to match against. This is treated in the same way as
-`pattern` for `event_match`.
-
-Room-specific Rules `room`
-These rules change the behaviour of all messages for a given room. The
-`rule_id` of a room rule is always the ID of the room that it affects.
-
-Sender-specific rules `sender`
-These rules configure notification behaviour for messages from a
-specific Matrix user ID. The `rule_id` of Sender rules is always the
-Matrix user ID of the user whose messages they'd apply to.
-
-Underride rules `underride`
-These are identical to `override` rules, but have a lower priority than
-`content`, `room` and `sender` rules.
-
-Rules with the same `kind` can specify an ordering priority. This
-determines which rule is selected in the event of multiple matches. For
-example, a rule matching "tea" and a separate rule matching "time" would
-both match the sentence "It's time for tea". The ordering of the rules
-would then resolve the tiebreak to determine which rule is executed.
-Only `actions` for highest priority rule will be sent to the Push
-Gateway.
-
-Each rule can be enabled or disabled. Disabled rules never match. If no
-rules match an event, the homeserver MUST NOT notify the Push Gateway
-for that event. Homeservers MUST NOT notify the Push Gateway for events
-that the user has sent themselves.
-
-###### Actions
-
-All rules have an associated list of `actions`. An action affects if and
-how a notification is delivered for a matching event. The following
-actions are defined:
-
-`notify`
-This causes each matching event to generate a notification.
-
-`dont_notify`
-This prevents each matching event from generating a notification
-
-`coalesce`
-This enables notifications for matching events but activates homeserver
-specific behaviour to intelligently coalesce multiple events into a
-single notification. Not all homeservers may support this. Those that do
-not support it should treat it as the `notify` action.
-
-`set_tweak`
-Sets an entry in the `tweaks` dictionary key that is sent in the
-notification request to the Push Gateway. This takes the form of a
-dictionary with a `set_tweak` key whose value is the name of the tweak
-to set. It may also have a `value` key which is the value to which it
-should be set.
-
-The following tweaks are defined:
-
-* `sound`: A string representing the sound to be played when this notification
-arrives. A value of `default` means to play a default sound. A device
-may choose to alert the user by some other means if appropriate, eg.
-vibration.
-
-* `highlight`: A boolean representing whether or not this message should be highlighted
-in the UI. This will normally take the form of presenting the message in
-a different colour and/or style. The UI might also be adjusted to draw
-particular attention to the room in which the event occurred. If a
-`highlight` tweak is given with no value, its value is defined to be
-`true`. If no highlight tweak is given at all then the value of
-`highlight` is defined to be false.
-
-Tweaks are passed transparently through the homeserver so client
-applications and Push Gateways may agree on additional tweaks. For
-example, a tweak may be added to specify how to flash the notification
-light on a mobile device.
-
-Actions that have no parameters are represented as a string. Otherwise,
-they are represented as a dictionary with a key equal to their name and
-other keys as their parameters, e.g.
-`{ "set_tweak": "sound", "value": "default" }`
-
-###### Conditions
-
-`override` and `underride` rules MAY have a list of 'conditions'. All
-conditions must hold true for an event in order for the rule to match. A
-rule with no conditions always matches.
-
-Unrecognised conditions MUST NOT match any events, effectively making
-the push rule disabled.
-
-`room`, `sender` and `content` rules do not have conditions in the same
-way, but instead have predefined conditions. In the cases of `room` and
-`sender` rules, the `rule_id` of the rule determines its behaviour.
-
-The following conditions are defined:
-
-**`event_match`**
-
-This is a glob pattern match on a field of the event. Parameters:
-
--   `key`: The dot-separated path of the property of the event to match, e.g.
-    `content.body`.
-
--   `pattern`: The glob-style pattern to match against.
-
-The match is performed case-insensitively, and must match the entire value of
-the event field given by `key` (though see below regarding `content.body`). The
-exact meaning of "case insensitive" is defined by the implementation of the
-homeserver.
-
-Within `pattern`:
-
-  * The character `*` matches zero or more characters.
-  * `?` matches exactly one character.
-
-If the property specified by `key` is completely absent from the event, or does
-not have a string value, then the condition will not match, even if `pattern`
-is `*`.
-
-{{% boxes/note %}}
-For example, if `key` is `content.topic`, and `pattern` is `lunc?*`, then
-the following event will match:
-
-```json
-{
-  "content": {
-    "topic": "Lunch plans",
-  },
-  "event_id": "$143273582443PhrSn:example.org",
-  "room_id": "!636q39766251:example.com",
-  "sender": "@example:example.org",
-  "state_key": "",
-  "type": "m.room.topic"
-}
-```
-
-Other `topic` values which will match are:
-
- * `"LUNCH"` (case-insensitive; `*` may match zero characters)
-
-The following `membership` values will NOT match:
- * `" lunch"` (note leading space)
- * `"lunc"` (`?` must match a character)
- * `null` (not a string)
-{{% /boxes/note %}}
-
-As a special case, if `key` is `content.body`, then `pattern` must instead
-match any substring of the value of the property which starts and ends at a
-word boundary. A word boundary is defined as the start or end of the value, or
-any character not in the sets `[A-Z]`, `[a-z]`, `[0-9]` or `_`.
-
-{{% boxes/note %}}
-For example, if `key` is `content.body` and `pattern` is `ex*ple`, the
-following event will match:
-
-```json
-{
-  "content": {
-    "body": "An example event.",
-  },
-  "event_id": "$143273976499sgjks:example.org",
-  "room_id": "!636q39766251:example.com",
-  "sender": "@example:example.org",
-  "type": "m.room.message"
-}
-```
-
-Other `body` values which will match are:
-
- * `"exple"` (the pattern can match at the start and end of the body.)
- * `"An exciting triple-whammy"` (the pattern can span multiple words, and `-`
-   acts as a word separator.)
-{{% /boxes/note %}}
-
-
-{{% boxes/warning %}}
-Note that there is no implicit condition for `state_key`. In other words, push
-rules which should match only state events must include an explicit condition
-for `state_key`.
-
-For an example of this, see the default rule
-[`.m.rule.tombstone`](#mruletombstone) below.
-{{% /boxes/warning %}}
-
-**`contains_display_name`**
-
-This matches unencrypted messages where `content.body` contains the
-owner's display name in that room. This is a separate rule because
-display names may change and as such it would be hard to maintain a rule
-that matched the user's display name. This condition has no parameters.
-
-**`room_member_count`**
-
-This matches the current number of members in the room. Parameters:
-
--   `is`: A decimal integer optionally prefixed by one of, `==`, `<`,
-    `>`, `>=` or `<=`. A prefix of `<` matches rooms where the member
-    count is strictly less than the given number and so forth. If no
-    prefix is present, this parameter defaults to `==`.
-
-**`sender_notification_permission`**
-
-This takes into account the current power levels in the room, ensuring
-the sender of the event has high enough power to trigger the
-notification.
-
-Parameters:
-
--   `key`: A string that determines the power level the sender must have
-    to trigger notifications of a given type, such as `room`. Refer to
-    the [m.room.power\_levels](#mroompower_levels) event schema for information about what
-    the defaults are and how to interpret the event. The `key` is used
-    to look up the power level required to send a notification type from
-    the `notifications` object in the power level event content.
-
-##### Predefined Rules
-
-Homeservers can specify "server-default rules" which operate at a lower
-priority than "user-defined rules". The `rule_id` for all server-default
-rules MUST start with a dot (".") to identify them as "server-default".
-The following server-default rules are specified:
-
-###### Default Override Rules
-
-**`.m.rule.master`**
-
-Matches all events. This can be enabled to turn off all push
-notifications other than those generated by override rules set by the
-user. By default this rule is disabled.
-
-Definition:
-
-```json
-{
-    "rule_id": ".m.rule.master",
-    "default": true,
-    "enabled": false,
-    "conditions": [],
-    "actions": [
-        "dont_notify"
-    ]
-}
-```
-
-**`.m.rule.suppress_notices`**
-
-Matches messages with a `msgtype` of `notice`.
-
-Definition:
-
-```json
-{
-    "rule_id": ".m.rule.suppress_notices",
-    "default": true,
-    "enabled": true,
-    "conditions": [
-        {
-            "kind": "event_match",
-            "key": "content.msgtype",
-            "pattern": "m.notice",
-        }
-    ],
-    "actions": [
-        "dont_notify",
-    ]
-}
-```
-
-**`.m.rule.invite_for_me`**
-
-Matches any invites to a new room for this user.
-
-Definition:
-
-```json
-{
-    "rule_id": ".m.rule.invite_for_me",
-    "default": true,
-    "enabled": true,
-    "conditions": [
-        {
-            "key": "type",
-            "kind": "event_match",
-            "pattern": "m.room.member"
-        },
-        {
-            "key": "content.membership",
-            "kind": "event_match",
-            "pattern": "invite"
-        },
-        {
-            "key": "state_key",
-            "kind": "event_match",
-            "pattern": "[the user's Matrix ID]"
-        }
-    ],
-    "actions": [
-       "notify",
-        {
-            "set_tweak": "sound",
-            "value": "default"
-        }
-    ]
-}
-```
-
-**`.m.rule.member_event`**
-
-Matches any `m.room.member_event`.
-
-Definition:
-
-```json
-{
-    "rule_id": ".m.rule.member_event",
-    "default": true,
-    "enabled": true,
-    "conditions": [
-        {
-            "key": "type",
-            "kind": "event_match",
-            "pattern": "m.room.member"
-        }
-    ],
-    "actions": [
-        "dont_notify"
-    ]
-}
-```
-
-**`.m.rule.contains_display_name`**
-
-Matches any message whose content is unencrypted and 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 name="mruletombstone"></a>`.m.rule.tombstone`**
-
-Matches any state event whose type is `m.room.tombstone`. This is
-intended to notify users of a room when it is upgraded, similar to what
-an `@room` notification would accomplish.
-
-Definition:
-
-```json
-{
-    "rule_id": ".m.rule.tombstone",
-    "default": true,
-    "enabled": true,
-    "conditions": [
-        {
-            "kind": "event_match",
-            "key": "type",
-            "pattern": "m.room.tombstone"
-        },
-        {
-            "kind": "event_match",
-            "key": "state_key",
-            "pattern": ""
-        }
-    ],
-    "actions": [
-        "notify",
-        {
-            "set_tweak": "highlight"
-        }
-    ]
-}
-```
-
-**`.m.rule.roomnotif`**
-
-Matches any message whose content is unencrypted and 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"
-        }
-    ]
-}
-```
-
-###### Default Content Rules
-
-**`.m.rule.contains_user_name`**
-
-Matches any message whose content is unencrypted and 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`**
-
-Matches any incoming VOIP call.
-
-Definition:
-
-```json
-{
-    "rule_id": ".m.rule.call",
-    "default": true,
-    "enabled": true,
-    "conditions": [
-        {
-            "key": "type",
-            "kind": "event_match",
-            "pattern": "m.call.invite"
-        }
-    ],
-    "actions": [
-        "notify",
-        {
-            "set_tweak": "sound",
-            "value": "ring"
-        }
-    ]
-}
-```
-
-**`.m.rule.encrypted_room_one_to_one`**
-
-Matches any encrypted event sent in a room with exactly two members.
-Unlike other push rules, this rule cannot be matched against the content
-of the event by nature of it being encrypted. This causes the rule to be
-an "all or nothing" match where it either matches *all* events that are
-encrypted (in 1:1 rooms) or none.
-
-Definition:
-
-```json
-{
-    "rule_id": ".m.rule.encrypted_room_one_to_one",
-    "default": true,
-    "enabled": true,
-    "conditions": [
-        {
-            "kind": "room_member_count",
-            "is": "2"
-        },
-        {
-            "kind": "event_match",
-            "key": "type",
-            "pattern": "m.room.encrypted"
-        }
-    ],
-    "actions": [
-        "notify",
-        {
-            "set_tweak": "sound",
-            "value": "default"
-        }
-    ]
-}
-```
-
-**`.m.rule.room_one_to_one`**
-
-Matches any message sent in a room with exactly two members.
-
-Definition:
-
-```json
-{
-    "rule_id": ".m.rule.room_one_to_one",
-    "default": true,
-    "enabled": true,
-    "conditions": [
-        {
-            "kind": "room_member_count",
-            "is": "2"
-        },
-        {
-            "kind": "event_match",
-            "key": "type",
-            "pattern": "m.room.message"
-        }
-    ],
-    "actions": [
-        "notify",
-        {
-            "set_tweak": "sound",
-            "value": "default"
-        }
-    ]
-}
-```
-
-**`.m.rule.message`**
-
-Matches all chat messages.
-
-Definition:
-
-```json
-{
-     "rule_id": ".m.rule.message",
-     "default": true,
-     "enabled": true,
-     "conditions": [
-         {
-             "kind": "event_match",
-             "key": "type",
-             "pattern": "m.room.message"
-         }
-     ],
-     "actions": [
-         "notify"
-     ]
-}
-```
-
-**`.m.rule.encrypted`**
-
-Matches all encrypted events. Unlike other push rules, this rule cannot
-be matched against the content of the event by nature of it being
-encrypted. This causes the rule to be an "all or nothing" match where it
-either matches *all* events that are encrypted (in group rooms) or none.
-
-Definition:
-
-```json
-{
-     "rule_id": ".m.rule.encrypted",
-     "default": true,
-     "enabled": true,
-     "conditions": [
-         {
-             "kind": "event_match",
-             "key": "type",
-             "pattern": "m.room.encrypted"
-         }
-     ],
-     "actions": [
-         "notify"
-     ]
-}
-```
-
-##### Push Rules: API
-
-Clients can retrieve, add, modify and remove push rules globally or
-per-device using the APIs below.
-
-{{% http-api spec="client-server" api="pushrules" %}}
-
-##### Push Rules: Events
-
-When a user changes their push rules a `m.push_rules` event is sent to
-all clients in the `account_data` section of their next `/sync` request.
-The content of the event is the current push rules for the user.
-
-{{% event event="m.push_rules" %}}
-
-###### Examples
-
-To create a rule that suppresses notifications for the room with ID
-`!dj234r78wl45Gh4D:matrix.org`:
-
-    curl -X PUT -H "Content-Type: application/json" "https://example.com/_matrix/client/v3/pushrules/global/room/%21dj234r78wl45Gh4D%3Amatrix.org?access_token=123456" -d \
-    '{
-       "actions" : ["dont_notify"]
-     }'
-
-To suppress notifications for the user `@spambot:matrix.org`:
-
-    curl -X PUT -H "Content-Type: application/json" "https://example.com/_matrix/client/v3/pushrules/global/sender/%40spambot%3Amatrix.org?access_token=123456" -d \
-    '{
-       "actions" : ["dont_notify"]
-     }'
-
-To always notify for messages that contain the work 'cake' and set a
-specific sound (with a rule\_id of `SSByZWFsbHkgbGlrZSBjYWtl`):
-
-    curl -X PUT -H "Content-Type: application/json" "https://example.com/_matrix/client/v3/pushrules/global/content/SSByZWFsbHkgbGlrZSBjYWtl?access_token=123456" -d \
-    '{
-       "pattern": "cake",
-       "actions" : ["notify", {"set_sound":"cakealarm.wav"}]
-     }'
-
-To add a rule suppressing notifications for messages starting with
-'cake' but ending with 'lie', superseding the previous rule:
-
-    curl -X PUT -H "Content-Type: application/json" "https://example.com/_matrix/client/v3/pushrules/global/content/U3BvbmdlIGNha2UgaXMgYmVzdA?access_token=123456&before=SSByZWFsbHkgbGlrZSBjYWtl" -d \
-    '{
-       "pattern": "cake*lie",
-       "actions" : ["notify"]
-     }'
-
-To add a custom sound for notifications messages containing the word
-'beer' in any rooms with 10 members or fewer (with greater importance
-than the room, sender and content rules):
-
-    curl -X PUT -H "Content-Type: application/json" "https://example.com/_matrix/client/v3/pushrules/global/override/U2VlIHlvdSBpbiBUaGUgRHVrZQ?access_token=123456" -d \
-    '{
-       "conditions": [
-         {"kind": "event_match", "key": "content.body", "pattern": "beer" },
-         {"kind": "room_member_count", "is": "<=10"}
-       ],
-       "actions" : [
-         "notify",
-         {"set_sound":"beeroclock.wav"}
-       ]
-     }'
-
-#### Server behaviour
-
-#### Push Gateway behaviour
-
-##### Recommendations for APNS
-
-The exact format for sending APNS notifications is flexible and up to
-the client app and its' push gateway to agree on. As APNS requires that
-the sender has a private key owned by the app developer, each app must
-have its own push gateway. It is recommended that:
-
--   The APNS token be base64 encoded and used as the pushkey.
--   A different app\_id be used for apps on the production and sandbox
-    APS environments.
--   APNS push gateways do not attempt to wait for errors from the APNS
-    gateway before returning and instead to store failures and return
-    'rejected' responses next time that pushkey is used.
-
-#### Security considerations
-
-Clients specify the Push Gateway URL to use to send event notifications
-to. This URL should be over HTTPS and *never* over HTTP.
-
-As push notifications will pass through a Push Provider, message content
-shouldn't be sent in the push itself where possible. Instead, Push
-Gateways should send a "sync" command to instruct the client to get new
-events from the homeserver directly.
diff --git a/content/client-server-api/modules/read_markers.md b/content/client-server-api/modules/read_markers.md
deleted file mode 100644
index 4ee07938..00000000
--- a/content/client-server-api/modules/read_markers.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-type: module
----
-
-### Fully read markers
-
-The history for a given room may be split into three sections: messages
-the user has read (or indicated they aren't interested in them),
-messages the user might have read some but not others, and messages the
-user hasn't seen yet. The "fully read marker" (also known as a "read
-marker") marks the last event of the first section, whereas the user's
-read receipt marks the last event of the second section.
-
-#### Events
-
-The user's fully read marker is kept as an event in the room's [account
-data](#client-config). The event may be read to determine the user's
-current fully read marker location in the room, and just like other
-account data events the event will be pushed down the event stream when
-updated.
-
-The fully read marker is kept under an `m.fully_read` event. If the
-event does not exist on the user's account data, the fully read marker
-should be considered to be the user's read receipt location.
-
-{{% event event="m.fully_read" %}}
-
-#### Client behaviour
-
-The client cannot update fully read markers by directly modifying the
-`m.fully_read` account data event. Instead, the client must make use of
-the read markers API to change the values.
-
-The read markers API can additionally update the user's read receipt
-(`m.read`) location in the same operation as setting the fully read
-marker location. This is because read receipts and read markers are
-commonly updated at the same time, and therefore the client might wish
-to save an extra HTTP call. Providing an `m.read` location performs the
-same task as a request to `/receipt/m.read/$event:example.org`.
-
-{{% http-api spec="client-server" api="read_markers" %}}
-
-#### Server behaviour
-
-The server MUST prevent clients from setting `m.fully_read` directly in
-room account data. The server must additionally ensure that it treats
-the presence of `m.read` in the `/read_markers` request the same as how
-it would for a request to `/receipt/m.read/$event:example.org`.
-
-Upon updating the `m.fully_read` event due to a request to
-`/read_markers`, the server MUST send the updated account data event
-through to the client via the event stream (eg: `/sync`), provided any
-applicable filters are also satisfied.
diff --git a/content/client-server-api/modules/receipts.md b/content/client-server-api/modules/receipts.md
deleted file mode 100644
index 1abd45a5..00000000
--- a/content/client-server-api/modules/receipts.md
+++ /dev/null
@@ -1,88 +0,0 @@
----
-type: module
----
-
-### Receipts
-
-This module adds in support for receipts. These receipts are a form of
-acknowledgement of an event. This module defines a single
-acknowledgement: `m.read` which indicates that the user has read up to a
-given event.
-
-Sending a receipt for each event can result in sending large amounts of
-traffic to a homeserver. To prevent this from becoming a problem,
-receipts are implemented using "up to" markers. This marker indicates
-that the acknowledgement applies to all events "up to and including" the
-event specified. For example, marking an event as "read" would indicate
-that the user had read all events *up to* the referenced event. See the
-[Receiving notifications](#receiving-notifications) section for more
-information on how read receipts affect notification counts.
-
-#### Events
-
-Each `user_id`, `receipt_type` pair must be associated with only a
-single `event_id`.
-
-{{% event event="m.receipt" %}}
-
-#### Client behaviour
-
-In `/sync`, receipts are listed under the `ephemeral` array of events
-for a given room. New receipts that come down the event streams are
-deltas which update existing mappings. Clients should replace older
-receipt acknowledgements based on `user_id` and `receipt_type` pairs.
-For example:
-
-    Client receives m.receipt:
-      user = @alice:example.com
-      receipt_type = m.read
-      event_id = $aaa:example.com
-
-    Client receives another m.receipt:
-      user = @alice:example.com
-      receipt_type = m.read
-      event_id = $bbb:example.com
-
-    The client should replace the older acknowledgement for $aaa:example.com with
-    this one for $bbb:example.com
-
-Clients should send read receipts when there is some certainty that the
-event in question has been **displayed** to the user. Simply receiving
-an event does not provide enough certainty that the user has seen the
-event. The user SHOULD need to *take some action* such as viewing the
-room that the event was sent to or dismissing a notification in order
-for the event to count as "read". Clients SHOULD NOT send read receipts
-for events sent by their own user.
-
-A client can update the markers for its user by interacting with the
-following HTTP APIs.
-
-{{% http-api spec="client-server" api="receipts" %}}
-
-#### Server behaviour
-
-For efficiency, receipts SHOULD be batched into one event per room
-before delivering them to clients.
-
-Receipts are sent across federation as EDUs with type `m.receipt`. The
-format of the EDUs are:
-
-```
-{
-    <room_id>: {
-        <receipt_type>: {
-            <user_id>: { <content> }
-        },
-        ...
-    },
-    ...
-}
-```
-
-These are always sent as deltas to previously sent receipts. Currently
-only a single `<receipt_type>` should be used: `m.read`.
-
-#### Security considerations
-
-As receipts are sent outside the context of the event graph, there are
-no integrity checks performed on the contents of `m.receipt` events.
diff --git a/content/client-server-api/modules/report_content.md b/content/client-server-api/modules/report_content.md
deleted file mode 100644
index 3b32ff8d..00000000
--- a/content/client-server-api/modules/report_content.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-type: module
----
-
-### Reporting Content
-
-Users may encounter content which they find inappropriate and should be
-able to report it to the server administrators or room moderators for
-review. This module defines a way for users to report content.
-
-Content is reported based upon a negative score, where -100 is "most
-offensive" and 0 is "inoffensive".
-
-#### Client behaviour
-
-{{% http-api spec="client-server" api="report_content" %}}
-
-#### Server behaviour
-
-Servers are free to handle the reported content however they desire.
-This may be a dedicated room to alert server administrators to the
-reported content or some other mechanism for notifying the appropriate
-people.
diff --git a/content/client-server-api/modules/room_previews.md b/content/client-server-api/modules/room_previews.md
deleted file mode 100644
index ea5e324e..00000000
--- a/content/client-server-api/modules/room_previews.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-type: module
----
-
-### Room Previews
-
-It is sometimes desirable to offer a preview of a room, where a user can
-"lurk" and read messages posted to the room, without joining the room.
-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
-/events](#get_matrixclientv3events) endpoint.
-
-#### Client behaviour
-
-A client wishing to view a room without joining it should call [GET
-/rooms/:room\_id/initialSync](#get_matrixclientv3roomsroomidinitialsync),
-followed by [GET /events](#get_matrixclientv3events). Clients will need to do
-this in parallel for each room they wish to view.
-
-Clients can of course also call other endpoints such as [GET
-/rooms/:room\_id/messages](#get_matrixclientv3roomsroomidmessages)
-and [GET /search](#post_matrixclientv3search) to
-access events outside the `/events` stream.
-
-{{% http-api spec="client-server" api="peeking_events" %}}
-
-#### Server behaviour
-
-For clients which have not joined a room, servers are required to only
-return events where the room state at the event had the
-`m.room.history_visibility` state event present with
-`history_visibility` value `world_readable`.
-
-#### Security considerations
-
-Clients may wish to display to their users that rooms which are
-`world_readable` *may* be showing messages to non-joined users. There is
-no way using this module to find out whether any non-joined guest users
-*do* see events in the room, or to list or count any lurking users.
diff --git a/content/client-server-api/modules/room_upgrades.md b/content/client-server-api/modules/room_upgrades.md
deleted file mode 100644
index e9794dea..00000000
--- a/content/client-server-api/modules/room_upgrades.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-type: module
----
-
-### Room Upgrades
-
-From time to time, a room may need to be upgraded to a different room
-version for a variety of reasons. This module defines a way for rooms
-to upgrade to a different room version when needed.
-
-#### Events
-
-{{% event event="m.room.tombstone" %}}
-
-#### Client behaviour
-
-Clients which understand `m.room.tombstone` events and the `predecessor`
-field on `m.room.create` events should communicate to the user that the
-room was upgraded. One way of accomplishing this would be hiding the old
-room from the user's room list and showing banners linking between the
-old and new room - ensuring that permalinks work when referencing the
-old room. Another approach may be to virtually merge the rooms such that
-the old room's timeline seamlessly continues into the new timeline
-without the user having to jump between the rooms.
-
-{{% http-api spec="client-server" api="room_upgrades" %}}
-
-#### Server behaviour
-
-When the client requests to upgrade a known room to a known version, the
-server:
-
-1.  Checks that the user has permission to send `m.room.tombstone`
-    events in the room.
-
-2.  Creates a replacement room with a `m.room.create` event containing a
-    `predecessor` field and the applicable `room_version`.
-
-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:
-
-    -   `m.room.server_acl`
-    -   `m.room.encryption`
-    -   `m.room.name`
-    -   `m.room.avatar`
-    -   `m.room.topic`
-    -   `m.room.guest_access`
-    -   `m.room.history_visibility`
-    -   `m.room.join_rules`
-    -   `m.room.power_levels`
-
-    Membership events should not be transferred to the new room due to
-    technical limitations of servers not being able to impersonate
-    people from other homeservers. Additionally, servers should not
-    transfer state events which are sensitive to who sent them, such as
-    events outside of the Matrix namespace where clients may rely on the
-    sender to match certain criteria.
-
-4.  Moves any local aliases to the new room.
-
-5.  Sends a `m.room.tombstone` event to the old room to indicate that it
-    is not intended to be used any further.
-
-6.  If possible, the power levels in the old room should also be
-    modified to prevent sending of events and inviting new users. For
-    example, setting `events_default` and `invite` to the greater of
-    `50` and `users_default + 1`.
-
-When a user joins the new room, the server should automatically
-transfer/replicate some of the user's personalized settings such as
-notifications, tags, etc.
diff --git a/content/client-server-api/modules/search.md b/content/client-server-api/modules/search.md
deleted file mode 100644
index bcd38188..00000000
--- a/content/client-server-api/modules/search.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-type: module
----
-
-### Server Side Search
-
-The search API allows clients to perform full text search across events
-in all rooms that the user has been in, including those that they have
-left. Only events that the user is allowed to see will be searched, e.g.
-it won't include events in rooms that happened after you left.
-
-#### Client behaviour
-
-There is a single HTTP API for performing server-side search, documented
-below.
-
-{{% http-api spec="client-server" api="search" %}}
-
-#### Search Categories
-
-The search API allows clients to search in different categories of
-items. Currently the only specified category is `room_events`.
-
-##### `room_events`
-
-This category covers all events that the user is allowed to see,
-including events in rooms that they have left. The search is performed
-on certain keys of certain event types.
-
-The supported keys to search over are:
-
--   `content.body` in `m.room.message`
--   `content.name` in `m.room.name`
--   `content.topic` in `m.room.topic`
-
-The search will *not* include rooms that are end to end encrypted.
-
-The results include a `rank` key that can be used to sort the results by
-relevancy. The higher the `rank` the more relevant the result is.
-
-The value of `count` gives an approximation of the total number of
-results. Homeservers may give an estimate rather than an exact value for
-this field.
-
-#### Ordering
-
-The client can specify the ordering that the server returns results in.
-The two allowed orderings are:
-
--   `rank`, which returns the most relevant results first.
--   `recent`, which returns the most recent results first.
-
-The default ordering is `rank`.
-
-#### Groups
-
-The client can request that the results are returned along with grouping
-information, e.g. grouped by `room_id`. In this case the response will
-contain a group entry for each distinct value of `room_id`. Each group
-entry contains at least a list of the `event_ids` that are in that
-group, as well as potentially other metadata about the group.
-
-The current required supported groupings are:
-
--   `room_id`
--   `sender`
-
-#### Pagination
-
-The server may return a `next_batch` key at various places in the
-response. These are used to paginate the results. To fetch more results,
-the client should send the *same* request to the server with a
-`next_batch` query parameter set to that of the token.
-
-The scope of the pagination is defined depending on where the
-`next_batch` token was returned. For example, using a token inside a
-group will return more results from within that group.
-
-The currently supported locations for the `next_batch` token are:
-
--   `search_categories.<category>.next_batch`
--   `search_categories.<category>.groups.<group_key>.<group_id>.next_batch`
-
-A server need not support pagination, even if there are more matching
-results. In that case, they must not return a `next_batch` token in the
-response.
-
-#### Security considerations
-
-The server must only return results that the user has permission to see.
diff --git a/content/client-server-api/modules/secrets.md b/content/client-server-api/modules/secrets.md
deleted file mode 100644
index 17b515c7..00000000
--- a/content/client-server-api/modules/secrets.md
+++ /dev/null
@@ -1,336 +0,0 @@
----
-type: module
----
-
-### Secrets
-
-{{% added-in v="1.1" %}}
-
-Clients may have secret information that they wish to be made available
-to other authorised clients, but that the server should not be able to
-see, so the information must be encrypted as it passes through the
-server. This can be done either asynchronously, by storing encrypted
-data on the server for later retrieval, or synchronously, by sending
-messages to each other.
-
-Each secret has an identifier that is used by clients to refer to the
-secret when storing, fetching, requesting, or sharing the secret.
-Secrets are plain strings; structured data can be stored by encoding it
-as a string.
-
-#### Storage
-
-When secrets are stored on the server, they are stored in the user's
-[account-data](#client-config), using an event type equal to the
-secret's identifier. The keys that secrets are encrypted with are
-described by data that is also stored in the user's account-data. Users
-can have multiple keys, allowing them to control what sets of secrets
-clients can access, depending on what keys are given to them.
-
-##### Key storage
-
-Each key has an ID, and the description of the key is stored in the
-user's account\_data using the event type
-`m.secret_storage.key.[key ID]`. The contents of the account data for
-the key will include an `algorithm` property, which indicates the
-encryption algorithm used, as well as a `name` property, which is a
-human-readable name. Key descriptions may also have a `passphrase`
-property for generating the key from a user-entered passphrase, as
-described in [deriving keys from
-passphrases](#deriving-keys-from-passphrases).
-
-`KeyDescription`
-
-| Parameter  | Type      | Description
-|------------|-----------|-------------------------------------------------------------------------------------------------------------------------------------|
-| name       | string    | Optional. The name of the key. If not given, the client may use a generic name such as "Unnamed key", or "Default key" if the key is marked as the default key (see below). |
-| algorithm  | string    | **Required.** The encryption algorithm to be used for this key. Currently, only `m.secret_storage.v1.aes-hmac-sha2` is supported.   |
-| passphrase | string    | See [deriving keys from passphrases](#deriving-keys-from-passphrases) section for a description of this property.                   |
-
-Other properties depend on the encryption algorithm, and are described
-below.
-
-A key can be marked as the "default" key by setting the user's
-account\_data with event type `m.secret_storage.default_key` to an
-object that has the ID of the key as its `key` property. The default key
-will be used to encrypt all secrets that the user would expect to be
-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 not default
-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.
-
-`DefaultKey`
-
-| Parameter  | Type      | Description
-|------------|-----------|------------------------------------------|
-| key        | string    | **Required.** The ID of the default key. |
-
-##### Secret storage
-
-Encrypted data is stored in the user's account\_data using the event
-type defined by the feature that uses the data. The account\_data will
-have an `encrypted` property that is a map from key ID to an object. The
-algorithm from the `m.secret_storage.key.[key ID]` data for the given
-key defines how the other properties are interpreted, though it's
-expected that most encryption schemes would have `ciphertext` and `mac`
-properties, where the `ciphertext` property is the unpadded
-base64-encoded ciphertext, and the `mac` is used to ensure the integrity
-of the data.
-
-`Secret`
-
-| Parameter | Type             | Description |
-|-----------|------------------|-------------|
-| encrypted | {string: object} | **Required.** Map from key ID the encrypted data. The exact format for the encrypted data is dependent on the key algorithm. See the definition of `AesHmacSha2EncryptedData` in the [m.secret_storage.v1.aes-hmac-sha2](#msecret_storagev1aes-hmac-sha2) section. |
-
-Example:
-
-Some secret is encrypted using keys with ID `key_id_1` and `key_id_2`:
-
-`org.example.some.secret`:
-
-```
-{
-  "encrypted": {
-    "key_id_1": {
-      "ciphertext": "base64+encoded+encrypted+data",
-      "mac": "base64+encoded+mac",
-      // ... other properties according to algorithm property in
-      // m.secret_storage.key.key_id_1
-    },
-    "key_id_2": {
-      // ...
-    }
-  }
-}
-```
-
-and the key descriptions for the keys would be:
-
-`m.secret_storage.key.key_id_1`:
-
-```
-{
-  "name": "Some key",
-  "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
-  // ... other properties according to algorithm
-}
-```
-
-`m.secret_storage.key.key_id_2`:
-
-```
-{
-  "name": "Some other key",
-  "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
-  // ... other properties according to algorithm
-}
-```
-
-If `key_id_1` is the default key, then we also have:
-
-`m.secret_storage.default_key`:
-
-```
-{
-  "key": "key_id_1"
-}
-```
-
-###### `m.secret_storage.v1.aes-hmac-sha2`
-
-Secrets encrypted using the `m.secret_storage.v1.aes-hmac-sha2`
-algorithm are encrypted using AES-CTR-256, and authenticated using
-HMAC-SHA-256. The secret is encrypted as follows:
-
-1.  Given the secret storage key, generate 64 bytes by performing an
-    HKDF with SHA-256 as the hash, a salt of 32 bytes of 0, and with the
-    secret name as the info. The first 32 bytes are used as the AES key,
-    and the next 32 bytes are used as the MAC key
-2.  Generate 16 random bytes, set bit 63 to 0 (in order to work around
-    differences in AES-CTR implementations), and use this as the AES
-    initialization vector. This becomes the `iv` property, encoded using
-    base64.
-3.  Encrypt the data using AES-CTR-256 using the AES key generated
-    above. This encrypted data, encoded using base64, becomes the
-    `ciphertext` property.
-4.  Pass the raw encrypted data (prior to base64 encoding) through
-    HMAC-SHA-256 using the MAC key generated above. The resulting MAC is
-    base64-encoded and becomes the `mac` property.
-
-`AesHmacSha2EncryptedData`
-
-| Parameter  | Type    | Description
-|------------|---------|------------------------------------------------------------------------|
-| iv         | string  |   **Required.** The 16-byte initialization vector, encoded as base64.  |
-| ciphertext | string  |   **Required.** The AES-CTR-encrypted data, encoded as base64.         |
-| mac        | string  |   **Required.** The MAC, encoded as base64.                            |
-
-For the purposes of allowing clients to check whether a user has
-correctly entered the key, clients should:
-
-1.  encrypt and MAC a message consisting of 32 bytes of 0 as described
-    above, using the empty string as the info parameter to the HKDF in
-    step 1.
-2.  store the `iv` and `mac` in the `m.secret_storage.key.[key ID]`
-    account-data.
-
-`AesHmacSha2KeyDescription`
-
-| Parameter   | Type   | Description                                                                                                                       |
-|-------------|--------|-----------------------------------------------------------------------------------------------------------------------------------|
-| name        | string | Optional. The name of the key.                                                                                                    |
-| algorithm   | string | **Required.** The encryption algorithm to be used for this key. Currently, only `m.secret_storage.v1.aes-hmac-sha2` is supported. |
-| passphrase  | object | See [deriving keys from passphrases](#deriving-keys-from-passphrases) section for a description of this property.                 |
-| iv          | string | The 16-byte initialization vector, encoded as base64.                                                                             |
-| mac         | string | The MAC of the result of encrypting 32 bytes of 0, encoded as base64.                                                             |
-
-For example, the `m.secret_storage.key.key_id` for a key using this
-algorithm could look like:
-
-```json
-{
-  "name": "m.default",
-  "algorithm": "m.secret_storage.v1.aes-hmac-sha2",
-  "iv": "random+data",
-  "mac": "mac+of+encrypted+zeros"
-}
-```
-
-and data encrypted using this algorithm could look like this:
-
-```json
-{
-  "encrypted": {
-      "key_id": {
-        "iv": "16+bytes+base64",
-        "ciphertext": "base64+encoded+encrypted+data",
-        "mac": "base64+encoded+mac"
-      }
-  }
-}
-```
-
-###### Key representation
-
-When a user is given a raw key for `m.secret_storage.v1.aes-hmac-sha2`,
-it will be presented as a string constructed as follows:
-
-1.  The key is prepended by the two bytes `0x8b` and `0x01`
-2.  All the bytes in the string above, including the two header bytes,
-    are XORed together to form a parity byte. This parity byte is
-    appended to the byte string.
-3.  The byte string is encoded using base58, using the same [mapping as
-    is used for Bitcoin
-    addresses](https://en.bitcoin.it/wiki/Base58Check_encoding#Base58_symbol_chart),
-    that is, using the alphabet
-    `123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz`.
-4.  The string is formatted into groups of four characters separated by
-    spaces.
-
-When decoding a raw key, the process should be reversed, with the
-exception that whitespace is insignificant in the user's input.
-
-###### Deriving keys from passphrases
-
-A user may wish to use a chosen passphrase rather than a randomly
-generated key. In this case, information on how to generate the key from
-a passphrase will be stored in the `passphrase` property of the
-`m.secret_storage.key.[key ID]` account-data. The `passphrase` property
-has an `algorithm` property that indicates how to generate the key from
-the passphrase. Other properties of the `passphrase` property are
-defined by the `algorithm` specified.
-
-Currently, the only algorithm defined is `m.pbkdf2`. For the `m.pbkdf2` algorithm, the `passphrase` property has the
-following properties:
-
-| Parameter  | Type    | Description                                                            |
-|------------|---------|------------------------------------------------------------------------|
-| algorithm  | string  | **Required.** Must be `m.pbkdf2`                                       |
-| salt       | string  | **Required.** The salt used in PBKDF2.                                 |
-| iterations | integer | **Required.** The number of iterations to use in PBKDF2.               |
-| bits       | integer | Optional. The number of bits to generate for the key. Defaults to 256. |
-
-The key is generated using PBKDF2 with SHA-512 as the hash, using the
-salt given in the `salt` parameter, and the number of iterations given
-in the `iterations` parameter.
-
-Example:
-
-```
-{
-    "passphrase": {
-        "algorithm": "m.pbkdf2",
-        "salt": "MmMsAlty",
-        "iterations": 100000,
-        "bits": 256
-    },
-    ...
-}
-```
-
-#### Sharing
-
-To request a secret from other devices, a client sends an
-`m.secret.requests` device event with `action` set to `request` and
-`name` set to the identifier of the secret. A device that wishes to
-share the secret will reply with an `m.secret.send` event, encrypted
-using olm. When the original client obtains the secret, it sends an
-`m.secret.request` event with `action` set to `request_cancellation` to
-all devices other than the one that it received the secret from. Clients
-should ignore `m.secret.send` events received from devices that it did
-not send an `m.secret.request` event to.
-
-Clients must ensure that they only share secrets with other devices that
-are allowed to see them. For example, clients should only share secrets
-with the user’s own devices that are verified and may prompt the user to
-confirm sharing the secret.
-
-##### Event definitions
-
-###### `m.secret.request`
-
-Sent by a client to request a secret from another device or to cancel a
-previous request. It is sent as an unencrypted to-device event.
-
-| Parameter             | Type   | Description                                                                            |
-|-----------------------|--------|----------------------------------------------------------------------------------------|
-| name                  | string | Required if ``action`` is ``request``. The name of the secret that is being requested. |
-| action                | enum   | **Required.** One of ["request", "request_cancellation"].                              |
-| requesting_device_id  | string | **Required.** The ID of the device requesting the secret.                              |
-| request_id            | string | **Required.** A random string uniquely identifying (with respect to the requester and the target) the target for a secret. If the secret is requested from multiple devices at the same time, the same ID may be used for every target. The same ID is also used in order to cancel a previous request.                                                  |
-
-Example:
-
-```json
-{
-  "name": "org.example.some.secret",
-  "action": "request",
-  "requesting_device_id": "ABCDEFG",
-  "request_id": "randomly_generated_id_9573"
-}
-```
-
-###### `m.secret.send`
-
-Sent by a client to share a secret with another device, in response to
-an `m.secret.request` event. It must be encrypted as an
-`m.room.encrypted` event, then sent as a to-device event.
-
-| Parameter   | Type   | Description                                                  |
-|-------------|--------|--------------------------------------------------------------|
-| request_id  | string | **Required.** The ID of the request that this a response to. |
-|  secret     | string | **Required.** The contents of the secret.                    |
-
-Example:
-
-```json
-{
-  "request_id": "randomly_generated_id_9573",
-  "secret": "ThisIsASecretDon'tTellAnyone"
-}
-```
diff --git a/content/client-server-api/modules/send_to_device.md b/content/client-server-api/modules/send_to_device.md
deleted file mode 100644
index 586e5416..00000000
--- a/content/client-server-api/modules/send_to_device.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-type: module
----
-
-### Send-to-Device messaging
-
-This module provides a means by which clients can exchange signalling
-messages without them being stored permanently as part of a shared
-communication history. A message is delivered exactly once to each
-client device.
-
-The primary motivation for this API is exchanging data that is
-meaningless or undesirable to persist in the room DAG - for example,
-one-time authentication tokens or key data. It is not intended for
-conversational data, which should be sent using the normal [`/rooms/<room_id>/send`](/client-server-api/#put_matrixclientv3roomsroomidsendeventtypetxnid) API for
-consistency throughout Matrix.
-
-#### Client behaviour
-
-To send a message to other devices, a client should call
-[`/sendToDevice`](/client-server-api/#put_matrixclientv3sendtodeviceeventtypetxnid). Only one message can be sent to each device per
-transaction, and they must all have the same event type. The device ID
-in the request body can be set to `*` to request that the message be
-sent to all known devices.
-
-If there are send-to-device messages waiting for a client, they will be
-returned by [`/sync`](/client-server-api/#get_matrixclientv3sync), as detailed in [Extensions to /sync](/client-server-api/#extensions-to-sync). Clients should
-inspect the `type` of each returned event, and ignore any they do not
-understand.
-
-#### Server behaviour
-
-Servers should store pending messages for local users until they are
-successfully delivered to the destination device. When a client calls
-[`/sync`](/client-server-api/#get_matrixclientv3sync)
-with an access token which corresponds to a device with pending
-messages, the server should list the pending messages, in order of
-arrival, in the response body.
-
-When the client calls `/sync` again with the `next_batch` token from the
-first response, the server should infer that any send-to-device messages
-in that response have been delivered successfully, and delete them from
-the store.
-
-If there is a large queue of send-to-device messages, the server should
-limit the number sent in each `/sync` response. 100 messages is
-recommended as a reasonable limit.
-
-If the client sends messages to users on remote domains, those messages
-should be sent on to the remote servers via
-[federation](/server-server-api#send-to-device-messaging).
-
-#### Protocol definitions
-
-{{% http-api spec="client-server" api="to_device" %}}
-
-##### Extensions to /sync
-
-This module adds the following properties to the [`/sync`](/client-server-api/#get_matrixclientv3sync) response:
-
-| Parameter | Type      | Description                                                                 |
-|-----------|-----------|-----------------------------------------------------------------------------|
-| to_device | ToDevice  | Optional. Information on the send-to-device messages for the client device. |
-
-`ToDevice`
-
-| Parameter | Type      | Description                      |
-|-----------|-----------|----------------------------------|
-| events    | [Event]   | List of send-to-device messages. |
-
-`Event`
-
-| Parameter  | Type         | Description                                                                                     |
-|------------|--------------|-------------------------------------------------------------------------------------------------|
-| content    | EventContent | The content of this event. The fields in this object will vary depending on the type of event.  |
-| sender     | string       | The Matrix user ID of the user who sent this event.                                             |
-| type       | string       | The type of event.                                                                              |
-
-Example response:
-
-```json
-{
-  "next_batch": "s72595_4483_1934",
-  "rooms": {"leave": {}, "join": {}, "invite": {}},
-  "to_device": {
-    "events": [
-      {
-        "sender": "@alice:example.com",
-        "type": "m.new_device",
-        "content": {
-          "device_id": "XYZABCDE",
-          "rooms": ["!726s6s6q:example.com"]
-        }
-      }
-    ]
-  }
-}
-```
diff --git a/content/client-server-api/modules/server_acls.md b/content/client-server-api/modules/server_acls.md
deleted file mode 100644
index eaa4b275..00000000
--- a/content/client-server-api/modules/server_acls.md
+++ /dev/null
@@ -1,61 +0,0 @@
----
-type: module
----
-
-### Server Access Control Lists (ACLs) for rooms
-
-In some scenarios room operators may wish to prevent a malicious or
-untrusted server from participating in their room. Sending an
-[m.room.server\_acl](#mroomserver_acl) state event into a room is an effective way to
-prevent the server from participating in the room at the federation
-level.
-
-Server ACLs can also be used to make rooms only federate with a limited
-set of servers, or retroactively make the room no longer federate with
-any other server, similar to setting the `m.federate` value on the
-[m.room.create](#mroomcreate) event.
-
-{{% event event="m.room.server_acl" %}}
-
-{{% boxes/note %}}
-Port numbers are not supported because it is unclear to parsers whether
-a port number should be matched or an IP address literal. Additionally,
-it is unlikely that one would trust a server running on a particular
-domain's port but not a different port, especially considering the
-server host can easily change ports.
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-CIDR notation is not supported for IP addresses because Matrix does not
-encourage the use of IPs for identifying servers. Instead, a blanket
-`allow_ip_literals` is provided to cover banning them.
-{{% /boxes/note %}}
-
-#### Client behaviour
-
-Clients are not expected to perform any additional duties beyond sending
-the event. Clients should describe changes to the server ACLs to the
-user in the user interface, such as in the timeline.
-
-Clients may wish to kick affected users from the room prior to denying a
-server access to the room to help prevent those servers from
-participating and to provide feedback to the users that they have been
-excluded from the room.
-
-#### Server behaviour
-
-Servers MUST prevent blacklisted servers from sending events or
-participating in the room when an [m.room.server\_acl](#mroomserver_acl) event is
-present in the room state. Which APIs are specifically affected are
-described in the Server-Server API specification.
-
-Servers should still send events to denied servers if they are still
-residents of the room.
-
-#### Security considerations
-
-Server ACLs are only effective if every server in the room honours them.
-Servers that do not honour the ACLs may still permit events sent by
-denied servers into the room, leaking them to other servers in the room.
-To effectively enforce an ACL in a room, the servers that do not honour
-the ACLs should be denied in the room as well.
diff --git a/content/client-server-api/modules/server_notices.md b/content/client-server-api/modules/server_notices.md
deleted file mode 100644
index b0e2fa22..00000000
--- a/content/client-server-api/modules/server_notices.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-type: module
----
-
-### Server Notices
-
-Homeserver hosts often want to send messages to users in an official
-capacity, or have resource limits which affect a user's ability to use
-the homeserver. For example, the homeserver may be limited to a certain
-number of active users per month and has exceeded that limit. To
-communicate this failure to users, the homeserver would use the Server
-Notices room.
-
-The aesthetics of the room (name, topic, avatar, etc) are left as an
-implementation detail. It is recommended that the homeserver decorate
-the room such that it looks like an official room to users.
-
-#### Events
-
-Notices are sent to the client as normal `m.room.message` events with a
-`msgtype` of `m.server_notice` in the server notices room. Events with a
-`m.server_notice` `msgtype` outside of the server notice room must be
-ignored by clients.
-
-The specified values for `server_notice_type` are:
-
-`m.server_notice.usage_limit_reached`
-The server has exceeded some limit which requires the server
-administrator to intervene. The `limit_type` describes the kind of limit
-reached. The specified values for `limit_type` are:
-
-`monthly_active_user`
-The server's number of active users in the last 30 days has exceeded the
-maximum. New connections are being refused by the server. What defines
-"active" is left as an implementation detail, however servers are
-encouraged to treat syncing users as "active".
-
-{{% event event="m.room.message$m.server_notice" %}}
-
-#### Client behaviour
-
-Clients can identify the server notices room by the `m.server_notice`
-tag on the room. Active notices are represented by the [pinned
-events](#mroompinned_events) in the server notices room. Server notice
-events pinned in that room should be shown to the user through special
-UI and not through the normal pinned events interface in the client. For
-example, clients may show warning banners or bring up dialogs to get the
-user's attention. Events which are not server notice events and are
-pinned in the server notices room should be shown just like any other
-pinned event in a room.
-
-The client must not expect to be able to reject an invite to join the
-server notices room. Attempting to reject the invite must result in a
-`M_CANNOT_LEAVE_SERVER_NOTICE_ROOM` error. Servers should not prevent
-the user leaving the room after joining the server notices room, however
-the same error code must be used if the server will prevent leaving the
-room.
-
-#### Server behaviour
-
-Servers should manage exactly 1 server notices room per user. Servers
-must identify this room to clients with the `m.server_notice` tag.
-Servers should invite the target user rather than automatically join
-them to the server notice room.
-
-How servers send notices to clients, and which user they use to send the
-events, is left as an implementation detail for the server.
diff --git a/content/client-server-api/modules/spaces.md b/content/client-server-api/modules/spaces.md
deleted file mode 100644
index e7962488..00000000
--- a/content/client-server-api/modules/spaces.md
+++ /dev/null
@@ -1,254 +0,0 @@
----
-type: module
-weight: 340
----
-
-### Spaces
-
-{{% added-in v="1.2" %}}
-
-Often used to group rooms of similar subject matter (such as a public "Official
-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
-"space-room". The space's name, topic, avatar, aliases, etc are all defined through
-the existing relevant state events within the space-room.
-
-Sending normal [`m.room.message`](#mroommessage) events within the space-room is
-discouraged - clients are not generally expected to have a way to render the timeline
-of the room. As such, space-rooms should be created with [`m.room.power_levels`](#mroompower_levels)
-which prohibit normal events by setting `events_default` to a suitably high number.
-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`](#mroommember), [`m.room.history_visibility`](#mroomhistory_visibility),
-and [`m.room.join_rules`](#mroomjoin_rules). Public spaces are encouraged to have
-a similar setup to public rooms: `world_readable` history visibility, published
-canonical alias, and suitably public `join_rule`. Invites, including third-party
-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
-just rooms with extra functionality on top.
-
-#### Managing rooms/spaces included in a space
-
-Spaces form a hierarchy of rooms which clients can use to structure their room
-list into a tree-like view. The parent/child relationship can be defined in two
-ways: with [`m.space.child`](#mspacechild) state events in the space-room, or with
-[`m.space.parent`](#mspaceparent) state events in the child room.
-
-In most cases, both the child and parent relationship should be defined to aid
-discovery of the space and its rooms. When only a `m.space.child` is used, the space
-is effectively a curated list of rooms which the rooms themselves might not be aware
-of. When only a `m.space.parent` is used, the rooms are "secretly" added to spaces
-with the effect of not being advertised directly by the space.
-
-{{% boxes/warning %}}
-Considering spaces are rooms themselves, it is possible to nest spaces within spaces,
-and it is possible to create a loop. Though the creation of loops is explicitly disallowed,
-implementations might still encounter them and must be careful not to loop infinitely when
-this happens.
-
-Clients and servers should additionally be aware of excessively long trees which may
-cause performance issues.
-{{% /boxes/warning %}}
-
-##### `m.space.child` relationship
-
-When using this approach, the state events get sent into the space-room which is the
-parent to the room. The `state_key` for the event is the child room's ID.
-
-For example, to achieve the following:
-
-```
-#space:example.org
-    #general:example.org (!abcdefg:example.org)
-    !private:example.org
-```
-
-the state of `#space:example.org` would consist of:
-
-*Unimportant fields trimmed for brevity.*
-
-```json
-{
-    "type": "m.space.child",
-    "state_key": "!abcdefg:example.org",
-    "content": {
-        "via": ["example.org"]
-    }
-}
-```
-```json
-{
-    "type": "m.space.child",
-    "state_key": "!private:example.org",
-    "content": {
-        "via": ["example.org"]
-    }
-}
-```
-
-No state events in the child rooms themselves would be required (though they
-can also be present). This allows for users
-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`.
-
-{{% event event="m.space.child" %}}
-
-###### Ordering
-
-When the client is displaying the children of a space, the children should be ordered
-using the algorithm below. In some cases, like a traditional left side room list, the
-client may override the ordering to provide better user experience. A theoretical
-space summary view would however show the children ordered.
-
-Taking the set of space children, first order the children with a valid `order` key
-lexicographically by Unicode code-points such that `\x20` (space) is sorted before
-`\x7E` (`~`). Then, take the remaining children and order them by the `origin_server_ts`
-of their `m.space.child` event in ascending numeric order, placing them after the
-children with a valid `order` key in the resulting set.
-
-In cases where the `order` values are the same, the children are ordered by their
-timestamps.  If the timestamps are the same, the children are ordered lexicographically
-by their room IDs (state keys) in ascending order.
-
-Noting the careful use of ASCII spaces here, the following demonstrates a set of space
-children being ordered appropriately:
-
-*Unimportant fields trimmed for brevity.*
-
-```json
-[
-    {
-        "type": "m.space.child",
-        "state_key": "!b:example.org",
-        "origin_server_ts": 1640341000000,
-        "content": {
-            "order": " ",
-            "via": ["example.org"]
-        }
-    },
-    {
-        "type": "m.space.child",
-        "state_key": "!a:example.org",
-        "origin_server_ts": 1640141000000,
-        "content": {
-            "order": "aaaa",
-            "via": ["example.org"]
-        }
-    },
-    {
-        "type": "m.space.child",
-        "state_key": "!c:example.org",
-        "origin_server_ts": 1640841000000,
-        "content": {
-            "order": "first",
-            "via": ["example.org"]
-        }
-    },
-    {
-        "type": "m.space.child",
-        "state_key": "!e:example.org",
-        "origin_server_ts": 1640641000000,
-        "content": {
-            "via": ["example.org"]
-        }
-    },
-    {
-        "type": "m.space.child",
-        "state_key": "!d:example.org",
-        "origin_server_ts": 1640741000000,
-        "content": {
-            "via": ["example.org"]
-        }
-    }
-]
-```
-
-1. `!b:example.org` is first because `\x20` is before `aaaa` lexically.
-2. `!a:example.org` is next because `aaaa` is before `first` lexically.
-3. `!c:example.org` is next because `first` is the last `order` value.
-4. `!e:example.org` is next because the event timestamp is smallest.
-5. `!d:example.org` is last because the event timestamp is largest.
-
-##### `m.space.parent` relationships
-
-Rooms can additionally claim to be part of a space by populating their own state
-with a parent event. Similar to child events within spaces, the parent event's
-`state_key` is the room ID of the parent space, and they have a similar `via` list
-within their `content` to denote both whether or not the link is valid and which
-servers might be possible to join through.
-
-To avoid situations where a room falsely claims it is part of a given space,
-`m.space.parent` events should be ignored unless one of the following is true:
-
-* A corresponding `m.space.child` event can be found in the supposed parent space.
-* The sender of the `m.space.parent` event has sufficient power level in the
-  supposed parent space to send `m.space.child` state events (there doesn't need
-  to be a matching child event).
-
-{{% boxes/note %}}
-Clients might need to peek into a parent space to inspect the room state if they
-aren't already joined. If the client is unable to peek the state, the link should
-be assumed to be invalid.
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-A consequence of the second condition is that a room admin being demoted in the
-parent space, leaving the parent space, or otherwise being removed from the parent
-space can mean that a previously valid `m.space.parent` event becomes invalid.
-{{% /boxes/note %}}
-
-`m.space.parent` events can additionally include a `canonical` boolean key in their
-`content` to denote that the parent space is the main/primary space for the room.
-This can be used to, for example, have the client find other rooms by peeking into
-that space and suggesting them to the user. Only one canonical parent should exist,
-though this is not enforced. To tiebreak, use the lowest room ID sorted lexicographically
-by Unicode code-points.
-
-{{% event event="m.space.parent" %}}
-
-#### Discovering rooms within spaces
-
-Often the client will want to assist the user in exploring what rooms/spaces are part
-of a space. This can be done with crawling [`m.space.child`](#mspacechild) state events
-in the client and peeking into the rooms to get information like the room name, though
-this is impractical for most cases.
-
-Instead, a hierarchy API is provided to walk the space tree and discover the rooms with
-their aesthetic details.
-
-The [`GET /hierarchy`](#get_matrixclientv1roomsroomidhierarchy) API works in a depth-first
-manner: when it encounters another space as a child it recurses into that space before
-returning non-space children.
-
-{{% boxes/warning %}}
-Though prohibited, it is still possible for loops to occur. Servers should gracefully
-break loops.
-
-Additionally, a given child room might appear multiple times in the response as a
-grandchild (for example).
-{{% /boxes/warning %}}
-
-{{% http-api spec="client-server" api="space_hierarchy" %}}
-
-##### Server behaviour
-
-In the case where the server does not have access to the state of a child room, it can
-request the information over federation with the
-[`GET /hierarchy`](/server-server-api/#get_matrixfederationv1hierarchyroomid) API. The
-response to this endpoint should be cached for a period of time. The response might
-additionally contain information about rooms the requesting user is already a member
-of, or that the server is aware of - the local data should be used instead of the remote
-server's data.
-
-Note that the response to the client endpoint is contextual based on the user. Servers are
-encouraged to cache the data for a period of time, though permission checks may need to
-be performed to ensure the response is accurate for that user.
diff --git a/content/client-server-api/modules/sso_login.md b/content/client-server-api/modules/sso_login.md
deleted file mode 100644
index 923d9cd1..00000000
--- a/content/client-server-api/modules/sso_login.md
+++ /dev/null
@@ -1,325 +0,0 @@
----
-type: module
----
-
-### SSO client login/authentication
-
-Single Sign-On (SSO) is a generic term which refers to protocols which
-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 to delegate user authentication
-to an external authentication server supporting one of these protocols.
-In this process, there are three systems involved:
-
--   A Matrix client, using the APIs defined this specification, which
-    is seeking to authenticate a user to a Matrix homeserver.
--   A Matrix homeserver, implementing the APIs defined in this
-    specification, but which is delegating user authentication to the
-    authentication server.
--   An "authentication server", which is responsible for
-    authenticating the user.
-
-This specification is concerned only with communication between the
-Matrix client and the homeserver, and is independent of the SSO protocol
-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](#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
-at the authentication server. Once the user is authenticated, their
-browser is redirected to that URI. It is up to the Matrix homeserver
-implementation to implement a suitable endpoint. For example, for CAS
-authentication the homeserver should provide a means for the
-administrator to configure where the CAS server is and the REST
-endpoints which consume the ticket.
-
-Homeservers may optionally expose multiple possible SSO options for
-the user to pursue, typically in the form of several "log in with $provider"
-buttons. These are known as "identity providers" (IdPs).
-
-#### Client login via SSO
-
-An overview of the process is as follows:
-
-1.  The Matrix client calls [`GET /login`](/client-server-api/#get_matrixclientv3login) to find the supported login
-    types, and the homeserver includes a flow with
-    `"type": "m.login.sso"` in the response.
-2.  To initiate the `m.login.sso` login type, the Matrix client
-    instructs the user's browser to navigate to the
-    [`/login/sso/redirect`](/client-server-api/#get_matrixclientv3loginssoredirect) endpoint on the user's homeserver.
-    Note that this may be the IdP-dependent version of the endpoint if the
-    user has selected one of the `identity_providers` from the flow.
-3.  The homeserver responds with an HTTP redirect to the SSO user
-    interface, which the browser follows.
-4.  The authentication server and the homeserver interact to verify the
-    user's identity and other authentication information, potentially
-    using a number of redirects.
-5.  The browser is directed to the `redirectUrl` provided by the client
-    with a `loginToken` query parameter for the client to log in with.
-6.  The client exchanges the login token for an access token by calling
-    the [`/login`](/client-server-api/#post_matrixclientv3login) endpoint with a `type` of `m.login.token`.
-
-For native applications, typically steps 1 to 4 are carried out by
-opening an embedded web view.
-
-These steps are illustrated as follows:
-
-```
-    Matrix Client                        Matrix Homeserver      Auth Server
-        |                                       |                   |
-        |-------------(0) GET /login----------->|                   |
-        |<-------------login types--------------|                   |
-        |                                       |                   |
-        |   Webview                             |                   |
-        |      |                                |                   |
-        |----->|                                |                   |
-        |      |--(1) GET /login/sso/redirect-->|                   |
-        |      |<---------(2) 302---------------|                   |
-        |      |                                |                   |
-        |      |<========(3) Authentication process================>|
-        |      |                                |                   |
-        |      |<--(4) redirect to redirectUrl--|                   |
-        |<-----|                                |                   |
-        |                                       |                   |
-        |---(5) POST /login with login token--->|                   |
-        |<-------------access token-------------|                   |
-```
-
-{{% boxes/note %}}
-In the older [r0.4.0
-version](https://matrix.org/docs/spec/client_server/r0.4.0.html#cas-based-client-login)
-of this specification it was possible to authenticate via CAS when the
-homeserver provides a `m.login.cas` login flow. This specification
-deprecates the use of `m.login.cas` to instead prefer `m.login.sso`,
-which is the same process with the only change being which redirect
-endpoint to use: for `m.login.cas`, use `/cas/redirect` and for
-`m.login.sso` use `/sso/redirect` (described below). The endpoints are
-otherwise the same.
-{{% /boxes/note %}}
-
-{{% definition path="api/client-server/definitions/sso_login_flow" %}}
-
-##### Client behaviour
-
-The client starts the process by instructing the browser to navigate to
-[`/login/sso/redirect`](/client-server-api/#get_matrixclientv3loginssoredirect)
-(or [`/login/sso/redirect/{idpId}`](/client-server-api/#get_matrixclientv3loginssoredirectidpid)
-when using one of the `identity_providers`)
-with an appropriate `redirectUrl`. Once
-authentication is successful, the browser will be redirected to that
-`redirectUrl`.
-
-{{% http-api spec="client-server" api="sso_login_redirect" %}}
-
-###### Security considerations
-
-1.  CSRF attacks via manipulation of parameters on the `redirectUrl`
-
-    Clients should validate any requests to the `redirectUrl`. In
-    particular, it may be possible for attackers to falsify any query
-    parameters, leading to cross-site request forgery (CSRF) attacks.
-
-    For example, consider a web-based client at
-    `https://client.example.com`, which wants to initiate SSO login on
-    the homeserver at `server.example.org`. It does this by storing the
-    homeserver name in a query parameter for the `redirectUrl`: it
-    redirects to
-    `https://server.example.org/login/sso/redirect?redirectUrl=https://client.example.com?hs=server.example.org`.
-
-    An attacker could trick a victim into following a link to
-    `https://server.example.org/login/sso/redirect?redirectUrl=https://client.example.com?hs=evil.com`,
-    which would result in the client sending a login token for the
-    victim's account to the attacker-controlled site `evil.com`.
-
-    To guard against this, clients MUST NOT store state (such as the
-    address of the homeserver being logged into) anywhere it can be
-    modified by external processes.
-
-    Instead, the state could be stored in
-    [localStorage](https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage)
-    or in a cookie.
-
-2.  For added security, clients SHOULD include a unique identifier in
-    the `redirectUrl` and reject any callbacks that do not contain a
-    recognised identifier, to guard against unsolicited login attempts
-    and replay attacks.
-
-##### Server behaviour
-
-Servers should note that `identity_providers` are optional, and older clients
-might not interpret the value correctly. In these cases, the client will use
-the generic `/redirect` endpoint instead of the `/redirect/{idpId}` endpoint.
-
-###### Redirecting to the Authentication server
-
-The server should handle
-`/_matrix/client/v3/login/sso/redirect` as follows:
-
-1.  It should build a suitable request for the SSO system.
-2.  It should store enough state that the flow can be securely resumed
-    after the SSO process completes. One way to do this is by storing a
-    cookie which is stored in the user's browser, by adding a
-    `Set-Cookie` header to the response.
-3.  It should redirect the user's browser to the SSO login page with the
-    appropriate parameters.
-
-See also the "Security considerations" below.
-
-###### Handling the callback from the Authentication server
-
-Note that there will normally be a single callback URI which is used for
-both login and user-interactive authentication: it is up to the
-homeserver implementation to distinguish which is taking place.
-
-The homeserver should validate the response from the SSO system: this
-may require additional calls to the authentication server, and/or may
-require checking a signature on the response.
-
-The homeserver then proceeds as follows:
-
-1.  The homeserver MUST map the user details received from the
-    authentication server to a valid [Matrix user
-    identifier](/appendices#user-identifiers). The guidance in
-    [Mapping from other character
-    sets](/appendices#mapping-from-other-character-sets) may be
-    useful.
-2.  If the generated user identifier represents a new user, it should be
-    registered as a new user.
-3.  The homeserver should generate a short-term login token. This is an
-    opaque token, suitable for use with the `m.login.token` type of the
-    [`/login`](/client-server-api/#post_matrixclientv3login) API. The lifetime of this token SHOULD be limited to
-    around five seconds.
-4.  The homeserver adds a query parameter of `loginToken`, with the
-    value of the generated login token, to the `redirectUrl` given in
-    the `/_matrix/client/v3/login/sso/redirect`
-    request. (Note: `redirectURL` may or may not include existing query
-    parameters. If it already includes one or more `loginToken`
-    parameters, they should be removed before adding the new one.)
-5.  The homeserver redirects the user's browser to the URI thus built.
-
-##### Security considerations
-
-1.  Homeservers should ensure that login tokens are not sent to
-    malicious clients.
-
-    For example, consider a homeserver at `server.example.org`. An
-    attacker tricks a victim into following a link to
-    `https://server.example.org/login/sso/redirect?redirectUrl=https://evil.com`,
-    resulting in a login token being sent to the attacker-controlled
-    site `evil.com`. This is a form of cross-site request forgery
-    (CSRF).
-
-    To mitigate this, Homeservers SHOULD confirm with the user that they
-    are happy to grant access to their matrix account to the site named
-    in the `redirectUrl`. This can be done either *before* redirecting
-    to the SSO login page when handling the
-    `/_matrix/client/v3/login/sso/redirect`
-    endpoint, or *after* login when handling the callback from the
-    authentication server. (If the check is performed before
-    redirecting, it is particularly important that the homeserver guards
-    against unsolicited authentication attempts as below).
-
-    It may be appropriate to whitelist a set of known-trusted client
-    URLs in this process. In particular, the homeserver's own [login
-    fallback](#login-fallback) implementation could be excluded.
-
-2.  For added security, homeservers SHOULD guard against unsolicited
-    authentication attempts by tracking pending requests. One way to do
-    this is to set a cookie when handling
-    `/_matrix/client/v3/login/sso/redirect`, which
-    is checked and cleared when handling the callback from the
-    authentication server.
-
-#### SSO during User-Interactive Authentication
-
-[User-interactive authentication](#user-interactive-authentication-api) is used by client-server endpoints
-which require additional confirmation of the user's identity (beyond
-holding an access token). Typically this means that the user must
-re-enter their password, but for homeservers which delegate to an SSO
-server, this means redirecting to the authentication server during
-user-interactive auth.
-
-The implementation of this is based on the [Fallback](#fallback) mechanism for
-user-interactive auth.
-
-#### Client behaviour
-
-Clients do not need to take any particular additional steps beyond
-ensuring that the fallback mechanism has been implemented, and treating
-the `m.login.sso` authentication type the same as any other unknown type
-(i.e. they should open a browser window for
-`/_matrix/client/v3/auth/m.login.sso/fallback/web?session=<session_id>`.
-Once the flow has completed, the client retries the request with the
-session only.)
-
-#### Server behaviour
-
-##### Redirecting to the Authentication server
-
-The server should handle
-`/_matrix/client/v3/auth/m.login.sso/fallback/web`
-in much the same way as
-`/_matrix/client/v3/login/sso/redirect`, which is to
-say:
-
-1.  It should build a suitable request for the SSO system.
-2.  It should store enough state that the flow can be securely resumed
-    after the SSO process completes. One way to do this is by storing a
-    cookie which is stored in the user's browser, by adding a
-    `Set-Cookie` header to the response.
-3.  It should redirect the user's browser to the SSO login page with the
-    appropriate parameters.
-
-See also the "Security considerations" below.
-
-###### Handling the callback from the Authentication server
-
-Note that there will normally be a single callback URI which is used for
-both login and user-interactive authentication: it is up to the
-homeserver implementation to distinguish which is taking place.
-
-The homeserver should validate the response from the SSO system: this
-may require additional calls to the authentication server, and/or may
-require checking a signature on the response.
-
-The homeserver then returns the [user-interactive authentication
-fallback completion](#fallback) page to the user's browser.
-
-###### Security considerations
-
-1.  Confirming the operation
-
-    The homeserver SHOULD confirm that the user is happy for the
-    operation to go ahead. The goal of the user-interactive
-    authentication operation is to guard against a compromised
-    `access_token` being used to take over the user's account. Simply
-    redirecting the user to the SSO system is insufficient, since they
-    may not realise what is being asked of them, or the SSO system may
-    even confirm the authentication automatically.
-
-    For example, the homeserver might serve a page with words to the
-    effect of:
-
-    > A client is trying to remove a device from your account. To
-    > confirm this action, re-authenticate with single sign-on. If you
-    > did not expect this, your account may be compromised!
-
-    This confirmation could take place before redirecting to the SSO
-    authentication page (when handling the
-    `/_matrix/client/v3/auth/m.login.sso/fallback/web`
-    endpoint), or *after* authentication when handling the callback from
-    the authentication server. (If the check is performed before
-    redirecting, it is particularly important that the homeserver guards
-    against unsolicited authentication attempts as below).
-
-2.  For added security, homeservers SHOULD guard against unsolicited
-    authentication attempts by tracking pending requests. One way to do
-    this is to set a cookie when handling
-    `/_matrix/client/v3/auth/m.login.sso/fallback/web`,
-    which is checked and cleared when handling the callback from the
-    authentication server.
diff --git a/content/client-server-api/modules/stickers.md b/content/client-server-api/modules/stickers.md
deleted file mode 100644
index aa10a655..00000000
--- a/content/client-server-api/modules/stickers.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-type: module
----
-
-### Sticker Messages
-
-This module allows users to send sticker messages in to rooms or direct
-messaging sessions.
-
-Sticker messages are specialised image messages that are displayed
-without controls (e.g. no "download" link, or light-box view on click,
-as would be displayed for for [m.image](#mimage) events).
-
-Sticker messages are intended to provide simple "reaction" events in the
-message timeline. The matrix client should provide some mechanism to
-display the sticker "body" e.g. as a tooltip on hover, or in a modal
-when the sticker image is clicked.
-
-#### Events
-
-Sticker events are received as a single `m.sticker` event in the
-`timeline` section of a room, in a `/sync`.
-
-{{% event event="m.sticker" %}}
-
-#### Client behaviour
-
-Clients supporting this message type should display the image content
-from the event URL directly in the timeline.
-
-A thumbnail image should be provided in the `info` object. This is
-largely intended as a fallback for clients that do not fully support the
-`m.sticker` event type. In most cases it is fine to set the thumbnail
-URL to the same URL as the main event content.
-
-It is recommended that sticker image content should be 512x512 pixels in
-size or smaller. The dimensions of the image file should be twice the
-intended display size specified in the `info` object in order to assist
-rendering sharp images on higher DPI screens.
diff --git a/content/client-server-api/modules/tags.md b/content/client-server-api/modules/tags.md
deleted file mode 100644
index 379cce8b..00000000
--- a/content/client-server-api/modules/tags.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-type: module
----
-
-### Room Tagging
-
-Users can add tags to rooms. Tags are namespaced strings used to label
-rooms. A room may have multiple tags. Tags are only visible to the user
-that set them but are shared across all their devices.
-
-#### Events
-
-The tags on a room are received as single `m.tag` event in the
-`account_data` section of a room. The content of the `m.tag` event is a
-`tags` key whose value is an object mapping the name of each tag to
-another object.
-
-The JSON object associated with each tag gives information about the
-tag, e.g how to order the rooms with a given tag.
-
-Ordering information is given under the `order` key as a number between
-0 and 1. The numbers are compared such that 0 is displayed first.
-Therefore a room with an `order` of `0.2` would be displayed before a
-room with an `order` of `0.7`. If a room has a tag without an `order`
-key then it should appear after the rooms with that tag that have an
-`order` key.
-
-The name of a tag MUST NOT exceed 255 bytes.
-
-The tag namespace is defined as follows:
-
--   The namespace `m.*` is reserved for tags defined in the Matrix
-    specification. Clients must ignore any tags in this namespace they
-    don't understand.
--   The namespace `u.*` is reserved for user-defined tags. The portion
-    of the string after the `u.` is defined to be the display name of
-    this tag. No other semantics should be inferred from tags in this
-    namespace.
--   A client or app willing to use special tags for advanced
-    functionality should namespace them similarly to state keys:
-    `tld.name.*`
--   Any tag in the `tld.name.*` form but not matching the namespace of
-    the current client should be ignored
--   Any tag not matching the above rules should be interpreted as a user
-    tag from the `u.*` namespace, as if the name had already had `u.`
-    stripped from the start (ie. the name of the tag is used as the
-    display name directly). These non-namespaced tags are supported for
-    historical reasons. New tags should use one of the defined
-    namespaces above.
-
-Several special names are listed in the specification: The following
-tags are defined in the `m.*` namespace:
-
--   `m.favourite`: The user's favourite rooms. These should be shown
-    with higher precedence than other rooms.
--   `m.lowpriority`: These should be shown with lower precedence than
-    others.
--   `m.server_notice`: Used to identify [Server Notice
-    Rooms](#server-notices).
-
-{{% event event="m.tag" %}}
-
-#### Client Behaviour
-
-{{% http-api spec="client-server" api="tags" %}}
diff --git a/content/client-server-api/modules/third_party_invites.md b/content/client-server-api/modules/third_party_invites.md
deleted file mode 100644
index 2635347d..00000000
--- a/content/client-server-api/modules/third_party_invites.md
+++ /dev/null
@@ -1,240 +0,0 @@
----
-type: module
----
-
-### Third party invites
-
-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` with the details of the
-third party identifier.
-
-The homeserver asks the identity server whether a Matrix user ID is
-known for that identifier:
-
--   If it is, an invite is simply issued for that user.
--   If it is not, the homeserver asks the identity server to record the
-    details of the invitation, and to notify the invitee's homeserver of
-    this pending invitation if it gets a binding for this identifier in
-    the future. The identity server returns a token and public key to
-    the inviting homeserver.
-
-When the invitee's homeserver receives the notification of the binding,
-it should insert an `m.room.member` event into the room's graph for that
-user, with `content.membership` = `invite`, as well as a
-`content.third_party_invite` property which contains proof that the
-invitee does indeed own that third party identifier. See the
-[m.room.member](#mroommember) schema for more information.
-
-#### Events
-
-{{% event event="m.room.third_party_invite" %}}
-
-#### Client behaviour
-
-A client asks a server to invite a user by their third party identifier.
-
-{{% http-api spec="client-server" api="third_party_membership" %}}
-
-#### Server behaviour
-
-Upon receipt of an `/invite`, the server is expected to look up the
-third party identifier with the provided identity server. If the lookup
-yields a result for a Matrix User ID then the normal invite process can
-be initiated. This process ends up looking like this:
-
-```
-    +---------+                         +-------------+                                    +-----------------+
-    | Client  |                         | Homeserver  |                                    | IdentityServer  |
-    +---------+                         +-------------+                                    +-----------------+
-        |                                     |                                                    |
-        | POST /invite                        |                                                    |
-        |------------------------------------>|                                                    |
-        |                                     |                                                    |
-        |                                     | GET /lookup                                        |
-        |                                     |--------------------------------------------------->|
-        |                                     |                                                    |
-        |                                     |                                     User ID result |
-        |                                     |<---------------------------------------------------|
-        |                                     |                                                    |
-        |                                     | Invite process for the discovered User ID          |
-        |                                     |------------------------------------------          |
-        |                                     |                                         |          |
-        |                                     |<-----------------------------------------          |
-        |                                     |                                                    |
-        |        Complete the /invite request |                                                    |
-        |<------------------------------------|                                                    |
-        |                                     |                                                    |
-```
-
-However, if the lookup does not yield a bound User ID, the homeserver
-must store the invite on the identity server and emit a valid
-`m.room.third_party_invite` event to the room. This process ends up
-looking like this:
-
-```
-    +---------+                         +-------------+                                               +-----------------+
-    | Client  |                         | Homeserver  |                                               | IdentityServer  |
-    +---------+                         +-------------+                                               +-----------------+
-        |                                     |                                                               |
-        | POST /invite                        |                                                               |
-        |------------------------------------>|                                                               |
-        |                                     |                                                               |
-        |                                     | GET /lookup                                                   |
-        |                                     |-------------------------------------------------------------->|
-        |                                     |                                                               |
-        |                                     |                                             "no users" result |
-        |                                     |<--------------------------------------------------------------|
-        |                                     |                                                               |
-        |                                     | POST /store-invite                                            |
-        |                                     |-------------------------------------------------------------->|
-        |                                     |                                                               |
-        |                                     |          Information needed for the m.room.third_party_invite |
-        |                                     |<--------------------------------------------------------------|
-        |                                     |                                                               |
-        |                                     | Emit m.room.third_party_invite to the room                    |
-        |                                     |-------------------------------------------                    |
-        |                                     |                                          |                    |
-        |                                     |<------------------------------------------                    |
-        |                                     |                                                               |
-        |        Complete the /invite request |                                                               |
-        |<------------------------------------|                                                               |
-        |                                     |                                                               |
-```
-
-All homeservers MUST verify the signature in the 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
-specification) MUST validate that the public key used for signing is
-still valid, by checking `key_validity_url` in the above described way.
-
-No other homeservers may reject the joining of the room on the basis of
-`key_validity_url`, this is so that all homeservers have a consistent
-view of the room. They may, however, indicate to their clients that a
-member's membership is questionable.
-
-For example, given H1, H2, and H3 as homeservers, UserA as a user of H1,
-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.
-
-```
-    +-------+ +-----------------+         +-----+                                          +-----+           +-----+                      +-----+
-    | UserA | | ThirdPartyUser  |         | H1  |                                          | H2  |           | H3  |                      | IS  |
-    +-------+ +-----------------+         +-----+                                          +-----+           +-----+                      +-----+
-        |              |                     |                                                |                 |                            |
-        | POST /invite for ThirdPartyUser    |                                                |                 |                            |
-        |----------------------------------->|                                                |                 |                            |
-        |              |                     |                                                |                 |                            |
-        |              |                     | GET /lookup                                    |                 |                            |
-        |              |                     |---------------------------------------------------------------------------------------------->|
-        |              |                     |                                                |                 |                            |
-        |              |                     |                                                |                Lookup results (empty object) |
-        |              |                     |<----------------------------------------------------------------------------------------------|
-        |              |                     |                                                |                 |                            |
-        |              |                     | POST /store-invite                             |                 |                            |
-        |              |                     |---------------------------------------------------------------------------------------------->|
-        |              |                     |                                                |                 |                            |
-        |              |                     |                                                |      Token, keys, etc for third party invite |
-        |              |                     |<----------------------------------------------------------------------------------------------|
-        |              |                     |                                                |                 |                            |
-        |              |                     | (Federation) Emit m.room.third_party_invite    |                 |                            |
-        |              |                     |----------------------------------------------->|                 |                            |
-        |              |                     |                                                |                 |                            |
-        |           Complete /invite request |                                                |                 |                            |
-        |<-----------------------------------|                                                |                 |                            |
-        |              |                     |                                                |                 |                            |
-        |              | Verify identity     |                                                |                 |                            |
-        |              |-------------------------------------------------------------------------------------------------------------------->|
-        |              |                     |                                                |                 |                            |
-        |              |                     |                                                |                 |          POST /3pid/onbind |
-        |              |                     |                                                |                 |<---------------------------|
-        |              |                     |                                                |                 |                            |
-        |              |                     |                         PUT /exchange_third_party_invite/:roomId |                            |
-        |              |                     |<-----------------------------------------------------------------|                            |
-        |              |                     |                                                |                 |                            |
-        |              |                     | Verify the request                             |                 |                            |
-        |              |                     |-------------------                             |                 |                            |
-        |              |                     |                  |                             |                 |                            |
-        |              |                     |<------------------                             |                 |                            |
-        |              |                     |                                                |                 |                            |
-        |              |                     | (Federation) Emit m.room.member for invite     |                 |                            |
-        |              |                     |----------------------------------------------->|                 |                            |
-        |              |                     |                                                |                 |                            |
-        |              |                     |                                                |                 |                            |
-        |              |                     | (Federation) Emit the m.room.member event sent to H2             |                            |
-        |              |                     |----------------------------------------------------------------->|                            |
-        |              |                     |                                                |                 |                            |
-        |              |                     | Complete /exchange_third_party_invite/:roomId request            |                            |
-        |              |                     |----------------------------------------------------------------->|                            |
-        |              |                     |                                                |                 |                            |
-        |              |                     |                                                |                 | Participate in the room    |
-        |              |                     |                                                |                 |------------------------    |
-        |              |                     |                                                |                 |                       |    |
-        |              |                     |                                                |                 |<-----------------------    |
-        |              |                     |                                                |                 |                            |
-```
-
-Note that when H1 sends the `m.room.member` event to H2 and H3 it does
-not have to block on either server's receipt of the event. Likewise, H1
-may complete the `/exchange_third_party_invite/:roomId` request at the
-same time as sending the `m.room.member` event to H2 and H3.
-Additionally, H3 may complete the `/3pid/onbind` request it got from IS
-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
-/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.
-
-The reason that no other homeserver may reject the event based on
-checking `key_validity_url` is that we must ensure event acceptance is
-deterministic. If some other participating server doesn't have a network
-path to the keyserver, or if the keyserver were to go offline, or revoke
-its keys, that other server would reject the event and cause the
-participating servers' graphs to diverge. This relies on participating
-servers trusting each other, but that trust is already implied by the
-server-server protocol. Also, the public key signature verification must
-still be performed, so the attack surface here is minimized.
-
-#### Security considerations
-
-There are a number of privacy and trust implications to this module.
-
-It is important for user privacy that leaking the mapping between a
-matrix user ID and a third party identifier is hard. In particular,
-being able to look up all third party identifiers from a matrix user ID
-(and accordingly, being able to link each third party identifier) should
-be avoided wherever possible. To this end, the third party identifier is
-not put in any event, rather an opaque display name provided by the
-identity server is put into the events. Clients should not remember or
-display third party identifiers from invites, other than for the use of
-the inviter themself.
-
-Homeservers are not required to trust any particular identity server(s).
-It is generally a client's responsibility to decide which identity
-servers it trusts, not a homeserver's. Accordingly, this API takes
-identity servers as input from end users, and doesn't have any specific
-trusted set. It is possible some homeservers may want to supply
-defaults, or reject some identity servers for *its* users, but no
-homeserver is allowed to dictate which identity servers *other*
-homeservers' users trust.
-
-There is some risk of denial of service attacks by flooding homeservers
-or identity servers with many requests, or much state to store.
-Defending against these is left to the implementer's discretion.
diff --git a/content/client-server-api/modules/third_party_networks.md b/content/client-server-api/modules/third_party_networks.md
deleted file mode 100644
index 924d820b..00000000
--- a/content/client-server-api/modules/third_party_networks.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-type: module
----
-
-### Third Party Networks
-
-Application services can provide access to third party networks via
-bridging. This allows Matrix users to communicate with users on other
-communication platforms, with messages ferried back and forth by the
-application service. A single application service may bridge multiple
-third party networks, and many individual locations within those
-networks. A single third party network location may be bridged to
-multiple Matrix rooms.
-
-#### Third Party Lookups
-
-A client may wish to provide a rich interface for joining third party
-locations and connecting with third party users. Information necessary
-for such an interface is provided by third party lookups.
-
-{{% http-api spec="client-server" api="third_party_lookup" %}}
diff --git a/content/client-server-api/modules/typing_notifications.md b/content/client-server-api/modules/typing_notifications.md
deleted file mode 100644
index 722c011f..00000000
--- a/content/client-server-api/modules/typing_notifications.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-type: module
----
-
-### Typing Notifications
-
-Users may wish to be informed when another user is typing in a room.
-This can be achieved using typing notifications. These are ephemeral
-events scoped to a `room_id`. This means they do not form part of the
-[Event Graph](index.html#event-graphs) but still have a `room_id` key.
-
-#### Events
-
-{{% event event="m.typing" %}}
-
-#### Client behaviour
-
-When a client receives an `m.typing` event, it MUST use the user ID list
-to **REPLACE** its knowledge of every user who is currently typing. The
-reason for this is that the server *does not remember* users who are not
-currently typing as that list gets big quickly. The client should mark
-as not typing any user ID who is not in that list.
-
-It is recommended that clients store a `boolean` indicating whether the
-user is typing or not. Whilst this value is `true` a timer should fire
-periodically every N seconds to send a typing HTTP request. The value of
-N is recommended to be no more than 20-30 seconds. This request should
-be re-sent by the client to continue informing the server the user is
-still typing. As subsequent requests will replace older requests, a
-safety margin of 5 seconds before the expected timeout runs out is
-recommended. When the user stops typing, the state change of the
-`boolean` to `false` should trigger another HTTP request to inform the
-server that the user has stopped typing.
-
-{{% http-api spec="client-server" api="typing" %}}
-
-#### Security considerations
-
-Clients may not wish to inform everyone in a room that they are typing
-and instead only specific users in the room.
diff --git a/content/client-server-api/modules/voip_events.md b/content/client-server-api/modules/voip_events.md
deleted file mode 100644
index b4930fac..00000000
--- a/content/client-server-api/modules/voip_events.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-type: module
----
-
-### Voice over IP
-
-This module outlines how two users in a room can set up a Voice over IP
-(VoIP) call to each other. Voice and video calls are built upon the
-WebRTC 1.0 standard. Call signalling is achieved by sending [message
-events](#events) to the room. In this version of the spec, only two-party
-communication is supported (e.g. between two peers, or between a peer
-and a multi-point conferencing unit). This means that clients MUST only
-send call events to rooms with exactly two participants.
-
-#### Events
-
-{{% event-group group_name="m.call" %}}
-
-#### Client behaviour
-
-A call is set up with message events exchanged as follows:
-
-```
-    Caller                    Callee
-    [Place Call]
-    m.call.invite ----------->
-    m.call.candidate -------->
-    [..candidates..] -------->
-                            [Answers call]
-           <--------------- m.call.answer
-     [Call is active and ongoing]
-           <--------------- m.call.hangup
-```
-
-Or a rejected call:
-
-```
-    Caller                      Callee
-    m.call.invite ------------>
-    m.call.candidate --------->
-    [..candidates..] --------->
-                             [Rejects call]
-             <-------------- m.call.hangup
-```
-
-Calls are negotiated according to the WebRTC specification.
-
-##### Glare
-
-"Glare" is a problem which occurs when two users call each other at
-roughly the same time. This results in the call failing to set up as
-there already is an incoming/outgoing call. A glare resolution algorithm
-can be used to determine which call to hangup and which call to answer.
-If both clients implement the same algorithm then they will both select
-the same call and the call will be successfully connected.
-
-As calls are "placed" to rooms rather than users, the glare resolution
-algorithm outlined below is only considered for calls which are to the
-same room. The algorithm is as follows:
-
--   If an `m.call.invite` to a room is received whilst the client is
-    **preparing to send** an `m.call.invite` to the same room:
-    -   the client should cancel its outgoing call and instead
-        automatically accept the incoming call on behalf of the user.
--   If an `m.call.invite` to a room is received **after the client has
-    sent** an `m.call.invite` to the same room and is waiting for a
-    response:
-    -   the client should perform a lexicographical comparison of the
-        call IDs of the two calls and use the *lesser* of the two calls,
-        aborting the greater. If the incoming call is the lesser, the
-        client should accept this call on behalf of the user.
-
-The call setup should appear seamless to the user as if they had simply
-placed a call and the other party had accepted. This means any media
-stream that had been setup for use on a call should be transferred and
-used for the call that replaces it.
-
-#### Server behaviour
-
-The homeserver MAY provide a TURN server which clients can use to
-contact the remote party. The following HTTP API endpoints will be used
-by clients in order to get information about the TURN server.
-
-{{% http-api spec="client-server" api="voip" %}}
-
-#### Security considerations
-
-Calls should only be placed to rooms with one other user in them. If
-they are placed to group chat rooms it is possible that another user
-will intercept and answer the call.
diff --git a/content/identity-service-api.md b/content/identity-service-api.md
deleted file mode 100644
index aa648098..00000000
--- a/content/identity-service-api.md
+++ /dev/null
@@ -1,400 +0,0 @@
----
-title: "Identity Service API"
-weight: 40
-type: docs
----
-
-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
-questions about the identities of users. In particular, it stores
-associations of the form "identifier X represents the same user as
-identifier Y", where identities may exist on different systems (such as
-email addresses, phone numbers, Matrix user IDs, etc).
-
-The identity server has some private-public keypairs. When asked about
-an association, it will sign details of the association with its private
-key. Clients may validate the assertions about associations by verifying
-the signature with the public key of the identity server.
-
-In general, identity servers are treated as reliable oracles. They do
-not necessarily provide evidence that they have validated associations,
-but claim to have done so. Establishing the trustworthiness of an
-individual identity server is left as an exercise for the client.
-
-3PID types are described in [3PID Types](/appendices#pid-types)
-Appendix.
-
-## API standards
-
-The mandatory baseline for identity server communication in Matrix is
-exchanging JSON objects over HTTP APIs. HTTPS is required for
-communication, and all API calls use a Content-Type of
-`application/json`. In addition, strings MUST be encoded as UTF-8.
-
-Any errors which occur at the Matrix API level MUST return a "standard
-error response". This is a JSON object which looks like:
-
-```json
-{
-  "errcode": "<error code>",
-  "error": "<error message>"
-}
-```
-
-The `error` string will be a human-readable error message, usually a
-sentence explaining what went wrong. The `errcode` string will be a
-unique string which can be used to handle an error message e.g.
-`M_FORBIDDEN`. There may be additional keys depending on the error, but
-the keys `error` and `errcode` MUST always be present.
-
-Some standard error codes are below:
-
-`M_NOT_FOUND`
-The resource requested could not be located.
-
-`M_MISSING_PARAMS`
-The request was missing one or more parameters.
-
-`M_INVALID_PARAM`
-The request contained one or more invalid parameters.
-
-`M_SESSION_NOT_VALIDATED`
-The session has not been validated.
-
-`M_NO_VALID_SESSION`
-A session could not be located for the given parameters.
-
-`M_SESSION_EXPIRED`
-The session has expired and must be renewed.
-
-`M_INVALID_EMAIL`
-The email address provided was not valid.
-
-`M_EMAIL_SEND_ERROR`
-There was an error sending an email. Typically seen when attempting to
-verify ownership of a given email address.
-
-`M_INVALID_ADDRESS`
-The provided third party address was not valid.
-
-`M_SEND_ERROR`
-There was an error sending a notification. Typically seen when
-attempting to verify ownership of a given third party address.
-
-`M_UNRECOGNIZED`
-The request contained an unrecognised value, such as an unknown token or
-medium.
-
-`M_THREEPID_IN_USE`
-The third party identifier is already in use by another user. Typically
-this error will have an additional `mxid` property to indicate who owns
-the third party identifier.
-
-`M_UNKNOWN`
-An unknown error has occurred.
-
-{{% http-api spec="identity" api="versions" %}}
-
-## Privacy
-
-Identity is a privacy-sensitive issue. While the identity server exists
-to provide identity information, access should be restricted to avoid
-leaking potentially sensitive data. In particular, being able to
-construct large-scale connections between identities should be avoided.
-To this end, in general APIs should allow a 3PID to be mapped to a
-Matrix user identity, but not in the other direction (i.e. one should
-not be able to get all 3PIDs associated with a Matrix user ID, or get
-all 3PIDs associated with a 3PID).
-
-## Web browser clients
-
-It is realistic to expect that some clients will be written to be run
-within a web browser or similar environment. In these cases, the
-identity server should respond to pre-flight requests and supply
-Cross-Origin Resource Sharing (CORS) headers on all requests.
-
-When a client approaches the server with a pre-flight (OPTIONS) request,
-the server should respond with the CORS headers for that route. The
-recommended CORS headers to be returned by servers on all requests are:
-
-    Access-Control-Allow-Origin: *
-    Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
-    Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
-
-## Authentication
-
-Most endpoints in the Identity Service API require authentication
-in order to ensure that the requesting user has accepted all relevant
-policies and is otherwise permitted to make the request.
-
-Identity Servers use a scheme similar to the Client-Server API's concept
-of access tokens to authenticate users. The access tokens provided by an
-Identity Server cannot be used to authenticate Client-Server API
-requests.
-
-An access token is provided to an endpoint in one of two ways:
-
-1.  Via a query string parameter, `access_token=TheTokenHere`.
-2.  Via a request header, `Authorization: Bearer TheTokenHere`.
-
-Clients are encouraged to the use the `Authorization` header where
-possible to prevent the access token being leaked in access/HTTP logs.
-The query string should only be used in cases where the `Authorization`
-header is inaccessible for the client.
-
-When credentials are required but missing or invalid, the HTTP call will
-return with a status of 401 and the error code `M_UNAUTHORIZED`.
-
-{{% http-api spec="identity" api="v2_auth" %}}
-
-## Terms of service
-
-Identity Servers are encouraged to have terms of service (or similar
-policies) to ensure that users have agreed to their data being processed
-by the server. To facilitate this, an identity server can respond to
-almost any authenticated API endpoint with an HTTP 403 and the error
-code `M_TERMS_NOT_SIGNED`. The error code is used to indicate that the
-user must accept new terms of service before being able to continue.
-
-All endpoints which support authentication can return the
-`M_TERMS_NOT_SIGNED` error. When clients receive the error, they are
-expected to make a call to `GET /terms` to find out what terms the
-server offers. The client compares this to the `m.accepted_terms`
-account data for the user (described later) and presents the user with
-option to accept the still-missing terms of service. After the user has
-made their selection, if applicable, the client sends a request to
-`POST /terms` to indicate the user's acceptance. The server cannot
-expect that the client will send acceptance for all pending terms, and
-the client should not expect that the server will not respond with
-another `M_TERMS_NOT_SIGNED` on their next request. The terms the user
-has just accepted are appended to `m.accepted_terms`.
-
-{{% event event="m.accepted_terms" %}}
-
-{{% http-api spec="identity" api="v2_terms" %}}
-
-## Status check
-
-{{% http-api spec="identity" api="v2_ping" %}}
-
-## Key management
-
-An identity server has some long-term public-private keypairs. These are
-named in a scheme `algorithm:identifier`, e.g. `ed25519:0`. When signing
-an association, the standard [Signing
-JSON](/appendices#signing-json) algorithm applies.
-
-The identity server may also keep track of some short-term
-public-private keypairs, which may have different usage and lifetime
-characteristics than the service's long-term keys.
-
-{{% http-api spec="identity" api="v2_pubkey" %}}
-
-## Association lookup
-
-{{% http-api spec="identity" api="v2_lookup" %}}
-
-### Client behaviour
-
-Prior to performing a lookup clients SHOULD make a request to the
-`/hash_details` endpoint to determine what algorithms the server
-supports (described in more detail below). The client then uses this
-information to form a `/lookup` request and receive known bindings from
-the server.
-
-Clients MUST support at least the `sha256` algorithm.
-
-### Server behaviour
-
-Servers, upon receipt of a `/lookup` request, will compare the query
-against known bindings it has, hashing the identifiers it knows about as
-needed to verify exact matches to the request.
-
-Servers MUST support at least the `sha256` algorithm.
-
-### Algorithms
-
-Some algorithms are defined as part of the specification, however other
-formats can be negotiated between the client and server using
-`/hash_details`.
-
-#### `sha256`
-
-This algorithm MUST be supported by clients and servers at a minimum. It
-is additionally the preferred algorithm for lookups.
-
-When using this algorithm, the client converts the query first into
-strings separated by spaces in the format `<address> <medium> <pepper>`.
-The `<pepper>` is retrieved from `/hash_details`, the `<medium>` is
-typically `email` or `msisdn` (both lowercase), and the `<address>` is
-the 3PID to search for. For example, if the client wanted to know about
-`alice@example.org`'s bindings, it would first format the query as
-`alice@example.org email ThePepperGoesHere`.
-
-{{% boxes/rationale %}}
-Mediums and peppers are appended to the address to prevent a common
-prefix for each 3PID, helping prevent attackers from pre-computing the
-internal state of the hash function.
-{{% /boxes/rationale %}}
-
-After formatting each query, the string is run through SHA-256 as
-defined by [RFC 4634](https://tools.ietf.org/html/rfc4634). The
-resulting bytes are then encoded using URL-Safe [Unpadded
-Base64](/appendices#unpadded-base64) (similar to [room version
-4's event ID format](/rooms/v4#event-ids)).
-
-An example set of queries when using the pepper `matrixrocks` would be:
-
-    "alice@example.com email matrixrocks" -> "4kenr7N9drpCJ4AfalmlGQVsOn3o2RHjkADUpXJWZUc"
-    "bob@example.com email matrixrocks"   -> "LJwSazmv46n0hlMlsb_iYxI0_HXEqy_yj6Jm636cdT8"
-    "18005552067 msisdn matrixrocks"      -> "nlo35_T5fzSGZzJApqu8lgIudJvmOQtDaHtr-I4rU7I"
-
-The set of hashes is then given as the `addresses` array in `/lookup`.
-Note that the pepper used MUST be supplied as `pepper` in the `/lookup`
-request.
-
-#### `none`
-
-This algorithm performs plaintext lookups on the identity server.
-Typically this algorithm should not be used due to the security concerns
-of unhashed identifiers, however some scenarios (such as LDAP-backed
-identity servers) prevent the use of hashed identifiers. Identity
-servers (and optionally clients) can use this algorithm to perform those
-kinds of lookups.
-
-Similar to the `sha256` algorithm, the client converts the queries into
-strings separated by spaces in the format `<address> <medium>` - note
-the lack of `<pepper>`. For example, if the client wanted to know about
-`alice@example.org`'s bindings, it would format the query as
-`alice@example.org email`.
-
-The formatted strings are then given as the `addresses` in `/lookup`.
-Note that the `pepper` is still required, and must be provided to ensure
-the client has made an appropriate request to `/hash_details` first.
-
-### Security considerations
-
-{{% boxes/note %}}
-[MSC2134](https://github.com/matrix-org/matrix-doc/pull/2134) has much
-more information about the security considerations made for this section
-of the specification. This section covers the high-level details for why
-the specification is the way it is.
-{{% /boxes/note %}}
-
-Typically the lookup endpoint is used when a client has an unknown 3PID
-it wants to find a Matrix User ID for. Clients normally do this kind of
-lookup when inviting new users to a room or searching a user's address
-book to find any Matrix users they may not have discovered yet. Rogue or
-malicious identity servers could harvest this unknown information and do
-nefarious things with it if it were sent in plain text. In order to
-protect the privacy of users who might not have a Matrix identifier
-bound to their 3PID addresses, the specification attempts to make it
-difficult to harvest 3PIDs.
-
-{{% boxes/rationale %}}
-Hashing identifiers, while not perfect, helps make the effort required
-to harvest identifiers significantly higher. Phone numbers in particular
-are still difficult to protect with hashing, however hashing is
-objectively better than not.
-
-An alternative to hashing would be using bcrypt or similar with many
-rounds, however by nature of needing to serve mobile clients and clients
-on limited hardware the solution needs be kept relatively lightweight.
-{{% /boxes/rationale %}}
-
-Clients should be cautious of servers not rotating their pepper very
-often, and potentially of servers which use a weak pepper - these
-servers may be attempting to brute force the identifiers or use rainbow
-tables to mine the addresses. Similarly, clients which support the
-`none` algorithm should consider at least warning the user of the risks
-in sending identifiers in plain text to the identity server.
-
-Addresses are still potentially reversible using a calculated rainbow
-table given some identifiers, such as phone numbers, common email
-address domains, and leaked addresses are easily calculated. For
-example, phone numbers can have roughly 12 digits to them, making them
-an easier target for attack than email addresses.
-
-## Establishing associations
-
-The flow for creating an association is session-based.
-
-Within a session, one may prove that one has ownership of a 3PID. Once
-this has been established, the user can form an association between that
-3PID and a Matrix user ID. Note that this association is only proved one
-way; a user can associate *any* Matrix user ID with a validated 3PID,
-i.e. I can claim that any email address I own is associated with
-@billg:microsoft.com.
-
-Sessions are time-limited; a session is considered to have been modified
-when it was created, and then when a validation is performed within it.
-A session can only be checked for validation, and validation can only be
-performed within a session, within a 24-hour period since its most
-recent modification. Any attempts to perform these actions after the
-expiry will be rejected, and a new session should be created and used
-instead.
-
-To start a session, the client makes a request to the appropriate
-`/requestToken` endpoint. The identity server then sends a validation
-token to the user, and the user provides the token to the client. The
-client then provides the token to the appropriate `/submitToken`
-endpoint, completing the session. At this point, the client should
-`/bind` the third party identifier or leave it for another entity to
-bind.
-
-### Format of a validation token
-
-The format of the validation token is left up to the identity server: it
-should choose one appropriate to the 3PID type. (For example, it would
-be inappropriate to expect a user to copy a long passphrase including
-punctuation from an SMS message into a client.)
-
-Whatever format the identity server uses, the validation token must
-consist of at most 255 Unicode codepoints. Clients must pass the token
-through without modification.
-
-### Email associations
-
-{{% http-api spec="identity" api="v2_email_associations" %}}
-
-### Phone number associations
-
-{{% http-api spec="identity" api="v2_phone_associations" %}}
-
-### General
-
-{{% http-api spec="identity" api="v2_associations" %}}
-
-## Invitation storage
-
-An identity server can store pending invitations to a user's 3PID, which
-will be retrieved and can be either notified on or look up when the 3PID
-is associated with a Matrix user ID.
-
-At a later point, if the owner of that particular 3PID binds it with a
-Matrix user ID, the identity server will attempt to make an HTTP POST to
-the Matrix user's homeserver via the
-[/3pid/onbind](/server-server-api#put_matrixfederationv13pidonbind)
-endpoint. The request MUST be signed with a long-term private key for
-the identity server.
-
-{{% http-api spec="identity" api="v2_store_invite" %}}
-
-## Ephemeral invitation signing
-
-To aid clients who may not be able to perform crypto themselves, the
-identity server offers some crypto functionality to help in accepting
-invitations. This is less secure than the client doing it itself, but
-may be useful where this isn't possible.
-
-{{% http-api spec="identity" api="v2_invitation_signing" %}}
diff --git a/content/proposals.md b/content/proposals.md
deleted file mode 100644
index b18c981e..00000000
--- a/content/proposals.md
+++ /dev/null
@@ -1,523 +0,0 @@
----
-title: "Spec Change Proposals"
-weight: 60
-type: docs
----
-
-If you are interested in submitting a change to the Matrix
-Specification, please take note of the following guidelines.
-
-Most changes to the Specification require a formal proposal. Bug fixes,
-typos, and clarifications to existing behaviour do not need proposals -
-see the [contributing
-guide](https://github.com/matrix-org/matrix-doc/blob/main/CONTRIBUTING.rst)
-for more information on what does and does not need a proposal.
-
-The proposal process involves some technical writing, having it reviewed
-by everyone, having the proposal being accepted, then actually having
-your ideas implemented as committed changes to the [Specification
-repository](https://github.com/matrix-org/matrix-doc).
-
-Meet the [members of the Core Team](https://matrix.org/foundation), a
-group of individuals tasked with ensuring the spec process is as smooth
-and painless as possible. Members of the Spec Core Team will do their
-best to participate in discussion, summarise when things become
-long-winded, and generally try to act towards the benefit of everyone.
-As a majority, team members have the ability to change the state of a
-proposal, and individually have the final say in proposal discussion.
-
-## Guiding Principles
-
-Proposals **must** act to the greater benefit of the entire Matrix
-ecosystem, rather than benefiting or privileging any single player or
-subset of players -and must not contain any patent encumbered
-intellectual property. Members of the Core Team pledge to act as a
-neutral custodian for Matrix on behalf of the whole ecosystem.
-
-For clarity: the Matrix ecosystem is anyone who uses the Matrix
-protocol. That includes client users, server admins, client developers,
-bot developers, bridge and application service developers, users and
-admins who are indirectly using Matrix via 3rd party networks which
-happen to be bridged, server developers, room moderators and admins,
-companies/projects building products or services on Matrix, spec
-contributors, translators, and those who created it in the first place.
-
-"Greater benefit" could include maximising:
-
--   the number of end-users reachable on the open Matrix network
--   the number of regular users on the Matrix network (e.g. 30-day
-    retained federated users)
--   the number of online servers in the open federation
--   the number of developers building on Matrix
--   the number of independent implementations which use Matrix
--   the number of bridged end-users reachable on the open Matrix network
--   the signal-to-noise ratio of the content on the open Matrix network
-    (i.e. minimising spam)
--   the ability for users to discover content on their terms (empowering
-    them to select what to see and what not to see)
--   the quality and utility of the Matrix spec (as defined by ease and
-    ability with which a developer can implement spec-compliant clients,
-    servers, bots, bridges, and other integrations without needing to
-    refer to any other external material)
-
-In addition, proposal authors are expected to uphold the following
-values in their proposed changes to the Matrix protocol:
-
--   Supporting the whole long-term ecosystem rather than individual
-    stakeholder gain
--   Openness rather than proprietary lock-in
--   Interoperability rather than fragmentation
--   Cross-platform rather than platform-specific
--   Collaboration rather than competition
--   Accessibility rather than elitism
--   Transparency rather than stealth
--   Empathy rather than contrariness
--   Pragmatism rather than perfection
--   Proof rather than conjecture
-
-Please [see
-MSC1779](https://github.com/matrix-org/matrix-doc/blob/main/proposals/1779-open-governance.md)
-for full details of the project's Guiding Principles.
-
-## Technical notes
-
-Proposals **must** develop Matrix as a layered protocol: with new
-features building on layers of shared abstractions rather than
-introducing tight vertical coupling within the stack. This ensures that
-new features can evolve rapidly by building on existing layers and
-swapping out old features without impacting the rest of the stack or
-requiring substantial upgrades to the whole ecosystem. This is critical
-for Matrix to rapidly evolve and compete effectively with centralised
-systems, despite being a federated protocol.
-
-For instance, new features should be implemented using the highest layer
-abstractions possible (e.g. new event types, which layer on top of the
-existing room semantics, and so don't even require any API changes).
-Failing that, the next recourse would be backwards-compatible changes to
-the next layer down (e.g. room APIs); failing that, considering changes
-to the format of events or the DAG; etc. It would be a very unusual
-feature which doesn't build on the existing infrastructure provided by
-the spec and instead created new primitives or low level APIs.
-
-Backwards compatibility is very important for Matrix, but not at the
-expense of hindering the protocol's evolution. Backwards incompatible
-changes to endpoints are allowed when no other alternative exists, and
-must be versioned under a new major release of the API. Backwards
-incompatible changes to the room algorithm are also allowed when no
-other alternative exists, and must be versioned under a new version of
-the room algorithm.
-
-There is sometimes a dilemma over where to include higher level
-features: for instance, should video conferencing be formalised in the
-spec, or should it be implemented via widgets? Should reputation systems
-be specified? Should search engine behaviour be specified?
-
-There is no universal answer to this, but the following guidelines
-should be applied:
-
-1.  If the feature would benefit the whole Matrix ecosystem and is
-    aligned with the guiding principles above, then it should be
-    supported by the spec.
-2.  If the spec already makes the feature possible without changing any
-    of the implementations and spec, then it may not need to be added to
-    the spec.
-3.  However, if the best user experience for a feature does require
-    custom implementation behaviour then the behaviour should be defined
-    in the spec such that all implementations may implement it.
-4.  However, the spec must never add dependencies on
-    unspecified/nonstandardised 3rd party behaviour.
-
-As a worked example:
-
-1.  Video conferencing is clearly a feature which would benefit the
-    whole ecosystem, and so the spec should find a way to make it
-    happen.
-2.  Video conferencing can be achieved by widgets without requiring any
-    compulsory changes to clients nor servers to work, and so could be
-    omitted from the spec.
-3.  A better experience could be achieved by embedding Jitsi natively
-    into clients rather than using a widget...
-4.  ...except that would add a dependency on unspecified/nonstandardised
-    3rd party behaviour, so must not be added to the spec.
-
-Therefore, our two options in the specific case of video conferencing
-are either to spec SFU conferencing semantics for WebRTC (or refer to an
-existing spec for doing so), or to keep it as a widget-based approach
-(optionally with widget extensions specific for more deeply integrating
-video conferencing use cases).
-
-As an alternative example: it's very unlikely that "how to visualise
-Magnetic Resonance Imaging data over Matrix" would ever be added to the
-Matrix spec (other than perhaps a custom event type in a wider
-standardised Matrix event registry) given that the spec's existing
-primitives of file transfer and extensible events (MSC1767) give
-excellent tools for transferring and visualising arbitrary rich data.
-
-Supporting public search engines are likely to not require custom spec
-features (other than possibly better bulk access APIs), given they can
-be implemented as clients using the existing CS API. An exception could
-be API features required by decentralised search infrastructure
-(avoiding centralisation of power by a centralised search engine).
-
-Features such as reactions, threaded messages, editable messages,
-spam/abuse/content filtering (and reputation systems), are all features
-which would clearly benefit the whole Matrix ecosystem, and cannot be
-implemented in an interoperable way using the current spec; so they
-necessitate a spec change.
-
-## Process
-
-The process for submitting a Matrix Spec Change (MSC) Proposal in detail
-is as follows:
-
--   Create a first draft of your proposal using [GitHub-flavored
-    Markdown](https://help.github.com/articles/basic-writing-and-formatting-syntax/)
-    -   In the document, clearly state the problem being solved, and the
-        possible solutions being proposed for solving it and their
-        respective trade-offs.
-    -   Proposal documents are intended to be as lightweight and
-        flexible as the author desires; there is no formal template; the
-        intention is to iterate as quickly as possible to get to a good
-        design.
-    -   However, a [template with suggested
-        headers](https://github.com/matrix-org/matrix-doc/blob/main/proposals/0000-proposal-template.md)
-        is available to get you started if necessary.
-    -   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.
--   Fork and make a PR to the
-    [matrix-doc](https://github.com/matrix-org/matrix-doc) repository.
-    The ID of your PR will become the MSC ID for the lifetime of your
-    proposal.
-    -   The proposal must live in the `proposals/` directory with a
-        filename that follows the format `1234-my-new-proposal.md` where
-        `1234` is the MSC ID.
-    -   Your PR description must include a link to the rendered Markdown
-        document and a summary of the proposal.
-    -   It is often very helpful to link any related MSCs or [matrix-doc
-        issues](https://github.com/matrix-org/matrix-doc/issues) to give
-        context for the proposal.
-    -   Additionally, please be sure to sign off your proposal PR as per
-        the guidelines listed on
-        [CONTRIBUTING.rst](https://github.com/matrix-org/matrix-doc/blob/main/CONTRIBUTING.rst).
--   Gather feedback as widely as possible.
-    -   The aim is to get maximum consensus towards an optimal solution.
-        Sometimes trade-offs are required to meet this goal. Decisions
-        should be made to the benefit of all major use cases.
-    -   A good place to ask for feedback on a specific proposal is
-        [\#matrix-spec:matrix.org](https://matrix.to/#/#matrix-spec:matrix.org).
-        If preferred, an alternative room can be created and advertised
-        in \#matrix-spec:matrix.org. Please also link to the room in
-        your PR description.
-    -   For additional discussion areas, know that
-        \#matrix-dev:matrix.org is for developers using existing Matrix
-        APIs, \#matrix:matrix.org is for users trying to run Matrix apps
-        (clients & servers) and \#matrix-architecture:matrix.org is for
-        cross-cutting discussion of Matrix's architectural design.
-    -   The point of the spec proposal process is to be collaborative
-        rather than competitive, and to try to solve the problem in
-        question with the optimal set of trade-offs. The author should
-        neutrally gather the various viewpoints and get consensus, but
-        this can sometimes be time-consuming (or the author may be
-        biased), in which case an impartial 'shepherd' can be assigned
-        to help guide the proposal through this process instead. A
-        shepherd is typically a neutral party from the Spec Core Team or
-        an experienced member of the community. There is no formal
-        process for assignment. Simply ask for a shepherd to help get
-        your proposal through and one will be assigned based on
-        availability. Having a shepherd is not a requirement for
-        proposal acceptance.
--   Members of the Spec Core Team and community will review and discuss
-    the PR in the comments and in relevant rooms on Matrix. Discussion
-    outside of GitHub should be summarised in a comment on the PR.
--   When a member of the Spec Core Team believes that no new discussion
-    points are being made, and the proposal has suitable evidence of
-    working (see [implementing a proposal](#implementing-a-proposal)
-    below), they will propose a motion for a final comment period (FCP),
-    along with a *disposition* of either merge, close or postpone. This
-    FCP is provided to allow a short period of time for any invested
-    party to provide a final objection before a major decision is made.
-    If sufficient reasoning is given, an FCP can be cancelled. It is
-    often preceded by a comment summarising the current state of the
-    discussion, along with reasoning for its occurrence.
--   A concern can be raised by a Spec Core Team member at any time,
-    which will block an FCP from beginning. An FCP will only begin when
-    75% of the members of the Spec Core Team agree on its outcome, and
-    all existing concerns have been resolved.
--   The FCP will then begin and last for 5 days, giving anyone else some
-    time to speak up before it concludes. If sufficient reasoning
-    against the disposition is provided, a member of the Spec Core Team can
-    raise a concern and block FCP from completing. This will not reset or
-    pause the 5 day FCP timer, but FCP will not conclude until all concerns have
-    been resolved. If sufficient change in the MSC is required to resolve those
-    concerns, FCP might be cancelled and reproposed. Once FCP has concluded,
-    the disposition of the FCP will be carried out.
--   Once the proposal has been accepted and merged, it is time to submit
-    the actual change to the Specification that your proposal reasoned
-    about. This is known as a spec PR. However in order for the spec PR
-    to be accepted, an implementation **must** be shown to prove that it
-    works well in practice. A link to the implementation should be
-    included in the PR description. In addition, any significant
-    unforeseen changes to the original idea found during this process
-    will warrant another MSC. Any minor, non-fundamental changes are
-    allowed but **must** be documented in the original proposal
-    document. This ensures that someone reading a proposal in the future
-    doesn't assume old information that wasn't merged into the spec.
-    -   Similar to the proposal PR, please sign off the spec PR as per
-        the guidelines on
-        [CONTRIBUTING.rst](https://github.com/matrix-org/matrix-doc/blob/main/CONTRIBUTING.rst).
--   Your PR will then be reviewed and hopefully merged on the grounds it
-    is implemented sufficiently. If so, then give yourself a pat on the
-    back knowing you've contributed to the Matrix protocol for the
-    benefit of users and developers alike :)
-
-The process for handling proposals is shown visually in the following
-diagram. Note that the lifetime of a proposal is tracked through the
-corresponding labels for each stage on the
-[matrix-doc](https://github.com/matrix-org/matrix-doc) issue and pull
-request trackers.
-
-```
-                           +                          +
-         Proposals         |          Spec PRs        |  Additional States
-         +-------+         |          +------+        |  +---------------+
-                           |                          |
- +----------------------+  |         +---------+      |    +-----------+
- |                      |  |         |         |      |    |           |
- |      Proposal        |  |  +------= Spec PR |      |    | Postponed |
- | Drafting and Initial |  |  |      | Missing |      |    |           |
- |  Feedback Gathering  |  |  |      |         |      |    +-----------+
- |                      |  |  |      +----+----+      |
- +----------+-----------+  |  |           |           |    +----------+
-            |              |  |           v           |    |          |
-            v              |  |  +-----------------+  |    |  Closed  |
-  +-------------------+    |  |  |                 |  |    |          |
-  |                   |    |  |  | Spec PR Created |  |    +----------+
-  |    Proposal PR    |    |  |  |  and In Review  |  |
-  |     In Review     |    |  |  |                 |  |
-  |                   |    |  |  +--------+--------+  |
-  +---------+---------+    |  |           |           |
-            |              |  |           v           |
-            v              |  |     +-----------+     |
- +----------------------+  |  |     |           |     |
- |                      |  |  |     |  Spec PR  |     |
- |    Proposed Final    |  |  |     |  Merged!  |     |
- |    Comment Period    |  |  |     |           |     |
- |                      |  |  |     +-----------+     |
- +----------+-----------+  |  |                       |
-            |              |  |                       |
-            v              |  |                       |
- +----------------------+  |  |                       |
- |                      |  |  |                       |
- | Final Comment Period |  |  |                       |
- |                      |  |  |                       |
- +----------+-----------+  |  |                       |
-            |              |  |                       |
-            v              |  |                       |
- +----------------------+  |  |                       |
- |                      |  |  |                       |
- | Final Comment Period |  |  |                       |
- |       Complete       |  |  |                       |
- |                      |  |  |                       |
- +----------+-----------+  |  |                       |
-            |              |  |                       |
-            +-----------------+                       |
-                           |                          |
-                           +                          +
-```
-
-## Lifetime States
-
-**Note:** All labels are to be placed on the proposal PR.
-
-| Name                            | GitHub Label                    | Description                                                                                                                                                                                                                          |
-|---------------------------------|---------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Proposal Drafting and Feedback  | [No label](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+-label%3Aabandoned+-label%3Afinal-comment-period+-label%3Afinished-final-comment-period+-label%3Amerged+-label%3Aobsolete+-label%3Aproposal-postponed+-label%3Aproposed-final-comment-period+-label%3Aproposal-in-review+-label%3Aspec-pr-in-review+-label%3Aspec-pr-missing) | A proposal document which is still work-in-progress but is being shared to incorporate feedback. Please prefix your proposal's title with `[WIP]` to make it easier for reviewers to skim their notifications list. |
-| Proposal In Review              | [proposal-in-review](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+label%3Aproposal-in-review)                          | A proposal document which is now ready and waiting for review by the Spec Core Team and community                       |
-| Proposed Final Comment Period   | [proposed-final-comment-period](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+label%3Aproposed-final-comment-period+)   | Currently awaiting signoff of a 75% majority of team members in order to enter the final comment period                 |
-| Final Comment Period            | [final-comment-period](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+label%3Afinal-comment-period+)                     | A proposal document which has reached final comment period either for merge, closure or postponement                    |
-| Final Comment Period Complete   | [finished-final-comment-period](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+label%3Afinished-final-comment-period+)   | The final comment period has been completed. Waiting for a demonstration implementation                                 |
-| Spec PR Missing                 | [spec-pr-missing](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+label%3Aspec-pr-missing)                                | The proposal has been agreed, and proven with a demonstration implementation. Waiting for a PR against the Spec         |
-| Spec PR In Review               | [spec-pr-in-review](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+label%3Aspec-pr-in-review+)                           | The spec PR has been written, and is currently under review                                                             |
-| Spec PR Merged                  | [merged](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+label%3Amerged)                                                  | A proposal with a sufficient working implementation and whose Spec PR has been merged!                                  |
-| Postponed                       | [proposal-postponed](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+label%3Aproposal-postponed+)                         | A proposal that is temporarily blocked or a feature that may not be useful currently but perhaps sometime in the future |
-| Abandoned                       | [abandoned](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+label%3Aabandoned)                                      | A proposal where the author/shepherd is not responsive                                                                  |
-| Obsolete                        | [obsolete](https://github.com/matrix-org/matrix-doc/issues?q=label%3Aproposal+label%3Aobsolete+)                                             | A proposal which has been made obsolete by another proposal or decision elsewhere.                                      |
-
-## Categories
-
-We use category labels on MSCs to place them into a track of work. The
-Spec Core Team decides which of the tracks they are focusing on for the
-next while and generally makes an effort to pull MSCs out of that
-category when possible.
-
-The current categories are:
-
-| Name        | GitHub Label     | Description                           |
-|-------------|------------------|---------------------------------------|
-| Core        | kind:core        | Important for the protocol's success. |
-| Feature     | kind:feature     | Nice to have additions to the spec.   |
-| Maintenance | kind:maintenance | Fixes or clarifies existing spec.     |
-
-Some examples of core MSCs would be aggregations, cross-signing, and
-groups/communities. These are the sorts of things that if not
-implemented could cause the protocol to fail or become second-class.
-Features would be areas like enhanced media APIs, new transports, and
-bookmarks in comparison. Finally, maintenance MSCs would include
-improving error codes, clarifying what is required of an API, and adding
-properties to an API which makes it easier to use.
-
-The Spec Core Team assigns a category to each MSC based on the
-descriptions above. This can mean that new MSCs get categorized into an
-area the team isn't focused on, though that can always change as
-priorities evolve. We still encourage that MSCs be opened, even if not
-the focus for the time being, as they can still make progress and even
-be merged without the Spec Core Team focusing on them specifically.
-
-## Implementing a proposal
-
-As part of the proposal process the Spec Core Team will require evidence
-of the MSC working in order for it to move into FCP. This can usually be
-a branch/pull request to whichever implementation of choice that proves
-the MSC works in practice, though in some cases the MSC itself will be
-small enough to be considered proven. Where it's unclear if an MSC will
-require an implementation proof, ask in
-[\#matrix-spec:matrix.org](https://matrix.to/#/#matrix-spec:matrix.org).
-
-### Early release of an MSC/idea
-
-To help facilitate early releases of software dependent on a spec
-release, implementations are required to use the following process to
-ensure that the official Matrix namespace is not cluttered with
-development or testing data.
-
-**Note:** Unreleased implementations (including proofs-of-concept demonstrating
-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
-    unstable feature flags as appropriate.
-    -   When using unstable endpoints, they MUST include a vendor
-        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
-    of the MSC working as proposed. A typical example of this is an
-    implementation of the MSC, though the implementation does not need
-    to be shipped anywhere and can therefore avoid the
-    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
-    (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.
-1.  A spec PR is written to incorporate the changes into Matrix.
-1.  A spec release happens.
-1.  A transition period of about 2 months starts immediately after the
-    spec release, before implementations start to encourage other
-    implementations to switch to stable endpoints. For example, a server
-    implementation should start asking client implementations to support
-    the stable endpoints 2 months after the spec release, if they
-    haven't already. The same applies in the reverse: if clients cannot
-    switch to stable prefixes because server implementations haven't
-    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
-    completed FCP. Once that has occurred, implementations are allowed
-    to use stable endpoints, but are not required to.
--   Implementations are able to ship features that are exposed to users
-    by default before an MSC has been merged to the spec, provided they
-    follow the process above.
--   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
-    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.
-
-## Proposal Tracking
-
-This is a living document generated from the list of proposals on the
-issue and pull request trackers of the
-[matrix-doc](https://github.com/matrix-org/matrix-doc) repo.
-
-We use labels and some metadata in MSC PR descriptions to generate this
-page. Labels are assigned by the Spec Core Team whilst triaging the
-proposals based on those which exist in the
-[matrix-doc](https://github.com/matrix-org/matrix-doc) repo already.
-
-It is worth mentioning that a previous version of the MSC process used a
-mixture of GitHub issues and PRs, leading to some MSC numbers deriving
-from GitHub issue IDs instead. A useful feature of GitHub is that it
-does automatically resolve to an issue, if an issue ID is placed in a
-pull URL. This means that
-<https://github.com/matrix-org/matrix-doc/pull/$MSCID> will correctly
-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 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
-    in the issue description.
--   The creation date is taken from the GitHub PR, but can be overridden
-    by adding a "Date: yyyy-mm-dd" line in the PR description.
--   Updated Date is taken from GitHub.
--   Author is the creator of the MSC PR, but can be overridden by adding
-    a "Author: @username" line in the body of the issue description.
-    Please make sure @username is a GitHub user (include the @!)
--   A shepherd can be assigned by adding a "Shepherd: @username" line in
-    the issue description. Again, make sure this is a real GitHub user.
-
-{{% proposal-tables %}}
diff --git a/content/push-gateway-api.md b/content/push-gateway-api.md
deleted file mode 100644
index 541db129..00000000
--- a/content/push-gateway-api.md
+++ /dev/null
@@ -1,57 +0,0 @@
----
-title: "Push Gateway API"
-weight: 50
-type: docs
----
-
-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
-push gateway. The gateway then submits a push notification to the push
-notification provider (e.g. APNS, GCM).
-
-```
-                                   +--------------------+  +-------------------+
-                  Matrix HTTP      |                    |  |                   |
-             Notification Protocol |   App Developer    |  |   Device Vendor   |
-                                   |                    |  |                   |
-           +-------------------+   | +----------------+ |  | +---------------+ |
-           |                   |   | |                | |  | |               | |
-           | Matrix homeserver +----->  Push Gateway  +------> Push Provider | |
-           |                   |   | |                | |  | |               | |
-           +-^-----------------+   | +----------------+ |  | +----+----------+ |
-             |                     |                    |  |      |            |
-    Matrix   |                     |                    |  |      |            |
- Client/Server API  +              |                    |  |      |            |
-             |      |              +--------------------+  +-------------------+
-             |   +--+-+                                           |
-             |   |    <-------------------------------------------+
-             +---+    |
-                 |    |          Provider Push Protocol
-                 +----+
-
-         Mobile Device or Client
-```
-
-## Homeserver behaviour
-
-This describes the format used by "HTTP" pushers to send notifications
-of events to Push Gateways. If the endpoint returns an HTTP error code,
-the homeserver SHOULD retry for a reasonable amount of time using
-exponential backoff.
-
-When pushing notifications for events, the homeserver is expected to
-include all of the event-related fields in the `/notify` request. When
-the homeserver is performing a push where the `format` is
-`"event_id_only"`, only the `event_id`, `room_id`, `counts`, and
-`devices` are required to be populated.
-
-Note that most of the values and behaviour of this endpoint is described
-by the Client-Server API's [Push
-Module](/client-server-api#push-notifications).
-
-{{% http-api spec="push-gateway" api="push_notifier" %}}
diff --git a/content/rooms/_index.md b/content/rooms/_index.md
deleted file mode 100644
index f946cb61..00000000
--- a/content/rooms/_index.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: Room Versions
-type: docs
-weight: 60
----
-
-Rooms are central to how Matrix operates, and have strict rules for what
-is allowed to be contained within them. Rooms can also have various
-algorithms that handle different tasks, such as what to do when two or
-more events collide in the underlying DAG. To allow rooms to be improved
-upon through new algorithms or rules, "room versions" are employed to
-manage a set of expectations for each room. New room versions are
-assigned as needed.
-
-There is no implicit ordering or hierarchy to room versions, and their
-principles are immutable once placed in the specification. Although
-there is a recommended set of versions, some rooms may benefit from
-features introduced by other versions. Rooms move between different
-versions by "upgrading" to the desired version. Due to versions not
-being ordered or hierarchical, this means a room can "upgrade" from
-version 2 to version 1, if it is so desired.
-
-## Feature matrix
-
-Some functionality is only available in specific room versions, such
-as knocking. The table below shows which versions support which features
-from a client's perspective. Server implementations are still welcome
-to reference the following table, however the detailed per-version
-specifications are more likely to be of interest.
-
-<!--
-Dev note: When the room version columns get overwhelming, merge versions
-1 through 6 as "1 ... 6" or similar given they don't add any features.
-
-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 |
-|-------------------|---|---|---|---|---|---|---|---|---|
-| **Knocking**      | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ | ✔ |
-| **Restricted join rules** | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✔ | ✔ |
-
-## Complete list of room versions
-
-Room versions are divided into two distinct groups: stable and unstable.
-Stable room versions may be used by rooms safely. Unstable room versions
-are everything else which is either not listed in the specification or
-flagged as unstable for some other reason. Versions can switch between
-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 9** as
-the default room version when creating new rooms.
-
-The available room versions are:
-
--   [Version 1](/rooms/v1) - **Stable**. The current version of most
-    rooms.
--   [Version 2](/rooms/v2) - **Stable**. Implements State Resolution
-    Version 2.
--   [Version 3](/rooms/v3) - **Stable**. Introduces events whose IDs
-    are the event's hash.
--   [Version 4](/rooms/v4) - **Stable**. Builds on v3 by using
-    URL-safe base64 for event IDs.
--   [Version 5](/rooms/v5) - **Stable**. Introduces enforcement of
-    signing key validity periods.
--   [Version 6](/rooms/v6) - **Stable**. Alters several
-    authorization rules for events.
--   [Version 7](/rooms/v7) - **Stable**. Introduces knocking.
--   [Version 8](/rooms/v8) - **Stable**. Adds a join rule to allow members
-    of another room to join without invite.
--   [Version 9](/rooms/v9) - **Stable**. Builds on v8 to fix issues when
-    redacting some membership events.
-
-## Room version grammar
-
-Room versions are used to change properties of rooms that may not be
-compatible with other servers. For example, changing the rules for event
-authorization would cause older servers to potentially end up in a
-split-brain situation due to not understanding the new rules.
-
-A room version is defined as a string of characters which MUST NOT
-exceed 32 codepoints in length. Room versions MUST NOT be empty and
-SHOULD contain only the characters `a-z`, `0-9`, `.`, and `-`.
-
-Room versions are not intended to be parsed and should be treated as
-opaque identifiers. Room versions consisting only of the characters
-`0-9` and `.` are reserved for future versions of the Matrix protocol.
-
-The complete grammar for a legal room version is:
-
-    room_version = 1*room_version_char
-    room_version_char = DIGIT
-                      / %x61-7A         ; a-z
-                      / "-" / "."
-
-Examples of valid room versions are:
-
--   `1` (would be reserved by the Matrix protocol)
--   `1.2` (would be reserved by the Matrix protocol)
--   `1.2-beta`
--   `com.example.version`
-
diff --git a/content/rooms/fragments/v1-auth-rules.md b/content/rooms/fragments/v1-auth-rules.md
deleted file mode 100644
index d7c4dace..00000000
--- a/content/rooms/fragments/v1-auth-rules.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-toc_hide: true
----
-
-The types of state events that affect authorization are:
-
--   `m.room.create`
--   `m.room.member`
--   `m.room.join_rules`
--   `m.room.power_levels`
--   `m.room.third_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 %}}
-
-The rules are as follows:
-
-1.  If type is `m.room.create`:
-    1.  If it has any previous events, reject.
-    2.  If the domain of the `room_id` does not match the domain of the
-        `sender`, reject.
-    3.  If `content.room_version` is present and is not a recognised
-        version, reject.
-    4.  If `content` has no `creator` field, reject.
-    5.  Otherwise, allow.
-2.  Reject if event has `auth_events` that:
-    1.  have duplicate entries for a given `type` and `state_key` pair
-    2.  have 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.
-3.  If event does not have a `m.room.create` in its `auth_events`,
-    reject.
-4.  If type is `m.room.aliases`:
-    1.  If event has no `state_key`, reject.
-    2.  If sender's domain doesn't matches `state_key`, reject.
-    3.  Otherwise, allow.
-5.  If type is `m.room.member`:
-    1.  If no `state_key` key or `membership` key in `content`, reject.
-    2.  If `membership` is `join`:
-        1.  If the only previous event is an `m.room.create` and the
-            `state_key` is the creator, 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` then allow if membership
-            state is `invite` or `join`.
-        5.  If the `join_rule` is `public`, allow.
-        6.  Otherwise, reject.
-    3.  If `membership` is `invite`:
-        1.  If `content` has `third_party_invite` key:
-            1.  If *target user* is banned, reject.
-            2.  If `content.third_party_invite` does not have a `signed`
-                key, reject.
-            3.  If `signed` does not have `mxid` and `token` keys,
-                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` field.
-                2.  A list of public keys in the `public_keys` field.
-            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.
-    4.  If `membership` is `leave`:
-        1.  If the `sender` matches `state_key`, allow if and only if
-            that user's current membership state is `invite` or `join`.
-        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.
-    5.  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.
-    6.  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 `users` key in `content` is not a dictionary with keys that
-        are valid user IDs with values that are integers (or a string
-        that is an integer), reject.
-    2.  If there is no previous `m.room.power_levels` event in the room,
-        allow.
-    3.  For the keys `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.
-    4.  For each entry being added, changed or removed in both the
-        `events` and `users` keys:
-        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.
-    5.  For each entry being changed under the `users` key, other than
-        the `sender`'s own entry:
-        1.  If the current value is equal to the `sender`'s current
-            power level, reject.
-    6.  Otherwise, allow.
-11. If type is `m.room.redaction`:
-    1.  If the `sender`'s power level is greater than or equal to the
-        *redact level*, allow.
-    2.  If the domain of the `event_id` of the event being redacted is
-        the same as the domain of the `event_id` of the
-        `m.room.redaction`, allow.
-    3.  Otherwise, reject.
-12. 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 %}}
diff --git a/content/rooms/fragments/v1-canonical-json.md b/content/rooms/fragments/v1-canonical-json.md
deleted file mode 100644
index 480229e9..00000000
--- a/content/rooms/fragments/v1-canonical-json.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-toc_hide: true
----
-
-Servers MUST NOT strictly enforce the JSON format specified in the
-[appendices](/appendices#canonical-json) for the reasons
-described there.
diff --git a/content/rooms/fragments/v1-redactions.md b/content/rooms/fragments/v1-redactions.md
deleted file mode 100644
index f876f654..00000000
--- a/content/rooms/fragments/v1-redactions.md
+++ /dev/null
@@ -1,33 +0,0 @@
----
-toc_hide: true
----
-
-Upon receipt of a redaction event, the server must strip off any keys
-not in the following list:
-
--   `event_id`
--   `type`
--   `room_id`
--   `sender`
--   `state_key`
--   `content`
--   `hashes`
--   `signatures`
--   `depth`
--   `prev_events`
--   `prev_state`
--   `auth_events`
--   `origin`
--   `origin_server_ts`
--   `membership`
-
-The content object must also be stripped of all keys, unless it is one
-of one of the following event types:
-
--   `m.room.member` allows key `membership`.
--   `m.room.create` allows key `creator`.
--   `m.room.join_rules` allows key `join_rule`.
--   `m.room.power_levels` allows keys `ban`, `events`, `events_default`,
-    `kick`, `redact`, `state_default`, `users`, `users_default`.
--   `m.room.aliases` allows key `aliases`.
--   `m.room.history_visibility` allows key `history_visibility`.
diff --git a/content/rooms/fragments/v2-state-res.md b/content/rooms/fragments/v2-state-res.md
deleted file mode 100644
index 508f9c1a..00000000
--- a/content/rooms/fragments/v2-state-res.md
+++ /dev/null
@@ -1,169 +0,0 @@
----
-toc_hide: true
----
-
-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 *E*'s `event_type` and `state_key` is
-    replaced by *E*'s `event_id`.
-
-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>), …} consisting of
-the states after each of *E*'s `prev_event`s
-{*E*<sub>1</sub>, *E*<sub>2</sub>, …}, where 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 *unconflicted state map* is the state where the value of each key
-exists and is the same in each state *S*<sub>*i*</sub>. The *conflicted
-state set* is the set of all other state events. Note that the
-unconflicted state map only has one event per `(event_type, state_key)`,
-whereas the conflicted state set may have multiple events.
-
-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>.
-
-Full conflicted set
-The *full conflicted set* is the union of the conflicted state set 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
-Given an `m.room.power_levels` event *P*, the *mainline of* *P* is the
-list of events generated by starting with *P* and recursively taking the
-`m.room.power_levels` events from the `auth_events`, ordered such that
-*P* is last. Given another event *e*, the *closest mainline event to*
-*e* is the first event encountered in the mainline when iteratively
-descending through the `m.room.power_levels` events in the `auth_events`
-starting at *e*. If no mainline event is encountered when iteratively
-descending through the `m.room.power_levels` events, then the closest
-mainline event to *e* can be considered to be a dummy event that is
-before any other event in the mainline of *P* for the purposes of
-condition 1 below.
-
-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 closest mainline event to *x* appears *before* the closest
-    mainline event to *y*; or
-2.  the closest mainline events are the same, but *x*'s
-    `origin_server_ts` is *less* than *y*'s `origin_server_ts`; or
-3.  the closest mainline 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.  Take all *power events* and any events in their auth chains,
-    recursively, that appear in the *full conflicted set* and order them
-    by the *reverse topological power ordering*.
-2.  Apply the *iterative auth checks algorithm*, starting from the
-    *unconflicted 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.
diff --git a/content/rooms/fragments/v3-auth-rules.md b/content/rooms/fragments/v3-auth-rules.md
deleted file mode 100644
index 1a6ae490..00000000
--- a/content/rooms/fragments/v3-auth-rules.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-toc_hide: true
----
-
-{{% added-in this=true %}} In room versions 1 and 2, events need a
-signature from the domain of the `event_id` in order to be considered
-valid. This room version does not include an `event_id` over federation
-in the same respect, so does not need a signature from that server.
-The event must still be signed by the server denoted by the `sender`,
-however.
-
-The types of state events that affect authorization are:
-
--   `m.room.create`
--   `m.room.member`
--   `m.room.join_rules`
--   `m.room.power_levels`
--   `m.room.third_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 %}}
-
-The complete list of rules, as of room version 3, is as follows:
-
-1.  If type is `m.room.create`:
-    1.  If it has any previous events, reject.
-    2.  If the domain of the `room_id` does not match the domain of the
-        `sender`, reject.
-    3.  If `content.room_version` is present and is not a recognised
-        version, reject.
-    4.  If `content` has no `creator` field, reject.
-    5.  Otherwise, allow.
-2.  Reject if event has `auth_events` that:
-    1.  have duplicate entries for a given `type` and `state_key` pair
-    2.  have 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.
-3.  If event does not have a `m.room.create` in its `auth_events`,
-    reject.
-4.  If type is `m.room.aliases`:
-    1.  If event has no `state_key`, reject.
-    2.  If sender's domain doesn't matches `state_key`, reject.
-    3.  Otherwise, allow.
-5.  If type is `m.room.member`:
-    1.  If no `state_key` key or `membership` key in `content`, reject.
-    2.  If `membership` is `join`:
-        1.  If the only previous event is an `m.room.create` and the
-            `state_key` is the creator, 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` then allow if membership
-            state is `invite` or `join`.
-        5.  If the `join_rule` is `public`, allow.
-        6.  Otherwise, reject.
-    3.  If `membership` is `invite`:
-        1.  If `content` has `third_party_invite` key:
-            1.  If *target user* is banned, reject.
-            2.  If `content.third_party_invite` does not have a `signed`
-                key, reject.
-            3.  If `signed` does not have `mxid` and `token` keys,
-                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` field.
-                2.  A list of public keys in the `public_keys` field.
-            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.
-    4.  If `membership` is `leave`:
-        1.  If the `sender` matches `state_key`, allow if and only if
-            that user's current membership state is `invite` or `join`.
-        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.
-    5.  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.
-    6.  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 `users` key in `content` is not a dictionary with keys that
-        are valid user IDs with values that are integers (or a string
-        that is an integer), reject.
-    2.  If there is no previous `m.room.power_levels` event in the room,
-        allow.
-    3.  For the keys `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.
-    4.  For each entry being added, changed or removed in both the
-        `events` and `users` keys:
-        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.
-    5.  For each entry being changed under the `users` key, other than
-        the `sender`'s own entry:
-        1.  If the current value is equal to the `sender`'s current
-            power level, reject.
-    6.  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 %}}
diff --git a/content/rooms/fragments/v3-handling-redactions.md b/content/rooms/fragments/v3-handling-redactions.md
deleted file mode 100644
index 13c414fb..00000000
--- a/content/rooms/fragments/v3-handling-redactions.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-toc_hide: true
----
-
-{{% added-in this=true %}} In room versions 1 and 2, redactions were
-explicitly part of the [authorization rules](/rooms/v1/#authorization-rules)
-under Rule 11. As of room version 3, these conditions no longer exist as
-represented by [this version's authorization rules](#authorization-rules).
-
-While redactions are always accepted by the authorization rules for
-events, they should not be sent to clients until both the redaction
-event and the event the redaction affects have been received, and can
-be validated. If both events are valid and have been seen by the server,
-then the server applies the redaction if one of the following conditions
-is met:
-
-1. The power level of the redaction event's `sender` is greater than or
-   equal to the *redact level*.
-2. The domain of the redaction event's `sender` matches that of the
-   original event's `sender`.
-
-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.
diff --git a/content/rooms/fragments/v4-event-format.md b/content/rooms/fragments/v4-event-format.md
deleted file mode 100644
index 938f0f61..00000000
--- a/content/rooms/fragments/v4-event-format.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-toc_hide: true
----
-
-Events in rooms of this version have the following structure:
-
-{{% definition path="api/server-server/definitions/pdu_v4" %}}
diff --git a/content/rooms/fragments/v4-event-ids.md b/content/rooms/fragments/v4-event-ids.md
deleted file mode 100644
index 8df1ec2a..00000000
--- a/content/rooms/fragments/v4-event-ids.md
+++ /dev/null
@@ -1,14 +0,0 @@
----
-toc_hide: true
----
-
-{{% added-in this=true %}} The event ID is the [reference
-hash](/server-server-api#calculating-the-reference-hash-for-an-event) of
-the event encoded using a variation of [Unpadded
-Base64](/appendices#unpadded-base64) which replaces the 62nd and
-63rd characters with `-` and `_` instead of using `+` and `/`. This
-matches [RFC4648's definition of URL-safe
-base64](https://tools.ietf.org/html/rfc4648#section-5).
-
-Event IDs are still prefixed with `$` and might result in looking like
-`$Rqnc-F-dvnEYJTyHq_iKxU2bZ1CI92-kuZq3a5lr5Zg`.
diff --git a/content/rooms/fragments/v5-signing-requirements.md b/content/rooms/fragments/v5-signing-requirements.md
deleted file mode 100644
index 3e8cc20e..00000000
--- a/content/rooms/fragments/v5-signing-requirements.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-toc_hide: true
----
-
-When validating event signatures, servers MUST enforce the
-`valid_until_ts` property from a key request is at least as large as the
-`origin_server_ts` for the event being validated. Servers missing a copy
-of the signing key MUST try to obtain one via the [GET
-/\_matrix/key/v2/server](/server-server-api#get_matrixkeyv2serverkeyid)
-or [POST
-/\_matrix/key/v2/query](/server-server-api#post_matrixkeyv2query)
-APIs. When using the `/query` endpoint, servers MUST set the
-`minimum_valid_until_ts` property to prompt the notary server to attempt
-to refresh the key if appropriate.
-
-Servers MUST use the lesser of `valid_until_ts` and 7 days into the
-future when determining if a key is valid. This is to avoid a situation
-where an attacker publishes a key which is valid for a significant
-amount of time without a way for the homeserver owner to revoke it.
diff --git a/content/rooms/fragments/v6-canonical-json.md b/content/rooms/fragments/v6-canonical-json.md
deleted file mode 100644
index 6ece1ed8..00000000
--- a/content/rooms/fragments/v6-canonical-json.md
+++ /dev/null
@@ -1,10 +0,0 @@
----
-toc_hide: true
----
-
-Servers MUST strictly enforce the JSON format specified in the
-[appendices](/appendices#canonical-json). This translates to a
-400 `M_BAD_JSON` error on most endpoints, or discarding of events over
-federation. For example, the Federation API's `/send` endpoint would
-discard the event whereas the Client Server API's `/send/{eventType}`
-endpoint would return a `M_BAD_JSON` error.
diff --git a/content/rooms/fragments/v6-redactions.md b/content/rooms/fragments/v6-redactions.md
deleted file mode 100644
index 39ee61b8..00000000
--- a/content/rooms/fragments/v6-redactions.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-toc_hide: true
----
-
-Upon receipt of a redaction event, the server must strip off any keys
-not in the following list:
-
--   `event_id`
--   `type`
--   `room_id`
--   `sender`
--   `state_key`
--   `content`
--   `hashes`
--   `signatures`
--   `depth`
--   `prev_events`
--   `prev_state`
--   `auth_events`
--   `origin`
--   `origin_server_ts`
--   `membership`
-
-The content object must also be stripped of all keys, unless it is one
-of one of the following event types:
-
--   `m.room.member` allows key `membership`.
--   `m.room.create` allows key `creator`.
--   `m.room.join_rules` allows key `join_rule`.
--   `m.room.power_levels` allows keys `ban`, `events`, `events_default`,
-    `kick`, `redact`, `state_default`, `users`, `users_default`.
--   `m.room.history_visibility` allows key `history_visibility`.
diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md
deleted file mode 100644
index 4b14762d..00000000
--- a/content/rooms/fragments/v8-auth-rules.md
+++ /dev/null
@@ -1,162 +0,0 @@
----
-toc_hide: true
----
-
-Events must be signed by the server denoted by the `sender` key.
-
-`m.room.redaction` events are not explicitly part of the auth rules.
-They are still subject to the minimum power level rules, but should always
-fall into "10. Otherwise, allow". Instead of being authorized at the time
-of receipt, they are authorized at a later stage: see the
-[Redactions](#redactions) section below for more information.
-
-The types of state events that affect authorization are:
-
--   `m.room.create`
--   `m.room.member`
--   `m.room.join_rules`
--   `m.room.power_levels`
--   `m.room.third_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 %}}
-
-The rules are as follows:
-
-1.  If type is `m.room.create`:
-    1.  If it has any previous events, reject.
-    2.  If the domain of the `room_id` does not match the domain of the
-        `sender`, reject.
-    3.  If `content.room_version` is present and is not a recognised
-        version, reject.
-    4.  If `content` has no `creator` field, reject.
-    5.  Otherwise, allow.
-2.  Reject if event has `auth_events` that:
-    1.  have duplicate entries for a given `type` and `state_key` pair
-    2.  have 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.
-3.  If event does not have a `m.room.create` in its `auth_events`,
-    reject.
-4.  If type is `m.room.member`:
-    1.  If no `state_key` key or `membership` key in `content`, reject.
-    2.  If `content` has a `join_authorised_via_users_server`
-        key:
-        1.  If the event is not validly signed by 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 creator, 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`:
-            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, reject.
-            3.  Otherwise, allow.
-        6.  If the `join_rule` is `public`, allow.
-        7.  Otherwise, reject.
-    4.  If `membership` is `invite`:
-        1.  If `content` has `third_party_invite` key:
-            1.  If *target user* is banned, reject.
-            2.  If `content.third_party_invite` does not have a `signed`
-                key, reject.
-            3.  If `signed` does not have `mxid` and `token` keys,
-                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` field.
-                2.  A list of public keys in the `public_keys` field.
-            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`, 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.
-5.  If the `sender`'s current membership state is not `join`, reject.
-6.  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*.
-7.  If the event type's *required power level* is greater than the
-    `sender`'s power level, reject.
-8.  If the event has a `state_key` that starts with an `@` and does not
-    match the `sender`, reject.
-9. If type is `m.room.power_levels`:
-    1.  If `users` key in `content` is not a dictionary with keys that
-        are valid user IDs with values that are integers (or a string
-        that is an integer), reject.
-    2.  If there is no previous `m.room.power_levels` event in the room,
-        allow.
-    3.  For the keys `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.
-    4.  For each entry being added, changed or removed in both the
-        `events`, `users`, and `notifications` keys:
-        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.
-    5.  For each entry being changed under the `users` key, other than
-        the `sender`'s own entry:
-        1.  If the current value is equal to the `sender`'s current
-            power level, reject.
-    6.  Otherwise, allow.
-10. 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 %}}
\ No newline at end of file
diff --git a/content/rooms/v1.md b/content/rooms/v1.md
deleted file mode 100644
index 1519873b..00000000
--- a/content/rooms/v1.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: Room Version 1
-type: docs
-weight: 10
----
-
-This room version is the first ever version for rooms, and contains the
-building blocks for other room versions.
-
-## Client considerations
-
-Clients which implement the redaction algorithm locally should refer to the
-[redactions](#redactions) section below.
-
-### Redactions
-
-{{% rver-fragment name="v1-redactions" %}}
-
-## 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 %}}
-
-The algorithms defined here should only apply to version 1 rooms. Other
-algorithms may be used by other room versions, and as such servers
-should be aware of which version room they are dealing with prior to
-executing a given algorithm.
-
-{{% boxes/warning %}}
-Although there are many rooms using room version 1, it is known to have
-undesirable effects. Servers implementing support for room version 1
-should be aware that restrictions should be generally relaxed and that
-inconsistencies may occur.
-{{% /boxes/warning %}}
-
-### Redactions
-
-[See above](#redactions).
-
-### Event format
-
-Events in version 1 rooms have the following structure:
-
-{{% definition path="api/server-server/definitions/pdu" %}}
-
-### Authorization rules
-
-{{% rver-fragment name="v1-auth-rules" %}}
-
-### State resolution
-
-{{% boxes/warning %}}
-Room version 1 is known to have bugs that can cause the state of rooms
-to reset to older versions of the room's state. For example this could
-mean that users who had joined the room may be removed from the room,
-admins and moderators could lose their power level, and users who have
-been banned from the room may be able to rejoin. Other state events such
-as the the room's name or topic could also reset to a previous version.
-
-This is fixed in the state resolution algorithm introduced in room
-version 2.
-{{% /boxes/warning %}}
-
-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 *E*'s `event_type` and `state_key` is
-    replaced by *E*'s `event_id`.
-
-The room state *S*(*E*) before *E* is the *resolution* of the set of
-states {*S*′(*E*′), *S*′(*E*″), …} consisting of the states after each
-of *E*'s `prev_event`s {*E*′, *E*″, …}.
-
-The *resolution* of a set of states is defined as follows. The resolved
-state is built up in a number of passes; here we use *R* to refer to the
-results of the resolution so far.
-
--   Start by setting *R* to the union of the states to be resolved,
-    excluding any *conflicting* events.
--   First we resolve conflicts between `m.room.power_levels` events. If
-    there is no conflict, this step is skipped, otherwise:
-    -   Assemble all the `m.room.power_levels` events from the states to
-        be resolved into a list.
-    -   Sort the list by ascending `depth` then descending
-        `sha1(event_id)`.
-    -   Add the first event in the list to *R*.
-    -   For each subsequent event in the list, check that the event
-        would be allowed by the authorization rules for a room in state
-        *R*. If the event would be allowed, then update *R* with the
-        event and continue with the next event in the list. If it would
-        not be allowed, stop and continue below with `m.room.join_rules`
-        events.
--   Repeat the above process for conflicts between `m.room.join_rules`
-    events.
--   Repeat the above process for conflicts between `m.room.member`
-    events.
--   No other events affect the authorization rules, so for all other
-    conflicts, just pick the event with the highest depth and lowest
-    `sha1(event_id)` that passes authentication in *R* and add it to
-    *R*.
-
-A *conflict* occurs between states where those states have different
-`event_ids` for the same `(event_type, state_key)`. The events thus
-affected are said to be *conflicting* events.
-
-### Canonical JSON
-
-{{% rver-fragment name="v1-canonical-json" %}}
diff --git a/content/rooms/v2.md b/content/rooms/v2.md
deleted file mode 100644
index cdc59190..00000000
--- a/content/rooms/v2.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Room Version 2
-type: docs
-weight: 20
----
-
-This room version builds on [version 1](/rooms/v1) with an improved
-state resolution algorithm.
-
-## Client considerations
-
-There are no client considerations introduced in this room version. Clients
-which implement the redaction algorithm locally should refer to the
-[redactions](#redactions) section below for a full overview of the algorithm.
-
-## 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 details contained here, and can safely ignore their
-presence.
-{{% /boxes/warning %}}
-
-Room version 2 uses the base components of [room version 1](/rooms/v1),
-changing only the state resolution algorithm.
-
-### State resolution
-
-{{% added-in this=true %}}
-
-{{% rver-fragment name="v2-state-res" %}}
-
-## Unchanged from v1
-
-The following sections have not been modified since v1, but are included for
-completeness.
-
-### Redactions
-
-{{% rver-fragment name="v1-redactions" %}}
-
-### Event format
-
-Events in rooms of this version have the following structure:
-
-{{% definition path="api/server-server/definitions/pdu" %}}
-
-### Authorization rules
-
-{{% rver-fragment name="v1-auth-rules" %}}
-
-### Canonical JSON
-
-{{% rver-fragment name="v1-canonical-json" %}}
diff --git a/content/rooms/v3.md b/content/rooms/v3.md
deleted file mode 100644
index 310c6625..00000000
--- a/content/rooms/v3.md
+++ /dev/null
@@ -1,111 +0,0 @@
----
-title: Room Version 3
-type: docs
-weight: 30
----
-
-This room version builds on [version 2](/rooms/v2) with an improved event
-format.
-
-## Client considerations
-
-This room version changes the format for event IDs sent to clients.
-Clients should be aware that these event IDs may contain slashes and
-other potentially problematic characters. Clients should be treating
-event IDs as opaque identifiers and should not be attempting to parse
-them into a usable form, just like with other room versions.
-
-Clients should expect to see event IDs changed from the format of
-`$randomstring:example.org` to something like
-`$acR1l0raoZnm60CBwAVgqbZqoO/mYU81xysh1u7XcJk` (note the lack of domain
-and the potentially problematic slash).
-
-Though unchanged in this room version, clients which implement the
-redaction algorithm locally should refer to the [redactions](#redactions)
-section below for a full overview.
-
-## 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 3 uses the event format described here in addition to
-all the remaining behaviour described by [room version 2](/rooms/v2).
-
-### Handling redactions
-
-<!-- set withVersioning=true so we get all the "new in this version" stuff -->
-{{% rver-fragment name="v3-handling-redactions" withVersioning=true %}}
-
-### Event IDs
-
-{{% boxes/rationale %}}
-In other room versions (namely version 1 and 2) the event ID is a
-distinct field from the remainder of the event, which must be tracked as
-such. This leads to complications where servers receive multiple events
-with the same ID in either the same or different rooms where the server
-cannot easily keep track of which event it should be using. By removing
-the use of a dedicated event ID, servers are required to track the
-hashes on an event to determine its ID.
-{{% /boxes/rationale %}}
-
-{{% added-in this=true %}} The event ID is the [reference
-hash](/server-server-api#calculating-the-reference-hash-for-an-event) of
-the event encoded using [Unpadded
-Base64](/appendices#unpadded-base64), prefixed with `$`. A
-resulting event ID using this approach should look similar to
-`$CD66HAED5npg6074c6pDtLKalHjVfYb2q4Q3LZgrW6o`.
-
-### Event format
-
-When events are sent over federation, the `event_id` field is no longer
-included. A server receiving an event should compute the relevant
-event ID for itself.
-
-Additionally, the format of the `auth_events` and `prev_events` fields are
-changed: instead of lists of `(event_id, hash)` pairs, they are now plain lists
-of event IDs.
-
-These changes to the format of an event mean that servers must be aware of the
-version of the room containing an incoming event, so that the event can be
-correctly parsed and handled. This is facilitated via changes to the
-server-server API (such as the inclusion of `room_version` in the response to
-[`GET /_matrix/federation/v1/make_join/{roomId}/{userId}`](/server-server-api/#get_matrixfederationv1make_joinroomiduserid).)
-
-The complete structure of a event in a v3 room is shown below.
-
-{{% definition path="api/server-server/definitions/pdu_v3" %}}
-
-### Authorization rules
-
-{{% added-in this=true %}} `m.room.redaction` events are no longer
-explicitly part of the auth rules. They are still subject to the
-minimum power level rules, but should always fall into "11. Otherwise,
-allow". Instead of being authorized at the time of receipt, they are
-authorized at a later stage: see the [Handling Redactions](#handling-redactions)
-section below for more information.
-
-<!-- set withVersioning=true so we get all the "new in this version" stuff -->
-{{% rver-fragment name="v3-auth-rules" withVersioning=true %}}
-
-## Unchanged from v2
-
-The following sections have not been modified since v2, but are included for
-completeness.
-
-### Redactions
-
-{{% rver-fragment name="v1-redactions" %}}
-
-### State resolution
-
-{{% rver-fragment name="v2-state-res" %}}
-
-### Canonical JSON
-
-{{% rver-fragment name="v1-canonical-json" %}}
diff --git a/content/rooms/v4.md b/content/rooms/v4.md
deleted file mode 100644
index 01c695ba..00000000
--- a/content/rooms/v4.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: Room Version 4
-type: docs
-weight: 40
----
-
-This room version builds on [version 3](/rooms/v3) using a different
-encoding for event IDs.
-
-## Client considerations
-
-This room version changes the format form event IDs sent to clients.
-Clients should already be treating event IDs as opaque identifiers, and
-should not be concerned with the format of them. Clients should still
-encode the event ID when including it in a request path.
-
-Clients should expect to see event IDs changed from the format of
-`$randomstring:example.org` to something like
-`$Rqnc-F-dvnEYJTyHq_iKxU2bZ1CI92-kuZq3a5lr5Zg` (note the lack of
-domain).
-
-Though unchanged in this room version, clients which implement the
-redaction algorithm locally should refer to the [redactions](#redactions)
-section below for a full overview.
-
-## 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 4 uses the same algorithms defined in [room version
-3](/rooms/v3), however using URL-safe base64 to generate the event ID.
-
-### Event IDs
-
-{{% boxes/rationale %}}
-Room version 3 generated event IDs that were difficult for client
-implementations which were not encoding the event ID to function in
-those rooms. It additionally raised concern due to the `/` character
-being interpreted differently by some reverse proxy software, and
-generally made administration harder.
-{{% /boxes/rationale %}}
-
-{{% rver-fragment name="v4-event-ids" withVersioning="true" %}}
-
-## Unchanged from v3
-
-The following sections have not been modified since v3, but are included for
-completeness.
-
-### Redactions
-
-{{% rver-fragment name="v1-redactions" %}}
-
-### Handling redactions
-
-{{% rver-fragment name="v3-handling-redactions" %}}
-
-### Event format
-
-The event format is the same as [room version 3](/rooms/v3#event-format),
-however the event IDs in the following example are updated to reflect
-the changes in this room version.
-
-{{% rver-fragment name="v4-event-format" %}}
-
-### Authorization rules
-
-{{% rver-fragment name="v3-auth-rules" %}}
-
-### State resolution
-
-{{% rver-fragment name="v2-state-res" %}}
-
-### Canonical JSON
-
-{{% rver-fragment name="v1-canonical-json" %}}
diff --git a/content/rooms/v5.md b/content/rooms/v5.md
deleted file mode 100644
index b4283071..00000000
--- a/content/rooms/v5.md
+++ /dev/null
@@ -1,64 +0,0 @@
----
-title: Room Version 5
-type: docs
-weight: 50
----
-
-This room version builds on [version 4](/rooms/v4) while enforcing signing
-key validity periods for events.
-
-## Client considerations
-
-There are no client considerations introduced in this room version. Clients
-which implement the redaction algorithm locally should refer to the
-[redactions](#redactions) section below for a full overview of the algorithm.
-
-## 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 5 uses the same algorithms defined in [room version
-4](/rooms/v4), ensuring that signing key validity is respected.
-
-### Signing key validity period
-
-{{% rver-fragment name="v5-signing-requirements" %}}
-
-## Unchanged from v4
-
-The following sections have not been modified since v4, but are included for
-completeness.
-
-### Redactions
-
-{{% rver-fragment name="v1-redactions" %}}
-
-### Handling redactions
-
-{{% rver-fragment name="v3-handling-redactions" %}}
-
-### Event IDs
-
-{{% rver-fragment name="v4-event-ids" %}}
-
-### Event format
-
-{{% rver-fragment name="v4-event-format" %}}
-
-### Authorization rules
-
-{{% rver-fragment name="v3-auth-rules" %}}
-
-### State resolution
-
-{{% rver-fragment name="v2-state-res" %}}
-
-### Canonical JSON
-
-{{% rver-fragment name="v1-canonical-json" %}}
diff --git a/content/rooms/v6.md b/content/rooms/v6.md
deleted file mode 100644
index 67131371..00000000
--- a/content/rooms/v6.md
+++ /dev/null
@@ -1,221 +0,0 @@
----
-title: Room Version 6
-type: docs
-weight: 60
----
-
-This room version builds on [version 5](/rooms/v5) while changing various
-authorization rules performed on events.
-
-## Client considerations
-
-There are no client considerations introduced in this room version. Clients
-which implement the redaction algorithm locally should refer to the
-[redactions](#redactions) section below for a full overview of the algorithm.
-
-### Redactions
-
-{{% added-in this=true %}} All significant meaning for `m.room.aliases`
-has been removed from the redaction algorithm. The remaining rules are
-the same as past room versions.
-
-{{% rver-fragment name="v6-redactions" %}}
-
-## 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 6 makes the following alterations to algorithms described
-in [room version 5](/rooms/v5).
-
-### Redactions
-
-[See above](#redactions).
-
-### Authorization rules
-
-`m.room.redaction` events are not explicitly part of the auth rules.
-They are still subject to the minimum power level rules, but should always
-fall into "10. Otherwise, allow". Instead of being authorized at the time
-of receipt, they are authorized at a later stage: see the
-[Handling Redactions](#handling-redactions) section below for more information.
-
-{{% added-in this=true %}} Rule 4, which related specifically to events
-of type `m.room.aliases`, is removed. `m.room.aliases` events must still pass
-authorization checks relating to state events.
-
-{{% added-in this=true %}} Additionally, the authorization rules for events
-of type `m.room.power_levels` now include the content key `notifications`.
-This new rule takes the place of rule 10.4, which checked the `events` and
-`users` keys.
-
-Events must be signed by the server denoted by the `sender` key.
-
-The types of state events that affect authorization are:
-
--   `m.room.create`
--   `m.room.member`
--   `m.room.join_rules`
--   `m.room.power_levels`
--   `m.room.third_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 %}}
-
-The rules are as follows:
-
-1.  If type is `m.room.create`:
-    1.  If it has any previous events, reject.
-    2.  If the domain of the `room_id` does not match the domain of the
-        `sender`, reject.
-    3.  If `content.room_version` is present and is not a recognised
-        version, reject.
-    4.  If `content` has no `creator` field, reject.
-    5.  Otherwise, allow.
-2.  Reject if event has `auth_events` that:
-    1.  have duplicate entries for a given `type` and `state_key` pair
-    2.  have 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.
-3.  If event does not have a `m.room.create` in its `auth_events`,
-    reject.
-4.  If type is `m.room.member`:
-    1.  If no `state_key` key or `membership` key in `content`, reject.
-    2.  If `membership` is `join`:
-        1.  If the only previous event is an `m.room.create` and the
-            `state_key` is the creator, 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` then allow if membership
-            state is `invite` or `join`.
-        5.  If the `join_rule` is `public`, allow.
-        6.  Otherwise, reject.
-    3.  If `membership` is `invite`:
-        1.  If `content` has `third_party_invite` key:
-            1.  If *target user* is banned, reject.
-            2.  If `content.third_party_invite` does not have a `signed`
-                key, reject.
-            3.  If `signed` does not have `mxid` and `token` keys,
-                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` field.
-                2.  A list of public keys in the `public_keys` field.
-            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.
-    4.  If `membership` is `leave`:
-        1.  If the `sender` matches `state_key`, allow if and only if
-            that user's current membership state is `invite` or `join`.
-        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.
-    5.  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.
-    6.  Otherwise, the membership is unknown. Reject.
-5.  If the `sender`'s current membership state is not `join`, reject.
-6.  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*.
-7.  If the event type's *required power level* is greater than the
-    `sender`'s power level, reject.
-8.  If the event has a `state_key` that starts with an `@` and does not
-    match the `sender`, reject.
-9. If type is `m.room.power_levels`:
-    1.  If `users` key in `content` is not a dictionary with keys that
-        are valid user IDs with values that are integers (or a string
-        that is an integer), reject.
-    2.  If there is no previous `m.room.power_levels` event in the room,
-        allow.
-    3.  For the keys `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.
-    4.  For each entry being added, changed or removed in both the
-        `events`, `users`, and `notifications` keys:
-        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.
-    5.  For each entry being changed under the `users` key, other than
-        the `sender`'s own entry:
-        1.  If the current value is equal to the `sender`'s current
-            power level, reject.
-    6.  Otherwise, allow.
-10. 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 %}}
-
-### Canonical JSON
-
-{{% rver-fragment name="v6-canonical-json" %}}
-
-## Unchanged from v5
-
-The following sections have not been modified since v5, but are included for
-completeness.
-
-### Handling redactions
-
-{{% rver-fragment name="v3-handling-redactions" %}}
-
-### Event IDs
-
-{{% rver-fragment name="v4-event-ids" %}}
-
-### Event format
-
-{{% rver-fragment name="v4-event-format" %}}
-
-### State resolution
-
-{{% rver-fragment name="v2-state-res" %}}
-
-### Signing key validity period
-
-{{% rver-fragment name="v5-signing-requirements" %}}
diff --git a/content/rooms/v7.md b/content/rooms/v7.md
deleted file mode 100644
index 07e09238..00000000
--- a/content/rooms/v7.md
+++ /dev/null
@@ -1,218 +0,0 @@
----
-title: Room Version 7
-type: docs
-weight: 60
----
-
-This room version builds on [version 6](/rooms/v6) to introduce knocking
-as a possible join rule and membership state.
-
-## Client considerations
-
-This is the first room version to support knocking completely. As such,
-users will not be able to knock on rooms which are not based off v7.
-
-Though unchanged in this room version, clients which implement the
-redaction algorithm locally should refer to the [redactions](#redactions)
-section below for a full overview.
-
-## 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 7 adds new authorization rules for events to support knocking.
-[Room version 6](/rooms/v6) has details of other authorization rule changes,
-as do the versions v6 is based upon.
-
-### Authorization rules
-
-{{% added-in this=true %}} For checks performed upon `m.room.member` events, a
-new point for `membership=knock` is added.
-
-Events must be signed by the server denoted by the `sender` key.
-
-`m.room.redaction` events are not explicitly part of the auth rules.
-They are still subject to the minimum power level rules, but should always
-fall into "10. Otherwise, allow". Instead of being authorized at the time
-of receipt, they are authorized at a later stage: see the
-[Redactions](#redactions) section below for more information.
-
-The types of state events that affect authorization are:
-
--   `m.room.create`
--   `m.room.member`
--   `m.room.join_rules`
--   `m.room.power_levels`
--   `m.room.third_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 %}}
-
-The rules are as follows:
-
-1.  If type is `m.room.create`:
-    1.  If it has any previous events, reject.
-    2.  If the domain of the `room_id` does not match the domain of the
-        `sender`, reject.
-    3.  If `content.room_version` is present and is not a recognised
-        version, reject.
-    4.  If `content` has no `creator` field, reject.
-    5.  Otherwise, allow.
-2.  Reject if event has `auth_events` that:
-    1.  have duplicate entries for a given `type` and `state_key` pair
-    2.  have 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.
-3.  If event does not have a `m.room.create` in its `auth_events`,
-    reject.
-4.  If type is `m.room.member`:
-    1.  If no `state_key` key or `membership` key in `content`, reject.
-    2.  If `membership` is `join`:
-        1.  If the only previous event is an `m.room.create` and the
-            `state_key` is the creator, 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 `public`, allow.
-        6.  Otherwise, reject.
-    3.  If `membership` is `invite`:
-        1.  If `content` has `third_party_invite` key:
-            1.  If *target user* is banned, reject.
-            2.  If `content.third_party_invite` does not have a `signed`
-                key, reject.
-            3.  If `signed` does not have `mxid` and `token` keys,
-                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` field.
-                2.  A list of public keys in the `public_keys` field.
-            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.
-    4.  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.
-    5.  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.
-    6. If `membership` is `knock`:
-        1.  If the `join_rule` is anything other than `knock`, 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.
-    7.  Otherwise, the membership is unknown. Reject.
-5.  If the `sender`'s current membership state is not `join`, reject.
-6.  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*.
-7.  If the event type's *required power level* is greater than the
-    `sender`'s power level, reject.
-8.  If the event has a `state_key` that starts with an `@` and does not
-    match the `sender`, reject.
-9. If type is `m.room.power_levels`:
-    1.  If `users` key in `content` is not a dictionary with keys that
-        are valid user IDs with values that are integers (or a string
-        that is an integer), reject.
-    2.  If there is no previous `m.room.power_levels` event in the room,
-        allow.
-    3.  For the keys `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.
-    4.  For each entry being added, changed or removed in both the
-        `events`, `users`, and `notifications` keys:
-        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.
-    5.  For each entry being changed under the `users` key, other than
-        the `sender`'s own entry:
-        1.  If the current value is equal to the `sender`'s current
-            power level, reject.
-    6.  Otherwise, allow.
-10. 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 %}}
-
-## Unchanged from v6
-
-The following sections have not been modified since v6, but are included for
-completeness.
-
-### Redactions
-
-{{% rver-fragment name="v6-redactions" %}}
-
-### Handling redactions
-
-{{% rver-fragment name="v3-handling-redactions" %}}
-
-### Event IDs
-
-{{% rver-fragment name="v4-event-ids" %}}
-
-### Event format
-
-{{% rver-fragment name="v4-event-format" %}}
-
-### State resolution
-
-{{% rver-fragment name="v2-state-res" %}}
-
-### Canonical JSON
-
-{{% rver-fragment name="v6-canonical-json" %}}
-
-### Signing key validity period
-
-{{% rver-fragment name="v5-signing-requirements" %}}
diff --git a/content/rooms/v8.md b/content/rooms/v8.md
deleted file mode 100644
index 50a1f065..00000000
--- a/content/rooms/v8.md
+++ /dev/null
@@ -1,123 +0,0 @@
----
-title: Room Version 8
-type: docs
-weight: 60
----
-
-This room version builds on [version 7](/rooms/v7) to introduce a new
-join rule that allows members to join the room based on membership in
-another room.
-
-{{% boxes/warning %}}
-This room version is known to have issues relating to redactions of member
-join events. [Room version 9](/rooms/v9) should be preferred over v8 when
-creating rooms.
-{{% /boxes/warning %}}
-
-## Client considerations
-
-Clients are encouraged to expose the option for the join rule in their
-user interface for supported room versions.
-
-The new join rule, `restricted`, is described in the
-[Client-Server API](/client-server-api/#restricted-rooms).
-
-Clients which implement the redaction algorithm locally should refer to the
-[redactions](#redactions) section below for a full overview.
-
-### Redactions
-
-{{% added-in this=true %}} `m.room.join_rules` events now keep `allow` in addition to other
-keys in `content` when being redacted.
-
-{{% boxes/warning %}}
-[Room version 9](/rooms/v9) adds additional cases of protected properties for behaviour
-related to restricted rooms (the functionality introduced in v8). v9 is preferred over
-v8 when creating new rooms.
-{{% /boxes/warning %}}
-
-The full redaction algorithm follows.
-
-Upon receipt of a redaction event, the server must strip off any keys
-not in the following list:
-
--   `event_id`
--   `type`
--   `room_id`
--   `sender`
--   `state_key`
--   `content`
--   `hashes`
--   `signatures`
--   `depth`
--   `prev_events`
--   `prev_state`
--   `auth_events`
--   `origin`
--   `origin_server_ts`
--   `membership`
-
-The content object must also be stripped of all keys, unless it is one
-of one of the following event types:
-
--   `m.room.member` allows key `membership`.
--   `m.room.create` allows key `creator`.
--   `m.room.join_rules` allows keys `join_rule`, `allow`.
--   `m.room.power_levels` allows keys `ban`, `events`, `events_default`,
-    `kick`, `redact`, `state_default`, `users`, `users_default`.
--   `m.room.history_visibility` allows key `history_visibility`.
-
-## 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 8 adds a new join rule to allow members of a room to join another
-room without invite. Otherwise, the room version inherits all properties of
-[Room version 7](/rooms/v7).
-
-### Authorization rules
-
-{{% added-in this=true %}} For checks performed upon `m.room.member` events, new
-points for handling `content.join_authorised_via_users_server` are added (Rule 4.2
-and 4.3.5).
-
-{{% rver-fragment name="v8-auth-rules" %}}
-
-### Redactions
-
-[See above](#redactions).
-
-## Unchanged from v7
-
-The following sections have not been modified since v7, but are included for
-completeness.
-
-### Handling redactions
-
-{{% rver-fragment name="v3-handling-redactions" %}}
-
-### Event IDs
-
-{{% rver-fragment name="v4-event-ids" %}}
-
-### Event format
-
-{{% rver-fragment name="v4-event-format" %}}
-
-### State resolution
-
-{{% rver-fragment name="v2-state-res" %}}
-
-### Canonical JSON
-
-{{% rver-fragment name="v6-canonical-json" %}}
-
-### Signing key validity period
-
-{{% rver-fragment name="v5-signing-requirements" %}}
diff --git a/content/rooms/v9.md b/content/rooms/v9.md
deleted file mode 100644
index 285a7640..00000000
--- a/content/rooms/v9.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-title: Room Version 9
-type: docs
-weight: 60
----
-
-This room version builds on [version 8](/rooms/v8) to add additional redaction
-rules that were unintentionally missed when incorporating v8.
-
-## Client considerations
-
-See [room version 8](/rooms/v8) for specific details regarding the addition of
-restricted rooms.
-
-Clients which implement the redaction algorithm locally should refer to the
-[redactions](#redactions) section below for a full overview.
-
-### Redactions
-
-{{% added-in this=true %}} `m.room.member` now keep `join_authorised_via_users_server`
-in addition to other keys in `content` when being redacted.
-
-{{% boxes/rationale %}}
-Without the `join_authorised_via_users_server` property, redacted join events
-can become invalid when verifying the auth chain of a given event, thus creating
-a split-brain scenario where the user is able to speak from one server's
-perspective but most others will continually reject their events.
-
-This can theoretically be worked around with a rejoin to the room, being careful
-not to use the faulty events as `prev_events`, though instead it is encouraged
-to use v9 rooms over v8 rooms to outright avoid the situation.
-
-[Issue #3373](https://github.com/matrix-org/matrix-doc/issues/3373) has further
-information.
-{{% /boxes/rationale %}}
-
-The full redaction algorithm follows.
-
-{{% rver-fragment name="v3-handling-redactions" %}}
-
-Upon receipt of a redaction event, the server must strip off any keys
-not in the following list:
-
--   `event_id`
--   `type`
--   `room_id`
--   `sender`
--   `state_key`
--   `content`
--   `hashes`
--   `signatures`
--   `depth`
--   `prev_events`
--   `prev_state`
--   `auth_events`
--   `origin`
--   `origin_server_ts`
--   `membership`
-
-The content object must also be stripped of all keys, unless it is one
-of one of the following event types:
-
--   `m.room.member` allows keys `membership`, `join_authorised_via_users_server`.
--   `m.room.create` allows key `creator`.
--   `m.room.join_rules` allows keys `join_rule`, `allow`.
--   `m.room.power_levels` allows keys `ban`, `events`, `events_default`,
-    `kick`, `redact`, `state_default`, `users`, `users_default`.
--   `m.room.history_visibility` allows key `history_visibility`.
-
-## 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 8 added a new `restricted` join rule to allow members of a room
-to join another room without invite. Room version 9 is based upon v8 with the
-following considerations.
-
-### Redactions
-
-[See above](#redactions).
-
-## Unchanged from v8
-
-The following sections have not been modified since v8, but are included for
-completeness.
-
-### Handling redactions
-
-{{% rver-fragment name="v3-handling-redactions" %}}
-
-### Event IDs
-
-{{% rver-fragment name="v4-event-ids" %}}
-
-### Event format
-
-{{% rver-fragment name="v4-event-format" %}}
-
-### Authorization rules
-
-{{% rver-fragment name="v8-auth-rules" %}}
-
-### State resolution
-
-{{% rver-fragment name="v2-state-res" %}}
-
-### Canonical JSON
-
-{{% rver-fragment name="v6-canonical-json" %}}
-
-### Signing key validity period
-
-{{% rver-fragment name="v5-signing-requirements" %}}
diff --git a/content/server-server-api.md b/content/server-server-api.md
deleted file mode 100644
index b848d3d6..00000000
--- a/content/server-server-api.md
+++ /dev/null
@@ -1,1256 +0,0 @@
----
-title: "Server-Server API"
-weight: 20
-type: docs
----
-
-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:
-
-Persisted 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 client-server communication in Matrix is
-exchanging JSON objects over HTTP APIs. More efficient optional
-transports will in future be supported as optional extensions - e.g. a
-packed binary encoding over stream-cipher encrypted TCP socket for
-low-bandwidth/low-roundtrip mobile usage. For the default HTTP
-transport, all API calls use a Content-Type of `application/json`. In
-addition, all strings MUST be encoded as UTF-8.
-
-## Server discovery
-
-### Resolving server names
-
-Each Matrix homeserver is identified by a server name consisting of a
-hostname and an optional port, as described by the
-[grammar](/appendices#server-name). Where applicable, a delegated
-server name uses the same grammar.
-
-Server names are resolved to an IP address and port to connect to, and
-have various conditions affecting which certificates and `Host` headers
-to send. The process overall is as follows:
-
-1.  If the hostname is an IP literal, then that IP address should be
-    used, together with the given port number, or 8448 if no port is
-    given. The target server must present a valid certificate for the IP
-    address. The `Host` header in the request should be set to the
-    server name, including the port if the server name included one.
-2.  If the hostname is not an IP literal, and the server name includes
-    an explicit port, resolve the IP address using AAAA or A records.
-    Requests are made to the resolved IP address and given port with a
-    `Host` header of the original server name (with port). The target
-    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`, 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
-    cached by the requesting server. Servers should respect the cache
-    control headers present on the response, or use a sensible default
-    when headers are not present. The recommended sensible default is 24
-    hours. Servers should additionally impose a maximum cache time for
-    responses: 48 hours is recommended. Errors are recommended to be
-    cached for up to an hour, and servers are encouraged to
-    exponentially back off for repeated failures. The schema of the
-    `/.well-known` request is later in this section. If the response is
-    invalid (bad JSON, missing properties, non-200 response, etc), skip
-    to step 4. If the response is valid, the `m.server` property is
-    parsed as `<delegated_hostname>[:<delegated_port>]` and processed as
-    follows:
-    -   If `<delegated_hostname>` is an IP literal, then that IP address
-        should be used together with the `<delegated_port>` or 8448 if
-        no port is provided. The target server must present a valid TLS
-        certificate for the IP address. Requests must be made with a
-        `Host` header containing the IP address, including the port if
-        one was provided.
-    -   If `<delegated_hostname>` is not an IP literal, and
-        `<delegated_port>` is present, an IP address is discovered by
-        looking up an AAAA or A record for `<delegated_hostname>`. The
-        resulting IP address is used, alongside the `<delegated_port>`.
-        Requests must be made with a `Host` header of
-        `<delegated_hostname>:<delegated_port>`. The target server must
-        present a valid certificate for `<delegated_hostname>`.
-    -   If `<delegated_hostname>` is not an IP literal and no
-        `<delegated_port>` is present, an SRV record is looked up for
-        `_matrix._tcp.<delegated_hostname>`. This may result in another
-        hostname (to be resolved using AAAA or A records) and port.
-        Requests should be made to the resolved IP address and port with
-        a `Host` header containing the `<delegated_hostname>`. The
-        target server must present a valid certificate for
-        `<delegated_hostname>`.
-    -   If no SRV record is found, an IP address is resolved using AAAA
-        or A records. Requests are then made to the resolve IP address
-        and a port of 8448, using a `Host` header of
-        `<delegated_hostname>`. The target server must present a valid
-        certificate for `<delegated_hostname>`.
-4.  If the `/.well-known` request resulted in an error response, a
-    server is found by resolving an SRV record for
-    `_matrix._tcp.<hostname>`. This may result in a hostname (to be
-    resolved using AAAA or A records) and port. Requests are made to the
-    resolved IP address and port, using 8448 as a default port, with a
-    `Host` header of `<hostname>`. The target server must present a
-    valid certificate for `<hostname>`.
-5.  If the `/.well-known` request returned an error response, and the
-    SRV record was not found, an IP address is resolved using AAAA and A
-    records. Requests are made to the resolved IP address using port
-    8448 and a `Host` header containing the `<hostname>`. The target
-    server must present a valid certificate for `<hostname>`.
-
-{{% boxes/note %}}
-The reasons we require `<hostname>` rather than `<delegated_hostname>` for SRV
-delegation are:
-  1. DNS is insecure (not all domains have DNSSEC), so the target of the delegation
-      must prove that it is a valid delegate for `<hostname>` via TLS.
-  2. Consistency with the recommendations in [RFC6125](https://datatracker.ietf.org/doc/html/rfc6125#section-6.2.1)
-     and other applications using SRV records such [XMPP](https://datatracker.ietf.org/doc/html/rfc6120#section-13.7.2.1).
-{{% /boxes/note %}}
-
-The TLS certificate provided by the target server must be signed by a
-known Certificate Authority. Servers are ultimately responsible for
-determining the trusted Certificate Authorities, however are strongly
-encouraged to rely on the operating system's judgement. Servers can
-offer administrators a means to override the trusted authorities list.
-Servers can additionally skip the certificate validation for a given
-whitelist of domains or netmasks for the purposes of testing or in
-networks where verification is done elsewhere, such as with `.onion`
-addresses. Servers should respect SNI when making requests where
-possible: a SNI should be sent for the certificate which is expected,
-unless that certificate is expected to be an IP address in which case
-SNI is not supported and should not be sent.
-
-Servers are encouraged to make use of the [Certificate
-Transparency](https://www.certificate-transparency.org/) project.
-
-{{% http-api spec="server-server" api="wellknown" %}}
-
-### Server implementation
-
-{{% http-api spec="server-server" api="version" %}}
-
-### Retrieving server keys
-
-{{% boxes/note %}}
-There was once a "version 1" of the key exchange. It has been removed
-from the specification due to lack of significance. It may be reviewed
-[from the historical
-draft](https://github.com/matrix-org/matrix-doc/blob/51faf8ed2e4a63d4cfd6d23183698ed169956cc0/specification/server_server_api.rst#232version-1).
-{{% /boxes/note %}}
-
-Each homeserver publishes its public keys under
-`/_matrix/key/v2/server/{keyId}`. Homeservers query for keys by either
-getting `/_matrix/key/v2/server/{keyId}` directly or by querying an
-intermediate notary server using a
-`/_matrix/key/v2/query/{serverName}/{keyId}` API. Intermediate notary
-servers query the `/_matrix/key/v2/server/{keyId}` API on behalf of
-another server and sign the response with their own key. A server may
-query multiple notary servers to ensure that they all report the same
-public keys.
-
-This approach is borrowed from the [Perspectives
-Project](https://web.archive.org/web/20170702024706/https://perspectives-project.org/),
-but modified to include the NACL keys and to use JSON instead of XML. It
-has the advantage of avoiding a single trust-root since each server is
-free to pick which notary servers they trust and can corroborate the
-keys returned by a given notary server by querying other servers.
-
-#### Publishing Keys
-
-Homeservers publish their signing keys in a JSON object at
-`/_matrix/key/v2/server/{key_id}`. The response contains a list of
-`verify_keys` that are valid for signing federation requests made by the
-homeserver and for signing events. It contains a list of
-`old_verify_keys` which are only valid for signing events.
-
-{{% http-api spec="server-server" api="keys_server" %}}
-
-#### Querying Keys Through Another Server
-
-Servers may query another server's keys through a notary server. The
-notary server may be another homeserver. The notary server will retrieve
-keys from the queried servers through use of the
-`/_matrix/key/v2/server/{keyId}` API. The notary server will
-additionally sign the response from the queried server before returning
-the results.
-
-Notary servers can return keys for servers that are offline or having
-issues serving their own keys by using cached responses. Keys can be
-queried from multiple servers to mitigate against DNS spoofing.
-
-{{% http-api spec="server-server" api="keys_query" %}}
-
-## Authentication
-
-### Request Authentication
-
-Every HTTP request made by a homeserver is authenticated using public
-key digital signatures. The request method, target and body are signed
-by wrapping them in a JSON object and signing it using the JSON signing
-algorithm. The resulting signatures are added as an Authorization header
-with an auth scheme of `X-Matrix`. Note that the target field should
-include the full path starting with `/_matrix/...`, including the `?`
-and any query parameters if present, but should not include the leading
-`https:`, nor the destination server's hostname.
-
-Step 1 sign JSON:
-
-```
-{
-    "method": "GET",
-    "uri": "/target",
-    "origin": "origin.hs.example.com",
-    "destination": "destination.hs.example.com",
-    "content": <JSON-parsed request body>,
-    "signatures": {
-        "origin.hs.example.com": {
-            "ed25519:key1": "ABCDEF..."
-        }
-    }
-}
-```
-
-The server names in the JSON above are the server names for each
-homeserver involved. Delegation from the [server name resolution
-section](#resolving-server-names) above do not affect these - the server
-names from before delegation would take place are used. This same
-condition applies throughout the request signing process.
-
-Step 2 add Authorization header:
-
-    GET /target HTTP/1.1
-    Authorization: X-Matrix origin=origin.example.com,key="ed25519:key1",sig="ABCDEF..."
-    Content-Type: application/json
-
-    <JSON-encoded request body>
-
-Example python code:
-
-```py
-def authorization_headers(origin_name, origin_signing_key,
-                          destination_name, request_method, request_target,
-                          content=None):
-    request_json = {
-         "method": request_method,
-         "uri": request_target,
-         "origin": origin_name,
-         "destination": destination_name,
-    }
-
-    if content is not None:
-        # Assuming content is already parsed as JSON
-        request_json["content"] = content
-
-    signed_json = sign_json(request_json, origin_name, origin_signing_key)
-
-    authorization_headers = []
-
-    for key, sig in signed_json["signatures"][origin_name].items():
-        authorization_headers.append(bytes(
-            "X-Matrix origin=%s,key=\"%s\",sig=\"%s\"" % (
-                origin_name, key, sig,
-            )
-        ))
-
-    return ("Authorization", authorization_headers)
-```
-
-### Response Authentication
-
-Responses are authenticated by the TLS server certificate. A homeserver
-should not send a request until it has authenticated the connected
-server to avoid leaking messages to eavesdroppers.
-
-### Client TLS Certificates
-
-Requests are authenticated at the HTTP layer rather than at the TLS
-layer because HTTP services like Matrix are often deployed behind load
-balancers that handle the TLS and these load balancers make it difficult
-to check TLS client certificates.
-
-A homeserver may provide a TLS client certificate and the receiving
-homeserver may check that the client certificate matches the certificate
-of the origin homeserver.
-
-## Transactions
-
-The transfer of EDUs and PDUs between homeservers is performed by an
-exchange of Transaction messages, which are encoded as JSON objects,
-passed over an HTTP PUT request. A Transaction is meaningful only to the
-pair of homeservers that exchanged it; they are not globally-meaningful.
-
-Transactions are limited in size; they can have at most 50 PDUs and 100
-EDUs.
-
-{{% http-api spec="server-server" api="transactions" %}}
-
-## PDUs
-
-Each PDU contains a single Room Event which the origin server wants to
-send to the destination.
-
-The `prev_events` field of a PDU identifies the "parents" of the event,
-and thus establishes a partial ordering on events within the room by
-linking them into a Directed Acyclic Graph (DAG). The sending server
-should populate this field with all of the events in the room for which
-it has not yet seen a child - thus demonstrating that the event comes
-after all other known events.
-
-For example, consider a room whose events form the DAG shown below. A
-server creating a new event in this room should populate the new event's
-`prev_events` field with both `E4` and `E6`, since neither event yet has
-a child:
-
-    E1
-    ^
-    |
-    E2 <--- E5
-    ^       ^
-    |       |
-    E3      E6
-    ^
-    |
-    E4
-
-For a full schema of what a PDU looks like, see the [room version
-specification](/rooms).
-
-### Checks performed on receipt of a PDU
-
-Whenever a server receives an event from a remote server, the receiving
-server must ensure that the event:
-
-1.  Is a valid event, otherwise it is dropped.
-2.  Passes signature checks, otherwise it is dropped.
-3.  Passes hash checks, otherwise it is redacted before being processed
-    further.
-4.  Passes authorization rules based on the event's auth events,
-    otherwise it is rejected.
-5.  Passes authorization rules based on the state at the event,
-    otherwise it is rejected.
-6.  Passes authorization rules based on the current state of the room,
-    otherwise it is "soft failed".
-
-Further details of these checks, and how to handle failures, are
-described below.
-
-The [Signing Events](#signing-events) section has more information on
-which hashes and signatures are expected on events, and how to calculate
-them.
-
-#### Definitions
-
-**Required Power Level** \
-A given event type has an associated *required power level*. This is
-given by the current `m.room.power_levels` event. The event type is
-either listed explicitly in the `events` section or given by either
-`state_default` or `events_default` depending on if the event is a state
-event or not.
-
-**Invite Level, Kick Level, Ban Level, Redact Level** \
-The levels given by the `invite`, `kick`, `ban`, and `redact` properties
-in the current `m.room.power_levels` state. Each defaults to 50 if
-unspecified.
-
-**Target User** \
-For an `m.room.member` state event, the user given by the `state_key` of
-the event.
-
-#### Authorization rules
-
-The rules governing whether an event is authorized depends on a set of
-state. A given event is checked multiple times against different sets of
-state, as specified above. Each room version can have a different
-algorithm for how the rules work, and which rules are applied. For more
-detailed information, please see the [room version
-specification](/rooms).
-
-##### Auth events selection
-
-The `auth_events` field of a PDU identifies the set of events which give
-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:
-
-- The `m.room.create` event.
-
-- The current `m.room.power_levels` event, if any.
-
-- The sender's current `m.room.member` event, if any.
-
-- If type is `m.room.member`:
-
-    - The target's current `m.room.member` event, if any.
-    - If `membership` is `join` or `invite`, the current
-      `m.room.join_rules` event, if any.
-    - If membership is `invite` and `content` contains a
-      `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 `content.join_authorised_via_users_server` is present,
-      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`.
-
-#### Rejection
-
-If an event is rejected it should neither be relayed to clients nor be
-included as a prev event in any new events generated by the server.
-Subsequent events from other servers that reference rejected events
-should be allowed if they still pass the auth rules. The state used in
-the checks should be calculated as normal, except not updating with the
-rejected event where it is a state event.
-
-If an event in an incoming transaction is rejected, this should not
-cause the transaction request to be responded to with an error response.
-
-{{% boxes/note %}}
-This means that events may be included in the room DAG even though they
-should be rejected.
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-This is in contrast to redacted events which can still affect the state
-of the room. For example, a redacted `join` event will still result in
-the user being considered joined.
-{{% /boxes/note %}}
-
-#### Soft failure
-
-{{% boxes/rationale %}}
-It is important that we prevent users from evading bans (or other power
-restrictions) by creating events which reference old parts of the DAG.
-For example, a banned user could continue to send messages to a room by
-having their server send events which reference the event before they
-were banned. Note that such events are entirely valid, and we cannot
-simply reject them, as it is impossible to distinguish such an event
-from a legitimate one which has been delayed. We must therefore accept
-such events and let them participate in state resolution and the
-federation protocol as normal. However, servers may choose not to send
-such events on to their clients, so that end users won't actually see
-the events.
-
-When this happens it is often fairly obvious to servers, as they can see
-that the new event doesn't actually pass auth based on the "current
-state" (i.e. the resolved state across all forward extremities). While
-the event is technically valid, the server can choose to not notify
-clients about the new event.
-
-This discourages servers from sending events that evade bans etc. in
-this way, as end users won't actually see the events.
-{{% /boxes/rationale %}}
-
-When the homeserver receives a new event over federation it should also
-check whether the event passes auth checks based on the current state of
-the room (as well as based on the state at the event). If the event does
-not pass the auth checks based on the *current state* of the room (but
-does pass the auth checks based on the state at that event) it should be
-"soft failed".
-
-When an event is "soft failed" it should not be relayed to the client
-nor be referenced by new events created by the homeserver (i.e. they
-should not be added to the server's list of forward extremities of the
-room). Soft failed events are otherwise handled as usual.
-
-{{% boxes/note %}}
-Soft failed events participate in state resolution as normal if further
-events are received which reference it. It is the job of the state
-resolution algorithm to ensure that malicious events cannot be injected
-into the room state via this mechanism.
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-Because soft failed state events participate in state resolution as
-normal, it is possible for such events to appear in the current state of
-the room. In that case the client should be told about the soft failed
-event in the usual way (e.g. by sending it down in the `state` section
-of a sync response).
-{{% /boxes/note %}}
-
-{{% boxes/note %}}
-A soft failed event should be returned in response to federation
-requests where appropriate (e.g. in `/event/<event_id>`). Note that soft
-failed events are returned in `/backfill` and `/get_missing_events`
-responses only if the requests include events referencing the soft
-failed events.
-{{% /boxes/note %}}
-
-Example
-
-As an example consider the event graph:
-
-      A
-     /
-    B
-
-where `B` is a ban of a user `X`. If the user `X` tries to set the topic
-by sending an event `C` while evading the ban:
-
-      A
-     / \
-    B   C
-
-servers that receive `C` after `B` should soft fail event `C`, and so
-will neither relay `C` to its clients nor send any events referencing
-`C`.
-
-If later another server sends an event `D` that references both `B` and
-`C` (this can happen if it received `C` before `B`):
-
-      A
-     / \
-    B   C
-     \ /
-      D
-
-then servers will handle `D` as normal. `D` is sent to the servers'
-clients (assuming `D` passes auth checks). The state at `D` may resolve
-to a state that includes `C`, in which case clients should also to be
-told that the state has changed to include `C`. (*Note*: This depends on
-the exact state resolution algorithm used. In the original version of
-the algorithm `C` would be in the resolved state, whereas in latter
-versions the algorithm tries to prioritise the ban over the topic
-change.)
-
-Note that this is essentially equivalent to the situation where one
-server doesn't receive `C` at all, and so asks another server for the
-state of the `C` branch.
-
-Let's go back to the graph before `D` was sent:
-
-      A
-     / \
-    B   C
-
-If all the servers in the room saw `B` before `C` and so soft fail `C`,
-then any new event `D'` will not reference `C`:
-
-      A
-     / \
-    B   C
-    |
-    D'
-
-#### Retrieving event authorization information
-
-The homeserver may be missing event authorization information, or wish
-to check with other servers to ensure it is receiving the correct auth
-chain. These APIs give the homeserver an avenue for getting the
-information it needs.
-
-{{% http-api spec="server-server" api="event_auth" %}}
-
-## EDUs
-
-EDUs, by comparison to PDUs, do not have an ID, a room ID, or a list of
-"previous" IDs. They are intended to be non-persistent data such as user
-presence, typing notifications, etc.
-
-{{% definition path="api/server-server/definitions/edu" %}}
-
-## Room State Resolution
-
-The *state* of a room is a map of `(event_type, state_key)` to
-`event_id`. Each room starts with an empty state, and each state event
-which is accepted into the room updates the state of that room.
-
-Where each event has a single `prev_event`, it is clear what the state
-of the room after each event should be. However, when two branches in
-the event graph merge, the state of those branches might differ, so a
-*state resolution* algorithm must be used to determine the resultant
-state.
-
-For example, consider the following event graph (where the oldest event,
-E0, is at the top):
-
-      E0
-      |
-      E1
-     /  \
-    E2  E4
-    |    |
-    E3   |
-     \  /
-      E5
-
-Suppose E3 and E4 are both `m.room.name` events which set the name of
-the room. What should the name of the room be at E5?
-
-The algorithm to be used for state resolution depends on the room
-version. For a description of each room version's algorithm, please see
-the [room version specification](/rooms).
-
-## Backfilling and retrieving missing events
-
-Once a homeserver has joined a room, it receives all the events emitted
-by other homeservers in that room, and is thus aware of the entire
-history of the room from that moment onwards. Since users in that room
-are able to request the history by the `/messages` client API endpoint,
-it's possible that they might step backwards far enough into history
-before the homeserver itself was a member of that room.
-
-To cover this case, the federation API provides a server-to-server
-analog of the `/messages` client API, allowing one homeserver to fetch
-history from another. This is the `/backfill` API.
-
-To request more history, the requesting homeserver picks another
-homeserver that it thinks may have more (most likely this should be a
-homeserver for some of the existing users in the room at the earliest
-point in history it has currently), and makes a `/backfill` request.
-
-Similar to backfilling a room's history, a server may not have all the
-events in the graph. That server may use the `/get_missing_events` API
-to acquire the events it is missing.
-
-{{% http-api spec="server-server" api="backfill" %}}
-
-## Retrieving events
-
-In some circumstances, a homeserver may be missing a particular event or
-information about the room which cannot be easily determined from
-backfilling. These APIs provide homeservers with the option of getting
-events and the state of the room at a given point in the timeline.
-
-{{% http-api spec="server-server" api="events" %}}
-
-## Joining Rooms
-
-When a new user wishes to join a room that the user's homeserver already
-knows about, the homeserver can immediately determine if this is
-allowable by inspecting the state of the room. If it is acceptable, it
-can generate, sign, and emit a new `m.room.member` state event adding
-the user into that room. When the homeserver does not yet know about the
-room it cannot do this directly. Instead, it must take a longer
-multi-stage handshaking process by which it first selects a remote
-homeserver which is already participating in that room, and use it to
-assist in the joining process. This is the remote join handshake.
-
-This handshake involves the homeserver of the new member wishing to join
-(referred to here as the "joining" server), the directory server hosting
-the room alias the user is requesting to join with, and a homeserver
-where existing room members are already present (referred to as the
-"resident" server).
-
-In summary, the remote join handshake consists of the joining server
-querying the directory server for information about the room alias;
-receiving a room ID and a list of join candidates. The joining server
-then requests information about the room from one of the residents. It
-uses this information to construct an `m.room.member` event which it
-finally sends to a resident server.
-
-Conceptually these are three different roles of homeserver. In practice
-the directory server is likely to be resident in the room, and so may be
-selected by the joining server to be the assisting resident. Likewise,
-it is likely that the joining server picks the same candidate resident
-for both phases of event construction, though in principle any valid
-candidate may be used at each time. Thus, any join handshake can
-potentially involve anywhere from two to four homeservers, though most
-in practice will use just two.
-
-<!--
-https://textart.io/sequence
-
-object Client JoiningServer DirectoryServer ResidentServer
-Client->JoiningServer: join request
-JoiningServer->DirectoryServer: directory request
-DirectoryServer->JoiningServer: directory response
-JoiningServer->ResidentServer: make_join request
-ResidentServer->JoiningServer: make_join response
-JoiningServer->ResidentServer: send_join request
-ResidentServer->JoiningServer: send_join response
-JoiningServer->Client: join response
--->
-
-```
-+---------+          +---------------+            +-----------------+ +-----------------+
-| Client  |          | JoiningServer |            | DirectoryServer | | ResidentServer  |
-+---------+          +---------------+            +-----------------+ +-----------------+
-     |                       |                             |                   |
-     | join request          |                             |                   |
-     |---------------------->|                             |                   |
-     |                       |                             |                   |
-     |                       | directory request           |                   |
-     |                       |---------------------------->|                   |
-     |                       |                             |                   |
-     |                       |          directory response |                   |
-     |                       |<----------------------------|                   |
-     |                       |                             |                   |
-     |                       | make_join request           |                   |
-     |                       |------------------------------------------------>|
-     |                       |                             |                   |
-     |                       |                             |make_join response |
-     |                       |<------------------------------------------------|
-     |                       |                             |                   |
-     |                       | send_join request           |                   |
-     |                       |------------------------------------------------>|
-     |                       |                             |                   |
-     |                       |                             |send_join response |
-     |                       |<------------------------------------------------|
-     |                       |                             |                   |
-     |         join response |                             |                   |
-     |<----------------------|                             |                   |
-     |                       |                             |                   |
-```
-
-The first part of the handshake usually involves using the directory
-server to request the room ID and join candidates through the
-[`/query/directory`](/server-server-api/#get_matrixfederationv1querydirectory) API endpoint. In the case of a new user joining a
-room as a result of a received invite, the joining user's homeserver
-could optimise this step away by picking the origin server of that
-invite message as the join candidate. However, the joining server should
-be aware that the origin server of the invite might since have left the
-room, so should be prepared to fall back on the regular join flow if
-this optimisation fails.
-
-Once the joining server has the room ID and the join candidates, it then
-needs to obtain enough information about the room to fill in the
-required fields of the `m.room.member` event. It obtains this by
-selecting a resident from the candidate list, and using the
-`GET /make_join` endpoint. The resident server will then reply with
-enough information for the joining server to fill in the event.
-
-The joining server is expected to add or replace the `origin`,
-`origin_server_ts`, and `event_id` on the templated event received by
-the resident server. This event is then signed by the joining server.
-
-To complete the join handshake, the joining server submits this new event
-to the resident server it used for `GET /make_join`, using the `PUT /send_join`
-endpoint.
-
-The resident homeserver then adds its signature to this event and
-accepts it into the room's event graph. The joining server receives
-the full set of state for the newly-joined room as well as the freshly
-signed membership event. The resident server must also send the event
-to other servers participating in the room.
-
-{{% http-api spec="server-server" api="joins-v1" %}}
-
-{{% http-api spec="server-server" api="joins-v2" %}}
-
-### Restricted rooms
-
-Restricted rooms are described in detail in the
-[client-server API](/client-server-api/#restricted-rooms) and are available
-in room versions [which support restricted join rules](/rooms/#feature-matrix).
-
-A resident server processing a request to join a restricted room must
-ensure that the joining server satisfies at least one of the conditions
-specified by `m.room.join_rules`. If no conditions are available, or none
-match the required schema, then the joining server is considered to have
-failed all conditions.
-
-The resident server uses a 400 `M_UNABLE_TO_AUTHORISE_JOIN` error on
-`/make_join` and `/send_join` to denote that the resident server is unable
-to validate any of the conditions, usually because the resident server
-does not have state information about rooms required by the conditions.
-
-The resident server uses a 400 `M_UNABLE_TO_GRANT_JOIN` error on `/make_join`
-and `/send_join` to denote that the joining server should try a different
-server. This is typically because the resident server can see that the
-joining user satisfies one of the conditions, though the resident server
-would be unable to meet the auth rules governing `join_authorised_via_users_server`
-on the resulting `m.room.member` event.
-
-If the joining server fails all conditions then a 403 `M_FORBIDDEN` error
-is used by the resident server.
-
-## Knocking upon a room
-
-Rooms can permit knocking through the join rules, and if permitted this
-gives users a way to request to join (be invited) to the room. Users who
-knock on a room where the server is already a resident of the room can
-just send the knock event directly without using this process, however
-much like [joining rooms](/server-server-api/#joining-rooms) the server
-must handshake their way into having the knock sent on its behalf.
-
-The handshake is largely the same as the joining rooms handshake, where
-instead of a "joining server" there is a "knocking server", and the APIs
-to be called are different (`/make_knock` and `/send_knock`).
-
-Servers can retract knocks over federation by leaving the room, as described
-below for rejecting invites.
-
-{{% http-api spec="server-server" api="knocks" %}}
-
-## Inviting to a room
-
-When a user on a given homeserver invites another user on the same
-homeserver, the homeserver may sign the membership event itself and skip
-the process defined here. However, when a user invites another user on a
-different homeserver, a request to that homeserver to have the event
-signed and verified must be made.
-
-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.
-
-{{% http-api spec="server-server" api="invites-v1" %}}
-
-{{% http-api spec="server-server" api="invites-v2" %}}
-
-## Leaving Rooms (Rejecting Invites)
-
-Normally homeservers can send appropriate `m.room.member` events to have
-users leave the room, to reject local invites, or to retract a knock.
-Remote invites/knocks from other homeservers do not involve the server in the
-graph and therefore need another approach to reject the invite. Joining
-the room and promptly leaving is not recommended as clients and servers will
-interpret that as accepting the invite, then leaving the room rather
-than rejecting the invite.
-
-Similar to the [Joining Rooms](#joining-rooms) handshake, the server
-which wishes to leave the room starts with sending a `/make_leave`
-request to a resident server. In the case of rejecting invites, the
-resident server may be the server which sent the invite. After receiving
-a template event from `/make_leave`, the leaving server signs the event
-and replaces the `event_id` with its own. This is then sent to the
-resident server via `/send_leave`. The resident server will then send
-the event to other servers in the room.
-
-{{% http-api spec="server-server" api="leaving-v1" %}}
-
-{{% http-api spec="server-server" api="leaving-v2" %}}
-
-## Third-party invites
-
-{{% boxes/note %}}
-More information about third party invites is available in the
-[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
-Matrix ID to invite, they can do so using a third-party identifier (e.g.
-an e-mail or a phone number).
-
-This identifier and its bindings to Matrix IDs are verified by an
-identity server implementing the [Identity Service
-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
-request on the identity server will return it. The invite is then
-processed by the inviting homeserver as a standard `m.room.member`
-invite event. This is the 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 for this
-identifier and to deliver it to whoever binds it to its Matrix ID. It
-will also send an `m.room.third_party_invite` event in the room to
-specify a display name, a token and public keys the identity server
-provided as a response to the invite storage request.
-
-When a third-party identifier with pending invites gets bound to a
-Matrix ID, the identity server will send a POST request to the ID's
-homeserver as described in the [Invitation
-Storage](/identity-service-api#invitation-storage)
-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` invite event
-containing a special `third_party_invite` section containing the token
-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 room's homeserver to auth the event.
-
-{{% http-api spec="server-server" api="third_party_invite" %}}
-
-#### Verifying the invite
-
-When a homeserver receives an `m.room.member` invite event for a room
-it's in with a `third_party_invite` object, it must verify that the
-association between the third-party identifier initially invited to the
-room and the Matrix ID that claims to be bound to it has been verified
-without having to rely on a third-party server.
-
-To do so, it will fetch from the room's state events the
-`m.room.third_party_invite` event for which the state key matches with
-the value for the `token` key in the `third_party_invite` object from
-the `m.room.member` event's content to fetch the public keys initially
-delivered by the identity server that stored the invite.
-
-It will then use these keys to verify that the `signed` object (in the
-`third_party_invite` object from the `m.room.member` event's content)
-was signed by the same identity server.
-
-Since this `signed` object can only be delivered once in the POST
-request emitted by the identity server upon binding between the
-third-party identifier and the Matrix ID, and contains the invited
-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.
-
-## Public Room Directory
-
-To complement the [Client-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.
-
-{{% http-api spec="server-server" api="public_rooms" %}}
-
-## Spaces
-
-To complement the [Client-Server API's Spaces module](/client-server-api/#spaces),
-homeservers need a way to query information about spaces from other servers.
-
-{{% http-api spec="server-server" api="space_hierarchy" %}}
-
-## Typing Notifications
-
-When a server's users send typing notifications, those notifications
-need to be sent to other servers in the room so their users are aware of
-the same state. Receiving servers should verify that the user is in the
-room, and is a user belonging to the sending server.
-
-{{% definition path="api/server-server/definitions/event-schemas/m.typing" %}}
-
-## Presence
-
-The server API for presence is based entirely on exchange of the
-following EDUs. There are no PDUs or Federation Queries involved.
-
-Servers should only send presence updates for users that the receiving
-server would be interested in. Such as the receiving server sharing a
-room with a given user.
-
-{{% definition path="api/server-server/definitions/event-schemas/m.presence" %}}
-
-## Receipts
-
-Receipts are EDUs used to communicate a marker for a given event.
-Currently the only kind of receipt supported is a "read receipt", or
-where in the event graph the user has read up to.
-
-Read receipts for events that a user sent do not need to be sent. It is
-implied that by sending the event the user has read up to the event.
-
-{{% definition path="api/server-server/definitions/event-schemas/m.receipt" %}}
-
-## Querying for information
-
-Queries are a way to retrieve information from a homeserver about a
-resource, such as a user or room. The endpoints here are often called in
-conjunction with a request from a client on the client-server API in
-order to complete the call.
-
-There are several types of queries that can be made. The generic
-endpoint to represent all queries is described first, followed by the
-more specific queries that can be made.
-
-{{% http-api spec="server-server" api="query" %}}
-
-## OpenID
-
-Third party services can exchange an access token previously generated
-by the <span class="title-ref">Client-Server API</span> for information
-about a user. This can help verify that a user is who they say they are
-without granting full access to the user's account.
-
-Access tokens generated by the OpenID API are only good for the OpenID
-API and nothing else.
-
-{{% http-api spec="server-server" api="openid" %}}
-
-## Device Management
-
-Details of a user's devices must be efficiently published to other users
-and kept up-to-date. This is critical for reliable end-to-end
-encryption, in order for users to know which devices are participating
-in a room. It's also required for to-device messaging to work. This
-section is intended to complement the [Device Management
-module](/client-server-api#device-management)
-of the Client-Server API.
-
-Matrix currently uses a custom pubsub system for synchronising
-information about the list of devices for a given user over federation.
-When a server wishes to determine a remote user's device list for the
-first time, it should populate a local cache from the result of a
-`/user/keys/query` API on the remote server. However, subsequent updates
-to the cache should be applied by consuming `m.device_list_update` EDUs.
-Each new `m.device_list_update` EDU describes an incremental change to
-one device for a given user which should replace any existing entry in
-the local server's cache of that device list. Servers must send
-`m.device_list_update` EDUs to all the servers who share a room with a
-given local user, and must be sent whenever that user's device list
-changes (i.e. for new or deleted devices, when that user joins a room
-which contains servers which are not already receiving updates for that
-user's device list, or changes in device information such as the
-device's human-readable name).
-
-Servers send `m.device_list_update` EDUs in a sequence per origin user,
-each with a unique `stream_id`. They also include a pointer to the most
-recent previous EDU(s) that this update is relative to in the `prev_id`
-field. To simplify implementation for clustered servers which could send
-multiple EDUs at the same time, the `prev_id` field should include all
-`m.device_list_update` EDUs which have not been yet been referenced in a
-EDU. If EDUs are emitted in series by a server, there should only ever
-be one `prev_id` in the EDU.
-
-This forms a simple directed acyclic graph of `m.device_list_update`
-EDUs, showing which EDUs a server needs to have received in order to
-apply an update to its local copy of the remote user's device list. If a
-server receives an EDU which refers to a `prev_id` it does not
-recognise, it must resynchronise its list by calling the
-`/user/keys/query API` and resume the process. The response contains a
-`stream_id` which should be used to correlate with subsequent
-`m.device_list_update` EDUs.
-
-{{% http-api spec="server-server" api="user_devices" %}}
-
-{{% definition path="api/server-server/definitions/event-schemas/m.device_list_update" %}}
-
-## End-to-End Encryption
-
-This section complements the [End-to-End Encryption
-module](/client-server-api#end-to-end-encryption)
-of the Client-Server API. For detailed information about end-to-end
-encryption, please see that module.
-
-The APIs defined here are designed to be able to proxy much of the
-client's request through to federation, and have the response also be
-proxied through to the client.
-
-{{% http-api spec="server-server" api="user_keys" %}}
-
-{{% definition path="api/server-server/definitions/event-schemas/m.signing_key_update" %}}
-
-## Send-to-device messaging
-
-The server API for send-to-device messaging is based on the
-`m.direct_to_device` EDU. There are no PDUs or Federation Queries
-involved.
-
-Each send-to-device message should be sent to the destination server
-using the following EDU:
-
-{{% definition path="api/server-server/definitions/event-schemas/m.direct_to_device" %}}
-
-## Content Repository
-
-Attachments to events (images, files, etc) are uploaded to a homeserver
-via the Content Repository described in the [Client-Server
-API](/client-server-api). When a server wishes
-to serve content originating from a remote server, it needs to ask the
-remote server for the media.
-
-Servers should use the server described in the Matrix Content URI, which
-has the format `mxc://{ServerName}/{MediaID}`. Servers should use the
-download endpoint described in the [Client-Server
-API](/client-server-api), being sure to use
-the `allow_remote` parameter (set to `false`).
-
-## Server Access Control Lists (ACLs)
-
-Server ACLs and their purpose are described in the [Server
-ACLs](/client-server-api#server-access-control-lists-acls-for-rooms)
-section of the Client-Server API.
-
-When a remote server makes a request, it MUST be verified to be allowed
-by the server ACLs. If the server is denied access to a room, the
-receiving server MUST reply with a 403 HTTP status code and an `errcode`
-of `M_FORBIDDEN`.
-
-The following endpoint prefixes MUST be protected:
-
--   `/_matrix/federation/v1/send` (on a per-PDU basis)
--   `/_matrix/federation/v1/make_join`
--   `/_matrix/federation/v1/make_leave`
--   `/_matrix/federation/v1/send_join`
--   `/_matrix/federation/v2/send_join`
--   `/_matrix/federation/v1/send_leave`
--   `/_matrix/federation/v2/send_leave`
--   `/_matrix/federation/v1/invite`
--   `/_matrix/federation/v2/invite`
--   `/_matrix/federation/v1/make_knock`
--   `/_matrix/federation/v1/send_knock`
--   `/_matrix/federation/v1/state`
--   `/_matrix/federation/v1/state_ids`
--   `/_matrix/federation/v1/backfill`
--   `/_matrix/federation/v1/event_auth`
--   `/_matrix/federation/v1/get_missing_events`
-
-## Signing Events
-
-Signing events is complicated by the fact that servers can choose to
-redact non-essential parts of an event.
-
-### Adding hashes and signatures to outgoing events
-
-Before signing the event, the *content hash* of the event is calculated
-as described below. The hash is encoded using [Unpadded
-Base64](/appendices#unpadded-base64) and stored in the event
-object, in a `hashes` object, under a `sha256` key.
-
-The event object is then *redacted*, following the [redaction
-algorithm](/client-server-api#redactions).
-Finally it is signed as described in [Signing
-JSON](/appendices#signing-json), using the server's signing key
-(see also [Retrieving server keys](#retrieving-server-keys)).
-
-The signature is then copied back to the original event object.
-
-For an example of a signed event, see the [room version
-specification](/rooms).
-
-### Validating hashes and signatures on received events
-
-When a server receives an event over federation from another server, the
-receiving server should check the hashes and signatures on that event.
-
-First the signature is checked. The event is redacted following the
-[redaction
-algorithm](/client-server-api#redactions), and
-the resultant object is checked for a signature from the originating
-server, following the algorithm described in [Checking for a
-signature](/appendices#checking-for-a-signature). Note that this
-step should succeed whether we have been sent the full event or a
-redacted copy.
-
-The signatures expected on an event are:
-
--   The `sender`'s server, unless the invite was created as a result of
-    3rd party invite. The sender must already match the 3rd party
-    invite, and the server which actually sends the event may be a
-    different server.
--   For room versions 1 and 2, the server which created the `event_id`.
-    Other room versions do not track the `event_id` over federation and
-    therefore do not need a signature from those servers.
-
-If the signature is found to be valid, the expected content hash is
-calculated as described below. The content hash in the `hashes` property
-of the received event is base64-decoded, and the two are compared for
-equality.
-
-If the hash check fails, then it is assumed that this is because we have
-only been given a redacted version of the event. To enforce this, the
-receiving server should use the redacted copy it calculated rather than
-the full copy it received.
-
-### Calculating the reference hash for an event
-
-The *reference hash* of an event covers the essential fields of an
-event, including content hashes. It is used for event identifiers in
-some room versions. See the [room version
-specification](/rooms) for more information. It is
-calculated as follows.
-
-1.  The event is put through the redaction algorithm.
-2.  The `signatures`, `age_ts`, and `unsigned` properties are removed
-    from the event, if present.
-3.  The event is converted into [Canonical
-    JSON](/appendices#canonical-json).
-4.  A sha256 hash is calculated on the resulting JSON object.
-
-### Calculating the content hash for an event
-
-The *content hash* of an event covers the complete event including the
-*unredacted* contents. It is calculated as follows.
-
-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.
-
-### Example code
-
-```py
-def hash_and_sign_event(event_object, signing_key, signing_name):
-    # First we need to hash the event object.
-    content_hash = compute_content_hash(event_object)
-    event_object["hashes"] = {"sha256": encode_unpadded_base64(content_hash)}
-
-    # Strip all the keys that would be removed if the event was redacted.
-    # The hashes are not stripped and cover all the keys in the event.
-    # This means that we can tell if any of the non-essential keys are
-    # modified or removed.
-    stripped_object = strip_non_essential_keys(event_object)
-
-    # Sign the stripped JSON object. The signature only covers the
-    # essential keys and the hashes. This means that we can check the
-    # signature even if the event is redacted.
-    signed_object = sign_json(stripped_object, signing_key, signing_name)
-
-    # Copy the signatures from the stripped event to the original event.
-    event_object["signatures"] = signed_object["signatures"]
-
-def compute_content_hash(event_object):
-    # take a copy of the event before we remove any keys.
-    event_object = dict(event_object)
-
-    # Keys under "unsigned" can be modified by other servers.
-    # They are useful for conveying information like the age of an
-    # event that will change in transit.
-    # Since they can be modified we need to exclude them from the hash.
-    event_object.pop("unsigned", None)
-
-    # Signatures will depend on the current value of the "hashes" key.
-    # We cannot add new hashes without invalidating existing signatures.
-    event_object.pop("signatures", None)
-
-    # The "hashes" key might contain multiple algorithms if we decide to
-    # migrate away from SHA-2. We don't want to include an existing hash
-    # output in our hash so we exclude the "hashes" dict from the hash.
-    event_object.pop("hashes", None)
-
-    # Encode the JSON using a canonical encoding so that we get the same
-    # bytes on every server for the same JSON object.
-    event_json_bytes = encode_canonical_json(event_object)
-
-    return hashlib.sha256(event_json_bytes)
-```
-
-## Security considerations
-
-When a domain's ownership changes, the new controller of the domain can
-masquerade as the previous owner, receiving messages (similarly to
-email) and request past messages from other servers. In the future,
-proposals like
-[MSC1228](https://github.com/matrix-org/matrix-doc/issues/1228) will
-address this issue.
diff --git a/data-definitions/sas-emoji-v1-i18n/ar.json b/data-definitions/sas-emoji-v1-i18n/ar.json
deleted file mode 100644
index 822d6f1c..00000000
--- a/data-definitions/sas-emoji-v1-i18n/ar.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Pin": "دَبُّوس",
-    "Folder": "مُجَلَّد",
-    "Headphones": "سَمّاعَة رَأس",
-    "Anchor": "مِرسَاة",
-    "Bell": "جَرَس",
-    "Trumpet": "بُوق",
-    "Guitar": "غيتار",
-    "Ball": "كُرَة",
-    "Trophy": "كَأسُ النَّصر",
-    "Rocket": "صَارُوخ",
-    "Aeroplane": "طَائِرة",
-    "Bicycle": "دَرّاجَة",
-    "Train": "قِطَار",
-    "Flag": "عَلَم",
-    "Telephone": "تِلِفُون",
-    "Hammer": "مِطرَقَة",
-    "Key": "مِفتَاح",
-    "Lock": "قُفل",
-    "Scissors": "مِقَصّ",
-    "Paperclip": "مِشبَكُ وَرَق",
-    "Pencil": "قَلَمُ رَصاص",
-    "Book": "كِتَاب",
-    "Light Bulb": "مِصبَاح",
-    "Gift": "هَدِيَّة",
-    "Clock": "سَاعَة",
-    "Hourglass": "سَاعَةٌ رَملِيَّة",
-    "Umbrella": "مِظَلَّة",
-    "Thumbs Up": "رَفعُ إِبهَام",
-    "Santa": "سانتا",
-    "Spanner": "مِفتَاحُ رَبط",
-    "Glasses": "نَظَّارَة",
-    "Hat": "قُبَّعَة",
-    "Robot": "رُوبُوت",
-    "Smiley": "اِبتِسَامَة",
-    "Heart": "قَلب",
-    "Cake": "كَعكَة",
-    "Pizza": "بِيتزا",
-    "Corn": "ذُرَة",
-    "Strawberry": "فَراوِلَة",
-    "Apple": "تُفَّاحَة",
-    "Banana": "مَوزَة",
-    "Fire": "نار",
-    "Cloud": "سَحابَة",
-    "Moon": "قَمَر",
-    "Globe": "كُرَةٌ أرضِيَّة",
-    "Mushroom": "فُطر",
-    "Cactus": "صبار",
-    "Tree": "شَجَرَة",
-    "Flower": "زَهرَة",
-    "Butterfly": "فَرَاشَة",
-    "Octopus": "أُخطُبُوط",
-    "Fish": "سَمَكَة",
-    "Turtle": "سُلحفاة",
-    "Penguin": "بِطريق",
-    "Rooster": "دِيك",
-    "Panda": "باندَا",
-    "Rabbit": "أَرنَب",
-    "Elephant": "فِيل",
-    "Pig": "خِنزِير",
-    "Unicorn": "حِصَانٌ بِقَرن",
-    "Horse": "حِصَان",
-    "Lion": "أَسَد",
-    "Cat": "هِرَّة",
-    "Dog": "كَلب"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/base.json b/data-definitions/sas-emoji-v1-i18n/base.json
deleted file mode 100644
index 68129bd6..00000000
--- a/data-definitions/sas-emoji-v1-i18n/base.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Dog",
-    "Cat": "Cat",
-    "Lion": "Lion",
-    "Horse": "Horse",
-    "Unicorn": "Unicorn",
-    "Pig": "Pig",
-    "Elephant": "Elephant",
-    "Rabbit": "Rabbit",
-    "Panda": "Panda",
-    "Rooster": "Rooster",
-    "Penguin": "Penguin",
-    "Turtle": "Turtle",
-    "Fish": "Fish",
-    "Octopus": "Octopus",
-    "Butterfly": "Butterfly",
-    "Flower": "Flower",
-    "Tree": "Tree",
-    "Cactus": "Cactus",
-    "Mushroom": "Mushroom",
-    "Globe": "Globe",
-    "Moon": "Moon",
-    "Cloud": "Cloud",
-    "Fire": "Fire",
-    "Banana": "Banana",
-    "Apple": "Apple",
-    "Strawberry": "Strawberry",
-    "Corn": "Corn",
-    "Pizza": "Pizza",
-    "Cake": "Cake",
-    "Heart": "Heart",
-    "Smiley": "Smiley",
-    "Robot": "Robot",
-    "Hat": "Hat",
-    "Glasses": "Glasses",
-    "Spanner": "Spanner",
-    "Santa": "Santa",
-    "Thumbs Up": "Thumbs Up",
-    "Umbrella": "Umbrella",
-    "Hourglass": "Hourglass",
-    "Clock": "Clock",
-    "Gift": "Gift",
-    "Light Bulb": "Light Bulb",
-    "Book": "Book",
-    "Pencil": "Pencil",
-    "Paperclip": "Paperclip",
-    "Scissors": "Scissors",
-    "Lock": "Lock",
-    "Key": "Key",
-    "Hammer": "Hammer",
-    "Telephone": "Telephone",
-    "Flag": "Flag",
-    "Train": "Train",
-    "Bicycle": "Bicycle",
-    "Aeroplane": "Aeroplane",
-    "Rocket": "Rocket",
-    "Trophy": "Trophy",
-    "Ball": "Ball",
-    "Guitar": "Guitar",
-    "Trumpet": "Trumpet",
-    "Bell": "Bell",
-    "Anchor": "Anchor",
-    "Headphones": "Headphones",
-    "Folder": "Folder",
-    "Pin": "Pin"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/bg.json b/data-definitions/sas-emoji-v1-i18n/bg.json
deleted file mode 100644
index 6727ee6f..00000000
--- a/data-definitions/sas-emoji-v1-i18n/bg.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Pin": "Кабърче",
-    "Folder": "Папка",
-    "Headphones": "Слушалки",
-    "Anchor": "Котва",
-    "Bell": "Звънец",
-    "Trumpet": "Тромпет",
-    "Guitar": "Китара",
-    "Ball": "Топка",
-    "Trophy": "Трофей",
-    "Rocket": "Ракета",
-    "Aeroplane": "Самолет",
-    "Bicycle": "Колело",
-    "Train": "Влак",
-    "Flag": "Флаг",
-    "Telephone": "Телефон",
-    "Hammer": "Чук",
-    "Key": "Ключ",
-    "Lock": "Катинар",
-    "Scissors": "Ножици",
-    "Paperclip": "Кламер",
-    "Pencil": "Молив",
-    "Book": "Книга",
-    "Light Bulb": "Лампа",
-    "Gift": "Подарък",
-    "Clock": "Часовник",
-    "Hourglass": "Пясъчен часовник",
-    "Umbrella": "Чадър",
-    "Thumbs Up": "Палец нагоре",
-    "Santa": "Дядо Коледа",
-    "Spanner": "Гаечен ключ",
-    "Glasses": "Очила",
-    "Hat": "Шапка",
-    "Robot": "Робот",
-    "Smiley": "Усмивка",
-    "Heart": "Сърце",
-    "Cake": "Торта",
-    "Pizza": "Пица",
-    "Corn": "Царевица",
-    "Strawberry": "Ягода",
-    "Apple": "Ябълка",
-    "Banana": "Банан",
-    "Fire": "Огън",
-    "Cloud": "Облак",
-    "Moon": "Луна",
-    "Globe": "Глобус",
-    "Mushroom": "Гъба",
-    "Cactus": "Кактус",
-    "Tree": "Дърво",
-    "Flower": "Цвете",
-    "Butterfly": "Пеперуда",
-    "Octopus": "Октопод",
-    "Fish": "Риба",
-    "Turtle": "Костенурка",
-    "Penguin": "Пингвин",
-    "Rooster": "Петел",
-    "Panda": "Панда",
-    "Rabbit": "Заек",
-    "Elephant": "Слон",
-    "Pig": "Прасе",
-    "Unicorn": "Еднорог",
-    "Horse": "Кон",
-    "Lion": "Лъв",
-    "Cat": "Котка",
-    "Dog": "Куче"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/ca.json b/data-definitions/sas-emoji-v1-i18n/ca.json
deleted file mode 100644
index adca06b3..00000000
--- a/data-definitions/sas-emoji-v1-i18n/ca.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Cactus": "Cactus",
-    "Globe": "Globus terraqüi",
-    "Rooster": "Gall",
-    "Pin": "Xinxeta",
-    "Folder": "Carpeta",
-    "Headphones": "Auriculars",
-    "Anchor": "Àncora",
-    "Bell": "Campana",
-    "Trumpet": "Trompeta",
-    "Guitar": "Guitarra",
-    "Ball": "Pilota",
-    "Trophy": "Trofeu",
-    "Rocket": "Coet",
-    "Aeroplane": "Avió",
-    "Bicycle": "Bicicleta",
-    "Train": "Tren",
-    "Flag": "Bandera",
-    "Telephone": "Telèfon",
-    "Hammer": "Martell",
-    "Lock": "Cadenat",
-    "Key": "Clau",
-    "Scissors": "Tisores",
-    "Paperclip": "Clip",
-    "Pencil": "Llapis",
-    "Book": "Llibre",
-    "Light Bulb": "Bombeta",
-    "Gift": "Regal",
-    "Clock": "Rellotge",
-    "Hourglass": "Rellotge de sorra",
-    "Umbrella": "Paraigües",
-    "Thumbs Up": "Polzes amunt",
-    "Santa": "Pare Noél",
-    "Spanner": "Clau anglesa",
-    "Glasses": "Ulleres",
-    "Hat": "Barret",
-    "Robot": "Robot",
-    "Smiley": "Somrient",
-    "Heart": "Cor",
-    "Cake": "Pastís",
-    "Pizza": "Pizza",
-    "Corn": "Blat de moro",
-    "Strawberry": "Maduixa",
-    "Apple": "Poma",
-    "Banana": "Plàtan",
-    "Fire": "Foc",
-    "Cloud": "Núvol",
-    "Moon": "Lluna",
-    "Mushroom": "Bolet",
-    "Tree": "Arbre",
-    "Flower": "Flor",
-    "Butterfly": "Papallona",
-    "Octopus": "Pop",
-    "Fish": "Peix",
-    "Turtle": "Tortuga",
-    "Penguin": "Pingüí",
-    "Panda": "Panda",
-    "Rabbit": "Conill",
-    "Elephant": "Elefant",
-    "Unicorn": "Unicorn",
-    "Pig": "Porc",
-    "Horse": "Cavall",
-    "Lion": "Lleó",
-    "Cat": "Gat",
-    "Dog": "Gos"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/cs.json b/data-definitions/sas-emoji-v1-i18n/cs.json
deleted file mode 100644
index 66d3a42a..00000000
--- a/data-definitions/sas-emoji-v1-i18n/cs.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Pin": "Špendlík",
-    "Folder": "Složka",
-    "Headphones": "Sluchátka",
-    "Anchor": "Kotva",
-    "Bell": "Zvonek",
-    "Trumpet": "Trumpeta",
-    "Guitar": "Kytara",
-    "Ball": "Míč",
-    "Trophy": "Pohár",
-    "Rocket": "Raketa",
-    "Aeroplane": "Letadlo",
-    "Bicycle": "Kolo",
-    "Train": "Vlak",
-    "Flag": "Vlajka",
-    "Telephone": "Telefon",
-    "Hammer": "Kladivo",
-    "Key": "Klíč",
-    "Lock": "Zámek",
-    "Scissors": "Nůžky",
-    "Paperclip": "Sponka",
-    "Pencil": "Tužka",
-    "Book": "Kniha",
-    "Light Bulb": "Žárovka",
-    "Gift": "Dárek",
-    "Santa": "Mikuláš",
-    "Clock": "Hodiny",
-    "Hourglass": "Přesýpací hodiny",
-    "Umbrella": "Deštník",
-    "Thumbs Up": "Palec nahoru",
-    "Spanner": "Klíč",
-    "Glasses": "Brýle",
-    "Hat": "Klobouk",
-    "Robot": "Robot",
-    "Smiley": "Smajlík",
-    "Heart": "Srdce",
-    "Cake": "Dort",
-    "Pizza": "Pizza",
-    "Corn": "Kukuřice",
-    "Strawberry": "Jahoda",
-    "Apple": "Jablko",
-    "Banana": "Banán",
-    "Fire": "Oheň",
-    "Cloud": "Mrak",
-    "Moon": "Měsíc",
-    "Globe": "Zeměkoule",
-    "Mushroom": "Houba",
-    "Cactus": "Kaktus",
-    "Tree": "Strom",
-    "Flower": "Květina",
-    "Butterfly": "Motýl",
-    "Octopus": "Chobotnice",
-    "Fish": "Ryba",
-    "Turtle": "Želva",
-    "Penguin": "Tučňák",
-    "Rooster": "Kohout",
-    "Panda": "Panda",
-    "Rabbit": "Králík",
-    "Elephant": "Slon",
-    "Pig": "Prase",
-    "Unicorn": "Jednorožec",
-    "Horse": "Kůň",
-    "Lion": "Lev",
-    "Cat": "Kočka",
-    "Dog": "Pes"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/de.json b/data-definitions/sas-emoji-v1-i18n/de.json
deleted file mode 100644
index 83719cf3..00000000
--- a/data-definitions/sas-emoji-v1-i18n/de.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Hund",
-    "Cat": "Katze",
-    "Lion": "Löwe",
-    "Horse": "Pferd",
-    "Unicorn": "Einhorn",
-    "Pig": "Schwein",
-    "Elephant": "Elefant",
-    "Rabbit": "Hase",
-    "Panda": "Panda",
-    "Rooster": "Hahn",
-    "Penguin": "Pinguin",
-    "Turtle": "Schildkröte",
-    "Fish": "Fisch",
-    "Octopus": "Oktopus",
-    "Butterfly": "Schmetterling",
-    "Flower": "Blume",
-    "Tree": "Baum",
-    "Cactus": "Kaktus",
-    "Mushroom": "Pilz",
-    "Globe": "Globus",
-    "Moon": "Mond",
-    "Cloud": "Wolke",
-    "Fire": "Feuer",
-    "Banana": "Banane",
-    "Apple": "Apfel",
-    "Strawberry": "Erdbeere",
-    "Corn": "Mais",
-    "Pizza": "Pizza",
-    "Cake": "Kuchen",
-    "Heart": "Herz",
-    "Smiley": "Lächeln",
-    "Robot": "Roboter",
-    "Hat": "Hut",
-    "Glasses": "Brille",
-    "Spanner": "Schraubenschlüssel",
-    "Santa": "Weihnachtsmann",
-    "Thumbs Up": "Daumen Hoch",
-    "Umbrella": "Regenschirm",
-    "Hourglass": "Sanduhr",
-    "Clock": "Uhr",
-    "Gift": "Geschenk",
-    "Light Bulb": "Glühbirne",
-    "Book": "Buch",
-    "Pencil": "Bleistift",
-    "Paperclip": "Büroklammer",
-    "Scissors": "Schere",
-    "Lock": "Schloss",
-    "Key": "Schlüssel",
-    "Hammer": "Hammer",
-    "Telephone": "Telefon",
-    "Flag": "Flagge",
-    "Train": "Zug",
-    "Bicycle": "Fahrrad",
-    "Aeroplane": "Flugzeug",
-    "Rocket": "Rakete",
-    "Trophy": "Pokal",
-    "Ball": "Ball",
-    "Guitar": "Gitarre",
-    "Trumpet": "Trompete",
-    "Bell": "Glocke",
-    "Anchor": "Anker",
-    "Headphones": "Kopfhörer",
-    "Folder": "Ordner",
-    "Pin": "Stecknadel"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/eo.json b/data-definitions/sas-emoji-v1-i18n/eo.json
deleted file mode 100644
index 1fafa276..00000000
--- a/data-definitions/sas-emoji-v1-i18n/eo.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Hundo",
-    "Cat": "Kato",
-    "Lion": "Leono",
-    "Horse": "Ĉevalo",
-    "Unicorn": "Unukorno",
-    "Pig": "Porko",
-    "Elephant": "Elefanto",
-    "Rabbit": "Kuniklo",
-    "Panda": "Pando",
-    "Rooster": "Virkoko",
-    "Penguin": "Pingveno",
-    "Turtle": "Testudo",
-    "Fish": "Fiŝo",
-    "Octopus": "Polpo",
-    "Butterfly": "Papilio",
-    "Flower": "Floro",
-    "Tree": "Arbo",
-    "Cactus": "Kakto",
-    "Mushroom": "Fungo",
-    "Globe": "Globo",
-    "Moon": "Luno",
-    "Cloud": "Nubo",
-    "Fire": "Fajro",
-    "Banana": "Banano",
-    "Apple": "Pomo",
-    "Strawberry": "Frago",
-    "Corn": "Maizo",
-    "Pizza": "Pico",
-    "Cake": "Torto",
-    "Heart": "Koro",
-    "Smiley": "Rideto",
-    "Robot": "Roboto",
-    "Hat": "Ĉapelo",
-    "Glasses": "Okulvitroj",
-    "Spanner": "Ŝraŭbŝlosilo",
-    "Santa": "Kristnaska viro",
-    "Thumbs Up": "Dikfingro supren",
-    "Umbrella": "Ombrelo",
-    "Hourglass": "Sablohorloĝo",
-    "Clock": "Horloĝo",
-    "Gift": "Donaco",
-    "Light Bulb": "Lampo",
-    "Book": "Libro",
-    "Pencil": "Krajono",
-    "Paperclip": "Paperkuntenilo",
-    "Scissors": "Tondilo",
-    "Lock": "Seruro",
-    "Key": "Ŝlosilo",
-    "Hammer": "Martelo",
-    "Telephone": "Telefono",
-    "Flag": "Flago",
-    "Train": "Vagonaro",
-    "Bicycle": "Biciklo",
-    "Aeroplane": "Aviadilo",
-    "Rocket": "Raketo",
-    "Trophy": "Trofeo",
-    "Ball": "Pilko",
-    "Guitar": "Gitaro",
-    "Trumpet": "Trumpeto",
-    "Bell": "Sonorilo",
-    "Anchor": "Ankro",
-    "Headphones": "Kapaŭdilo",
-    "Folder": "Dosierujo",
-    "Pin": "Pinglo"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/es.json b/data-definitions/sas-emoji-v1-i18n/es.json
deleted file mode 100644
index 83d75f57..00000000
--- a/data-definitions/sas-emoji-v1-i18n/es.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Perro",
-    "Cat": "Gato",
-    "Lion": "León",
-    "Pig": "Cerdo",
-    "Fire": "Fuego",
-    "Apple": "Manzana",
-    "Clock": "Reloj",
-    "Gift": "Regalo",
-    "Book": "Libro",
-    "Pencil": "Lápiz",
-    "Key": "Llave",
-    "Hammer": "Martillo",
-    "Telephone": "Telefono",
-    "Train": "Tren",
-    "Bicycle": "Bicicleta",
-    "Ball": "Bola",
-    "Guitar": "Guitarra",
-    "Trumpet": "Trompeta",
-    "Bell": "Campana",
-    "Pin": "Alfiler",
-    "Horse": "Caballo",
-    "Unicorn": "Unicornio",
-    "Elephant": "Elefante",
-    "Rabbit": "Conejo",
-    "Panda": "Panda",
-    "Rooster": "Gallo",
-    "Penguin": "Pingüino",
-    "Turtle": "Tortuga",
-    "Fish": "Pez",
-    "Octopus": "Pulpo",
-    "Butterfly": "Mariposa",
-    "Flower": "Flor",
-    "Tree": "Árbol",
-    "Cactus": "Cactus",
-    "Mushroom": "Seta",
-    "Globe": "Globo",
-    "Moon": "Luna",
-    "Cloud": "Nube",
-    "Banana": "Plátano",
-    "Strawberry": "Fresa",
-    "Corn": "Maíz",
-    "Pizza": "Pizza",
-    "Cake": "Tarta",
-    "Heart": "Corazón",
-    "Smiley": "Emoticono",
-    "Robot": "Robot",
-    "Hat": "Sombrero",
-    "Glasses": "Gafas",
-    "Spanner": "Llave inglesa",
-    "Folder": "Carpeta",
-    "Headphones": "Cascos",
-    "Anchor": "Ancla",
-    "Trophy": "Trofeo",
-    "Rocket": "Cohete",
-    "Aeroplane": "Avión",
-    "Flag": "Bandera",
-    "Lock": "Candado",
-    "Scissors": "Tijeras",
-    "Paperclip": "Clip",
-    "Light Bulb": "Bombilla",
-    "Hourglass": "Reloj de arena",
-    "Umbrella": "Paraguas",
-    "Thumbs Up": "Pulgar arriba",
-    "Santa": "Papá Noel"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/et.json b/data-definitions/sas-emoji-v1-i18n/et.json
deleted file mode 100644
index 6cf53de3..00000000
--- a/data-definitions/sas-emoji-v1-i18n/et.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Koer",
-    "Cat": "Kass",
-    "Lion": "Lõvi",
-    "Horse": "Hobune",
-    "Unicorn": "Ükssarvik",
-    "Pig": "Siga",
-    "Elephant": "Elevant",
-    "Rabbit": "Jänes",
-    "Panda": "Panda",
-    "Rooster": "Kukk",
-    "Penguin": "Pingviin",
-    "Turtle": "Kilpkonn",
-    "Fish": "Kala",
-    "Octopus": "Kaheksajalg",
-    "Butterfly": "Liblikas",
-    "Flower": "Lill",
-    "Tree": "Puu",
-    "Cactus": "Kaktus",
-    "Mushroom": "Seen",
-    "Globe": "Maakera",
-    "Moon": "Kuu",
-    "Cloud": "Pilv",
-    "Fire": "Tuli",
-    "Banana": "Banaan",
-    "Apple": "Õun",
-    "Strawberry": "Maasikas",
-    "Corn": "Mais",
-    "Pizza": "Pitsa",
-    "Cake": "Kook",
-    "Heart": "Süda",
-    "Smiley": "Smaili",
-    "Robot": "Robot",
-    "Hat": "Kübar",
-    "Glasses": "Prillid",
-    "Spanner": "Mutrivõti",
-    "Santa": "Jõuluvana",
-    "Thumbs Up": "Pöidlad püsti",
-    "Umbrella": "Vihmavari",
-    "Hourglass": "Liivakell",
-    "Clock": "Kell",
-    "Gift": "Kingitus",
-    "Light Bulb": "Lambipirn",
-    "Book": "Raamat",
-    "Pencil": "Pliiats",
-    "Paperclip": "Kirjaklamber",
-    "Scissors": "Käärid",
-    "Lock": "Lukk",
-    "Key": "Võti",
-    "Hammer": "Haamer",
-    "Telephone": "Telefon",
-    "Flag": "Lipp",
-    "Train": "Rong",
-    "Bicycle": "Jalgratas",
-    "Aeroplane": "Lennuk",
-    "Rocket": "Rakett",
-    "Trophy": "Auhind",
-    "Ball": "Pall",
-    "Guitar": "Kitarr",
-    "Trumpet": "Trompet",
-    "Bell": "Kelluke",
-    "Anchor": "Ankur",
-    "Headphones": "Kõrvaklapid",
-    "Folder": "Kaust",
-    "Pin": "Nööpnõel"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/fi.json b/data-definitions/sas-emoji-v1-i18n/fi.json
deleted file mode 100644
index 58817bb0..00000000
--- a/data-definitions/sas-emoji-v1-i18n/fi.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Koira",
-    "Cat": "Kissa",
-    "Lion": "Leijona",
-    "Horse": "Hevonen",
-    "Unicorn": "Yksisarvinen",
-    "Pig": "Sika",
-    "Elephant": "Norsu",
-    "Rabbit": "Kani",
-    "Panda": "Panda",
-    "Rooster": "Kukko",
-    "Penguin": "Pingviini",
-    "Turtle": "Kilpikonna",
-    "Fish": "Kala",
-    "Octopus": "Tursas",
-    "Butterfly": "Perhonen",
-    "Flower": "Kukka",
-    "Tree": "Puu",
-    "Cactus": "Kaktus",
-    "Mushroom": "Sieni",
-    "Globe": "Maapallo",
-    "Moon": "Kuu",
-    "Cloud": "Pilvi",
-    "Fire": "Tuli",
-    "Banana": "Banaani",
-    "Apple": "Omena",
-    "Strawberry": "Mansikka",
-    "Corn": "Maissi",
-    "Pizza": "Pizza",
-    "Cake": "Kakku",
-    "Heart": "Sydän",
-    "Smiley": "Hymynaama",
-    "Robot": "Robotti",
-    "Hat": "Hattu",
-    "Glasses": "Silmälasit",
-    "Spanner": "Kiintoavain",
-    "Santa": "Joulupukki",
-    "Thumbs Up": "Peukalo ylös",
-    "Umbrella": "Sateenvarjo",
-    "Hourglass": "Tiimalasi",
-    "Clock": "Pöytäkello",
-    "Gift": "Lahja",
-    "Light Bulb": "Hehkulamppu",
-    "Book": "Kirja",
-    "Pencil": "Lyijykynä",
-    "Paperclip": "Paperiliitin",
-    "Scissors": "Sakset",
-    "Lock": "Lukko",
-    "Key": "Avain",
-    "Hammer": "Vasara",
-    "Telephone": "Puhelin",
-    "Flag": "Lippu",
-    "Train": "Juna",
-    "Bicycle": "Polkupyörä",
-    "Aeroplane": "Lentokone",
-    "Rocket": "Raketti",
-    "Trophy": "Palkinto",
-    "Ball": "Pallo",
-    "Guitar": "Kitara",
-    "Trumpet": "Trumpetti",
-    "Bell": "Soittokello",
-    "Anchor": "Ankkuri",
-    "Headphones": "Kuulokkeet",
-    "Folder": "Kansio",
-    "Pin": "Nuppineula"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/fr.json b/data-definitions/sas-emoji-v1-i18n/fr.json
deleted file mode 100644
index 6d754091..00000000
--- a/data-definitions/sas-emoji-v1-i18n/fr.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Chien",
-    "Cat": "Chat",
-    "Horse": "Cheval",
-    "Elephant": "Éléphant",
-    "Rabbit": "Lapin",
-    "Penguin": "Manchot",
-    "Fish": "Poisson",
-    "Butterfly": "Papillon",
-    "Flower": "Fleur",
-    "Tree": "Arbre",
-    "Mushroom": "Champignon",
-    "Moon": "Lune",
-    "Cloud": "Nuage",
-    "Fire": "Feu",
-    "Banana": "Banane",
-    "Apple": "Pomme",
-    "Pizza": "Pizza",
-    "Cake": "Gâteau",
-    "Heart": "Cœur",
-    "Hat": "Chapeau",
-    "Glasses": "Lunettes",
-    "Hourglass": "Sablier",
-    "Book": "Livre",
-    "Key": "Clé",
-    "Telephone": "Téléphone",
-    "Bicycle": "Vélo",
-    "Aeroplane": "Avion",
-    "Pig": "Cochon",
-    "Lion": "Lion",
-    "Unicorn": "Licorne",
-    "Panda": "Panda",
-    "Rooster": "Coq",
-    "Turtle": "Tortue",
-    "Octopus": "Poulpe",
-    "Cactus": "Cactus",
-    "Globe": "Globe",
-    "Strawberry": "Fraise",
-    "Corn": "Maïs",
-    "Smiley": "Sourire",
-    "Robot": "Robot",
-    "Spanner": "Clé à molette",
-    "Santa": "Père Noël",
-    "Thumbs Up": "Pouce en l’air",
-    "Umbrella": "Parapluie",
-    "Clock": "Réveil",
-    "Gift": "Cadeau",
-    "Light Bulb": "Ampoule",
-    "Pencil": "Crayon",
-    "Paperclip": "Trombone",
-    "Scissors": "Ciseaux",
-    "Lock": "Cadenas",
-    "Hammer": "Marteau",
-    "Flag": "Drapeau",
-    "Train": "Train",
-    "Rocket": "Fusée",
-    "Trophy": "Trophée",
-    "Ball": "Ballon",
-    "Guitar": "Guitare",
-    "Trumpet": "Trompette",
-    "Bell": "Cloche",
-    "Anchor": "Ancre",
-    "Headphones": "Casque audio",
-    "Folder": "Dossier",
-    "Pin": "Punaise"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/hr.json b/data-definitions/sas-emoji-v1-i18n/hr.json
deleted file mode 100644
index 2a4d1f12..00000000
--- a/data-definitions/sas-emoji-v1-i18n/hr.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Pin": "pribadača",
-    "Folder": "mapu",
-    "Headphones": "slušalice",
-    "Anchor": "sidro",
-    "Bell": "zvono",
-    "Trumpet": "truba",
-    "Guitar": "gitara",
-    "Ball": "lopta",
-    "Trophy": "trofej",
-    "Rocket": "raketa",
-    "Aeroplane": "avion",
-    "Bicycle": "bicikl",
-    "Train": "vlak",
-    "Flag": "zastava",
-    "Telephone": "telefon",
-    "Hammer": "čekić",
-    "Key": "ključ",
-    "Lock": "zaključati",
-    "Scissors": "škare",
-    "Paperclip": "spajalica",
-    "Pencil": "olovka",
-    "Book": "knjiga",
-    "Light Bulb": "žarulja",
-    "Gift": "poklon",
-    "Clock": "sat",
-    "Hourglass": "pješčani sat",
-    "Umbrella": "kišobran",
-    "Thumbs Up": "palac gore",
-    "Santa": "deda Mraz",
-    "Spanner": "ključ",
-    "Glasses": "naočale",
-    "Hat": "kapa",
-    "Robot": "robot",
-    "Smiley": "smajlića",
-    "Heart": "srca",
-    "Cake": "torta",
-    "Pizza": "pizza",
-    "Corn": "kukuruza",
-    "Strawberry": "jagoda",
-    "Apple": "jabuka",
-    "Banana": "banana",
-    "Fire": "vatra",
-    "Cloud": "oblak",
-    "Moon": "mjesec",
-    "Globe": "Globus",
-    "Mushroom": "gljiva",
-    "Cactus": "kaktus",
-    "Tree": "drvo",
-    "Flower": "svijet",
-    "Butterfly": "leptir",
-    "Octopus": "hobotnica",
-    "Fish": "riba",
-    "Turtle": "kornjača",
-    "Penguin": "pingvin",
-    "Rooster": "kokot",
-    "Panda": "panda",
-    "Rabbit": "zec",
-    "Elephant": "slon",
-    "Pig": "svinja",
-    "Unicorn": "jednorog",
-    "Horse": "konj",
-    "Lion": "lav",
-    "Cat": "mačka",
-    "Dog": "pas"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/hu.json b/data-definitions/sas-emoji-v1-i18n/hu.json
deleted file mode 100644
index 01d56730..00000000
--- a/data-definitions/sas-emoji-v1-i18n/hu.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Pin": "Rajszeg",
-    "Folder": "Mappa",
-    "Headphones": "Fejhallgató",
-    "Anchor": "Horgony",
-    "Bell": "Harang",
-    "Trumpet": "Trombita",
-    "Guitar": "Gitár",
-    "Ball": "Labda",
-    "Trophy": "Trófea",
-    "Rocket": "Rakáta",
-    "Aeroplane": "Repülő",
-    "Bicycle": "Kerékpár",
-    "Train": "Vonat",
-    "Flag": "Zászló",
-    "Telephone": "Telefon",
-    "Hammer": "Kalapács",
-    "Key": "Kulcs",
-    "Lock": "Lakat",
-    "Scissors": "Olló",
-    "Paperclip": "Gémkapocs",
-    "Pencil": "Ceruza",
-    "Book": "Könyv",
-    "Light Bulb": "Égő",
-    "Gift": "Ajándék",
-    "Clock": "Óra",
-    "Hourglass": "Homokóra",
-    "Umbrella": "Esernyő",
-    "Thumbs Up": "Hüvelykujj fel",
-    "Santa": "Télapó",
-    "Spanner": "Csavarkulcs",
-    "Glasses": "Szemüveg",
-    "Hat": "Kalap",
-    "Robot": "Robot",
-    "Smiley": "Mosoly",
-    "Heart": "Szív",
-    "Cake": "Süti",
-    "Pizza": "Pizza",
-    "Corn": "Kukorica",
-    "Strawberry": "Eper",
-    "Apple": "Alma",
-    "Banana": "Banán",
-    "Fire": "Tűz",
-    "Cloud": "Felhő",
-    "Moon": "Hold",
-    "Globe": "Földgömb",
-    "Mushroom": "Gomba",
-    "Cactus": "Kaktusz",
-    "Tree": "Fa",
-    "Flower": "Virág",
-    "Butterfly": "Pillangó",
-    "Octopus": "Polip",
-    "Fish": "Hal",
-    "Turtle": "Teknős",
-    "Penguin": "Pingvin",
-    "Rooster": "Kakas",
-    "Panda": "Panda",
-    "Rabbit": "Nyúl",
-    "Elephant": "Elefánt",
-    "Pig": "Malac",
-    "Unicorn": "Egyszarvú",
-    "Horse": "Ló",
-    "Lion": "Oroszlán",
-    "Cat": "Macska",
-    "Dog": "Kutya"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/id.json b/data-definitions/sas-emoji-v1-i18n/id.json
deleted file mode 100644
index 834d6406..00000000
--- a/data-definitions/sas-emoji-v1-i18n/id.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Pin": "Pin",
-    "Folder": "Map",
-    "Headphones": "Headphone",
-    "Anchor": "Jangkar",
-    "Bell": "Lonceng",
-    "Trumpet": "Terompet",
-    "Guitar": "Gitar",
-    "Ball": "Bola",
-    "Trophy": "Piala",
-    "Rocket": "Roket",
-    "Aeroplane": "Pesawat",
-    "Bicycle": "Sepeda",
-    "Train": "Kereta Api",
-    "Flag": "Bendera",
-    "Telephone": "Telepon",
-    "Hammer": "Palu",
-    "Spanner": "Kunci Bengkel",
-    "Key": "Kunci",
-    "Lock": "Gembok",
-    "Scissors": "Gunting",
-    "Paperclip": "Klip Kertas",
-    "Pencil": "Pensil",
-    "Book": "Buku",
-    "Light Bulb": "Bohlam Lampu",
-    "Gift": "Kado",
-    "Clock": "Jam",
-    "Hourglass": "Jam Pasir",
-    "Umbrella": "Payung",
-    "Thumbs Up": "Jempol",
-    "Santa": "Santa",
-    "Glasses": "Kacamata",
-    "Hat": "Topi",
-    "Robot": "Robot",
-    "Smiley": "Senyuman",
-    "Heart": "Hati",
-    "Cake": "Kue",
-    "Pizza": "Pizza",
-    "Corn": "Jagung",
-    "Strawberry": "Stroberi",
-    "Apple": "Apel",
-    "Banana": "Pisang",
-    "Fire": "Api",
-    "Cloud": "Awan",
-    "Moon": "Bulan",
-    "Globe": "Bola Dunia",
-    "Mushroom": "Jamur",
-    "Cactus": "Kaktus",
-    "Tree": "Pohon",
-    "Flower": "Bunga",
-    "Butterfly": "Kupu-Kupu",
-    "Octopus": "Gurita",
-    "Fish": "Ikan",
-    "Turtle": "Kura-Kura",
-    "Penguin": "Penguin",
-    "Rooster": "Ayam",
-    "Panda": "Panda",
-    "Rabbit": "Kelinci",
-    "Elephant": "Gajah",
-    "Pig": "Babi",
-    "Unicorn": "Unicorn",
-    "Horse": "Kuda",
-    "Lion": "Singa",
-    "Cat": "Kucing",
-    "Dog": "Anjing"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/it.json b/data-definitions/sas-emoji-v1-i18n/it.json
deleted file mode 100644
index 062f7f59..00000000
--- a/data-definitions/sas-emoji-v1-i18n/it.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Pin": "Puntina",
-    "Folder": "Cartella",
-    "Headphones": "Cuffie",
-    "Anchor": "Ancora",
-    "Bell": "Campana",
-    "Trumpet": "Trombetta",
-    "Guitar": "Chitarra",
-    "Ball": "Palla",
-    "Trophy": "Trofeo",
-    "Rocket": "Razzo",
-    "Aeroplane": "Aeroplano",
-    "Bicycle": "Bicicletta",
-    "Train": "Treno",
-    "Flag": "Bandiera",
-    "Telephone": "Telefono",
-    "Hammer": "Martello",
-    "Key": "Chiave",
-    "Lock": "Lucchetto",
-    "Scissors": "Forbici",
-    "Paperclip": "Graffetta",
-    "Pencil": "Matita",
-    "Book": "Libro",
-    "Light Bulb": "Lampadina",
-    "Gift": "Regalo",
-    "Clock": "Orologio",
-    "Hourglass": "Clessidra",
-    "Umbrella": "Ombrello",
-    "Thumbs Up": "Pollice alzato",
-    "Santa": "Babbo Natale",
-    "Spanner": "Chiave inglese",
-    "Glasses": "Occhiali",
-    "Hat": "Cappello",
-    "Robot": "Robot",
-    "Smiley": "Faccina sorridente",
-    "Heart": "Cuore",
-    "Cake": "Torta",
-    "Pizza": "Pizza",
-    "Corn": "Mais",
-    "Strawberry": "Fragola",
-    "Apple": "Mela",
-    "Banana": "Banana",
-    "Fire": "Fuoco",
-    "Cloud": "Nuvola",
-    "Moon": "Luna",
-    "Globe": "Globo",
-    "Mushroom": "Fungo",
-    "Cactus": "Cactus",
-    "Tree": "Albero",
-    "Flower": "Fiore",
-    "Butterfly": "Farfalla",
-    "Octopus": "Polpo",
-    "Fish": "Pesce",
-    "Turtle": "Tartaruga",
-    "Penguin": "Pinguino",
-    "Rooster": "Gallo",
-    "Panda": "Panda",
-    "Rabbit": "Coniglio",
-    "Elephant": "Elefante",
-    "Pig": "Maiale",
-    "Unicorn": "Unicorno",
-    "Horse": "Cavallo",
-    "Lion": "Leone",
-    "Cat": "Gatto",
-    "Dog": "Cane"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/ja.json b/data-definitions/sas-emoji-v1-i18n/ja.json
deleted file mode 100644
index 1ad4cf14..00000000
--- a/data-definitions/sas-emoji-v1-i18n/ja.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "犬",
-    "Cat": "猫",
-    "Horse": "馬",
-    "Octopus": "たこ",
-    "Flower": "花",
-    "Tree": "木",
-    "Mushroom": "きのこ",
-    "Moon": "月",
-    "Apple": "リンゴ",
-    "Cake": "ケーキ",
-    "Robot": "ロボと",
-    "Glasses": "めがね",
-    "Book": "本",
-    "Telephone": "電話機",
-    "Train": "電車",
-    "Bicycle": "自転車",
-    "Pin": "ピン",
-    "Folder": "フォルダ",
-    "Headphones": "ヘッドホン",
-    "Anchor": "いかり",
-    "Bell": "ベル",
-    "Trumpet": "トランペット",
-    "Guitar": "ギター",
-    "Ball": "ボール",
-    "Trophy": "トロフィー",
-    "Rocket": "ロケット",
-    "Aeroplane": "飛行機",
-    "Flag": "旗",
-    "Hammer": "金槌",
-    "Key": "鍵",
-    "Lock": "錠前",
-    "Scissors": "はさみ",
-    "Paperclip": "クリップ",
-    "Pencil": "鉛筆",
-    "Light Bulb": "電球",
-    "Gift": "ギフト",
-    "Clock": "時計",
-    "Hourglass": "砂時計",
-    "Umbrella": "傘",
-    "Thumbs Up": "いいね",
-    "Santa": "サンタ",
-    "Spanner": "スパナ",
-    "Hat": "帽子",
-    "Smiley": "スマイル",
-    "Heart": "ハート",
-    "Pizza": "ピザ",
-    "Corn": "とうもろこし",
-    "Strawberry": "いちご",
-    "Banana": "バナナ",
-    "Fire": "炎",
-    "Cloud": "雲",
-    "Globe": "地球",
-    "Cactus": "サボテン",
-    "Butterfly": "ちょうちょ",
-    "Fish": "魚",
-    "Turtle": "亀",
-    "Penguin": "ペンギン",
-    "Rooster": "ニワトリ",
-    "Panda": "パンダ",
-    "Rabbit": "うさぎ",
-    "Elephant": "ゾウ",
-    "Pig": "ブタ",
-    "Unicorn": "ユニコーン",
-    "Lion": "ライオン"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/nb_NO.json b/data-definitions/sas-emoji-v1-i18n/nb_NO.json
deleted file mode 100644
index b8bf02d3..00000000
--- a/data-definitions/sas-emoji-v1-i18n/nb_NO.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Hund",
-    "Cat": "Katt",
-    "Lion": "Løve",
-    "Horse": "Hest",
-    "Unicorn": "Enhjørning",
-    "Pig": "Gris",
-    "Elephant": "Elefant",
-    "Rabbit": "Kanin",
-    "Panda": "Panda",
-    "Rooster": "Hane",
-    "Penguin": "Pingvin",
-    "Turtle": "Skilpadde",
-    "Fish": "Fisk",
-    "Octopus": "Blekksprut",
-    "Butterfly": "Sommerfugl",
-    "Flower": "Blomst",
-    "Tree": "Tre",
-    "Cactus": "Kaktus",
-    "Mushroom": "Sopp",
-    "Globe": "Globus",
-    "Moon": "Måne",
-    "Cloud": "Sky",
-    "Fire": "Flamme",
-    "Banana": "Banan",
-    "Apple": "Eple",
-    "Strawberry": "Jordbær",
-    "Corn": "Mais",
-    "Pizza": "Pizza",
-    "Cake": "Kake",
-    "Heart": "Hjerte",
-    "Smiley": "Smilefjes",
-    "Robot": "Robot",
-    "Hat": "Hatt",
-    "Glasses": "Briller",
-    "Spanner": "Fastnøkkel",
-    "Santa": "Julenisse",
-    "Thumbs Up": "Tommel Opp",
-    "Umbrella": "Paraply",
-    "Hourglass": "Timeglass",
-    "Clock": "Klokke",
-    "Gift": "Gave",
-    "Light Bulb": "Lyspære",
-    "Book": "Bok",
-    "Pencil": "Blyant",
-    "Paperclip": "BInders",
-    "Scissors": "Saks",
-    "Lock": "Lås",
-    "Key": "Nøkkel",
-    "Hammer": "Hammer",
-    "Telephone": "Telefon",
-    "Flag": "Flagg",
-    "Train": "Tog",
-    "Bicycle": "Sykkel",
-    "Aeroplane": "Fly",
-    "Rocket": "Rakett",
-    "Trophy": "Pokal",
-    "Ball": "Ball",
-    "Guitar": "Gitar",
-    "Trumpet": "Trompet",
-    "Bell": "Bjelle",
-    "Anchor": "Anker",
-    "Headphones": "Hodetelefoner",
-    "Folder": "Mappe",
-    "Pin": "Tegnestift"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/nl.json b/data-definitions/sas-emoji-v1-i18n/nl.json
deleted file mode 100644
index ffaaba1f..00000000
--- a/data-definitions/sas-emoji-v1-i18n/nl.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Hond",
-    "Cat": "Kat",
-    "Lion": "Leeuw",
-    "Horse": "Paard",
-    "Unicorn": "Eenhoorn",
-    "Pig": "Varken",
-    "Elephant": "Olifant",
-    "Rabbit": "Konijn",
-    "Panda": "Panda",
-    "Rooster": "Haan",
-    "Penguin": "Pinguïn",
-    "Turtle": "Schildpad",
-    "Fish": "Vis",
-    "Octopus": "Octopus",
-    "Butterfly": "Vlinder",
-    "Flower": "Bloem",
-    "Tree": "Boom",
-    "Cactus": "Cactus",
-    "Mushroom": "Paddenstoel",
-    "Globe": "Wereldbol",
-    "Moon": "Maan",
-    "Cloud": "Wolk",
-    "Fire": "Vuur",
-    "Banana": "Banaan",
-    "Apple": "Appel",
-    "Strawberry": "Aardbei",
-    "Corn": "Maïs",
-    "Pizza": "Pizza",
-    "Cake": "Taart",
-    "Heart": "Hart",
-    "Smiley": "Smiley",
-    "Robot": "Robot",
-    "Hat": "Hoed",
-    "Glasses": "Bril",
-    "Spanner": "Moersleutel",
-    "Santa": "Kerstman",
-    "Thumbs Up": "Duim omhoog",
-    "Umbrella": "Paraplu",
-    "Hourglass": "Zandloper",
-    "Clock": "Wekker",
-    "Gift": "Geschenk",
-    "Light Bulb": "Gloeilamp",
-    "Book": "Boek",
-    "Pencil": "Potlood",
-    "Paperclip": "Papierklemmetje",
-    "Scissors": "Schaar",
-    "Lock": "Slot",
-    "Key": "Sleutel",
-    "Hammer": "Hamer",
-    "Telephone": "Telefoon",
-    "Flag": "Vlag",
-    "Train": "Trein",
-    "Bicycle": "Fiets",
-    "Aeroplane": "Vliegtuig",
-    "Rocket": "Raket",
-    "Trophy": "Trofee",
-    "Ball": "Bal",
-    "Guitar": "Gitaar",
-    "Trumpet": "Trompet",
-    "Bell": "Bel",
-    "Anchor": "Anker",
-    "Headphones": "Koptelefoon",
-    "Folder": "Map",
-    "Pin": "Duimspijker"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/pt_BR.json b/data-definitions/sas-emoji-v1-i18n/pt_BR.json
deleted file mode 100644
index e14901fb..00000000
--- a/data-definitions/sas-emoji-v1-i18n/pt_BR.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Cachorro",
-    "Cat": "Gato",
-    "Lion": "Leão",
-    "Horse": "Cavalo",
-    "Unicorn": "Unicórnio",
-    "Pig": "Porco",
-    "Elephant": "Elefante",
-    "Rabbit": "Coelho",
-    "Panda": "Panda",
-    "Rooster": "Galo",
-    "Penguin": "Pinguim",
-    "Turtle": "Tartaruga",
-    "Fish": "Peixe",
-    "Octopus": "Polvo",
-    "Butterfly": "Borboleta",
-    "Flower": "Flor",
-    "Tree": "Árvore",
-    "Cactus": "Cacto",
-    "Mushroom": "Cogumelo",
-    "Globe": "Globo",
-    "Moon": "Lua",
-    "Cloud": "Nuvem",
-    "Fire": "Fogo",
-    "Banana": "Banana",
-    "Apple": "Maçã",
-    "Strawberry": "Morango",
-    "Corn": "Milho",
-    "Pizza": "Pizza",
-    "Cake": "Bolo",
-    "Heart": "Coração",
-    "Smiley": "Sorriso",
-    "Robot": "Robô",
-    "Hat": "Chapéu",
-    "Glasses": "Óculos",
-    "Spanner": "Chave inglesa",
-    "Santa": "Papai-noel",
-    "Thumbs Up": "Joinha",
-    "Umbrella": "Guarda-chuva",
-    "Hourglass": "Ampulheta",
-    "Clock": "Relógio",
-    "Gift": "Presente",
-    "Light Bulb": "Lâmpada",
-    "Book": "Livro",
-    "Pencil": "Lápis",
-    "Paperclip": "Clipe de papel",
-    "Scissors": "Tesoura",
-    "Lock": "Cadeado",
-    "Key": "Chave",
-    "Hammer": "Martelo",
-    "Telephone": "Telefone",
-    "Flag": "Bandeira",
-    "Train": "Trem",
-    "Bicycle": "Bicicleta",
-    "Aeroplane": "Avião",
-    "Rocket": "Foguete",
-    "Trophy": "Troféu",
-    "Ball": "Bola",
-    "Guitar": "Guitarra",
-    "Trumpet": "Trombeta",
-    "Bell": "Sino",
-    "Anchor": "Âncora",
-    "Headphones": "Fones de ouvido",
-    "Folder": "Pasta",
-    "Pin": "Alfinete"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/ru.json b/data-definitions/sas-emoji-v1-i18n/ru.json
deleted file mode 100644
index 99f8c220..00000000
--- a/data-definitions/sas-emoji-v1-i18n/ru.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Собака",
-    "Cat": "Кошка",
-    "Lion": "Лев",
-    "Horse": "Лошадь",
-    "Unicorn": "Единорог",
-    "Pig": "Свинья",
-    "Elephant": "Слон",
-    "Rabbit": "Кролик",
-    "Panda": "Панда",
-    "Rooster": "Петух",
-    "Penguin": "Пингвин",
-    "Turtle": "Черепаха",
-    "Fish": "Рыба",
-    "Octopus": "Осьминог",
-    "Butterfly": "Бабочка",
-    "Flower": "Цветок",
-    "Tree": "Дерево",
-    "Cactus": "Кактус",
-    "Mushroom": "Гриб",
-    "Globe": "Глобус",
-    "Moon": "Луна",
-    "Cloud": "Облако",
-    "Fire": "Огонь",
-    "Banana": "Банан",
-    "Apple": "Яблоко",
-    "Strawberry": "Клубника",
-    "Corn": "Кукуруза",
-    "Pizza": "Пицца",
-    "Cake": "Торт",
-    "Heart": "Сердце",
-    "Smiley": "Улыбка",
-    "Robot": "Робот",
-    "Hat": "Шляпа",
-    "Glasses": "Очки",
-    "Spanner": "Ключ",
-    "Santa": "Санта",
-    "Thumbs Up": "Большой палец вверх",
-    "Umbrella": "Зонт",
-    "Hourglass": "Песочные часы",
-    "Clock": "Часы",
-    "Gift": "Подарок",
-    "Light Bulb": "Лампочка",
-    "Book": "Книга",
-    "Pencil": "Карандаш",
-    "Paperclip": "Скрепка",
-    "Scissors": "Ножницы",
-    "Lock": "Замок",
-    "Key": "Ключ",
-    "Hammer": "Молоток",
-    "Telephone": "Телефон",
-    "Flag": "Флаг",
-    "Train": "Поезд",
-    "Bicycle": "Велосипед",
-    "Aeroplane": "Самолет",
-    "Rocket": "Ракета",
-    "Trophy": "Кубок",
-    "Ball": "Мяч",
-    "Guitar": "Гитара",
-    "Trumpet": "Труба",
-    "Bell": "Колокол",
-    "Anchor": "Якорь",
-    "Headphones": "Наушники",
-    "Folder": "Папка",
-    "Pin": "Булавка"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/si.json b/data-definitions/sas-emoji-v1-i18n/si.json
deleted file mode 100644
index aa84535f..00000000
--- a/data-definitions/sas-emoji-v1-i18n/si.json
+++ /dev/null
@@ -1,6 +0,0 @@
-{
-    "Horse": "අශ්වයා",
-    "Lion": "සිංහයා",
-    "Cat": "පූසා",
-    "Dog": "බල්ලා"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/sk.json b/data-definitions/sas-emoji-v1-i18n/sk.json
deleted file mode 100644
index f0a7176c..00000000
--- a/data-definitions/sas-emoji-v1-i18n/sk.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Hlava psa",
-    "Cat": "Hlava mačky",
-    "Lion": "Hlava leva",
-    "Horse": "Kôň",
-    "Unicorn": "Hlava jednorožca",
-    "Pig": "Hlava prasaťa",
-    "Elephant": "Slon",
-    "Rabbit": "Hlava zajaca",
-    "Panda": "Hlava pandy",
-    "Rooster": "Kohút",
-    "Penguin": "Tučniak",
-    "Turtle": "Korytnačka",
-    "Fish": "Ryba",
-    "Octopus": "Chobotnica",
-    "Butterfly": "Motýľ",
-    "Flower": "Tulipán",
-    "Tree": "Listnatý strom",
-    "Cactus": "Kaktus",
-    "Mushroom": "Huba",
-    "Globe": "Zemeguľa",
-    "Moon": "Polmesiac",
-    "Cloud": "Oblak",
-    "Fire": "Oheň",
-    "Banana": "Banán",
-    "Apple": "Červené jablko",
-    "Strawberry": "Jahoda",
-    "Corn": "Kukuričný klas",
-    "Pizza": "Pizza",
-    "Cake": "Narodeninová torta",
-    "Heart": "červené srdce",
-    "Smiley": "Škeriaca sa tvár",
-    "Robot": "Robot",
-    "Hat": "Cilinder",
-    "Glasses": "Okuliare",
-    "Spanner": "Francúzsky kľúč",
-    "Santa": "Santa Claus",
-    "Thumbs Up": "Palec nahor",
-    "Umbrella": "Dáždnik",
-    "Hourglass": "Presýpacie hodiny",
-    "Clock": "Budík",
-    "Gift": "Zabalený darček",
-    "Light Bulb": "Žiarovka",
-    "Book": "Zatvorená kniha",
-    "Pencil": "Ceruzka",
-    "Paperclip": "Sponka na papier",
-    "Scissors": "Nožnice",
-    "Lock": "Zatvorená zámka",
-    "Key": "Kľúč",
-    "Hammer": "Kladivo",
-    "Telephone": "Telefón",
-    "Flag": "Kockovaná zástava",
-    "Train": "Rušeň",
-    "Bicycle": "Bicykel",
-    "Aeroplane": "Lietadlo",
-    "Rocket": "Raketa",
-    "Trophy": "Trofej",
-    "Ball": "Futbal",
-    "Guitar": "Gitara",
-    "Trumpet": "Trúbka",
-    "Bell": "Zvon",
-    "Anchor": "Kotva",
-    "Headphones": "Slúchadlá",
-    "Folder": "Fascikel",
-    "Pin": "Špendlík"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/sq.json b/data-definitions/sas-emoji-v1-i18n/sq.json
deleted file mode 100644
index ce5cea5c..00000000
--- a/data-definitions/sas-emoji-v1-i18n/sq.json
+++ /dev/null
@@ -1,65 +0,0 @@
-{
-    "Key": "Çelës",
-    "Clock": "Sahat",
-    "Pin": "Karficë",
-    "Folder": "Dosje",
-    "Headphones": "Kufje",
-    "Anchor": "Spirancë",
-    "Bell": "Kambanë",
-    "Trumpet": "Trombë",
-    "Guitar": "Kitarë",
-    "Ball": "Top",
-    "Trophy": "Trofe",
-    "Rocket": "Raketë",
-    "Aeroplane": "Avion",
-    "Bicycle": "Biçikletë",
-    "Train": "Tren",
-    "Flag": "Flamur",
-    "Telephone": "Telefon",
-    "Hammer": "Çekiç",
-    "Lock": "Dry",
-    "Scissors": "Gërshërë",
-    "Paperclip": "Kapëse",
-    "Pencil": "Laps",
-    "Book": "Libër",
-    "Light Bulb": "Llambë",
-    "Gift": "Dhuratë",
-    "Hourglass": "Klepsidër",
-    "Umbrella": "Ombrellë",
-    "Santa": "Babagjyshi i Vitit të Ri",
-    "Spanner": "Çelës",
-    "Glasses": "Syze",
-    "Hat": "Kapë",
-    "Robot": "Robot",
-    "Smiley": "Emotikon",
-    "Heart": "Zemër",
-    "Cake": "Tortë",
-    "Pizza": "Picë",
-    "Corn": "Misër",
-    "Strawberry": "Luleshtrydhe",
-    "Apple": "Mollë",
-    "Banana": "Banane",
-    "Fire": "Zjarr",
-    "Panda": "Panda",
-    "Cloud": "Re",
-    "Moon": "Hënë",
-    "Globe": "Rruzull",
-    "Mushroom": "Kërpudhë",
-    "Cactus": "Kaktus",
-    "Tree": "Pemë",
-    "Flower": "Lule",
-    "Butterfly": "Flutur",
-    "Octopus": "Oktapod",
-    "Fish": "Peshk",
-    "Turtle": "Breshkë",
-    "Penguin": "Pinguin",
-    "Rooster": "Këndes",
-    "Rabbit": "Lepur",
-    "Elephant": "Elefant",
-    "Pig": "Derr",
-    "Unicorn": "Njëbrirësh",
-    "Horse": "Kalë",
-    "Lion": "Luan",
-    "Cat": "Mace",
-    "Dog": "Qen"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/sr.json b/data-definitions/sas-emoji-v1-i18n/sr.json
deleted file mode 100644
index 5baae6e6..00000000
--- a/data-definitions/sas-emoji-v1-i18n/sr.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Pin": "чиода",
-    "Folder": "фасцикла",
-    "Headphones": "слушалице",
-    "Anchor": "сидро",
-    "Bell": "звоно",
-    "Trumpet": "труба",
-    "Guitar": "гитара",
-    "Ball": "лопта",
-    "Trophy": "пехар",
-    "Rocket": "ракета",
-    "Aeroplane": "авион",
-    "Bicycle": "бицикл",
-    "Train": "воз",
-    "Flag": "застава",
-    "Telephone": "телефон",
-    "Hammer": "чекић",
-    "Key": "кључ",
-    "Lock": "катанац",
-    "Scissors": "маказе",
-    "Paperclip": "спајалица",
-    "Pencil": "оловка",
-    "Book": "књига",
-    "Light Bulb": "сијалица",
-    "Gift": "поклон",
-    "Clock": "сат",
-    "Hourglass": "пешчаник",
-    "Umbrella": "кишобран",
-    "Thumbs Up": "палчић горе",
-    "Santa": "деда Мраз",
-    "Spanner": "кључ",
-    "Glasses": "наочаре",
-    "Hat": "шешир",
-    "Robot": "робот",
-    "Smiley": "смајли",
-    "Heart": "срце",
-    "Cake": "торта",
-    "Pizza": "пица",
-    "Corn": "кукуруз",
-    "Strawberry": "јагода",
-    "Apple": "јабука",
-    "Banana": "банана",
-    "Fire": "ватра",
-    "Cloud": "облак",
-    "Moon": "месец",
-    "Globe": "глобус",
-    "Mushroom": "печурка",
-    "Cactus": "кактус",
-    "Tree": "дрво",
-    "Flower": "цвет",
-    "Butterfly": "лептир",
-    "Octopus": "октопод",
-    "Fish": "риба",
-    "Turtle": "корњача",
-    "Penguin": "пингвин",
-    "Rooster": "петао",
-    "Panda": "панда",
-    "Rabbit": "зец",
-    "Elephant": "слон",
-    "Pig": "прасе",
-    "Unicorn": "једнорог",
-    "Horse": "коњ",
-    "Lion": "лав",
-    "Cat": "мачка",
-    "Dog": "пас"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/sv.json b/data-definitions/sas-emoji-v1-i18n/sv.json
deleted file mode 100644
index e0df5b30..00000000
--- a/data-definitions/sas-emoji-v1-i18n/sv.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Hund",
-    "Cat": "Katt",
-    "Lion": "Lejon",
-    "Horse": "Häst",
-    "Unicorn": "Enhörning",
-    "Pig": "Gris",
-    "Elephant": "Elefant",
-    "Rabbit": "Kanin",
-    "Panda": "Panda",
-    "Rooster": "Tupp",
-    "Penguin": "Pingvin",
-    "Turtle": "Sköldpadda",
-    "Fish": "Fisk",
-    "Octopus": "Bläckfisk",
-    "Butterfly": "Fjäril",
-    "Flower": "Blomma",
-    "Tree": "Träd",
-    "Cactus": "Kaktus",
-    "Mushroom": "Svamp",
-    "Globe": "Jordklot",
-    "Moon": "Måne",
-    "Cloud": "Moln",
-    "Fire": "Eld",
-    "Banana": "Banan",
-    "Apple": "Äpple",
-    "Strawberry": "Jordgubbe",
-    "Corn": "Majs",
-    "Pizza": "Pizza",
-    "Cake": "Tårta",
-    "Heart": "Hjärta",
-    "Smiley": "Smiley",
-    "Robot": "Robot",
-    "Hat": "Hatt",
-    "Glasses": "Glasögon",
-    "Spanner": "Skruvnyckel",
-    "Santa": "Tomte",
-    "Thumbs Up": "Tummen upp",
-    "Umbrella": "Paraply",
-    "Hourglass": "Timglas",
-    "Clock": "Klocka",
-    "Gift": "Present",
-    "Light Bulb": "Lampa",
-    "Book": "Bok",
-    "Pencil": "Penna",
-    "Paperclip": "Gem",
-    "Scissors": "Sax",
-    "Lock": "Lås",
-    "Key": "Nyckel",
-    "Hammer": "Hammare",
-    "Telephone": "Telefon",
-    "Flag": "Flagga",
-    "Train": "Tåg",
-    "Bicycle": "Cykel",
-    "Aeroplane": "Flygplan",
-    "Rocket": "Raket",
-    "Trophy": "Trofé",
-    "Ball": "Boll",
-    "Guitar": "Gitarr",
-    "Trumpet": "Trumpet",
-    "Bell": "Bjällra",
-    "Anchor": "Ankare",
-    "Headphones": "Hörlurar",
-    "Folder": "Mapp",
-    "Pin": "Häftstift"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/szl.json b/data-definitions/sas-emoji-v1-i18n/szl.json
deleted file mode 100644
index 0967ef42..00000000
--- a/data-definitions/sas-emoji-v1-i18n/szl.json
+++ /dev/null
@@ -1 +0,0 @@
-{}
diff --git a/data-definitions/sas-emoji-v1-i18n/tzm.json b/data-definitions/sas-emoji-v1-i18n/tzm.json
deleted file mode 100644
index 1045169c..00000000
--- a/data-definitions/sas-emoji-v1-i18n/tzm.json
+++ /dev/null
@@ -1,28 +0,0 @@
-{
-    "Folder": "Asdaw",
-    "Guitar": "Agiṭaṛ",
-    "Ball": "Tcama",
-    "Flag": "Acenyal",
-    "Telephone": "Atilifun",
-    "Key": "Tasarut",
-    "Book": "Adlis",
-    "Hat": "Taraza",
-    "Robot": "Aṛubu",
-    "Heart": "Ul",
-    "Apple": "Tadeffuyt",
-    "Banana": "Tabanant",
-    "Fire": "Timessi",
-    "Moon": "Ayyur",
-    "Mushroom": "Agursel",
-    "Tree": "Aseklu",
-    "Fish": "Aselm",
-    "Turtle": "Ifker",
-    "Rooster": "Ayaẓiḍ",
-    "Rabbit": "Agnin",
-    "Elephant": "Ilu",
-    "Pig": "Ilef",
-    "Horse": "Ayyis",
-    "Lion": "Izem",
-    "Cat": "Amuc",
-    "Dog": "Aydi"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/uk.json b/data-definitions/sas-emoji-v1-i18n/uk.json
deleted file mode 100644
index 1b331770..00000000
--- a/data-definitions/sas-emoji-v1-i18n/uk.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "Пес",
-    "Cat": "Кіт",
-    "Lion": "Лев",
-    "Horse": "Кінь",
-    "Unicorn": "Єдиноріг",
-    "Pig": "Свиня",
-    "Elephant": "Слон",
-    "Rabbit": "Кріль",
-    "Panda": "Панда",
-    "Rooster": "Когут",
-    "Penguin": "Пінгвін",
-    "Turtle": "Черепаха",
-    "Fish": "Риба",
-    "Octopus": "Восьминіг",
-    "Butterfly": "Метелик",
-    "Flower": "Квітка",
-    "Tree": "Дерево",
-    "Cactus": "Кактус",
-    "Mushroom": "Гриб",
-    "Globe": "Глобус",
-    "Moon": "Місяць",
-    "Cloud": "Хмара",
-    "Fire": "Вогонь",
-    "Banana": "Банан",
-    "Apple": "Яблуко",
-    "Strawberry": "Полуниця",
-    "Corn": "Кукурудза",
-    "Pizza": "Піца",
-    "Cake": "Пиріг",
-    "Heart": "Серце",
-    "Smiley": "Посмішка",
-    "Robot": "Робот",
-    "Hat": "Капелюх",
-    "Glasses": "Окуляри",
-    "Spanner": "Гайковий ключ",
-    "Santa": "Санта Клаус",
-    "Thumbs Up": "Великий палець вгору",
-    "Umbrella": "Парасолька",
-    "Hourglass": "Пісковий годинник",
-    "Clock": "Годинник",
-    "Gift": "Подарунок",
-    "Light Bulb": "Лампочка",
-    "Book": "Книга",
-    "Pencil": "Олівець",
-    "Paperclip": "Спиначка",
-    "Scissors": "Ножиці",
-    "Lock": "Замок",
-    "Key": "Ключ",
-    "Hammer": "Молоток",
-    "Telephone": "Телефон",
-    "Flag": "Прапор",
-    "Train": "Потяг",
-    "Bicycle": "Велосипед",
-    "Aeroplane": "Літак",
-    "Rocket": "Ракета",
-    "Trophy": "Приз",
-    "Ball": "М'яч",
-    "Guitar": "Гітара",
-    "Trumpet": "Труба",
-    "Bell": "Дзвін",
-    "Anchor": "Якір",
-    "Headphones": "Навушники",
-    "Folder": "Тека",
-    "Pin": "Кнопка"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/vi.json b/data-definitions/sas-emoji-v1-i18n/vi.json
deleted file mode 100644
index f6e146da..00000000
--- a/data-definitions/sas-emoji-v1-i18n/vi.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Pin": "Ghim",
-    "Folder": "Thư mục",
-    "Headphones": "Tai nghe",
-    "Anchor": "Mỏ neo",
-    "Bell": "Chuông",
-    "Trumpet": "Kèn",
-    "Guitar": "Ghi-ta",
-    "Ball": "Banh",
-    "Trophy": "Cúp",
-    "Rocket": "Tên lửa",
-    "Aeroplane": "Máy bay",
-    "Bicycle": "Xe đạp",
-    "Train": "Xe lửa",
-    "Flag": "Lá cờ",
-    "Telephone": "Điện thoại",
-    "Hammer": "Búa",
-    "Key": "Chìa khóa",
-    "Lock": "Ổ khóa",
-    "Scissors": "Cây kéo",
-    "Paperclip": "Kẹp giấy",
-    "Pencil": "Viết chì",
-    "Book": "Sách",
-    "Light Bulb": "Bóng đèn tròn",
-    "Gift": "Quà",
-    "Clock": "Đồng hồ",
-    "Hourglass": "Đồng hồ cát",
-    "Umbrella": "Cây dù",
-    "Thumbs Up": "Thích",
-    "Santa": "ông già Noel",
-    "Spanner": "Cờ-lê",
-    "Glasses": "Mắt kiếng",
-    "Hat": "Nón",
-    "Robot": "Rô-bô",
-    "Smiley": "Mặt cười",
-    "Heart": "Tim",
-    "Cake": "Bánh",
-    "Pizza": "Pizza",
-    "Corn": "Bắp",
-    "Strawberry": "Dâu tây",
-    "Apple": "Táo",
-    "Banana": "Chuối",
-    "Fire": "Lửa",
-    "Cloud": "Mây",
-    "Moon": "Mặt trăng",
-    "Globe": "Địa cầu",
-    "Mushroom": "Nấm",
-    "Cactus": "Xương rồng",
-    "Tree": "Cây",
-    "Flower": "Hoa",
-    "Butterfly": "Bướm",
-    "Octopus": "Bạch tuộc",
-    "Fish": "Cá",
-    "Turtle": "Rùa",
-    "Penguin": "Chim cánh cụt",
-    "Rooster": "Gà trống",
-    "Panda": "Gấu trúc",
-    "Rabbit": "Thỏ",
-    "Elephant": "Voi",
-    "Pig": "Heo",
-    "Unicorn": "Kỳ lân",
-    "Horse": "Ngựa",
-    "Lion": "Sư tử",
-    "Cat": "Mèo",
-    "Dog": "Chó"
-}
diff --git a/data-definitions/sas-emoji-v1-i18n/zh_Hans.json b/data-definitions/sas-emoji-v1-i18n/zh_Hans.json
deleted file mode 100644
index fb193afa..00000000
--- a/data-definitions/sas-emoji-v1-i18n/zh_Hans.json
+++ /dev/null
@@ -1,66 +0,0 @@
-{
-    "Dog": "狗",
-    "Cat": "猫",
-    "Lion": "狮子",
-    "Horse": "马",
-    "Unicorn": "独角兽",
-    "Pig": "猪",
-    "Elephant": "大象",
-    "Rabbit": "兔子",
-    "Panda": "熊猫",
-    "Rooster": "公鸡",
-    "Penguin": "企鹅",
-    "Turtle": "乌龟",
-    "Fish": "鱼",
-    "Octopus": "章鱼",
-    "Butterfly": "蝴蝶",
-    "Flower": "花",
-    "Tree": "树",
-    "Cactus": "仙人掌",
-    "Mushroom": "蘑菇",
-    "Globe": "地球",
-    "Moon": "月亮",
-    "Cloud": "云",
-    "Fire": "火",
-    "Banana": "香蕉",
-    "Apple": "苹果",
-    "Strawberry": "草莓",
-    "Corn": "玉米",
-    "Pizza": "披萨",
-    "Cake": "蛋糕",
-    "Heart": "心",
-    "Smiley": "笑脸",
-    "Robot": "机器人",
-    "Hat": "帽子",
-    "Glasses": "眼镜",
-    "Spanner": "扳手",
-    "Santa": "圣诞老人",
-    "Thumbs Up": "赞",
-    "Umbrella": "伞",
-    "Hourglass": "沙漏",
-    "Clock": "时钟",
-    "Gift": "礼物",
-    "Light Bulb": "灯泡",
-    "Book": "书",
-    "Pencil": "铅笔",
-    "Paperclip": "回形针",
-    "Scissors": "剪刀",
-    "Lock": "锁",
-    "Key": "钥匙",
-    "Hammer": "锤子",
-    "Telephone": "电话",
-    "Flag": "旗帜",
-    "Train": "火车",
-    "Bicycle": "自行车",
-    "Aeroplane": "飞机",
-    "Rocket": "火箭",
-    "Trophy": "奖杯",
-    "Ball": "球",
-    "Guitar": "吉他",
-    "Trumpet": "喇叭",
-    "Bell": "铃铛",
-    "Anchor": "锚",
-    "Headphones": "耳机",
-    "Folder": "文件夹",
-    "Pin": "图钉"
-}
diff --git a/data-definitions/sas-emoji.json b/data-definitions/sas-emoji.json
deleted file mode 100644
index e6bc02bf..00000000
--- a/data-definitions/sas-emoji.json
+++ /dev/null
@@ -1,2370 +0,0 @@
-[
-    {
-        "number": 0,
-        "emoji": "🐶",
-        "description": "Dog",
-        "unicode": "U+1F436",
-        "translated_descriptions": {
-            "ar": "كَلب",
-            "bg": "Куче",
-            "ca": "Gos",
-            "cs": "Pes",
-            "de": "Hund",
-            "eo": "Hundo",
-            "es": "Perro",
-            "et": "Koer",
-            "fi": "Koira",
-            "fr": "Chien",
-            "hr": "pas",
-            "hu": "Kutya",
-            "id": "Anjing",
-            "it": "Cane",
-            "ja": "犬",
-            "nb_NO": "Hund",
-            "nl": "Hond",
-            "pt_BR": "Cachorro",
-            "ru": "Собака",
-            "si": "බල්ලා",
-            "sk": "Hlava psa",
-            "sq": "Qen",
-            "sr": "пас",
-            "sv": "Hund",
-            "szl": null,
-            "tzm": "Aydi",
-            "uk": "Пес",
-            "vi": "Chó",
-            "zh_Hans": "狗"
-        }
-    },
-    {
-        "number": 1,
-        "emoji": "🐱",
-        "description": "Cat",
-        "unicode": "U+1F431",
-        "translated_descriptions": {
-            "ar": "هِرَّة",
-            "bg": "Котка",
-            "ca": "Gat",
-            "cs": "Kočka",
-            "de": "Katze",
-            "eo": "Kato",
-            "es": "Gato",
-            "et": "Kass",
-            "fi": "Kissa",
-            "fr": "Chat",
-            "hr": "mačka",
-            "hu": "Macska",
-            "id": "Kucing",
-            "it": "Gatto",
-            "ja": "猫",
-            "nb_NO": "Katt",
-            "nl": "Kat",
-            "pt_BR": "Gato",
-            "ru": "Кошка",
-            "si": "පූසා",
-            "sk": "Hlava mačky",
-            "sq": "Mace",
-            "sr": "мачка",
-            "sv": "Katt",
-            "szl": null,
-            "tzm": "Amuc",
-            "uk": "Кіт",
-            "vi": "Mèo",
-            "zh_Hans": "猫"
-        }
-    },
-    {
-        "number": 2,
-        "emoji": "🦁",
-        "description": "Lion",
-        "unicode": "U+1F981",
-        "translated_descriptions": {
-            "ar": "أَسَد",
-            "bg": "Лъв",
-            "ca": "Lleó",
-            "cs": "Lev",
-            "de": "Löwe",
-            "eo": "Leono",
-            "es": "León",
-            "et": "Lõvi",
-            "fi": "Leijona",
-            "fr": "Lion",
-            "hr": "lav",
-            "hu": "Oroszlán",
-            "id": "Singa",
-            "it": "Leone",
-            "ja": "ライオン",
-            "nb_NO": "Løve",
-            "nl": "Leeuw",
-            "pt_BR": "Leão",
-            "ru": "Лев",
-            "si": "සිංහයා",
-            "sk": "Hlava leva",
-            "sq": "Luan",
-            "sr": "лав",
-            "sv": "Lejon",
-            "szl": null,
-            "tzm": "Izem",
-            "uk": "Лев",
-            "vi": "Sư tử",
-            "zh_Hans": "狮子"
-        }
-    },
-    {
-        "number": 3,
-        "emoji": "🐎",
-        "description": "Horse",
-        "unicode": "U+1F40E",
-        "translated_descriptions": {
-            "ar": "حِصَان",
-            "bg": "Кон",
-            "ca": "Cavall",
-            "cs": "Kůň",
-            "de": "Pferd",
-            "eo": "Ĉevalo",
-            "es": "Caballo",
-            "et": "Hobune",
-            "fi": "Hevonen",
-            "fr": "Cheval",
-            "hr": "konj",
-            "hu": "Ló",
-            "id": "Kuda",
-            "it": "Cavallo",
-            "ja": "馬",
-            "nb_NO": "Hest",
-            "nl": "Paard",
-            "pt_BR": "Cavalo",
-            "ru": "Лошадь",
-            "si": "අශ්වයා",
-            "sk": "Kôň",
-            "sq": "Kalë",
-            "sr": "коњ",
-            "sv": "Häst",
-            "szl": null,
-            "tzm": "Ayyis",
-            "uk": "Кінь",
-            "vi": "Ngựa",
-            "zh_Hans": "马"
-        }
-    },
-    {
-        "number": 4,
-        "emoji": "🦄",
-        "description": "Unicorn",
-        "unicode": "U+1F984",
-        "translated_descriptions": {
-            "ar": "حِصَانٌ بِقَرن",
-            "bg": "Еднорог",
-            "ca": "Unicorn",
-            "cs": "Jednorožec",
-            "de": "Einhorn",
-            "eo": "Unukorno",
-            "es": "Unicornio",
-            "et": "Ükssarvik",
-            "fi": "Yksisarvinen",
-            "fr": "Licorne",
-            "hr": "jednorog",
-            "hu": "Egyszarvú",
-            "id": "Unicorn",
-            "it": "Unicorno",
-            "ja": "ユニコーン",
-            "nb_NO": "Enhjørning",
-            "nl": "Eenhoorn",
-            "pt_BR": "Unicórnio",
-            "ru": "Единорог",
-            "si": null,
-            "sk": "Hlava jednorožca",
-            "sq": "Njëbrirësh",
-            "sr": "једнорог",
-            "sv": "Enhörning",
-            "szl": null,
-            "tzm": null,
-            "uk": "Єдиноріг",
-            "vi": "Kỳ lân",
-            "zh_Hans": "独角兽"
-        }
-    },
-    {
-        "number": 5,
-        "emoji": "🐷",
-        "description": "Pig",
-        "unicode": "U+1F437",
-        "translated_descriptions": {
-            "ar": "خِنزِير",
-            "bg": "Прасе",
-            "ca": "Porc",
-            "cs": "Prase",
-            "de": "Schwein",
-            "eo": "Porko",
-            "es": "Cerdo",
-            "et": "Siga",
-            "fi": "Sika",
-            "fr": "Cochon",
-            "hr": "svinja",
-            "hu": "Malac",
-            "id": "Babi",
-            "it": "Maiale",
-            "ja": "ブタ",
-            "nb_NO": "Gris",
-            "nl": "Varken",
-            "pt_BR": "Porco",
-            "ru": "Свинья",
-            "si": null,
-            "sk": "Hlava prasaťa",
-            "sq": "Derr",
-            "sr": "прасе",
-            "sv": "Gris",
-            "szl": null,
-            "tzm": "Ilef",
-            "uk": "Свиня",
-            "vi": "Heo",
-            "zh_Hans": "猪"
-        }
-    },
-    {
-        "number": 6,
-        "emoji": "🐘",
-        "description": "Elephant",
-        "unicode": "U+1F418",
-        "translated_descriptions": {
-            "ar": "فِيل",
-            "bg": "Слон",
-            "ca": "Elefant",
-            "cs": "Slon",
-            "de": "Elefant",
-            "eo": "Elefanto",
-            "es": "Elefante",
-            "et": "Elevant",
-            "fi": "Norsu",
-            "fr": "Éléphant",
-            "hr": "slon",
-            "hu": "Elefánt",
-            "id": "Gajah",
-            "it": "Elefante",
-            "ja": "ゾウ",
-            "nb_NO": "Elefant",
-            "nl": "Olifant",
-            "pt_BR": "Elefante",
-            "ru": "Слон",
-            "si": null,
-            "sk": "Slon",
-            "sq": "Elefant",
-            "sr": "слон",
-            "sv": "Elefant",
-            "szl": null,
-            "tzm": "Ilu",
-            "uk": "Слон",
-            "vi": "Voi",
-            "zh_Hans": "大象"
-        }
-    },
-    {
-        "number": 7,
-        "emoji": "🐰",
-        "description": "Rabbit",
-        "unicode": "U+1F430",
-        "translated_descriptions": {
-            "ar": "أَرنَب",
-            "bg": "Заек",
-            "ca": "Conill",
-            "cs": "Králík",
-            "de": "Hase",
-            "eo": "Kuniklo",
-            "es": "Conejo",
-            "et": "Jänes",
-            "fi": "Kani",
-            "fr": "Lapin",
-            "hr": "zec",
-            "hu": "Nyúl",
-            "id": "Kelinci",
-            "it": "Coniglio",
-            "ja": "うさぎ",
-            "nb_NO": "Kanin",
-            "nl": "Konijn",
-            "pt_BR": "Coelho",
-            "ru": "Кролик",
-            "si": null,
-            "sk": "Hlava zajaca",
-            "sq": "Lepur",
-            "sr": "зец",
-            "sv": "Kanin",
-            "szl": null,
-            "tzm": "Agnin",
-            "uk": "Кріль",
-            "vi": "Thỏ",
-            "zh_Hans": "兔子"
-        }
-    },
-    {
-        "number": 8,
-        "emoji": "🐼",
-        "description": "Panda",
-        "unicode": "U+1F43C",
-        "translated_descriptions": {
-            "ar": "باندَا",
-            "bg": "Панда",
-            "ca": "Panda",
-            "cs": "Panda",
-            "de": "Panda",
-            "eo": "Pando",
-            "es": "Panda",
-            "et": "Panda",
-            "fi": "Panda",
-            "fr": "Panda",
-            "hr": "panda",
-            "hu": "Panda",
-            "id": "Panda",
-            "it": "Panda",
-            "ja": "パンダ",
-            "nb_NO": "Panda",
-            "nl": "Panda",
-            "pt_BR": "Panda",
-            "ru": "Панда",
-            "si": null,
-            "sk": "Hlava pandy",
-            "sq": "Panda",
-            "sr": "панда",
-            "sv": "Panda",
-            "szl": null,
-            "tzm": null,
-            "uk": "Панда",
-            "vi": "Gấu trúc",
-            "zh_Hans": "熊猫"
-        }
-    },
-    {
-        "number": 9,
-        "emoji": "🐓",
-        "description": "Rooster",
-        "unicode": "U+1F413",
-        "translated_descriptions": {
-            "ar": "دِيك",
-            "bg": "Петел",
-            "ca": "Gall",
-            "cs": "Kohout",
-            "de": "Hahn",
-            "eo": "Virkoko",
-            "es": "Gallo",
-            "et": "Kukk",
-            "fi": "Kukko",
-            "fr": "Coq",
-            "hr": "kokot",
-            "hu": "Kakas",
-            "id": "Ayam",
-            "it": "Gallo",
-            "ja": "ニワトリ",
-            "nb_NO": "Hane",
-            "nl": "Haan",
-            "pt_BR": "Galo",
-            "ru": "Петух",
-            "si": null,
-            "sk": "Kohút",
-            "sq": "Këndes",
-            "sr": "петао",
-            "sv": "Tupp",
-            "szl": null,
-            "tzm": "Ayaẓiḍ",
-            "uk": "Когут",
-            "vi": "Gà trống",
-            "zh_Hans": "公鸡"
-        }
-    },
-    {
-        "number": 10,
-        "emoji": "🐧",
-        "description": "Penguin",
-        "unicode": "U+1F427",
-        "translated_descriptions": {
-            "ar": "بِطريق",
-            "bg": "Пингвин",
-            "ca": "Pingüí",
-            "cs": "Tučňák",
-            "de": "Pinguin",
-            "eo": "Pingveno",
-            "es": "Pingüino",
-            "et": "Pingviin",
-            "fi": "Pingviini",
-            "fr": "Manchot",
-            "hr": "pingvin",
-            "hu": "Pingvin",
-            "id": "Penguin",
-            "it": "Pinguino",
-            "ja": "ペンギン",
-            "nb_NO": "Pingvin",
-            "nl": "Pinguïn",
-            "pt_BR": "Pinguim",
-            "ru": "Пингвин",
-            "si": null,
-            "sk": "Tučniak",
-            "sq": "Pinguin",
-            "sr": "пингвин",
-            "sv": "Pingvin",
-            "szl": null,
-            "tzm": null,
-            "uk": "Пінгвін",
-            "vi": "Chim cánh cụt",
-            "zh_Hans": "企鹅"
-        }
-    },
-    {
-        "number": 11,
-        "emoji": "🐢",
-        "description": "Turtle",
-        "unicode": "U+1F422",
-        "translated_descriptions": {
-            "ar": "سُلحفاة",
-            "bg": "Костенурка",
-            "ca": "Tortuga",
-            "cs": "Želva",
-            "de": "Schildkröte",
-            "eo": "Testudo",
-            "es": "Tortuga",
-            "et": "Kilpkonn",
-            "fi": "Kilpikonna",
-            "fr": "Tortue",
-            "hr": "kornjača",
-            "hu": "Teknős",
-            "id": "Kura-Kura",
-            "it": "Tartaruga",
-            "ja": "亀",
-            "nb_NO": "Skilpadde",
-            "nl": "Schildpad",
-            "pt_BR": "Tartaruga",
-            "ru": "Черепаха",
-            "si": null,
-            "sk": "Korytnačka",
-            "sq": "Breshkë",
-            "sr": "корњача",
-            "sv": "Sköldpadda",
-            "szl": null,
-            "tzm": "Ifker",
-            "uk": "Черепаха",
-            "vi": "Rùa",
-            "zh_Hans": "乌龟"
-        }
-    },
-    {
-        "number": 12,
-        "emoji": "🐟",
-        "description": "Fish",
-        "unicode": "U+1F41F",
-        "translated_descriptions": {
-            "ar": "سَمَكَة",
-            "bg": "Риба",
-            "ca": "Peix",
-            "cs": "Ryba",
-            "de": "Fisch",
-            "eo": "Fiŝo",
-            "es": "Pez",
-            "et": "Kala",
-            "fi": "Kala",
-            "fr": "Poisson",
-            "hr": "riba",
-            "hu": "Hal",
-            "id": "Ikan",
-            "it": "Pesce",
-            "ja": "魚",
-            "nb_NO": "Fisk",
-            "nl": "Vis",
-            "pt_BR": "Peixe",
-            "ru": "Рыба",
-            "si": null,
-            "sk": "Ryba",
-            "sq": "Peshk",
-            "sr": "риба",
-            "sv": "Fisk",
-            "szl": null,
-            "tzm": "Aselm",
-            "uk": "Риба",
-            "vi": "Cá",
-            "zh_Hans": "鱼"
-        }
-    },
-    {
-        "number": 13,
-        "emoji": "🐙",
-        "description": "Octopus",
-        "unicode": "U+1F419",
-        "translated_descriptions": {
-            "ar": "أُخطُبُوط",
-            "bg": "Октопод",
-            "ca": "Pop",
-            "cs": "Chobotnice",
-            "de": "Oktopus",
-            "eo": "Polpo",
-            "es": "Pulpo",
-            "et": "Kaheksajalg",
-            "fi": "Tursas",
-            "fr": "Poulpe",
-            "hr": "hobotnica",
-            "hu": "Polip",
-            "id": "Gurita",
-            "it": "Polpo",
-            "ja": "たこ",
-            "nb_NO": "Blekksprut",
-            "nl": "Octopus",
-            "pt_BR": "Polvo",
-            "ru": "Осьминог",
-            "si": null,
-            "sk": "Chobotnica",
-            "sq": "Oktapod",
-            "sr": "октопод",
-            "sv": "Bläckfisk",
-            "szl": null,
-            "tzm": null,
-            "uk": "Восьминіг",
-            "vi": "Bạch tuộc",
-            "zh_Hans": "章鱼"
-        }
-    },
-    {
-        "number": 14,
-        "emoji": "🦋",
-        "description": "Butterfly",
-        "unicode": "U+1F98B",
-        "translated_descriptions": {
-            "ar": "فَرَاشَة",
-            "bg": "Пеперуда",
-            "ca": "Papallona",
-            "cs": "Motýl",
-            "de": "Schmetterling",
-            "eo": "Papilio",
-            "es": "Mariposa",
-            "et": "Liblikas",
-            "fi": "Perhonen",
-            "fr": "Papillon",
-            "hr": "leptir",
-            "hu": "Pillangó",
-            "id": "Kupu-Kupu",
-            "it": "Farfalla",
-            "ja": "ちょうちょ",
-            "nb_NO": "Sommerfugl",
-            "nl": "Vlinder",
-            "pt_BR": "Borboleta",
-            "ru": "Бабочка",
-            "si": null,
-            "sk": "Motýľ",
-            "sq": "Flutur",
-            "sr": "лептир",
-            "sv": "Fjäril",
-            "szl": null,
-            "tzm": null,
-            "uk": "Метелик",
-            "vi": "Bướm",
-            "zh_Hans": "蝴蝶"
-        }
-    },
-    {
-        "number": 15,
-        "emoji": "🌷",
-        "description": "Flower",
-        "unicode": "U+1F337",
-        "translated_descriptions": {
-            "ar": "زَهرَة",
-            "bg": "Цвете",
-            "ca": "Flor",
-            "cs": "Květina",
-            "de": "Blume",
-            "eo": "Floro",
-            "es": "Flor",
-            "et": "Lill",
-            "fi": "Kukka",
-            "fr": "Fleur",
-            "hr": "svijet",
-            "hu": "Virág",
-            "id": "Bunga",
-            "it": "Fiore",
-            "ja": "花",
-            "nb_NO": "Blomst",
-            "nl": "Bloem",
-            "pt_BR": "Flor",
-            "ru": "Цветок",
-            "si": null,
-            "sk": "Tulipán",
-            "sq": "Lule",
-            "sr": "цвет",
-            "sv": "Blomma",
-            "szl": null,
-            "tzm": null,
-            "uk": "Квітка",
-            "vi": "Hoa",
-            "zh_Hans": "花"
-        }
-    },
-    {
-        "number": 16,
-        "emoji": "🌳",
-        "description": "Tree",
-        "unicode": "U+1F333",
-        "translated_descriptions": {
-            "ar": "شَجَرَة",
-            "bg": "Дърво",
-            "ca": "Arbre",
-            "cs": "Strom",
-            "de": "Baum",
-            "eo": "Arbo",
-            "es": "Árbol",
-            "et": "Puu",
-            "fi": "Puu",
-            "fr": "Arbre",
-            "hr": "drvo",
-            "hu": "Fa",
-            "id": "Pohon",
-            "it": "Albero",
-            "ja": "木",
-            "nb_NO": "Tre",
-            "nl": "Boom",
-            "pt_BR": "Árvore",
-            "ru": "Дерево",
-            "si": null,
-            "sk": "Listnatý strom",
-            "sq": "Pemë",
-            "sr": "дрво",
-            "sv": "Träd",
-            "szl": null,
-            "tzm": "Aseklu",
-            "uk": "Дерево",
-            "vi": "Cây",
-            "zh_Hans": "树"
-        }
-    },
-    {
-        "number": 17,
-        "emoji": "🌵",
-        "description": "Cactus",
-        "unicode": "U+1F335",
-        "translated_descriptions": {
-            "ar": "صبار",
-            "bg": "Кактус",
-            "ca": "Cactus",
-            "cs": "Kaktus",
-            "de": "Kaktus",
-            "eo": "Kakto",
-            "es": "Cactus",
-            "et": "Kaktus",
-            "fi": "Kaktus",
-            "fr": "Cactus",
-            "hr": "kaktus",
-            "hu": "Kaktusz",
-            "id": "Kaktus",
-            "it": "Cactus",
-            "ja": "サボテン",
-            "nb_NO": "Kaktus",
-            "nl": "Cactus",
-            "pt_BR": "Cacto",
-            "ru": "Кактус",
-            "si": null,
-            "sk": "Kaktus",
-            "sq": "Kaktus",
-            "sr": "кактус",
-            "sv": "Kaktus",
-            "szl": null,
-            "tzm": null,
-            "uk": "Кактус",
-            "vi": "Xương rồng",
-            "zh_Hans": "仙人掌"
-        }
-    },
-    {
-        "number": 18,
-        "emoji": "🍄",
-        "description": "Mushroom",
-        "unicode": "U+1F344",
-        "translated_descriptions": {
-            "ar": "فُطر",
-            "bg": "Гъба",
-            "ca": "Bolet",
-            "cs": "Houba",
-            "de": "Pilz",
-            "eo": "Fungo",
-            "es": "Seta",
-            "et": "Seen",
-            "fi": "Sieni",
-            "fr": "Champignon",
-            "hr": "gljiva",
-            "hu": "Gomba",
-            "id": "Jamur",
-            "it": "Fungo",
-            "ja": "きのこ",
-            "nb_NO": "Sopp",
-            "nl": "Paddenstoel",
-            "pt_BR": "Cogumelo",
-            "ru": "Гриб",
-            "si": null,
-            "sk": "Huba",
-            "sq": "Kërpudhë",
-            "sr": "печурка",
-            "sv": "Svamp",
-            "szl": null,
-            "tzm": "Agursel",
-            "uk": "Гриб",
-            "vi": "Nấm",
-            "zh_Hans": "蘑菇"
-        }
-    },
-    {
-        "number": 19,
-        "emoji": "🌏",
-        "description": "Globe",
-        "unicode": "U+1F30F",
-        "translated_descriptions": {
-            "ar": "كُرَةٌ أرضِيَّة",
-            "bg": "Глобус",
-            "ca": "Globus terraqüi",
-            "cs": "Zeměkoule",
-            "de": "Globus",
-            "eo": "Globo",
-            "es": "Globo",
-            "et": "Maakera",
-            "fi": "Maapallo",
-            "fr": "Globe",
-            "hr": "Globus",
-            "hu": "Földgömb",
-            "id": "Bola Dunia",
-            "it": "Globo",
-            "ja": "地球",
-            "nb_NO": "Globus",
-            "nl": "Wereldbol",
-            "pt_BR": "Globo",
-            "ru": "Глобус",
-            "si": null,
-            "sk": "Zemeguľa",
-            "sq": "Rruzull",
-            "sr": "глобус",
-            "sv": "Jordklot",
-            "szl": null,
-            "tzm": null,
-            "uk": "Глобус",
-            "vi": "Địa cầu",
-            "zh_Hans": "地球"
-        }
-    },
-    {
-        "number": 20,
-        "emoji": "🌙",
-        "description": "Moon",
-        "unicode": "U+1F319",
-        "translated_descriptions": {
-            "ar": "قَمَر",
-            "bg": "Луна",
-            "ca": "Lluna",
-            "cs": "Měsíc",
-            "de": "Mond",
-            "eo": "Luno",
-            "es": "Luna",
-            "et": "Kuu",
-            "fi": "Kuu",
-            "fr": "Lune",
-            "hr": "mjesec",
-            "hu": "Hold",
-            "id": "Bulan",
-            "it": "Luna",
-            "ja": "月",
-            "nb_NO": "Måne",
-            "nl": "Maan",
-            "pt_BR": "Lua",
-            "ru": "Луна",
-            "si": null,
-            "sk": "Polmesiac",
-            "sq": "Hënë",
-            "sr": "месец",
-            "sv": "Måne",
-            "szl": null,
-            "tzm": "Ayyur",
-            "uk": "Місяць",
-            "vi": "Mặt trăng",
-            "zh_Hans": "月亮"
-        }
-    },
-    {
-        "number": 21,
-        "emoji": "☁️",
-        "description": "Cloud",
-        "unicode": "U+2601U+FE0F",
-        "translated_descriptions": {
-            "ar": "سَحابَة",
-            "bg": "Облак",
-            "ca": "Núvol",
-            "cs": "Mrak",
-            "de": "Wolke",
-            "eo": "Nubo",
-            "es": "Nube",
-            "et": "Pilv",
-            "fi": "Pilvi",
-            "fr": "Nuage",
-            "hr": "oblak",
-            "hu": "Felhő",
-            "id": "Awan",
-            "it": "Nuvola",
-            "ja": "雲",
-            "nb_NO": "Sky",
-            "nl": "Wolk",
-            "pt_BR": "Nuvem",
-            "ru": "Облако",
-            "si": null,
-            "sk": "Oblak",
-            "sq": "Re",
-            "sr": "облак",
-            "sv": "Moln",
-            "szl": null,
-            "tzm": null,
-            "uk": "Хмара",
-            "vi": "Mây",
-            "zh_Hans": "云"
-        }
-    },
-    {
-        "number": 22,
-        "emoji": "🔥",
-        "description": "Fire",
-        "unicode": "U+1F525",
-        "translated_descriptions": {
-            "ar": "نار",
-            "bg": "Огън",
-            "ca": "Foc",
-            "cs": "Oheň",
-            "de": "Feuer",
-            "eo": "Fajro",
-            "es": "Fuego",
-            "et": "Tuli",
-            "fi": "Tuli",
-            "fr": "Feu",
-            "hr": "vatra",
-            "hu": "Tűz",
-            "id": "Api",
-            "it": "Fuoco",
-            "ja": "炎",
-            "nb_NO": "Flamme",
-            "nl": "Vuur",
-            "pt_BR": "Fogo",
-            "ru": "Огонь",
-            "si": null,
-            "sk": "Oheň",
-            "sq": "Zjarr",
-            "sr": "ватра",
-            "sv": "Eld",
-            "szl": null,
-            "tzm": "Timessi",
-            "uk": "Вогонь",
-            "vi": "Lửa",
-            "zh_Hans": "火"
-        }
-    },
-    {
-        "number": 23,
-        "emoji": "🍌",
-        "description": "Banana",
-        "unicode": "U+1F34C",
-        "translated_descriptions": {
-            "ar": "مَوزَة",
-            "bg": "Банан",
-            "ca": "Plàtan",
-            "cs": "Banán",
-            "de": "Banane",
-            "eo": "Banano",
-            "es": "Plátano",
-            "et": "Banaan",
-            "fi": "Banaani",
-            "fr": "Banane",
-            "hr": "banana",
-            "hu": "Banán",
-            "id": "Pisang",
-            "it": "Banana",
-            "ja": "バナナ",
-            "nb_NO": "Banan",
-            "nl": "Banaan",
-            "pt_BR": "Banana",
-            "ru": "Банан",
-            "si": null,
-            "sk": "Banán",
-            "sq": "Banane",
-            "sr": "банана",
-            "sv": "Banan",
-            "szl": null,
-            "tzm": "Tabanant",
-            "uk": "Банан",
-            "vi": "Chuối",
-            "zh_Hans": "香蕉"
-        }
-    },
-    {
-        "number": 24,
-        "emoji": "🍎",
-        "description": "Apple",
-        "unicode": "U+1F34E",
-        "translated_descriptions": {
-            "ar": "تُفَّاحَة",
-            "bg": "Ябълка",
-            "ca": "Poma",
-            "cs": "Jablko",
-            "de": "Apfel",
-            "eo": "Pomo",
-            "es": "Manzana",
-            "et": "Õun",
-            "fi": "Omena",
-            "fr": "Pomme",
-            "hr": "jabuka",
-            "hu": "Alma",
-            "id": "Apel",
-            "it": "Mela",
-            "ja": "リンゴ",
-            "nb_NO": "Eple",
-            "nl": "Appel",
-            "pt_BR": "Maçã",
-            "ru": "Яблоко",
-            "si": null,
-            "sk": "Červené jablko",
-            "sq": "Mollë",
-            "sr": "јабука",
-            "sv": "Äpple",
-            "szl": null,
-            "tzm": "Tadeffuyt",
-            "uk": "Яблуко",
-            "vi": "Táo",
-            "zh_Hans": "苹果"
-        }
-    },
-    {
-        "number": 25,
-        "emoji": "🍓",
-        "description": "Strawberry",
-        "unicode": "U+1F353",
-        "translated_descriptions": {
-            "ar": "فَراوِلَة",
-            "bg": "Ягода",
-            "ca": "Maduixa",
-            "cs": "Jahoda",
-            "de": "Erdbeere",
-            "eo": "Frago",
-            "es": "Fresa",
-            "et": "Maasikas",
-            "fi": "Mansikka",
-            "fr": "Fraise",
-            "hr": "jagoda",
-            "hu": "Eper",
-            "id": "Stroberi",
-            "it": "Fragola",
-            "ja": "いちご",
-            "nb_NO": "Jordbær",
-            "nl": "Aardbei",
-            "pt_BR": "Morango",
-            "ru": "Клубника",
-            "si": null,
-            "sk": "Jahoda",
-            "sq": "Luleshtrydhe",
-            "sr": "јагода",
-            "sv": "Jordgubbe",
-            "szl": null,
-            "tzm": null,
-            "uk": "Полуниця",
-            "vi": "Dâu tây",
-            "zh_Hans": "草莓"
-        }
-    },
-    {
-        "number": 26,
-        "emoji": "🌽",
-        "description": "Corn",
-        "unicode": "U+1F33D",
-        "translated_descriptions": {
-            "ar": "ذُرَة",
-            "bg": "Царевица",
-            "ca": "Blat de moro",
-            "cs": "Kukuřice",
-            "de": "Mais",
-            "eo": "Maizo",
-            "es": "Maíz",
-            "et": "Mais",
-            "fi": "Maissi",
-            "fr": "Maïs",
-            "hr": "kukuruza",
-            "hu": "Kukorica",
-            "id": "Jagung",
-            "it": "Mais",
-            "ja": "とうもろこし",
-            "nb_NO": "Mais",
-            "nl": "Maïs",
-            "pt_BR": "Milho",
-            "ru": "Кукуруза",
-            "si": null,
-            "sk": "Kukuričný klas",
-            "sq": "Misër",
-            "sr": "кукуруз",
-            "sv": "Majs",
-            "szl": null,
-            "tzm": null,
-            "uk": "Кукурудза",
-            "vi": "Bắp",
-            "zh_Hans": "玉米"
-        }
-    },
-    {
-        "number": 27,
-        "emoji": "🍕",
-        "description": "Pizza",
-        "unicode": "U+1F355",
-        "translated_descriptions": {
-            "ar": "بِيتزا",
-            "bg": "Пица",
-            "ca": "Pizza",
-            "cs": "Pizza",
-            "de": "Pizza",
-            "eo": "Pico",
-            "es": "Pizza",
-            "et": "Pitsa",
-            "fi": "Pizza",
-            "fr": "Pizza",
-            "hr": "pizza",
-            "hu": "Pizza",
-            "id": "Pizza",
-            "it": "Pizza",
-            "ja": "ピザ",
-            "nb_NO": "Pizza",
-            "nl": "Pizza",
-            "pt_BR": "Pizza",
-            "ru": "Пицца",
-            "si": null,
-            "sk": "Pizza",
-            "sq": "Picë",
-            "sr": "пица",
-            "sv": "Pizza",
-            "szl": null,
-            "tzm": null,
-            "uk": "Піца",
-            "vi": "Pizza",
-            "zh_Hans": "披萨"
-        }
-    },
-    {
-        "number": 28,
-        "emoji": "🎂",
-        "description": "Cake",
-        "unicode": "U+1F382",
-        "translated_descriptions": {
-            "ar": "كَعكَة",
-            "bg": "Торта",
-            "ca": "Pastís",
-            "cs": "Dort",
-            "de": "Kuchen",
-            "eo": "Torto",
-            "es": "Tarta",
-            "et": "Kook",
-            "fi": "Kakku",
-            "fr": "Gâteau",
-            "hr": "torta",
-            "hu": "Süti",
-            "id": "Kue",
-            "it": "Torta",
-            "ja": "ケーキ",
-            "nb_NO": "Kake",
-            "nl": "Taart",
-            "pt_BR": "Bolo",
-            "ru": "Торт",
-            "si": null,
-            "sk": "Narodeninová torta",
-            "sq": "Tortë",
-            "sr": "торта",
-            "sv": "Tårta",
-            "szl": null,
-            "tzm": null,
-            "uk": "Пиріг",
-            "vi": "Bánh",
-            "zh_Hans": "蛋糕"
-        }
-    },
-    {
-        "number": 29,
-        "emoji": "❤️",
-        "description": "Heart",
-        "unicode": "U+2764U+FE0F",
-        "translated_descriptions": {
-            "ar": "قَلب",
-            "bg": "Сърце",
-            "ca": "Cor",
-            "cs": "Srdce",
-            "de": "Herz",
-            "eo": "Koro",
-            "es": "Corazón",
-            "et": "Süda",
-            "fi": "Sydän",
-            "fr": "Cœur",
-            "hr": "srca",
-            "hu": "Szív",
-            "id": "Hati",
-            "it": "Cuore",
-            "ja": "ハート",
-            "nb_NO": "Hjerte",
-            "nl": "Hart",
-            "pt_BR": "Coração",
-            "ru": "Сердце",
-            "si": null,
-            "sk": "červené srdce",
-            "sq": "Zemër",
-            "sr": "срце",
-            "sv": "Hjärta",
-            "szl": null,
-            "tzm": "Ul",
-            "uk": "Серце",
-            "vi": "Tim",
-            "zh_Hans": "心"
-        }
-    },
-    {
-        "number": 30,
-        "emoji": "😀",
-        "description": "Smiley",
-        "unicode": "U+1F600",
-        "translated_descriptions": {
-            "ar": "اِبتِسَامَة",
-            "bg": "Усмивка",
-            "ca": "Somrient",
-            "cs": "Smajlík",
-            "de": "Lächeln",
-            "eo": "Rideto",
-            "es": "Emoticono",
-            "et": "Smaili",
-            "fi": "Hymynaama",
-            "fr": "Sourire",
-            "hr": "smajlića",
-            "hu": "Mosoly",
-            "id": "Senyuman",
-            "it": "Faccina sorridente",
-            "ja": "スマイル",
-            "nb_NO": "Smilefjes",
-            "nl": "Smiley",
-            "pt_BR": "Sorriso",
-            "ru": "Улыбка",
-            "si": null,
-            "sk": "Škeriaca sa tvár",
-            "sq": "Emotikon",
-            "sr": "смајли",
-            "sv": "Smiley",
-            "szl": null,
-            "tzm": null,
-            "uk": "Посмішка",
-            "vi": "Mặt cười",
-            "zh_Hans": "笑脸"
-        }
-    },
-    {
-        "number": 31,
-        "emoji": "🤖",
-        "description": "Robot",
-        "unicode": "U+1F916",
-        "translated_descriptions": {
-            "ar": "رُوبُوت",
-            "bg": "Робот",
-            "ca": "Robot",
-            "cs": "Robot",
-            "de": "Roboter",
-            "eo": "Roboto",
-            "es": "Robot",
-            "et": "Robot",
-            "fi": "Robotti",
-            "fr": "Robot",
-            "hr": "robot",
-            "hu": "Robot",
-            "id": "Robot",
-            "it": "Robot",
-            "ja": "ロボと",
-            "nb_NO": "Robot",
-            "nl": "Robot",
-            "pt_BR": "Robô",
-            "ru": "Робот",
-            "si": null,
-            "sk": "Robot",
-            "sq": "Robot",
-            "sr": "робот",
-            "sv": "Robot",
-            "szl": null,
-            "tzm": "Aṛubu",
-            "uk": "Робот",
-            "vi": "Rô-bô",
-            "zh_Hans": "机器人"
-        }
-    },
-    {
-        "number": 32,
-        "emoji": "🎩",
-        "description": "Hat",
-        "unicode": "U+1F3A9",
-        "translated_descriptions": {
-            "ar": "قُبَّعَة",
-            "bg": "Шапка",
-            "ca": "Barret",
-            "cs": "Klobouk",
-            "de": "Hut",
-            "eo": "Ĉapelo",
-            "es": "Sombrero",
-            "et": "Kübar",
-            "fi": "Hattu",
-            "fr": "Chapeau",
-            "hr": "kapa",
-            "hu": "Kalap",
-            "id": "Topi",
-            "it": "Cappello",
-            "ja": "帽子",
-            "nb_NO": "Hatt",
-            "nl": "Hoed",
-            "pt_BR": "Chapéu",
-            "ru": "Шляпа",
-            "si": null,
-            "sk": "Cilinder",
-            "sq": "Kapë",
-            "sr": "шешир",
-            "sv": "Hatt",
-            "szl": null,
-            "tzm": "Taraza",
-            "uk": "Капелюх",
-            "vi": "Nón",
-            "zh_Hans": "帽子"
-        }
-    },
-    {
-        "number": 33,
-        "emoji": "👓",
-        "description": "Glasses",
-        "unicode": "U+1F453",
-        "translated_descriptions": {
-            "ar": "نَظَّارَة",
-            "bg": "Очила",
-            "ca": "Ulleres",
-            "cs": "Brýle",
-            "de": "Brille",
-            "eo": "Okulvitroj",
-            "es": "Gafas",
-            "et": "Prillid",
-            "fi": "Silmälasit",
-            "fr": "Lunettes",
-            "hr": "naočale",
-            "hu": "Szemüveg",
-            "id": "Kacamata",
-            "it": "Occhiali",
-            "ja": "めがね",
-            "nb_NO": "Briller",
-            "nl": "Bril",
-            "pt_BR": "Óculos",
-            "ru": "Очки",
-            "si": null,
-            "sk": "Okuliare",
-            "sq": "Syze",
-            "sr": "наочаре",
-            "sv": "Glasögon",
-            "szl": null,
-            "tzm": null,
-            "uk": "Окуляри",
-            "vi": "Mắt kiếng",
-            "zh_Hans": "眼镜"
-        }
-    },
-    {
-        "number": 34,
-        "emoji": "🔧",
-        "description": "Spanner",
-        "unicode": "U+1F527",
-        "translated_descriptions": {
-            "ar": "مِفتَاحُ رَبط",
-            "bg": "Гаечен ключ",
-            "ca": "Clau anglesa",
-            "cs": "Klíč",
-            "de": "Schraubenschlüssel",
-            "eo": "Ŝraŭbŝlosilo",
-            "es": "Llave inglesa",
-            "et": "Mutrivõti",
-            "fi": "Kiintoavain",
-            "fr": "Clé à molette",
-            "hr": "ključ",
-            "hu": "Csavarkulcs",
-            "id": "Kunci Bengkel",
-            "it": "Chiave inglese",
-            "ja": "スパナ",
-            "nb_NO": "Fastnøkkel",
-            "nl": "Moersleutel",
-            "pt_BR": "Chave inglesa",
-            "ru": "Ключ",
-            "si": null,
-            "sk": "Francúzsky kľúč",
-            "sq": "Çelës",
-            "sr": "кључ",
-            "sv": "Skruvnyckel",
-            "szl": null,
-            "tzm": null,
-            "uk": "Гайковий ключ",
-            "vi": "Cờ-lê",
-            "zh_Hans": "扳手"
-        }
-    },
-    {
-        "number": 35,
-        "emoji": "🎅",
-        "description": "Santa",
-        "unicode": "U+1F385",
-        "translated_descriptions": {
-            "ar": "سانتا",
-            "bg": "Дядо Коледа",
-            "ca": "Pare Noél",
-            "cs": "Mikuláš",
-            "de": "Weihnachtsmann",
-            "eo": "Kristnaska viro",
-            "es": "Papá Noel",
-            "et": "Jõuluvana",
-            "fi": "Joulupukki",
-            "fr": "Père Noël",
-            "hr": "deda Mraz",
-            "hu": "Télapó",
-            "id": "Santa",
-            "it": "Babbo Natale",
-            "ja": "サンタ",
-            "nb_NO": "Julenisse",
-            "nl": "Kerstman",
-            "pt_BR": "Papai-noel",
-            "ru": "Санта",
-            "si": null,
-            "sk": "Santa Claus",
-            "sq": "Babagjyshi i Vitit të Ri",
-            "sr": "деда Мраз",
-            "sv": "Tomte",
-            "szl": null,
-            "tzm": null,
-            "uk": "Санта Клаус",
-            "vi": "ông già Noel",
-            "zh_Hans": "圣诞老人"
-        }
-    },
-    {
-        "number": 36,
-        "emoji": "👍",
-        "description": "Thumbs Up",
-        "unicode": "U+1F44D",
-        "translated_descriptions": {
-            "ar": "رَفعُ إِبهَام",
-            "bg": "Палец нагоре",
-            "ca": "Polzes amunt",
-            "cs": "Palec nahoru",
-            "de": "Daumen Hoch",
-            "eo": "Dikfingro supren",
-            "es": "Pulgar arriba",
-            "et": "Pöidlad püsti",
-            "fi": "Peukalo ylös",
-            "fr": "Pouce en l’air",
-            "hr": "palac gore",
-            "hu": "Hüvelykujj fel",
-            "id": "Jempol",
-            "it": "Pollice alzato",
-            "ja": "いいね",
-            "nb_NO": "Tommel Opp",
-            "nl": "Duim omhoog",
-            "pt_BR": "Joinha",
-            "ru": "Большой палец вверх",
-            "si": null,
-            "sk": "Palec nahor",
-            "sq": null,
-            "sr": "палчић горе",
-            "sv": "Tummen upp",
-            "szl": null,
-            "tzm": null,
-            "uk": "Великий палець вгору",
-            "vi": "Thích",
-            "zh_Hans": "赞"
-        }
-    },
-    {
-        "number": 37,
-        "emoji": "☂️",
-        "description": "Umbrella",
-        "unicode": "U+2602U+FE0F",
-        "translated_descriptions": {
-            "ar": "مِظَلَّة",
-            "bg": "Чадър",
-            "ca": "Paraigües",
-            "cs": "Deštník",
-            "de": "Regenschirm",
-            "eo": "Ombrelo",
-            "es": "Paraguas",
-            "et": "Vihmavari",
-            "fi": "Sateenvarjo",
-            "fr": "Parapluie",
-            "hr": "kišobran",
-            "hu": "Esernyő",
-            "id": "Payung",
-            "it": "Ombrello",
-            "ja": "傘",
-            "nb_NO": "Paraply",
-            "nl": "Paraplu",
-            "pt_BR": "Guarda-chuva",
-            "ru": "Зонт",
-            "si": null,
-            "sk": "Dáždnik",
-            "sq": "Ombrellë",
-            "sr": "кишобран",
-            "sv": "Paraply",
-            "szl": null,
-            "tzm": null,
-            "uk": "Парасолька",
-            "vi": "Cây dù",
-            "zh_Hans": "伞"
-        }
-    },
-    {
-        "number": 38,
-        "emoji": "⌛",
-        "description": "Hourglass",
-        "unicode": "U+231B",
-        "translated_descriptions": {
-            "ar": "سَاعَةٌ رَملِيَّة",
-            "bg": "Пясъчен часовник",
-            "ca": "Rellotge de sorra",
-            "cs": "Přesýpací hodiny",
-            "de": "Sanduhr",
-            "eo": "Sablohorloĝo",
-            "es": "Reloj de arena",
-            "et": "Liivakell",
-            "fi": "Tiimalasi",
-            "fr": "Sablier",
-            "hr": "pješčani sat",
-            "hu": "Homokóra",
-            "id": "Jam Pasir",
-            "it": "Clessidra",
-            "ja": "砂時計",
-            "nb_NO": "Timeglass",
-            "nl": "Zandloper",
-            "pt_BR": "Ampulheta",
-            "ru": "Песочные часы",
-            "si": null,
-            "sk": "Presýpacie hodiny",
-            "sq": "Klepsidër",
-            "sr": "пешчаник",
-            "sv": "Timglas",
-            "szl": null,
-            "tzm": null,
-            "uk": "Пісковий годинник",
-            "vi": "Đồng hồ cát",
-            "zh_Hans": "沙漏"
-        }
-    },
-    {
-        "number": 39,
-        "emoji": "⏰",
-        "description": "Clock",
-        "unicode": "U+23F0",
-        "translated_descriptions": {
-            "ar": "سَاعَة",
-            "bg": "Часовник",
-            "ca": "Rellotge",
-            "cs": "Hodiny",
-            "de": "Uhr",
-            "eo": "Horloĝo",
-            "es": "Reloj",
-            "et": "Kell",
-            "fi": "Pöytäkello",
-            "fr": "Réveil",
-            "hr": "sat",
-            "hu": "Óra",
-            "id": "Jam",
-            "it": "Orologio",
-            "ja": "時計",
-            "nb_NO": "Klokke",
-            "nl": "Wekker",
-            "pt_BR": "Relógio",
-            "ru": "Часы",
-            "si": null,
-            "sk": "Budík",
-            "sq": "Sahat",
-            "sr": "сат",
-            "sv": "Klocka",
-            "szl": null,
-            "tzm": null,
-            "uk": "Годинник",
-            "vi": "Đồng hồ",
-            "zh_Hans": "时钟"
-        }
-    },
-    {
-        "number": 40,
-        "emoji": "🎁",
-        "description": "Gift",
-        "unicode": "U+1F381",
-        "translated_descriptions": {
-            "ar": "هَدِيَّة",
-            "bg": "Подарък",
-            "ca": "Regal",
-            "cs": "Dárek",
-            "de": "Geschenk",
-            "eo": "Donaco",
-            "es": "Regalo",
-            "et": "Kingitus",
-            "fi": "Lahja",
-            "fr": "Cadeau",
-            "hr": "poklon",
-            "hu": "Ajándék",
-            "id": "Kado",
-            "it": "Regalo",
-            "ja": "ギフト",
-            "nb_NO": "Gave",
-            "nl": "Geschenk",
-            "pt_BR": "Presente",
-            "ru": "Подарок",
-            "si": null,
-            "sk": "Zabalený darček",
-            "sq": "Dhuratë",
-            "sr": "поклон",
-            "sv": "Present",
-            "szl": null,
-            "tzm": null,
-            "uk": "Подарунок",
-            "vi": "Quà",
-            "zh_Hans": "礼物"
-        }
-    },
-    {
-        "number": 41,
-        "emoji": "💡",
-        "description": "Light Bulb",
-        "unicode": "U+1F4A1",
-        "translated_descriptions": {
-            "ar": "مِصبَاح",
-            "bg": "Лампа",
-            "ca": "Bombeta",
-            "cs": "Žárovka",
-            "de": "Glühbirne",
-            "eo": "Lampo",
-            "es": "Bombilla",
-            "et": "Lambipirn",
-            "fi": "Hehkulamppu",
-            "fr": "Ampoule",
-            "hr": "žarulja",
-            "hu": "Égő",
-            "id": "Bohlam Lampu",
-            "it": "Lampadina",
-            "ja": "電球",
-            "nb_NO": "Lyspære",
-            "nl": "Gloeilamp",
-            "pt_BR": "Lâmpada",
-            "ru": "Лампочка",
-            "si": null,
-            "sk": "Žiarovka",
-            "sq": "Llambë",
-            "sr": "сијалица",
-            "sv": "Lampa",
-            "szl": null,
-            "tzm": null,
-            "uk": "Лампочка",
-            "vi": "Bóng đèn tròn",
-            "zh_Hans": "灯泡"
-        }
-    },
-    {
-        "number": 42,
-        "emoji": "📕",
-        "description": "Book",
-        "unicode": "U+1F4D5",
-        "translated_descriptions": {
-            "ar": "كِتَاب",
-            "bg": "Книга",
-            "ca": "Llibre",
-            "cs": "Kniha",
-            "de": "Buch",
-            "eo": "Libro",
-            "es": "Libro",
-            "et": "Raamat",
-            "fi": "Kirja",
-            "fr": "Livre",
-            "hr": "knjiga",
-            "hu": "Könyv",
-            "id": "Buku",
-            "it": "Libro",
-            "ja": "本",
-            "nb_NO": "Bok",
-            "nl": "Boek",
-            "pt_BR": "Livro",
-            "ru": "Книга",
-            "si": null,
-            "sk": "Zatvorená kniha",
-            "sq": "Libër",
-            "sr": "књига",
-            "sv": "Bok",
-            "szl": null,
-            "tzm": "Adlis",
-            "uk": "Книга",
-            "vi": "Sách",
-            "zh_Hans": "书"
-        }
-    },
-    {
-        "number": 43,
-        "emoji": "✏️",
-        "description": "Pencil",
-        "unicode": "U+270FU+FE0F",
-        "translated_descriptions": {
-            "ar": "قَلَمُ رَصاص",
-            "bg": "Молив",
-            "ca": "Llapis",
-            "cs": "Tužka",
-            "de": "Bleistift",
-            "eo": "Krajono",
-            "es": "Lápiz",
-            "et": "Pliiats",
-            "fi": "Lyijykynä",
-            "fr": "Crayon",
-            "hr": "olovka",
-            "hu": "Ceruza",
-            "id": "Pensil",
-            "it": "Matita",
-            "ja": "鉛筆",
-            "nb_NO": "Blyant",
-            "nl": "Potlood",
-            "pt_BR": "Lápis",
-            "ru": "Карандаш",
-            "si": null,
-            "sk": "Ceruzka",
-            "sq": "Laps",
-            "sr": "оловка",
-            "sv": "Penna",
-            "szl": null,
-            "tzm": null,
-            "uk": "Олівець",
-            "vi": "Viết chì",
-            "zh_Hans": "铅笔"
-        }
-    },
-    {
-        "number": 44,
-        "emoji": "📎",
-        "description": "Paperclip",
-        "unicode": "U+1F4CE",
-        "translated_descriptions": {
-            "ar": "مِشبَكُ وَرَق",
-            "bg": "Кламер",
-            "ca": "Clip",
-            "cs": "Sponka",
-            "de": "Büroklammer",
-            "eo": "Paperkuntenilo",
-            "es": "Clip",
-            "et": "Kirjaklamber",
-            "fi": "Paperiliitin",
-            "fr": "Trombone",
-            "hr": "spajalica",
-            "hu": "Gémkapocs",
-            "id": "Klip Kertas",
-            "it": "Graffetta",
-            "ja": "クリップ",
-            "nb_NO": "BInders",
-            "nl": "Papierklemmetje",
-            "pt_BR": "Clipe de papel",
-            "ru": "Скрепка",
-            "si": null,
-            "sk": "Sponka na papier",
-            "sq": "Kapëse",
-            "sr": "спајалица",
-            "sv": "Gem",
-            "szl": null,
-            "tzm": null,
-            "uk": "Спиначка",
-            "vi": "Kẹp giấy",
-            "zh_Hans": "回形针"
-        }
-    },
-    {
-        "number": 45,
-        "emoji": "✂️",
-        "description": "Scissors",
-        "unicode": "U+2702U+FE0F",
-        "translated_descriptions": {
-            "ar": "مِقَصّ",
-            "bg": "Ножици",
-            "ca": "Tisores",
-            "cs": "Nůžky",
-            "de": "Schere",
-            "eo": "Tondilo",
-            "es": "Tijeras",
-            "et": "Käärid",
-            "fi": "Sakset",
-            "fr": "Ciseaux",
-            "hr": "škare",
-            "hu": "Olló",
-            "id": "Gunting",
-            "it": "Forbici",
-            "ja": "はさみ",
-            "nb_NO": "Saks",
-            "nl": "Schaar",
-            "pt_BR": "Tesoura",
-            "ru": "Ножницы",
-            "si": null,
-            "sk": "Nožnice",
-            "sq": "Gërshërë",
-            "sr": "маказе",
-            "sv": "Sax",
-            "szl": null,
-            "tzm": null,
-            "uk": "Ножиці",
-            "vi": "Cây kéo",
-            "zh_Hans": "剪刀"
-        }
-    },
-    {
-        "number": 46,
-        "emoji": "🔒",
-        "description": "Lock",
-        "unicode": "U+1F512",
-        "translated_descriptions": {
-            "ar": "قُفل",
-            "bg": "Катинар",
-            "ca": "Cadenat",
-            "cs": "Zámek",
-            "de": "Schloss",
-            "eo": "Seruro",
-            "es": "Candado",
-            "et": "Lukk",
-            "fi": "Lukko",
-            "fr": "Cadenas",
-            "hr": "zaključati",
-            "hu": "Lakat",
-            "id": "Gembok",
-            "it": "Lucchetto",
-            "ja": "錠前",
-            "nb_NO": "Lås",
-            "nl": "Slot",
-            "pt_BR": "Cadeado",
-            "ru": "Замок",
-            "si": null,
-            "sk": "Zatvorená zámka",
-            "sq": "Dry",
-            "sr": "катанац",
-            "sv": "Lås",
-            "szl": null,
-            "tzm": null,
-            "uk": "Замок",
-            "vi": "Ổ khóa",
-            "zh_Hans": "锁"
-        }
-    },
-    {
-        "number": 47,
-        "emoji": "🔑",
-        "description": "Key",
-        "unicode": "U+1F511",
-        "translated_descriptions": {
-            "ar": "مِفتَاح",
-            "bg": "Ключ",
-            "ca": "Clau",
-            "cs": "Klíč",
-            "de": "Schlüssel",
-            "eo": "Ŝlosilo",
-            "es": "Llave",
-            "et": "Võti",
-            "fi": "Avain",
-            "fr": "Clé",
-            "hr": "ključ",
-            "hu": "Kulcs",
-            "id": "Kunci",
-            "it": "Chiave",
-            "ja": "鍵",
-            "nb_NO": "Nøkkel",
-            "nl": "Sleutel",
-            "pt_BR": "Chave",
-            "ru": "Ключ",
-            "si": null,
-            "sk": "Kľúč",
-            "sq": "Çelës",
-            "sr": "кључ",
-            "sv": "Nyckel",
-            "szl": null,
-            "tzm": "Tasarut",
-            "uk": "Ключ",
-            "vi": "Chìa khóa",
-            "zh_Hans": "钥匙"
-        }
-    },
-    {
-        "number": 48,
-        "emoji": "🔨",
-        "description": "Hammer",
-        "unicode": "U+1F528",
-        "translated_descriptions": {
-            "ar": "مِطرَقَة",
-            "bg": "Чук",
-            "ca": "Martell",
-            "cs": "Kladivo",
-            "de": "Hammer",
-            "eo": "Martelo",
-            "es": "Martillo",
-            "et": "Haamer",
-            "fi": "Vasara",
-            "fr": "Marteau",
-            "hr": "čekić",
-            "hu": "Kalapács",
-            "id": "Palu",
-            "it": "Martello",
-            "ja": "金槌",
-            "nb_NO": "Hammer",
-            "nl": "Hamer",
-            "pt_BR": "Martelo",
-            "ru": "Молоток",
-            "si": null,
-            "sk": "Kladivo",
-            "sq": "Çekiç",
-            "sr": "чекић",
-            "sv": "Hammare",
-            "szl": null,
-            "tzm": null,
-            "uk": "Молоток",
-            "vi": "Búa",
-            "zh_Hans": "锤子"
-        }
-    },
-    {
-        "number": 49,
-        "emoji": "☎️",
-        "description": "Telephone",
-        "unicode": "U+260EU+FE0F",
-        "translated_descriptions": {
-            "ar": "تِلِفُون",
-            "bg": "Телефон",
-            "ca": "Telèfon",
-            "cs": "Telefon",
-            "de": "Telefon",
-            "eo": "Telefono",
-            "es": "Telefono",
-            "et": "Telefon",
-            "fi": "Puhelin",
-            "fr": "Téléphone",
-            "hr": "telefon",
-            "hu": "Telefon",
-            "id": "Telepon",
-            "it": "Telefono",
-            "ja": "電話機",
-            "nb_NO": "Telefon",
-            "nl": "Telefoon",
-            "pt_BR": "Telefone",
-            "ru": "Телефон",
-            "si": null,
-            "sk": "Telefón",
-            "sq": "Telefon",
-            "sr": "телефон",
-            "sv": "Telefon",
-            "szl": null,
-            "tzm": "Atilifun",
-            "uk": "Телефон",
-            "vi": "Điện thoại",
-            "zh_Hans": "电话"
-        }
-    },
-    {
-        "number": 50,
-        "emoji": "🏁",
-        "description": "Flag",
-        "unicode": "U+1F3C1",
-        "translated_descriptions": {
-            "ar": "عَلَم",
-            "bg": "Флаг",
-            "ca": "Bandera",
-            "cs": "Vlajka",
-            "de": "Flagge",
-            "eo": "Flago",
-            "es": "Bandera",
-            "et": "Lipp",
-            "fi": "Lippu",
-            "fr": "Drapeau",
-            "hr": "zastava",
-            "hu": "Zászló",
-            "id": "Bendera",
-            "it": "Bandiera",
-            "ja": "旗",
-            "nb_NO": "Flagg",
-            "nl": "Vlag",
-            "pt_BR": "Bandeira",
-            "ru": "Флаг",
-            "si": null,
-            "sk": "Kockovaná zástava",
-            "sq": "Flamur",
-            "sr": "застава",
-            "sv": "Flagga",
-            "szl": null,
-            "tzm": "Acenyal",
-            "uk": "Прапор",
-            "vi": "Lá cờ",
-            "zh_Hans": "旗帜"
-        }
-    },
-    {
-        "number": 51,
-        "emoji": "🚂",
-        "description": "Train",
-        "unicode": "U+1F682",
-        "translated_descriptions": {
-            "ar": "قِطَار",
-            "bg": "Влак",
-            "ca": "Tren",
-            "cs": "Vlak",
-            "de": "Zug",
-            "eo": "Vagonaro",
-            "es": "Tren",
-            "et": "Rong",
-            "fi": "Juna",
-            "fr": "Train",
-            "hr": "vlak",
-            "hu": "Vonat",
-            "id": "Kereta Api",
-            "it": "Treno",
-            "ja": "電車",
-            "nb_NO": "Tog",
-            "nl": "Trein",
-            "pt_BR": "Trem",
-            "ru": "Поезд",
-            "si": null,
-            "sk": "Rušeň",
-            "sq": "Tren",
-            "sr": "воз",
-            "sv": "Tåg",
-            "szl": null,
-            "tzm": null,
-            "uk": "Потяг",
-            "vi": "Xe lửa",
-            "zh_Hans": "火车"
-        }
-    },
-    {
-        "number": 52,
-        "emoji": "🚲",
-        "description": "Bicycle",
-        "unicode": "U+1F6B2",
-        "translated_descriptions": {
-            "ar": "دَرّاجَة",
-            "bg": "Колело",
-            "ca": "Bicicleta",
-            "cs": "Kolo",
-            "de": "Fahrrad",
-            "eo": "Biciklo",
-            "es": "Bicicleta",
-            "et": "Jalgratas",
-            "fi": "Polkupyörä",
-            "fr": "Vélo",
-            "hr": "bicikl",
-            "hu": "Kerékpár",
-            "id": "Sepeda",
-            "it": "Bicicletta",
-            "ja": "自転車",
-            "nb_NO": "Sykkel",
-            "nl": "Fiets",
-            "pt_BR": "Bicicleta",
-            "ru": "Велосипед",
-            "si": null,
-            "sk": "Bicykel",
-            "sq": "Biçikletë",
-            "sr": "бицикл",
-            "sv": "Cykel",
-            "szl": null,
-            "tzm": null,
-            "uk": "Велосипед",
-            "vi": "Xe đạp",
-            "zh_Hans": "自行车"
-        }
-    },
-    {
-        "number": 53,
-        "emoji": "✈️",
-        "description": "Aeroplane",
-        "unicode": "U+2708U+FE0F",
-        "translated_descriptions": {
-            "ar": "طَائِرة",
-            "bg": "Самолет",
-            "ca": "Avió",
-            "cs": "Letadlo",
-            "de": "Flugzeug",
-            "eo": "Aviadilo",
-            "es": "Avión",
-            "et": "Lennuk",
-            "fi": "Lentokone",
-            "fr": "Avion",
-            "hr": "avion",
-            "hu": "Repülő",
-            "id": "Pesawat",
-            "it": "Aeroplano",
-            "ja": "飛行機",
-            "nb_NO": "Fly",
-            "nl": "Vliegtuig",
-            "pt_BR": "Avião",
-            "ru": "Самолет",
-            "si": null,
-            "sk": "Lietadlo",
-            "sq": "Avion",
-            "sr": "авион",
-            "sv": "Flygplan",
-            "szl": null,
-            "tzm": null,
-            "uk": "Літак",
-            "vi": "Máy bay",
-            "zh_Hans": "飞机"
-        }
-    },
-    {
-        "number": 54,
-        "emoji": "🚀",
-        "description": "Rocket",
-        "unicode": "U+1F680",
-        "translated_descriptions": {
-            "ar": "صَارُوخ",
-            "bg": "Ракета",
-            "ca": "Coet",
-            "cs": "Raketa",
-            "de": "Rakete",
-            "eo": "Raketo",
-            "es": "Cohete",
-            "et": "Rakett",
-            "fi": "Raketti",
-            "fr": "Fusée",
-            "hr": "raketa",
-            "hu": "Rakáta",
-            "id": "Roket",
-            "it": "Razzo",
-            "ja": "ロケット",
-            "nb_NO": "Rakett",
-            "nl": "Raket",
-            "pt_BR": "Foguete",
-            "ru": "Ракета",
-            "si": null,
-            "sk": "Raketa",
-            "sq": "Raketë",
-            "sr": "ракета",
-            "sv": "Raket",
-            "szl": null,
-            "tzm": null,
-            "uk": "Ракета",
-            "vi": "Tên lửa",
-            "zh_Hans": "火箭"
-        }
-    },
-    {
-        "number": 55,
-        "emoji": "🏆",
-        "description": "Trophy",
-        "unicode": "U+1F3C6",
-        "translated_descriptions": {
-            "ar": "كَأسُ النَّصر",
-            "bg": "Трофей",
-            "ca": "Trofeu",
-            "cs": "Pohár",
-            "de": "Pokal",
-            "eo": "Trofeo",
-            "es": "Trofeo",
-            "et": "Auhind",
-            "fi": "Palkinto",
-            "fr": "Trophée",
-            "hr": "trofej",
-            "hu": "Trófea",
-            "id": "Piala",
-            "it": "Trofeo",
-            "ja": "トロフィー",
-            "nb_NO": "Pokal",
-            "nl": "Trofee",
-            "pt_BR": "Troféu",
-            "ru": "Кубок",
-            "si": null,
-            "sk": "Trofej",
-            "sq": "Trofe",
-            "sr": "пехар",
-            "sv": "Trofé",
-            "szl": null,
-            "tzm": null,
-            "uk": "Приз",
-            "vi": "Cúp",
-            "zh_Hans": "奖杯"
-        }
-    },
-    {
-        "number": 56,
-        "emoji": "⚽",
-        "description": "Ball",
-        "unicode": "U+26BD",
-        "translated_descriptions": {
-            "ar": "كُرَة",
-            "bg": "Топка",
-            "ca": "Pilota",
-            "cs": "Míč",
-            "de": "Ball",
-            "eo": "Pilko",
-            "es": "Bola",
-            "et": "Pall",
-            "fi": "Pallo",
-            "fr": "Ballon",
-            "hr": "lopta",
-            "hu": "Labda",
-            "id": "Bola",
-            "it": "Palla",
-            "ja": "ボール",
-            "nb_NO": "Ball",
-            "nl": "Bal",
-            "pt_BR": "Bola",
-            "ru": "Мяч",
-            "si": null,
-            "sk": "Futbal",
-            "sq": "Top",
-            "sr": "лопта",
-            "sv": "Boll",
-            "szl": null,
-            "tzm": "Tcama",
-            "uk": "М'яч",
-            "vi": "Banh",
-            "zh_Hans": "球"
-        }
-    },
-    {
-        "number": 57,
-        "emoji": "🎸",
-        "description": "Guitar",
-        "unicode": "U+1F3B8",
-        "translated_descriptions": {
-            "ar": "غيتار",
-            "bg": "Китара",
-            "ca": "Guitarra",
-            "cs": "Kytara",
-            "de": "Gitarre",
-            "eo": "Gitaro",
-            "es": "Guitarra",
-            "et": "Kitarr",
-            "fi": "Kitara",
-            "fr": "Guitare",
-            "hr": "gitara",
-            "hu": "Gitár",
-            "id": "Gitar",
-            "it": "Chitarra",
-            "ja": "ギター",
-            "nb_NO": "Gitar",
-            "nl": "Gitaar",
-            "pt_BR": "Guitarra",
-            "ru": "Гитара",
-            "si": null,
-            "sk": "Gitara",
-            "sq": "Kitarë",
-            "sr": "гитара",
-            "sv": "Gitarr",
-            "szl": null,
-            "tzm": "Agiṭaṛ",
-            "uk": "Гітара",
-            "vi": "Ghi-ta",
-            "zh_Hans": "吉他"
-        }
-    },
-    {
-        "number": 58,
-        "emoji": "🎺",
-        "description": "Trumpet",
-        "unicode": "U+1F3BA",
-        "translated_descriptions": {
-            "ar": "بُوق",
-            "bg": "Тромпет",
-            "ca": "Trompeta",
-            "cs": "Trumpeta",
-            "de": "Trompete",
-            "eo": "Trumpeto",
-            "es": "Trompeta",
-            "et": "Trompet",
-            "fi": "Trumpetti",
-            "fr": "Trompette",
-            "hr": "truba",
-            "hu": "Trombita",
-            "id": "Terompet",
-            "it": "Trombetta",
-            "ja": "トランペット",
-            "nb_NO": "Trompet",
-            "nl": "Trompet",
-            "pt_BR": "Trombeta",
-            "ru": "Труба",
-            "si": null,
-            "sk": "Trúbka",
-            "sq": "Trombë",
-            "sr": "труба",
-            "sv": "Trumpet",
-            "szl": null,
-            "tzm": null,
-            "uk": "Труба",
-            "vi": "Kèn",
-            "zh_Hans": "喇叭"
-        }
-    },
-    {
-        "number": 59,
-        "emoji": "🔔",
-        "description": "Bell",
-        "unicode": "U+1F514",
-        "translated_descriptions": {
-            "ar": "جَرَس",
-            "bg": "Звънец",
-            "ca": "Campana",
-            "cs": "Zvonek",
-            "de": "Glocke",
-            "eo": "Sonorilo",
-            "es": "Campana",
-            "et": "Kelluke",
-            "fi": "Soittokello",
-            "fr": "Cloche",
-            "hr": "zvono",
-            "hu": "Harang",
-            "id": "Lonceng",
-            "it": "Campana",
-            "ja": "ベル",
-            "nb_NO": "Bjelle",
-            "nl": "Bel",
-            "pt_BR": "Sino",
-            "ru": "Колокол",
-            "si": null,
-            "sk": "Zvon",
-            "sq": "Kambanë",
-            "sr": "звоно",
-            "sv": "Bjällra",
-            "szl": null,
-            "tzm": null,
-            "uk": "Дзвін",
-            "vi": "Chuông",
-            "zh_Hans": "铃铛"
-        }
-    },
-    {
-        "number": 60,
-        "emoji": "⚓",
-        "description": "Anchor",
-        "unicode": "U+2693",
-        "translated_descriptions": {
-            "ar": "مِرسَاة",
-            "bg": "Котва",
-            "ca": "Àncora",
-            "cs": "Kotva",
-            "de": "Anker",
-            "eo": "Ankro",
-            "es": "Ancla",
-            "et": "Ankur",
-            "fi": "Ankkuri",
-            "fr": "Ancre",
-            "hr": "sidro",
-            "hu": "Horgony",
-            "id": "Jangkar",
-            "it": "Ancora",
-            "ja": "いかり",
-            "nb_NO": "Anker",
-            "nl": "Anker",
-            "pt_BR": "Âncora",
-            "ru": "Якорь",
-            "si": null,
-            "sk": "Kotva",
-            "sq": "Spirancë",
-            "sr": "сидро",
-            "sv": "Ankare",
-            "szl": null,
-            "tzm": null,
-            "uk": "Якір",
-            "vi": "Mỏ neo",
-            "zh_Hans": "锚"
-        }
-    },
-    {
-        "number": 61,
-        "emoji": "🎧",
-        "description": "Headphones",
-        "unicode": "U+1F3A7",
-        "translated_descriptions": {
-            "ar": "سَمّاعَة رَأس",
-            "bg": "Слушалки",
-            "ca": "Auriculars",
-            "cs": "Sluchátka",
-            "de": "Kopfhörer",
-            "eo": "Kapaŭdilo",
-            "es": "Cascos",
-            "et": "Kõrvaklapid",
-            "fi": "Kuulokkeet",
-            "fr": "Casque audio",
-            "hr": "slušalice",
-            "hu": "Fejhallgató",
-            "id": "Headphone",
-            "it": "Cuffie",
-            "ja": "ヘッドホン",
-            "nb_NO": "Hodetelefoner",
-            "nl": "Koptelefoon",
-            "pt_BR": "Fones de ouvido",
-            "ru": "Наушники",
-            "si": null,
-            "sk": "Slúchadlá",
-            "sq": "Kufje",
-            "sr": "слушалице",
-            "sv": "Hörlurar",
-            "szl": null,
-            "tzm": null,
-            "uk": "Навушники",
-            "vi": "Tai nghe",
-            "zh_Hans": "耳机"
-        }
-    },
-    {
-        "number": 62,
-        "emoji": "📁",
-        "description": "Folder",
-        "unicode": "U+1F4C1",
-        "translated_descriptions": {
-            "ar": "مُجَلَّد",
-            "bg": "Папка",
-            "ca": "Carpeta",
-            "cs": "Složka",
-            "de": "Ordner",
-            "eo": "Dosierujo",
-            "es": "Carpeta",
-            "et": "Kaust",
-            "fi": "Kansio",
-            "fr": "Dossier",
-            "hr": "mapu",
-            "hu": "Mappa",
-            "id": "Map",
-            "it": "Cartella",
-            "ja": "フォルダ",
-            "nb_NO": "Mappe",
-            "nl": "Map",
-            "pt_BR": "Pasta",
-            "ru": "Папка",
-            "si": null,
-            "sk": "Fascikel",
-            "sq": "Dosje",
-            "sr": "фасцикла",
-            "sv": "Mapp",
-            "szl": null,
-            "tzm": "Asdaw",
-            "uk": "Тека",
-            "vi": "Thư mục",
-            "zh_Hans": "文件夹"
-        }
-    },
-    {
-        "number": 63,
-        "emoji": "📌",
-        "description": "Pin",
-        "unicode": "U+1F4CC",
-        "translated_descriptions": {
-            "ar": "دَبُّوس",
-            "bg": "Кабърче",
-            "ca": "Xinxeta",
-            "cs": "Špendlík",
-            "de": "Stecknadel",
-            "eo": "Pinglo",
-            "es": "Alfiler",
-            "et": "Nööpnõel",
-            "fi": "Nuppineula",
-            "fr": "Punaise",
-            "hr": "pribadača",
-            "hu": "Rajszeg",
-            "id": "Pin",
-            "it": "Puntina",
-            "ja": "ピン",
-            "nb_NO": "Tegnestift",
-            "nl": "Duimspijker",
-            "pt_BR": "Alfinete",
-            "ru": "Булавка",
-            "si": null,
-            "sk": "Špendlík",
-            "sq": "Karficë",
-            "sr": "чиода",
-            "sv": "Häftstift",
-            "szl": null,
-            "tzm": null,
-            "uk": "Кнопка",
-            "vi": "Ghim",
-            "zh_Hans": "图钉"
-        }
-    }
-]
\ No newline at end of file
diff --git a/data/api/application-service/definitions/location.yaml b/data/api/application-service/definitions/location.yaml
deleted file mode 100644
index 5a0f92c8..00000000
--- a/data/api/application-service/definitions/location.yaml
+++ /dev/null
@@ -1,32 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-properties:
-  alias:
-    description: An alias for a matrix room.
-    type: string
-    example: "#freenode_#matrix:matrix.org"
-  protocol:
-    description: The protocol ID that the third party location is a part of.
-    type: string
-    example: "irc"
-  fields:
-    description: Information used to identify this third party location.
-    type: object
-    example: {
-      "network": "freenode",
-      "channel": "#matrix"
-    }
-required: ['alias', 'protocol', 'fields']
-title: Location
-type: object
\ No newline at end of file
diff --git a/data/api/application-service/definitions/location_batch.yaml b/data/api/application-service/definitions/location_batch.yaml
deleted file mode 100644
index 3f6de9df..00000000
--- a/data/api/application-service/definitions/location_batch.yaml
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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: array
-description: List of matched third party locations.
-items:
-  $ref: location.yaml
diff --git a/data/api/application-service/definitions/protocol.yaml b/data/api/application-service/definitions/protocol.yaml
deleted file mode 100644
index b16eedfc..00000000
--- a/data/api/application-service/definitions/protocol.yaml
+++ /dev/null
@@ -1,113 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-title: Protocol
-type: object
-properties:
-  user_fields:
-    description: |-
-      Fields which may be used to identify a third party user. These should be
-      ordered to suggest the way that entities may be grouped, where higher
-      groupings are ordered first. For example, the name of a network should be
-      searched before the nickname of a user.
-    type: array
-    items:
-      type: string
-      description: Field used to identify a third party user.
-    example: ["network", "nickname"]
-  location_fields:
-    description: |-
-      Fields which may be used to identify a third party location. These should be
-      ordered to suggest the way that entities may be grouped, where higher
-      groupings are ordered first. For example, the name of a network should be
-      searched before the name of a channel.
-    type: array
-    items:
-      type: string
-      description: Field used to identify a third party location.
-    example: ["network", "channel"]
-  icon:
-    description: A content URI representing an icon for the third party protocol.
-    type: string
-    example: "mxc://example.org/aBcDeFgH"
-  field_types:
-    title: Field Types
-    description: |-
-      The type definitions for the fields defined in the `user_fields` and
-      `location_fields`. Each entry in those arrays MUST have an entry here. The
-      `string` key for this object is field name itself.
-
-      May be an empty object if no fields are defined.
-    type: object
-    additionalProperties:
-      title: Field Type
-      description: Definition of valid values for a field.
-      type: object
-      properties:
-        regexp:
-          description: |-
-            A regular expression for validation of a field's value. This may be relatively
-            coarse to verify the value as the application service providing this protocol
-            may apply additional validation or filtering.
-          type: string
-        placeholder:
-          description: An placeholder serving as a valid example of the field value.
-          type: string
-      required: ['regexp', 'placeholder']
-    required: ['fieldname']
-    example: {
-      "network": {
-        "regexp": "([a-z0-9]+\\.)*[a-z0-9]+",
-        "placeholder": "irc.example.org"
-      },
-      "nickname": {
-        "regexp": "[^\\s#]+",
-        "placeholder": "username"
-      },
-      "channel": {
-        "regexp": "#[^\\s]+",
-        "placeholder": "#foobar"
-      }
-    }
-  instances:
-    description: |-
-      A list of objects representing independent instances of configuration.
-      For example, multiple networks on IRC if multiple are provided by the
-      same application service.
-    type: array
-    items:
-      type: object
-      title: Protocol Instance
-      properties:
-        desc:
-          type: string
-          description: A human-readable description for the protocol, such as the name.
-          example: "Freenode"
-        icon:
-          type: string
-          description: |-
-            An optional content URI representing the protocol. Overrides the one provided
-            at the higher level Protocol object.
-          example: "mxc://example.org/JkLmNoPq"
-        fields:
-          type: object
-          description: Preset values for `fields` the client may use to search by.
-          example: {
-            "network": "freenode"
-          }
-        network_id:
-          type: string
-          description: A unique identifier across all instances.
-          example: "freenode"
-      required: ['desc', 'fields', 'network_id']
-required: ['user_fields', 'location_fields', 'icon', 'field_types', 'instances']
diff --git a/data/api/application-service/definitions/protocol_metadata.yaml b/data/api/application-service/definitions/protocol_metadata.yaml
deleted file mode 100644
index e7bf45da..00000000
--- a/data/api/application-service/definitions/protocol_metadata.yaml
+++ /dev/null
@@ -1,70 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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
-description: Dictionary of supported third party protocols.
-additionalProperties:
-  $ref: protocol.yaml
-example: {
-  "irc": {
-    "user_fields": ["network", "nickname"],
-    "location_fields": ["network", "channel"],
-    "icon": "mxc://example.org/aBcDeFgH",
-    "field_types": {
-      "network": {
-        "regexp": "([a-z0-9]+\\.)*[a-z0-9]+",
-        "placeholder": "irc.example.org"
-      },
-      "nickname": {
-        "regexp": "[^\\s]+",
-        "placeholder": "username"
-      },
-      "channel": {
-        "regexp": "#[^\\s]+",
-        "placeholder": "#foobar"
-      }
-    },
-    "instances": [
-      {
-        "network_id": "freenode",
-        "desc": "Freenode",
-        "icon": "mxc://example.org/JkLmNoPq",
-        "fields": {
-          "network": "freenode.net",
-        }
-      }
-    ]
-  },
-  "gitter": {
-    "user_fields": ["username"],
-    "location_fields": ["room"],
-    "field_types": {
-      "username": {
-        "regexp": "@[^\\s]+",
-        "placeholder": "@username"
-      },
-      "room": {
-        "regexp": "[^\\s]+\\/[^\\s]+",
-        "placeholder": "matrix-org/matrix-doc"
-      }
-    },
-    "instances": [
-      {
-        "network_id": "gitter",
-        "desc": "Gitter",
-        "icon": "mxc://example.org/zXyWvUt",
-        "fields": {}
-      }
-    ]
-  }
-}
\ No newline at end of file
diff --git a/data/api/application-service/definitions/security.yaml b/data/api/application-service/definitions/security.yaml
deleted file mode 100644
index 6d7edd3a..00000000
--- a/data/api/application-service/definitions/security.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-homeserverAccessToken:
-  type: apiKey
-  description: The `hs_token` provided by the application service's registration.
-  name: access_token
-  in: query
diff --git a/data/api/application-service/definitions/user.yaml b/data/api/application-service/definitions/user.yaml
deleted file mode 100644
index 258e7c13..00000000
--- a/data/api/application-service/definitions/user.yaml
+++ /dev/null
@@ -1,33 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-# TODO: Change userid to user_id as a breaking change
-properties:
-  userid:
-    description: A Matrix User ID represting a third party user.
-    type: string
-    example: "@_gitter_jim:matrix.org"
-  protocol:
-    description: The protocol ID that the third party location is a part of.
-    type: string
-    example: "gitter"
-  fields:
-    description: Information used to identify this third party location.
-    type: object
-    example: {
-      "user": "jim"
-    }
-required: ['userid', 'protocol', 'fields']
-title: User
-type: object
\ No newline at end of file
diff --git a/data/api/application-service/definitions/user_batch.yaml b/data/api/application-service/definitions/user_batch.yaml
deleted file mode 100644
index 3653feb4..00000000
--- a/data/api/application-service/definitions/user_batch.yaml
+++ /dev/null
@@ -1,17 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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: array
-description: List of matched third party users.
-items:
-  $ref: user.yaml
diff --git a/data/api/application-service/protocols.yaml b/data/api/application-service/protocols.yaml
deleted file mode 100644
index b1e3ce6e..00000000
--- a/data/api/application-service/protocols.yaml
+++ /dev/null
@@ -1,279 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Application Service API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/app/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/thirdparty/protocol/{protocol}":
-    get:
-      summary: Retrieve metadata about a specific protocol that the application service supports.
-      description: |-
-        This API is called by the homeserver when it wants to present clients
-        with specific information about the various third party networks that
-        an application service supports.
-      operationId: getProtocolMetadata
-      security:
-        - homeserverAccessToken: []
-      parameters:
-        - in: path
-          name: protocol
-          type: string
-          description: The protocol ID.
-          required: true
-          x-example: "irc"
-      responses:
-        200:
-          description: The protocol was found and metadata returned.
-          schema:
-            $ref: definitions/protocol.yaml
-        401:
-          description: |-
-            The homeserver has not supplied credentials to the application service.
-            Optional error information can be included in the body of this response.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_UNAUTHORIZED"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        403:
-          description: |-
-            The credentials supplied by the homeserver were rejected.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_FORBIDDEN"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        404:
-          description: No protocol was found with the given path.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_NOT_FOUND"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-  "/thirdparty/user/{protocol}":
-    get:
-      summary: Retrieve the Matrix User ID of a corresponding third party user.
-      description: |-
-        This API is called by the homeserver in order to retrieve a Matrix
-        User ID linked to a user on the third party network, given a set of
-        user parameters.
-      operationId: queryUserByProtocol
-      security:
-        - homeserverAccessToken: []
-      parameters:
-        - in: path
-          name: protocol
-          type: string
-          description: The protocol ID.
-          required: true
-          x-example: irc
-        - in: query
-          name: fields...
-          type: string
-          description: |-
-            One or more custom fields that are passed to the application
-            service to help identify the user.
-      responses:
-        200:
-          description: The Matrix User IDs found with the given parameters.
-          schema:
-            $ref: definitions/user_batch.yaml
-        401:
-          description: |-
-            The homeserver has not supplied credentials to the application service.
-            Optional error information can be included in the body of this response.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_UNAUTHORIZED"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        403:
-          description: |-
-            The credentials supplied by the homeserver were rejected.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_FORBIDDEN"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        404:
-          description: No users were found with the given parameters.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_NOT_FOUND"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-  "/thirdparty/location/{protocol}":
-    get:
-      summary: Retrieve Matrix-side portal rooms leading to a third party location.
-      description: |-
-        Retrieve a list of Matrix portal rooms that lead to the matched third party location.
-      operationId: queryLocationByProtocol
-      security:
-        - homeserverAccessToken: []
-      parameters:
-        - in: path
-          name: protocol
-          type: string
-          description: The protocol ID.
-          required: true
-          x-example: irc
-        - in: query
-          name: fields...
-          type: string
-          description: |-
-            One or more custom fields that are passed to the application
-            service to help identify the third party location.
-      responses:
-        200:
-          description: At least one portal room was found.
-          schema:
-            $ref: definitions/location_batch.yaml
-        401:
-          description: |-
-            The homeserver has not supplied credentials to the application service.
-            Optional error information can be included in the body of this response.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_UNAUTHORIZED"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        403:
-          description: |-
-            The credentials supplied by the homeserver were rejected.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_FORBIDDEN"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        404:
-          description: No mappings were found with the given parameters.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_NOT_FOUND"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-  "/thirdparty/location":
-    get:
-      summary: Reverse-lookup third party locations given a Matrix room alias.
-      description: |-
-        Retrieve an array of third party network locations from a Matrix room
-        alias.
-      operationId: queryLocationByAlias
-      security:
-        - homeserverAccessToken: []
-      parameters:
-        - in: query
-          name: alias
-          type: string
-          description: The Matrix room alias to look up.
-      responses:
-        200:
-          description: |-
-            All found third party locations.
-          schema:
-            $ref: definitions/location_batch.yaml
-        401:
-          description: |-
-            The homeserver has not supplied credentials to the application service.
-            Optional error information can be included in the body of this response.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_UNAUTHORIZED"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        403:
-          description: |-
-            The credentials supplied by the homeserver were rejected.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_FORBIDDEN"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        404:
-          description: No mappings were found with the given parameters.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_NOT_FOUND"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-  "/thirdparty/user":
-    get:
-      summary: Reverse-lookup third party users given a Matrix User ID.
-      description: |-
-        Retrieve an array of third party users from a Matrix User ID.
-      operationId: queryUserByID
-      security:
-        - homeserverAccessToken: []
-      parameters:
-        - in: query 
-          name: userid
-          type: string
-          description: The Matrix User ID to look up.
-      responses:
-        200:
-          description: |-
-            An array of third party users.
-          schema:
-            $ref: definitions/user_batch.yaml
-        401:
-          description: |-
-            The homeserver has not supplied credentials to the application service.
-            Optional error information can be included in the body of this response.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_UNAUTHORIZED"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        403:
-          description: |-
-            The credentials supplied by the homeserver were rejected.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_UNAUTHORIZED"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        404:
-          description: No mappings were found with the given parameters.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_NOT_FOUND"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
diff --git a/data/api/application-service/query_room.yaml b/data/api/application-service/query_room.yaml
deleted file mode 100644
index 6ddc6234..00000000
--- a/data/api/application-service/query_room.yaml
+++ /dev/null
@@ -1,90 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Application Service API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/app/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomAlias}":
-    get:
-      summary: Query if a room alias should exist on the application service.
-      description: |-
-        This endpoint is invoked by the homeserver on an application service to query
-        the existence of a given room alias. The homeserver will only query room
-        aliases inside the application service's `aliases` namespace. The
-        homeserver will send this request when it receives a request to join a
-        room alias within the application service's namespace.
-      operationId: queryRoomByAlias
-      security:
-        - homeserverAccessToken: []
-      parameters:
-        - in: path
-          name: roomAlias
-          type: string
-          description: The room alias being queried.
-          required: true
-          x-example: "#magicforest:example.com"
-      responses:
-        200:
-          description: |-
-            The application service indicates that this room alias exists. The
-            application service MUST have created a room and associated it with
-            the queried room alias using the client-server API. Additional
-            information about the room such as its name and topic can be set
-            before responding.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-        401:
-          description: |-
-            The homeserver has not supplied credentials to the application service.
-            Optional error information can be included in the body of this response.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_UNAUTHORIZED"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        403:
-          description: |-
-            The credentials supplied by the homeserver were rejected.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_FORBIDDEN"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        404:
-          description: |-
-            The application service indicates that this room alias does not exist.
-            Optional error information can be included in the body of this response.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_NOT_FOUND"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
diff --git a/data/api/application-service/query_user.yaml b/data/api/application-service/query_user.yaml
deleted file mode 100644
index f8fc4ef1..00000000
--- a/data/api/application-service/query_user.yaml
+++ /dev/null
@@ -1,87 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Application Service API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/app/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/users/{userId}":
-    get:
-      summary: Query if a user should exist on the application service.
-      description: |-
-        This endpoint is invoked by the homeserver on an application service to query
-        the existence of a given user ID. The homeserver will only query user IDs
-        inside the application service's `users` namespace. The homeserver will
-        send this request when it receives an event for an unknown user ID in
-        the application service's namespace, such as a room invite.
-      operationId: queryUserById
-      security:
-        - homeserverAccessToken: []
-      parameters:
-        - in: path
-          name: userId
-          type: string
-          description: The user ID being queried.
-          required: true
-          x-example: "@alice:example.com"
-      responses:
-        200:
-          description: |-
-            The application service indicates that this user exists. The application
-            service MUST create the user using the client-server API.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-        401:
-          description: |-
-            The homeserver has not supplied credentials to the application service.
-            Optional error information can be included in the body of this response.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_UNAUTHORIZED"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        403:
-          description: |-
-            The credentials supplied by the homeserver were rejected.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_FORBIDDEN"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
-        404:
-          description: |-
-            The application service indicates that this user does not exist.
-            Optional error information can be included in the body of this response.
-          examples:
-            application/json: {
-              "errcode": "COM.EXAMPLE.MYAPPSERVICE_NOT_FOUND"
-            }
-          schema:
-            $ref: ../client-server/definitions/errors/error.yaml
diff --git a/data/api/application-service/transactions.yaml b/data/api/application-service/transactions.yaml
deleted file mode 100644
index de082904..00000000
--- a/data/api/application-service/transactions.yaml
+++ /dev/null
@@ -1,76 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Application Service API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/app/v1
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/transactions/{txnId}":
-    put:
-      summary: Send some events to the application service.
-      description: |-
-        This API is called by the homeserver when it wants to push an event
-        (or batch of events) to the application service.
-
-        Note that the application service should distinguish state events
-        from message events via the presence of a `state_key`, rather than
-        via the event type.
-      operationId: sendTransaction
-      security:
-        - homeserverAccessToken: []
-      parameters:
-        - in: path
-          name: txnId
-          type: string
-          description: |-
-            The transaction ID for this set of events. Homeservers generate
-            these IDs and they are used to ensure idempotency of requests.
-          required: true
-          x-example: "35"
-        - in: body
-          name: body
-          description: Transaction information
-          schema:
-            type: object
-            example: {
-              "events": [
-                {"$ref": "../../event-schemas/examples/m.room.member.yaml"},
-                {"$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"}
-              ]
-            }
-            properties:
-              events:
-                type: array
-                description: |-
-                  A list of events, formatted as per the Client-Server API.
-                items:
-                  $ref: "../client-server/definitions/client_event.yaml"
-            required: ["events"]
-      responses:
-        200:
-          description: The transaction was processed successfully.
-          examples:
-            application/json: {}
-          schema:
-            type: object
diff --git a/data/api/client-server/account-data.yaml b/data/api/client-server/account-data.yaml
deleted file mode 100644
index f7e7993d..00000000
--- a/data/api/client-server/account-data.yaml
+++ /dev/null
@@ -1,205 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Client Config API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/user/{userId}/account_data/{type}":
-    put:
-      summary: Set some account_data for the user.
-      description: |-
-        Set some account_data for the client. This config is only visible to the user
-        that set the account_data. The config will be synced to clients in the
-        top-level `account_data`.
-      operationId: setAccountData
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          required: true
-          description: |-
-            The ID of the user to set account_data for. The access token must be
-            authorized to make requests for this user ID.
-          x-example: "@alice:example.com"
-        - in: path
-          type: string
-          name: type
-          required: true
-          description: |-
-            The event type of the account_data to set. Custom types should be
-            namespaced to avoid clashes.
-          x-example: "org.example.custom.config"
-        - in: body
-          name: content
-          required: true
-          description: |-
-            The content of the account_data
-          schema:
-            type: object
-            example: {
-              "custom_account_data_key": "custom_config_value"}
-      responses:
-        200:
-          description:
-            The account_data was successfully added.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-      tags:
-        - User data
-    get:
-      summary: Get some account_data for the user.
-      description: |-
-        Get some account_data for the client. This config is only visible to the user
-        that set the account_data.
-      operationId: getAccountData
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          required: true
-          description: |-
-            The ID of the user to get account_data for. The access token must be
-            authorized to make requests for this user ID.
-          x-example: "@alice:example.com"
-        - in: path
-          type: string
-          name: type
-          required: true
-          description: |-
-            The event type of the account_data to get. Custom types should be
-            namespaced to avoid clashes.
-          x-example: "org.example.custom.config"
-      responses:
-        200:
-          description:
-            The account data content for the given type.
-          schema:
-            type: object
-            example: {
-              "custom_account_data_key": "custom_config_value"}
-      tags:
-        - User data
-  "/user/{userId}/rooms/{roomId}/account_data/{type}":
-    put:
-      summary: Set some account_data for the user.
-      description: |-
-        Set some account_data for the client on a given room. This config is only
-        visible to the user that set the account_data. The config will be synced to
-        clients in the per-room `account_data`.
-      operationId: setAccountDataPerRoom
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          required: true
-          description: |-
-            The ID of the user to set account_data for. The access token must be
-            authorized to make requests for this user ID.
-          x-example: "@alice:example.com"
-        - in: path
-          type: string
-          name: roomId
-          required: true
-          description: |-
-            The ID of the room to set account_data on.
-          x-example: "!726s6s6q:example.com"
-        - in: path
-          type: string
-          name: type
-          required: true
-          description: |-
-            The event type of the account_data to set. Custom types should be
-            namespaced to avoid clashes.
-          x-example: "org.example.custom.room.config"
-        - in: body
-          name: content
-          required: true
-          description: |-
-            The content of the account_data
-          schema:
-            type: object
-            example: {
-              "custom_account_data_key": "custom_account_data_value"}
-      responses:
-        200:
-          description:
-            The account_data was successfully added.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-      tags:
-        - User data
-    get:
-      summary: Get some account_data for the user.
-      description: |-
-        Get some account_data for the client on a given room. This config is only
-        visible to the user that set the account_data.
-      operationId: getAccountDataPerRoom
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          required: true
-          description: |-
-            The ID of the user to set account_data for. The access token must be
-            authorized to make requests for this user ID.
-          x-example: "@alice:example.com"
-        - in: path
-          type: string
-          name: roomId
-          required: true
-          description: |-
-            The ID of the room to get account_data for.
-          x-example: "!726s6s6q:example.com"
-        - in: path
-          type: string
-          name: type
-          required: true
-          description: |-
-            The event type of the account_data to get. Custom types should be
-            namespaced to avoid clashes.
-          x-example: "org.example.custom.room.config"
-      responses:
-        200:
-          description:
-            The account data content for the given type.
-          schema:
-            type: object
-            example: {
-              "custom_account_data_key": "custom_config_value"}
-      tags:
-        - User data
diff --git a/data/api/client-server/admin.yaml b/data/api/client-server/admin.yaml
deleted file mode 100644
index 403be39f..00000000
--- a/data/api/client-server/admin.yaml
+++ /dev/null
@@ -1,115 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Administration API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/admin/whois/{userId}":
-    get:
-      summary: Gets information about a particular user.
-      description: |-
-        Gets information about a particular user.
-
-        This API may be restricted to only be called by the user being looked
-        up, or by a server admin. Server-local administrator privileges are not
-        specified in this document.
-      operationId: getWhoIs
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          description: The user to look up.
-          required: true
-          x-example: "@peter:rabbit.rocks"
-      responses:
-        200:
-          description: The lookup was successful.
-          examples:
-            application/json: {
-                "user_id": "@peter:rabbit.rocks",
-                "devices": {
-                  "teapot": {
-                    "sessions": [
-                      {
-                        "connections": [
-                          {
-                            "ip": "127.0.0.1",
-                            "last_seen": 1411996332123,
-                            "user_agent": "curl/7.31.0-DEV"
-                          },
-                          {
-                            "ip": "10.0.0.2",
-                            "last_seen": 1411996332123,
-                            "user_agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36"
-                          }
-                        ]
-                      }
-                    ]
-                  }
-                }
-              }
-          schema:
-            type: object
-            properties:
-              user_id:
-                type: string
-                description: The Matrix user ID of the user.
-              devices:
-                type: object
-                description: |-
-                  Each key is an identifier for one of the user's devices.
-                additionalProperties:
-                  type: object
-                  title: DeviceInfo
-                  properties:
-                    sessions:
-                      type: array
-                      description: A user's sessions (i.e. what they did with an access token from one login).
-                      items:
-                        type: object
-                        title: SessionInfo
-                        properties:
-                          connections:
-                            type: array
-                            description: Information particular connections in the session.
-                            items:
-                              type: object
-                              title: ConnectionInfo
-                              properties:
-                                ip:
-                                  type: string
-                                  description: Most recently seen IP address of the session.
-                                last_seen:
-                                  type: integer
-                                  format: int64
-                                  description: Unix timestamp that the session was last active.
-                                user_agent:
-                                  type: string
-                                  description: User agent string last seen in the session.
-      tags:
-        - Server administration
diff --git a/data/api/client-server/administrative_contact.yaml b/data/api/client-server/administrative_contact.yaml
deleted file mode 100644
index e2e782aa..00000000
--- a/data/api/client-server/administrative_contact.yaml
+++ /dev/null
@@ -1,524 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Account Administrative Contact API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/account/3pid":
-    get:
-      summary: Gets a list of a user's third party identifiers.
-      description: |-
-        Gets a list of the third party identifiers that the homeserver has
-        associated with the user's account.
-
-        This is *not* the same as the list of third party identifiers bound to
-        the user's Matrix ID in identity servers.
-
-        Identifiers in this list may be used by the homeserver as, for example,
-        identifiers that it will accept to reset the user's account password.
-      operationId: getAccount3PIDs
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: The lookup was successful.
-          examples:
-            application/json: {
-              "threepids": [
-                {
-                  "medium": "email",
-                  "address": "monkey@banana.island",
-                  "validated_at": 1535176800000,
-                  "added_at": 1535336848756
-                }
-              ]
-            }
-          schema:
-            type: object
-            properties:
-              threepids:
-                type: array
-                items:
-                  type: object
-                  title: Third party identifier
-                  properties:
-                    medium:
-                      type: string
-                      description: The medium of the third party identifier.
-                      enum: ["email", "msisdn"]
-                    address:
-                      type: string
-                      description: The third party identifier address.
-                    validated_at:
-                      type: integer
-                      format: int64
-                      description: |-
-                        The timestamp, in milliseconds, when the identifier was
-                        validated by the identity server.
-                    added_at:
-                      type: integer
-                      format: int64
-                      description:
-                        The timestamp, in milliseconds, when the homeserver
-                        associated the third party identifier with the user.
-                  required: ['medium', 'address', 'validated_at', 'added_at']
-      tags:
-        - Account management
-    post:
-      summary: Adds contact information to the user's account.
-      description: |-
-        Adds contact information to the user's account.
-
-        This endpoint is deprecated in favour of the more specific `/3pid/add`
-        and `/3pid/bind` endpoints.
-
-        **Note:**
-        Previously this endpoint supported a `bind` parameter. This parameter
-        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.
-      operationId: post3PIDs
-      deprecated: true
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              three_pid_creds:
-                title: "ThreePidCredentials"
-                type: object
-                description: The third party credentials to associate with the account.
-                properties:
-                  client_secret:
-                    type: string
-                    description: The client secret used in the session with the identity server.
-                  id_server:
-                    type: string
-                    description: The identity server to use.
-                  id_access_token:
-                    type: string
-                    description: |-
-                      An access token previously registered with the identity server. Servers
-                      can treat this as optional to distinguish between r0.5-compatible clients
-                      and this specification version.
-                  sid:
-                    type: string
-                    description: The session identifier given by the identity server.
-                required: ["client_secret", "id_server", "id_access_token", "sid"]
-            required: ["three_pid_creds"]
-            example: {
-                "three_pid_creds": {
-                  "id_server": "matrix.org",
-                  "id_access_token": "abc123_OpaqueString",
-                  "sid": "abc123987",
-                  "client_secret": "d0nt-T3ll"
-                }
-              }
-      responses:
-        200:
-          description: The addition was successful.
-          examples:
-            application/json: {
-              "submit_url": "https://example.org/path/to/submitToken"
-            }
-          schema:
-            type: object
-            properties:
-              submit_url:
-                type: string
-                format: uri
-                description: |-
-                  An optional field containing a URL where the client must
-                  submit the validation token to, with identical parameters
-                  to the Identity Service API's `POST
-                  /validate/email/submitToken` endpoint (without the requirement
-                  for an access token). The homeserver must send this token to the
-                  user (if applicable), who should then be prompted to provide it
-                  to the client.
-
-                  If this field is not present, the client can assume that
-                  verification will happen without the client's involvement
-                  provided the homeserver advertises this specification version
-                  in the `/versions` response (ie: r0.5.0).
-                example: "https://example.org/path/to/submitToken"
-        403:
-          description: The credentials could not be verified with the identity server.
-          examples:
-            application/json: {
-                "errcode": "M_THREEPID_AUTH_FAILED",
-                "error": "The third party credentials could not be verified by the identity server."
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Account management
-  "/account/3pid/add":
-    post:
-      summary: Adds contact information to the user's account.
-      description: |-
-        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
-
-        Adds contact information to the user's account. Homeservers should use 3PIDs added
-        through this endpoint for password resets instead of relying on the identity server.
-
-        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.
-      operationId: add3PID
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              auth:
-                description: |-
-                  Additional authentication information for the
-                  user-interactive authentication API.
-                allOf:
-                - $ref: "definitions/auth_data.yaml"
-              client_secret:
-                type: string
-                description: The client secret used in the session with the homeserver.
-              sid:
-                type: string
-                description: The session identifier given by the homeserver.
-            required: ["client_secret",  "sid"]
-            example: {
-              "sid": "abc123987",
-              "client_secret": "d0nt-T3ll"
-            }
-      responses:
-        200:
-          description: The addition was successful.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-        401:
-          description: |-
-            The homeserver requires additional authentication information.
-          schema:
-            "$ref": "definitions/auth_response.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Account management
-  "/account/3pid/bind":
-    post:
-      summary: Binds a 3PID to the user's account through an Identity Service.
-      description: |-
-        Binds a 3PID to the user's account through the specified identity server.
-
-        Homeservers should not prevent this request from succeeding if another user
-        has bound the 3PID. Homeservers should simply proxy any errors received by
-        the identity server to the caller.
-
-        Homeservers should track successful binds so they can be unbound later.
-      operationId: bind3PID
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              client_secret:
-                type: string
-                description: The client secret used in the session with the identity server.
-              id_server:
-                type: string
-                description: The identity server to use.
-              id_access_token:
-                type: string
-                description: |-
-                  An access token previously registered with the identity server.
-              sid:
-                type: string
-                description: The session identifier given by the identity server.
-            required: ["client_secret", "id_server", "id_access_token", "sid"]
-            example: {
-              "id_server": "example.org",
-              "id_access_token": "abc123_OpaqueString",
-              "sid": "abc123987",
-              "client_secret": "d0nt-T3ll"
-            }
-      responses:
-        200:
-          description: The addition was successful.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Account management
-  "/account/3pid/delete":
-    post:
-      summary: Deletes a third party identifier from the user's account
-      description: |-
-        Removes a third party identifier from the user's account. This might not
-        cause an unbind of the identifier from the identity server.
-
-        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.
-      operationId: delete3pidFromAccount
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              id_server:
-                type: string
-                description: |-
-                    The identity server to unbind from. If not provided, the homeserver
-                    MUST use the `id_server` the identifier was added through. If the
-                    homeserver does not know the original `id_server`, it MUST return
-                    a `id_server_unbind_result` of `no-support`.
-                example: "example.org"
-              medium:
-                type: string
-                description: The medium of the third party identifier being removed.
-                enum: ["email", "msisdn"]
-                example: "email"
-              address:
-                type: string
-                description: The third party address being removed.
-                example: "example@example.org"
-            required: ['medium', 'address']
-      responses:
-        200:
-          description: |-
-            The homeserver has disassociated the third party identifier from the
-            user.
-          schema:
-            type: object
-            properties:
-              id_server_unbind_result:
-                type: string
-                enum:
-                  # XXX: I don't know why, but the order matters here so that "no-support"
-                  # doesn't become "no- support" by the renderer.
-                  - "no-support"
-                  - "success"
-                description: |-
-                  An indicator as to whether or not the homeserver was able to unbind
-                  the 3PID from the identity server. `success` indicates that the
-                  identity server has unbound the identifier whereas `no-support`
-                  indicates that the identity server refuses to support the request
-                  or the homeserver was not able to determine an identity server to
-                  unbind from.
-                example: "success"
-            required:
-              - id_server_unbind_result
-      tags:
-        - Account management
-  "/account/3pid/unbind":
-    post:
-      summary: Removes a user's third party identifier from an identity server.
-      description: |-
-        Removes a user's third party identifier from the provided identity server
-        without removing it from the homeserver.
-
-        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.
-      operationId: unbind3pidFromAccount
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              id_server:
-                type: string
-                description: |-
-                    The identity server to unbind from. If not provided, the homeserver
-                    MUST use the `id_server` the identifier was added through. If the
-                    homeserver does not know the original `id_server`, it MUST return
-                    a `id_server_unbind_result` of `no-support`.
-                example: "example.org"
-              medium:
-                type: string
-                description: The medium of the third party identifier being removed.
-                enum: ["email", "msisdn"]
-                example: "email"
-              address:
-                type: string
-                description: The third party address being removed.
-                example: "example@example.org"
-            required: ['medium', 'address']
-      responses:
-        200:
-          description: |-
-            The identity server has disassociated the third party identifier from the
-            user.
-          schema:
-            type: object
-            properties:
-              id_server_unbind_result:
-                type: string
-                enum:
-                  # XXX: I don't know why, but the order matters here so that "no-support"
-                  # doesn't become "no- support" by the renderer.
-                  - "no-support"
-                  - "success"
-                description: |-
-                  An indicator as to whether or not the identity server was able to unbind
-                  the 3PID. `success` indicates that the identity server has unbound the
-                  identifier whereas `no-support` indicates that the identity server
-                  refuses to support the request or the homeserver was not able to determine
-                  an identity server to unbind from.
-                example: "success"
-            required:
-              - id_server_unbind_result
-      tags:
-        - Account management
-  "/account/3pid/email/requestToken":
-    post:
-      summary: Begins the validation process for an email address for association with the user's account.
-      description: |-
-        The homeserver must check that the given email address is **not**
-        already associated with an account on this homeserver. This API should
-        be used to request validation tokens when adding an email address to an
-        account. This API's parameters and response are identical to that of
-        the [`/register/email/requestToken`](/client-server-api/#post_matrixclientv3registeremailrequesttoken)
-        endpoint. The homeserver should validate
-        the email itself, either by sending a validation email itself or by using
-        a service it has control over.
-      operationId: requestTokenTo3PIDEmail
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            $ref: "definitions/request_email_validation.yaml"
-      responses:
-        200:
-          description: |-
-            An email was sent to the given address. Note that this may be an
-            email containing the validation token or it may be informing the
-            user of an error.
-          schema:
-            $ref: "definitions/request_token_response.yaml"
-        403:
-          description: |-
-            The homeserver does not allow the third party identifier as a
-            contact option.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_DENIED",
-              "error": "Third party identifier is not allowed"
-            }
-        400:
-          description: |-
-            The third party identifier is already in use on the homeserver, or
-            the request was invalid. The error code `M_SERVER_NOT_TRUSTED`
-            can be returned if the server does not trust/support the identity server
-            provided in the request.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_IN_USE",
-              "error": "Third party identifier already in use"
-            }
-      tags:
-        - Account management
-  "/account/3pid/msisdn/requestToken":
-    post:
-      summary: Begins the validation process for a phone number for association with the user's account.
-      description: |-
-        The homeserver must check that the given phone number is **not**
-        already associated with an account on this homeserver. This API should
-        be used to request validation tokens when adding a phone number to an
-        account. This API's parameters and response are identical to that of
-        the [`/register/msisdn/requestToken`](/client-server-api/#post_matrixclientv3registermsisdnrequesttoken)
-        endpoint. The homeserver should validate
-        the phone number itself, either by sending a validation message itself or by using
-        a service it has control over.
-      operationId: requestTokenTo3PIDMSISDN
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            $ref: "definitions/request_msisdn_validation.yaml"
-      responses:
-        200:
-          description: An SMS message was sent to the given phone number.
-          schema:
-            $ref: "definitions/request_token_response.yaml"
-        403:
-          description: |-
-            The homeserver does not allow the third party identifier as a
-            contact option.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_DENIED",
-              "error": "Third party identifier is not allowed"
-            }
-        400:
-          description: |-
-            The third party identifier is already in use on the homeserver, or
-            the request was invalid. The error code `M_SERVER_NOT_TRUSTED`
-            can be returned if the server does not trust/support the identity server
-            provided in the request.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_IN_USE",
-              "error": "Third party identifier already in use"
-            }
-      tags:
-        - Account management
diff --git a/data/api/client-server/appservice_room_directory.yaml b/data/api/client-server/appservice_room_directory.yaml
deleted file mode 100644
index 233bf2bd..00000000
--- a/data/api/client-server/appservice_room_directory.yaml
+++ /dev/null
@@ -1,88 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Application Service Room Directory API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  # Note: this is the same access_token definition used elsewhere in the client
-  # server API, however this expects an access token for an application service.
-  $ref: definitions/security.yaml
-paths:
-  "/directory/list/appservice/{networkId}/{roomId}":
-    put:
-      summary: |-
-        Updates a room's visibility in the application service's room directory.
-      description: |-
-        Updates the visibility of a given room on the application service's room
-        directory.
-
-        This API is similar to the room directory visibility API used by clients
-        to update the homeserver's more general 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
-        users who are not identified as application services.
-      operationId: updateAppserviceRoomDirectoryVisibility
-      parameters:
-        - in: path
-          type: string
-          name: networkId
-          description: |-
-            The protocol (network) ID to update the room list for. This would
-            have been provided by the application service as being listed as
-            a supported protocol.
-          required: true
-          x-example: "irc"
-        - in: path
-          type: string
-          name: roomId
-          description: The room ID to add to the directory.
-          required: true
-          x-example: "!somewhere:example.org"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              visibility:
-                type: string
-                enum: ["public", "private"]
-                description: |-
-                  Whether the room should be visible (public) in the directory
-                  or not (private).
-                example: "public"
-            required: ['visibility']
-      security:
-        # again, this is the appservice's token - not a typical client's
-        - accessToken: []
-      responses:
-        200:
-          description: The room's directory visibility has been updated.
-          schema:
-            type: object
-          examples:
-            application/json: {}
-      tags:
-        - Application service room directory management
diff --git a/data/api/client-server/banning.yaml b/data/api/client-server/banning.yaml
deleted file mode 100644
index b1ba4d02..00000000
--- a/data/api/client-server/banning.yaml
+++ /dev/null
@@ -1,150 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Banning API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/ban":
-    post:
-      summary: Ban a user in the room.
-      description: |-
-        Ban a user in the room. If the user is currently in the room, also kick them.
-
-        When a user is banned from a room, they may not join it or be invited to it until they are unbanned.
-
-        The caller must have the required power level in order to perform this operation.
-      operationId: ban
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room identifier (not alias) from which the user should be banned.
-          required: true
-          x-example: "!e42d8c:matrix.org"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-                "reason": "Telling unfunny jokes",
-                "user_id": "@cheeky_monkey:matrix.org"
-              }
-            properties:
-              user_id:
-                type: string
-                description: The fully qualified user ID of the user being banned.
-              reason:
-                x-addedInMatrixVersion: "1.1"
-                type: string
-                description: The reason the user has been banned. This will be supplied as the
-                  `reason` on the target's updated [`m.room.member`](/client-server-api/#mroommember) event.
-            required: ["user_id"]
-      responses:
-        200:
-          description: The user has been kicked and banned from the room.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object
-        403:
-          description: |-
-            You do not have permission to ban the user from the room. A meaningful `errcode` and description error text will be returned. Example reasons for rejections are:
-
-            - The banner is not currently in the room.
-            - The banner's power level is insufficient to ban users from the room.
-          examples:
-            application/json: {
-                "errcode": "M_FORBIDDEN",
-                "error": "You do not have a high enough power level to ban from this room."
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room membership
-  "/rooms/{roomId}/unban":
-    post:
-      summary: Unban a user from the room.
-      description: |-
-        Unban a user from the room. This allows them to be invited to the room,
-        and join if they would otherwise be allowed to join according to its join rules.
-
-        The caller must have the required power level in order to perform this operation.
-      operationId: unban
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room identifier (not alias) from which the user should be unbanned.
-          required: true
-          x-example: "!e42d8c:matrix.org"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-              "user_id": "@cheeky_monkey:matrix.org",
-              "reason": "They've been banned long enough"
-            }
-            properties:
-              user_id:
-                type: string
-                description: The fully qualified user ID of the user being unbanned.
-              reason:
-                x-addedInMatrixVersion: "1.1"
-                type: string
-                description: |-
-                  Optional reason to be included as the `reason` on the subsequent
-                  membership event.
-            required: ["user_id"]
-      responses:
-        200:
-          description: The user has been unbanned from the room.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object
-        403:
-          description: |-
-            You do not have permission to unban the user from the room. A meaningful `errcode` and description error text will be returned. Example reasons for rejections are:
-
-            - The unbanner's power level is insufficient to unban users from the room.
-          examples:
-            application/json: {
-                "errcode": "M_FORBIDDEN",
-                "error": "You do not have a high enough power level to unban from this room."
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room membership
diff --git a/data/api/client-server/capabilities.yaml b/data/api/client-server/capabilities.yaml
deleted file mode 100644
index d31d01d7..00000000
--- a/data/api/client-server/capabilities.yaml
+++ /dev/null
@@ -1,112 +0,0 @@
-# Copyright 2019 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Capabilities API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/capabilities":
-    get:
-      summary: Gets information about the server's capabilities.
-      description: |-
-        Gets information about the server's supported feature set
-        and other relevant capabilities.
-      operationId: getCapabilities
-      security:
-        - accessToken: []
-      parameters: []
-      responses:
-        200:
-          description:
-            The capabilities of the server.
-          examples:
-            application/json: {
-              "capabilities": {
-                "m.change_password": {
-                  "enabled": false
-                },
-                "m.room_versions": {
-                  "default": "1",
-                  "available": {
-                    "1": "stable",
-                    "2": "stable",
-                    "3": "unstable",
-                    "test-version": "unstable"
-                  }
-                },
-                "com.example.custom.ratelimit": {
-                  "max_requests_per_hour": 600
-                }
-              }
-            }
-          schema:
-            type: object
-            required: ["capabilities"]
-            properties:
-              capabilities:
-                type: object
-                title: Capabilities
-                description: |-
-                    The custom capabilities the server supports, using the
-                    Java package naming convention.
-                additionalProperties:
-                  type: object
-                properties:
-                  "m.change_password":
-                    type: object
-                    description: |-
-                      Capability to indicate if the user can change their password.
-                    title: ChangePasswordCapability
-                    properties:
-                      enabled:
-                        type: boolean
-                        description: |-
-                          True if the user can change their password, false otherwise.
-                        example: false
-                    required: ['enabled']
-                  "m.room_versions":
-                    type: object
-                    description: The room versions the server supports.
-                    title: RoomVersionsCapability
-                    properties:
-                      default:
-                        type: string
-                        description: |-
-                          The default room version the server is using for new rooms.
-                        example: "1"
-                      available:
-                        type: object
-                        description: |-
-                          A detailed description of the room versions the server supports.
-                        additionalProperties:
-                          type: string
-                          title: RoomVersionStability
-                          enum: [stable, unstable]
-                          description: The stability of the room version.
-                    required: ['default', 'available']
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Capabilities
diff --git a/data/api/client-server/content-repo.yaml b/data/api/client-server/content-repo.yaml
deleted file mode 100644
index f614f9c7..00000000
--- a/data/api/client-server/content-repo.yaml
+++ /dev/null
@@ -1,454 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Content Repository API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/media/v3
-consumes:
-  - application/json
-  - "*/*"
-produces:
-  - application/json
-  - "*/*"
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/upload":
-    post:
-      summary: Upload some content to the content repository.
-      operationId: uploadContent
-      produces: ["application/json"]
-      security:
-        - accessToken: []
-      parameters:
-        - in: header
-          name: Content-Type
-          type: string
-          description: The content type of the file being uploaded
-          x-example: "application/pdf"
-        - in: query
-          type: string
-          x-example: "War and Peace.pdf"
-          name: filename
-          description: The name of the file being uploaded
-        - in: body
-          name: "<content>"
-          description: The content to be uploaded.
-          required: true
-          x-example: "<bytes>" # so the spec shows "<bytes>" without quotes.
-          schema:
-            type: string
-            example: "<bytes>"
-            format: byte
-      responses:
-        200:
-          description: The [MXC URI](/client-server-api/#matrix-content-mxc-uris) for the uploaded content.
-          schema:
-            type: object
-            required: ["content_uri"]
-            properties:
-              content_uri:
-                type: string
-                format: uri
-                description: "The [MXC URI](/client-server-api/#matrix-content-mxc-uris) to the uploaded content."
-          examples:
-            application/json: {
-              "content_uri": "mxc://example.com/AQwafuaFswefuhsfAFAgsw"
-            }
-        403:
-          description: |-
-            The user does not have permission to upload the content. Some reasons for this error include:
-
-            - The server does not permit the file type.
-            - The user has reached a quota for uploaded content.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "Cannot upload this content"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        413:
-          description: |-
-            The uploaded content is too large for the server.
-          examples:
-            application/json: {
-              "errcode": "M_TOO_LARGE",
-              "error": "Cannot upload files larger than 100mb"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Media
-  "/download/{serverName}/{mediaId}":
-    get:
-      summary: "Download content from the content repository."
-      operationId: getContent
-      produces: ["*/*"]
-      parameters:
-        - in: path
-          type: string
-          name: serverName
-          x-example: matrix.org
-          required: true
-          description: |
-            The server name from the `mxc://` URI (the authoritory component)
-        - in: path
-          type: string
-          name: mediaId
-          x-example: ascERGshawAWawugaAcauga
-          required: true
-          description: |
-            The media ID from the `mxc://` URI (the path component)
-        - in: query
-          type: boolean
-          name: allow_remote
-          x-example: false
-          required: false
-          default: true
-          description: |
-            Indicates to the server that it should not attempt to fetch the media if it is deemed
-            remote. This is to prevent routing loops where the server contacts itself. Defaults to
-            true if not provided.
-      responses:
-        200:
-          description: "The content that was previously uploaded."
-          headers:
-            Content-Type:
-              description: "The content type of the file that was previously uploaded."
-              type: "string"
-            Content-Disposition:
-              description: |-
-                The name of the file that was previously uploaded, if set.
-              type: "string"
-          schema:
-            type: file
-            # This is a workaround for us not being able to say the response is required.
-            description: "**Required.** The bytes for the uploaded file."
-        502:
-          description: |-
-            The content is too large for the server to serve.
-          examples:
-            application/json: {
-              "errcode": "M_TOO_LARGE",
-              "error": "Content is too large to serve"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Media
-  "/download/{serverName}/{mediaId}/{fileName}":
-    get:
-      summary: Download content from the content repository overriding the file name
-      description: |-
-        This will download content from the content repository (same as
-        the previous endpoint) but replace the target file name with the one
-        provided by the caller.
-      operationId: getContentOverrideName
-      produces: ["*/*"]
-      parameters:
-        - in: path
-          type: string
-          name: serverName
-          x-example: matrix.org
-          required: true
-          description: |
-            The server name from the `mxc://` URI (the authoritory component)
-        - in: path
-          type: string
-          name: mediaId
-          x-example: ascERGshawAWawugaAcauga
-          required: true
-          description: |
-            The media ID from the `mxc://` URI (the path component)
-        - in: path
-          type: string
-          name: fileName
-          x-example: filename.jpg
-          required: true
-          description: A filename to give in the `Content-Disposition` header.
-        - in: query
-          type: boolean
-          name: allow_remote
-          x-example: false
-          required: false
-          default: true
-          description: |
-            Indicates to the server that it should not attempt to fetch the media if it is deemed
-            remote. This is to prevent routing loops where the server contacts itself. Defaults to
-            true if not provided.
-      responses:
-        200:
-          description: "The content that was previously uploaded."
-          headers:
-            Content-Type:
-              description: "The content type of the file that was previously uploaded."
-              type: "string"
-            Content-Disposition:
-              description: |-
-                The `fileName` requested or the name of the file that was previously
-                uploaded, if set.
-              type: "string"
-          schema:
-            type: file
-            # This is a workaround for us not being able to say the response is required.
-            description: "**Required.** The bytes for the uploaded file."
-        502:
-          description: |-
-            The content is too large for the server to serve.
-          examples:
-            application/json: {
-              "errcode": "M_TOO_LARGE",
-              "error": "Content is too large to serve"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Media
-  "/thumbnail/{serverName}/{mediaId}":
-    get:
-      summary: Download a thumbnail of content from the content repository
-      description: |-
-        Download a thumbnail of content from the content repository.
-        See the [Thumbnails](/client-server-api/#thumbnails) section for more information.
-      operationId: getContentThumbnail
-      produces: ["image/jpeg", "image/png"]
-      parameters:
-        - in: path
-          type: string
-          name: serverName
-          required: true
-          x-example: example.org
-          description: |
-            The server name from the `mxc://` URI (the authoritory component)
-        - in: path
-          type: string
-          name: mediaId
-          x-example: ascERGshawAWawugaAcauga
-          required: true
-          description: |
-            The media ID from the `mxc://` URI (the path component)
-        - in: query
-          type: integer
-          x-example: 64
-          name: width
-          required: true
-          description: |-
-            The *desired* width of the thumbnail. The actual thumbnail may be
-            larger than the size specified.
-        - in: query
-          type: integer
-          x-example: 64
-          name: height
-          required: true
-          description: |-
-            The *desired* height of the thumbnail. The actual thumbnail may be
-            larger than the size specified.
-        - in: query
-          type: string
-          enum: ["crop", "scale"]
-          name: method
-          x-example: "scale"
-          description: |-
-            The desired resizing method. See the [Thumbnails](/client-server-api/#thumbnails)
-            section for more information.
-        - in: query
-          type: boolean
-          name: allow_remote
-          x-example: false
-          required: false
-          default: true
-          description: |-
-            Indicates to the server that it should not attempt to fetch
-            the media if it is deemed remote. This is to prevent routing loops
-            where the server contacts itself. Defaults to true if not provided.
-      responses:
-        200:
-          description: "A thumbnail of the requested content."
-          headers:
-            Content-Type:
-              description: "The content type of the thumbnail."
-              type: "string"
-              enum: ["image/jpeg", "image/png"]
-          schema:
-            type: file
-            # This is a workaround for us not being able to say the response is required.
-            description: "**Required.** The bytes for the thumbnail."
-        400:
-          description: |-
-            The request does not make sense to the server, or the server cannot thumbnail
-            the content. For example, the client requested non-integer dimensions or asked
-            for negatively-sized images.
-          examples:
-            application/json: {
-              "errcode": "M_UNKNOWN",
-              "error": "Cannot generate thumbnails for the requested content"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        413:
-          description: |-
-            The local content is too large for the server to thumbnail.
-          examples:
-            application/json: {
-              "errcode": "M_TOO_LARGE",
-              "error": "Content is too large to thumbnail"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        502:
-          description: |-
-            The remote content is too large for the server to thumbnail.
-          examples:
-            application/json: {
-              "errcode": "M_TOO_LARGE",
-              "error": "Content is too large to thumbnail"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Media
-  "/preview_url":
-    get:
-      summary: "Get information about a URL for a client"
-      description: |-
-        Get information about a URL for the client. Typically this is called when a
-        client sees a URL in a message and wants to render a preview for the user.
-
-        **Note:**
-        Clients should consider avoiding this endpoint for URLs posted in encrypted
-        rooms. Encrypted rooms often contain more sensitive information the users
-        do not want to share with the homeserver, and this can mean that the URLs
-        being shared should also not be shared with the homeserver.
-
-      operationId: getUrlPreview
-      produces: ["application/json"]
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          format: uri
-          x-example: "https://matrix.org"
-          name: url
-          description: "The URL to get a preview of."
-          required: true
-        - in: query
-          type: integer
-          format: int64
-          x-example: 1510610716656
-          name: ts
-          description: |-
-            The preferred point in time to return a preview for. The server may
-            return a newer version if it does not have the requested version
-            available.
-      responses:
-        200:
-          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 are described here.
-          schema:
-            type: object
-            properties:
-              "matrix:image:size":
-                type: integer
-                format: int64
-                description: |-
-                  The byte-size of the image. Omitted if there is no image attached.
-              "og:image":
-                type: string
-                format: uri
-                description: |-
-                  An [MXC URI](/client-server-api/#matrix-content-mxc-uris) to the image. Omitted if there is no image.
-          examples:
-            application/json: {
-                "og:title": "Matrix Blog Post",
-                "og:description": "This is a really cool blog post from matrix.org",
-                "og:image": "mxc://example.com/ascERGshawAWawugaAcauga",
-                "og:image:type": "image/png",
-                "og:image:height": 48,
-                "og:image:width": 48,
-                "matrix:image:size": 102400
-              }
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Media
-  "/config":
-    get:
-      summary: Get the configuration for the content repository.
-      description: |-
-        This endpoint allows clients to retrieve the configuration of the content
-        repository, such as upload limitations.
-        Clients SHOULD use this as a guide when using content repository endpoints.
-        All values are intentionally left optional. Clients SHOULD follow
-        the advice given in the field description when the field is not available.
-
-        **NOTE:** Both clients and server administrators should be aware that proxies
-        between the client and the server may affect the apparent behaviour of content
-        repository APIs, for example, proxies may enforce a lower upload size limit
-        than is advertised by the server on this endpoint.
-      operationId: getConfig
-      produces: ["application/json"]
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: The public content repository configuration for the matrix server.
-          schema:
-            type: object
-            properties:
-              m.upload.size:
-                type: integer
-                format: int64
-                description: |-
-                  The maximum size an upload can be in bytes.
-                  Clients SHOULD use this as a guide when uploading content.
-                  If not listed or null, the size limit should be treated as unknown.
-          examples:
-            application/json: {
-               "m.upload.size": 50000000
-            }
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-
-      tags:
-        - Media
diff --git a/data/api/client-server/create_room.yaml b/data/api/client-server/create_room.yaml
deleted file mode 100644
index 97c3dc91..00000000
--- a/data/api/client-server/create_room.yaml
+++ /dev/null
@@ -1,271 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Creation API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/createRoom":
-    post:
-      summary: Create a new room
-      description: |-
-        Create a new room with various configuration options.
-
-        The server MUST apply the normal state resolution rules when creating
-        the new room, including checking power levels for each event. It MUST
-        apply the events implied by the request in the following order:
-
-        1. The `m.room.create` event itself. Must be the first event in the
-           room.
-
-        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, giving the room creator
-           (and not other members) permission to send state events. Overridden
-           by the `power_level_content_override` parameter.
-
-        4. An `m.room.canonical_alias` event if `room_alias_name` is given.
-
-        5. Events set by the `preset`. Currently these are the `m.room.join_rules`,
-           `m.room.history_visibility`, and `m.room.guest_access` state events.
-
-        6. Events listed in `initial_state`, in the order that they are
-           listed.
-
-        7. Events implied by `name` and `topic` (`m.room.name` and `m.room.topic`
-           state events).
-
-        8. Invite events implied by `invite` and `invite_3pid` (`m.room.member` with
-           `membership: invite` and `m.room.third_party_invite`).
-
-        The available presets do the following with respect to room state:
-
-        | Preset                 | `join_rules` | `history_visibility` | `guest_access` | Other |
-        |------------------------|--------------|----------------------|----------------|-------|
-        | `private_chat`         | `invite`     | `shared`             | `can_join`     |       |
-        | `trusted_private_chat` | `invite`     | `shared`             | `can_join`     | All invitees are given the same power level as the room creator. |
-        | `public_chat`          | `public`     | `shared`             | `forbidden`    |       |
-
-        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`.
-      operationId: createRoom
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          description: The desired room configuration.
-          required: true
-          schema:
-            type: object
-            example: {
-              "preset": "public_chat",
-              "room_alias_name": "thepub",
-              "name": "The Grand Duke Pub",
-              "topic": "All about happy hour",
-              "creation_content": {
-                  "m.federate": false
-              }
-            }
-            properties:
-              visibility:
-                type: string
-                enum: ["public", "private"]
-                description: |-
-                  A `public` visibility indicates that the room will be shown
-                  in the published room list. A `private` visibility will hide
-                  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: |-
-                  The desired room alias **local part**. If this is included, a
-                  room alias will be created and mapped to the newly created
-                  room. The alias will belong on the *same* homeserver which
-                  created the room. For example, if this was set to "foo" and
-                  sent to the homeserver "example.com" the complete room alias
-                  would be `#foo:example.com`.
-
-                  The complete room alias will become the canonical alias for
-                  the room and an `m.room.canonical_alias` event will be sent
-                  into the room.
-              name:
-                type: string
-                description: |-
-                  If this is included, an `m.room.name` event will be sent
-                  into the room to indicate the name of the room. See Room
-                  Events for more information on `m.room.name`.
-              topic:
-                type: string
-                description: |-
-                  If this is included, an `m.room.topic` event will be sent
-                  into the room to indicate the topic for the room. See Room
-                  Events for more information on `m.room.topic`.
-              invite:
-                type: array
-                description: |-
-                  A list of user IDs to invite to the room. This will tell the
-                  server to invite everyone in the list to the newly created room.
-                items:
-                  type: string
-              invite_3pid:
-                type: array
-                description: |-
-                  A list of objects representing third party IDs to invite into
-                  the room.
-                items:
-                  type: object
-                  title: Invite3pid
-                  properties:
-                    id_server:
-                      type: string
-                      description: The hostname+port of the identity server which should be used for third party identifier lookups.
-                    id_access_token:
-                      type: string
-                      description: |-
-                        An access token previously registered with the identity server. Servers
-                        can treat this as optional to distinguish between r0.5-compatible clients
-                        and this specification version.
-                    medium:
-                      type: string
-                      # TODO: Link to Identity Service spec when it eixsts
-                      description: The kind of address being passed in the address field, for example `email`.
-                    address:
-                      type: string
-                      description: The invitee's third party identifier.
-                  required: ["id_server", "id_access_token", "medium", "address"]
-              room_version:
-                type: string
-                description: |-
-                  The room version to set for the room. If not provided, the homeserver is
-                  to use its configured default. If provided, the homeserver will return a
-                  400 error with the errcode `M_UNSUPPORTED_ROOM_VERSION` if it does not
-                  support the room version.
-                example: "1"
-              creation_content:
-                title: CreationContent
-                type: object
-                description: |-
-                  Extra keys, such as `m.federate`, to be added to the content
-                  of the [`m.room.create`](/client-server-api/#mroomcreate) event. The server will overwrite the following
-                  keys: `creator`, `room_version`. Future versions of the specification
-                  may allow the server to overwrite other keys.
-              initial_state:
-                type: array
-                description: |-
-                  A list of state events to set in the new room. This allows
-                  the user to override the default state events set in the new
-                  room. The expected format of the state events are an object
-                  with type, state_key and content keys set.
-
-                  Takes precedence over events set by `preset`, but gets
-                  overridden by `name` and `topic` keys.
-                items:
-                  type: object
-                  title: StateEvent
-                  properties:
-                    type:
-                      type: string
-                      description: The type of event to send.
-                    state_key:
-                      type: string
-                      description: The state_key of the state event. Defaults to an empty string.
-                    content:
-                      type: object
-                      description: The content of the event.
-                  required: ["type", "content"]
-              preset:
-                type: string
-                enum: ["private_chat", "public_chat", "trusted_private_chat"]
-                description: |-
-                  Convenience parameter for setting various default state events
-                  based on a preset.
-
-                  If unspecified, the server should use the `visibility` to determine
-                  which preset to use. A visbility of `public` equates to a preset of
-                  `public_chat` and `private` visibility equates to a preset of
-                  `private_chat`.
-              is_direct:
-                type: boolean
-                description: |-
-                  This flag makes the server set the `is_direct` flag on the
-                  `m.room.member` events sent to the users in `invite` and
-                  `invite_3pid`. See [Direct Messaging](/client-server-api/#direct-messaging) for more information.
-              power_level_content_override:
-                title: Power Level Event Content
-                type: object
-                description: |-
-                  The power level content to override in the default power level
-                  event. This object is applied on top of the generated
-                  [`m.room.power_levels`](/client-server-api/#mroompower_levels)
-                  event content prior to it being sent to the room. Defaults to
-                  overriding nothing.
-      responses:
-        200:
-          description: Information about the newly created room.
-          schema:
-            type: object
-            description: Information about the newly created room.
-            properties:
-              room_id:
-                type: string
-                description: |-
-                  The created room's ID.
-            required: ['room_id']
-          examples:
-            application/json: {
-              "room_id": "!sefiuhWgwghwWgh:example.com"
-            }
-        400:
-          description: |-
-
-            The request is invalid. A meaningful `errcode` and description
-            error text will be returned. Example reasons for rejection include:
-
-            - The request body is malformed (`errcode` set to `M_BAD_JSON`
-              or `M_NOT_JSON`).
-
-            - The room alias specified is already taken (`errcode` set to
-              `M_ROOM_IN_USE`).
-
-            - The initial state implied by the parameters to the request is
-              invalid: for example, the user's `power_level` is set below
-              that necessary to set the room name (`errcode` set to
-              `M_INVALID_ROOM_STATE`).
-
-            - The homeserver doesn't support the requested room version, or
-              one or more users being invited to the new room are residents
-              of a homeserver which does not support the requested room version.
-              The `errcode` will be `M_UNSUPPORTED_ROOM_VERSION` in these
-              cases.
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room creation
diff --git a/data/api/client-server/cross_signing.yaml b/data/api/client-server/cross_signing.yaml
deleted file mode 100644
index 603d88fd..00000000
--- a/data/api/client-server/cross_signing.yaml
+++ /dev/null
@@ -1,238 +0,0 @@
-# Copyright 2020 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Cross Signing API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/keys/device_signing/upload":
-    post:
-      x-addedInMatrixVersion: "1.1"
-      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).
-      operationId: uploadCrossSigningKeys
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: keys
-          description: |-
-            The keys to be published.
-          required: true
-          schema:
-            type: object
-            properties:
-              master_key:
-                description: |-
-                  Optional. The user\'s master key.
-                allOf:
-                  - $ref: definitions/cross_signing_key.yaml
-              self_signing_key:
-                description: |-
-                  Optional. The user\'s self-signing key. Must be signed by
-                  the accompanying master key, or by the user\'s most recently
-                  uploaded master key if no master key is included in the
-                  request.
-                allOf:
-                  - $ref: definitions/cross_signing_key.yaml
-              user_signing_key:
-                description: |-
-                  Optional. The user\'s user-signing key. Must be signed by
-                  the accompanying master key, or by the user\'s most recently
-                  uploaded master key if no master key is included in the
-                  request.
-                allOf:
-                  - $ref: definitions/cross_signing_key.yaml
-              auth:
-                description: |-
-                  Additional authentication information for the
-                  user-interactive authentication API.
-                allOf:
-                - $ref: "definitions/auth_data.yaml"
-            example: {
-              "master_key": {
-                "user_id": "@alice:example.com",
-                "usage": ["master"],
-                "keys": {
-                  "ed25519:base64+master+public+key": "base64+master+public+key",
-                }
-              },
-              "self_signing_key": {
-                "user_id": "@alice:example.com",
-                "usage": ["self_signing"],
-                "keys": {
-                  "ed25519:base64+self+signing+public+key": "base64+self+signing+master+public+key",
-                },
-                "signatures": {
-                  "@alice:example.com": {
-                    "ed25519:base64+master+public+key": "signature+of+self+signing+key"
-                  }
-                }
-              },
-              "user_signing_key": {
-                "user_id": "@alice:example.com",
-                "usage": ["user_signing"],
-                "keys": {
-                  "ed25519:base64+user+signing+public+key": "base64+user+signing+master+public+key",
-                },
-                "signatures": {
-                  "@alice:example.com": {
-                    "ed25519:base64+master+public+key": "signature+of+user+signing+key"
-                  }
-                }
-              }
-            }
-      responses:
-        200:
-          description: The provided keys were successfully uploaded.
-          schema:
-            type: object
-            example: {}
-        400:
-          description: |-
-            The input was invalid in some way. This can include one of the
-            following error codes:
-
-            * `M_INVALID_SIGNATURE`: For example, the self-signing or
-              user-signing key had an incorrect signature.
-            * `M_MISSING_PARAM`: No master key is available.
-          schema:
-            type: object
-            example: {
-              "errcode": "M_INVALID_SIGNATURE",
-              "error": "Invalid signature"
-            }
-        403:
-          description: |-
-            The public key of one of the keys is the same as one of the user\'s
-            device IDs, or the request is not authorized for any other reason.
-          schema:
-            type: object
-            example: {
-              "errcode": "M_FORBIDDEN",
-              "error": "Key ID in use"
-            }
-      tags:
-        - End-to-end encryption
-  "/keys/signatures/upload":
-    post:
-      x-addedInMatrixVersion: "1.1"
-      summary: Upload cross-signing signatures.
-      description: |-
-        Publishes cross-signing signatures for the user.  The request body is a
-        map from user ID to key ID to signed JSON object.
-      operationId: uploadCrossSigningSignatures
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: signatures
-          description: |-
-            The signatures to be published.
-          required: true
-          schema:
-            type: object
-            title: Signatures
-            additionalProperties:
-              type: object
-              additionalProperties:
-                type: object
-            example: {
-              "@alice:example.com": {
-                "HIJKLMN": {
-                  "user_id": "@alice:example.com",
-                  "device_id": "HIJKLMN",
-                  "algorithms": [
-                    "m.olm.curve25519-aes-sha256",
-                    "m.megolm.v1.aes-sha"
-                  ],
-                  "keys": {
-                    "curve25519:HIJKLMN": "base64+curve25519+key",
-                    "ed25519:HIJKLMN": "base64+ed25519+key"
-                  },
-                  "signatures": {
-                    "@alice:example.com": {
-                      "ed25519:base64+self+signing+public+key": "base64+signature+of+HIJKLMN"
-                    }
-                  }
-                },
-                "base64+master+public+key": {
-                  "user_id": "@alice:example.com",
-                  "usage": ["master"],
-                  "keys": {
-                    "ed25519:base64+master+public+key": "base64+master+public+key"
-                  },
-                  "signatures": {
-                    "@alice:example.com": {
-                      "ed25519:HIJKLMN": "base64+signature+of+master+key"
-                    }
-                  }
-                }
-              },
-              "@bob:example.com": {
-                "bobs+base64+master+public+key": {
-                  "user_id": "@bob:example.com",
-                  "keys": {
-                    "ed25519:bobs+base64+master+public+key": "bobs+base64+master+public+key"
-                  },
-                  "usage": ["master"],
-                  "signatures": {
-                    "@alice:example.com": {
-                      "ed25519:base64+user+signing+public+key": "base64+signature+of+bobs+master+key"
-                    }
-                  }
-                }
-              }
-            }
-      responses:
-        200:
-          description: The provided signatures were processed.
-          schema:
-            type: object
-            properties:
-              failures:
-                type: object
-                description: |-
-                  A map from user ID to key ID to an error for any signatures
-                  that failed.  If a signature was invalid, the `errcode` will
-                  be set to `M_INVALID_SIGNATURE`.
-                additionalProperties:
-                  type: object
-                  additionalProperties:
-                    type: object
-                    title: Error
-                example: {
-                  "@alice:example.com": {
-                    "HIJKLMN": {
-                      "errcode": "M_INVALID_SIGNATURE",
-                      "error": "Invalid signature"
-                    }
-                  }
-                }
-      tags:
-        - End-to-end encryption
diff --git a/data/api/client-server/definitions/auth_data.yaml b/data/api/client-server/definitions/auth_data.yaml
deleted file mode 100644
index c37c6a48..00000000
--- a/data/api/client-server/definitions/auth_data.yaml
+++ /dev/null
@@ -1,33 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-title: Authentication Data
-description: |-
-  Used by clients to submit authentication information to the interactive-authentication API
-type: object
-properties:
-  type:
-    description: The login type that the client is attempting to complete.
-    type: string
-  session:
-    description: The value of the session key given by the homeserver.
-    type: string
-additionalProperties:
-  description: Keys dependent on the login type
-  type: object
-required:
-  - type
-example:
-  type: "example.type.foo"
-  session: "xxxxx"
-  example_credential: "verypoorsharedsecret"
diff --git a/data/api/client-server/definitions/auth_response.yaml b/data/api/client-server/definitions/auth_response.yaml
deleted file mode 100644
index 5caf7a88..00000000
--- a/data/api/client-server/definitions/auth_response.yaml
+++ /dev/null
@@ -1,62 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-title: Authentication response
-description: |-
-  Used by servers to indicate that additional authentication information is required,
-type: object
-properties:
-  flows:
-    description: A list of the login flows supported by the server for this API.
-    title: Flow information
-    type: array
-    items:
-      type: object
-      properties:
-        stages:
-          description: |-
-            The login type of each of the stages required to complete this
-            authentication flow
-          type: array
-          items:
-            type: string
-            example: "example.type.foo"
-      required:
-        - stages
-  params:
-    type: object
-    description: |-
-      Contains any information that the client will need to know in order to
-      use a given type of authentication. For each login type presented,
-      that type may be present as a key in this dictionary. For example, the
-      public part of an OAuth client ID could be given here.
-    additionalProperties:
-      type: object
-    example:
-      "example.type.baz": { "example_key": "foobar" }
-  session:
-    type: string
-    description: |-
-      This is a session identifier that the client must pass back to the home
-      server, if one is provided, in subsequent attempts to authenticate in the
-      same API call.
-    example: "xxxxxxyz"
-  completed:
-    type: array
-    description: |-
-      A list of the stages the client has completed successfully
-    items:
-      type: string
-      example: "example.type.foo"
-required:
-  - flows
diff --git a/data/api/client-server/definitions/client_device.yaml b/data/api/client-server/definitions/client_device.yaml
deleted file mode 100644
index 6dc3abf3..00000000
--- a/data/api/client-server/definitions/client_device.yaml
+++ /dev/null
@@ -1,44 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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
-description: A client device
-title: Device
-properties:
-  device_id:
-    type: string
-    description: Identifier of this device.
-    example: QBUAZIFURK
-  display_name:
-    type: string
-    description: |-
-      Display name set by the user for this device. Absent if no name has been
-      set.
-    example: android
-  last_seen_ip:
-    type: string
-    description: |-
-      The IP address where this device was last seen. (May be a few minutes out
-      of date, for efficiency reasons).
-    example: 1.2.3.4
-  last_seen_ts:
-    type: integer
-    format: int64
-    description: |-
-      The timestamp (in milliseconds since the unix epoch) when this devices
-      was last seen. (May be a few minutes out of date, for efficiency
-      reasons).
-    example: 1474491775024
-required:
-  - device_id
diff --git a/data/api/client-server/definitions/client_event.yaml b/data/api/client-server/definitions/client_event.yaml
deleted file mode 100644
index 14aa9e6e..00000000
--- a/data/api/client-server/definitions/client_event.yaml
+++ /dev/null
@@ -1,47 +0,0 @@
-# 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.
-
-title: ClientEvent
-description: |-
-  The format used for events when they are returned from a homeserver to a client
-  via the Client-Server API, or sent to an Application Service via the Application Services API.
-type: object
-allOf:
-  - $ref: "client_event_without_room_id.yaml"
-  - properties:
-      room_id:
-        description: The ID of the room associated with this event.
-        type: string
-        example: '!jEsUZKDJdhlrceRyVU:example.org'
-
-      unsigned:
-        properties:
-            redacted_because:
-              title: ClientEvent
-              example: {
-                "type": "m.room.redaction",
-                "sender": "@moderator:example.org",
-                "content": {
-                  "reason": "spam"
-                },
-                "redacts": "$26RqwJMLw-yds1GAH_QxjHRC1Da9oasK0e5VLnck_45",
-                "event_id": "$Nhl3rsgHMjk-DjMJANawr9HHAhLg4GcoTYrSiYYGqEE",
-                "origin_server_ts": 1632491098485,
-                "room_id": '!jEsUZKDJdhlrceRyVU:example.org',
-                "unsigned": {
-                  "age": 1257,
-                }
-            }
-    required:
-      - room_id
diff --git a/data/api/client-server/definitions/client_event_without_room_id.yaml b/data/api/client-server/definitions/client_event_without_room_id.yaml
deleted file mode 100644
index 1b6d6073..00000000
--- a/data/api/client-server/definitions/client_event_without_room_id.yaml
+++ /dev/null
@@ -1,110 +0,0 @@
-# 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.
-
-title: ClientEventWithoutRoomID
-description: |-
-  The format used for events when they are returned from
-  API endpoints such as `/sync`, where the `room_id` is implied elsewhere
-  in the response.
-type: object
-required:
-  - event_id
-  - type
-  - sender
-  - origin_server_ts
-  - content
-properties:
-  event_id:
-    description: The globally unique identifier for this event.
-    type: string
-    example: '$26RqwJMLw-yds1GAH_QxjHRC1Da9oasK0e5VLnck_45'
-  type:
-    description: The type of the event.
-    type: string
-    example: 'm.room.member'
-  state_key:
-    description: |-
-      Present if, and only if, this event is a *state* event. The key making
-      this piece of state unique in the room. Note that it is often an empty
-      string.
-    type: string
-    example: '@user:example.org'
-  sender:
-    description: Contains the fully-qualified ID of the user who sent this event.
-    type: string
-    example: "@example:example.org"
-  origin_server_ts:
-    description: |-
-      Timestamp (in milliseconds since the unix epoch) on originating homeserver
-      when this event was sent.
-    type: integer
-    format: int64
-    example: 1632489532305
-  content:
-    description: |-
-      The body of this event, as created by the client which sent it.
-    type: object
-    example: {
-      "membership": "join"
-    }
-  unsigned:
-    title: UnsignedData
-    type: object
-    description: Contains optional extra information about the event.
-    properties:
-      age:
-        description: The time in milliseconds that has elapsed since the event was
-          sent. This field is generated by the local homeserver, and may be incorrect
-          if the local time on at least one of the two servers is out of sync, which can
-          cause the age to either be negative or greater than it actually is.
-        type: integer
-        format: int64
-        example: 1567437
-      redacted_because:
-        description: The event that redacted this event, if any.
-        type: object
-        title: ClientEventWithoutRoomID
-        example: {
-          "type": "m.room.redaction",
-          "sender": "@moderator:example.org",
-          "content": {
-            "reason": "spam"
-          },
-          "redacts": "$26RqwJMLw-yds1GAH_QxjHRC1Da9oasK0e5VLnck_45",
-          "event_id": "$Nhl3rsgHMjk-DjMJANawr9HHAhLg4GcoTYrSiYYGqEE",
-          "origin_server_ts": 1632491098485,
-          "unsigned": {
-            "age": 1257,
-          }
-        }
-      transaction_id:
-        description: |
-          The client-supplied transaction ID, for example, provided via
-          `PUT /_matrix/client/v3/rooms/{roomId}/send/{eventType}/{txnId}`,
-          if the client being given the event is the same one which sent it.
-        type: string
-      prev_content:
-        description: |
-          The previous `content` for this event. This field is generated
-          by the local homeserver, and is only returned if the event is a state event,
-          and the client has permission to see the previous content.
-        x-changedInMatrixVersion:
-          1.2: |
-            Previously, this field was specified at the top level of returned
-            events rather than in `unsigned` (with the exception of the [`GET
-            .../notifications`](/client-server-api/#get_matrixclientv3notifications)
-            endpoint), though in practice no known server implementations honoured
-            this.
-        title: EventContent
-        type: object
diff --git a/data/api/client-server/definitions/cross_signing_key.yaml b/data/api/client-server/definitions/cross_signing_key.yaml
deleted file mode 100644
index cebc5ecd..00000000
--- a/data/api/client-server/definitions/cross_signing_key.yaml
+++ /dev/null
@@ -1,55 +0,0 @@
-# Copyright 2020 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: CrossSigningKey
-description: Cross signing key
-properties:
-  user_id:
-    type: string
-    description: |-
-      The ID of the user the key belongs to.
-    example: "@alice:example.com"
-  usage:
-    type: array
-    description: |-
-      What the key is used for.
-    items:
-      type: string
-      enum: ["master", "self_signing", "user_signing"]
-  keys:
-    type: object
-    additionalProperties:
-      type: string
-    description: |-
-      The public key.  The object must have exactly one property, whose name is
-      in the form `<algorithm>:<unpadded_base64_public_key>`, and whose value
-      is the unpadded base64 public key.
-    example:
-      "ed25519:alice+base64+public+key": "alice+base64+public+key"
-  signatures:
-    type: object
-    title: Signatures
-    description: |-
-      Signatures of the key, calculated using the process described at [Signing JSON](/appendices/#signing-json).
-      Optional for the master key. Other keys must be signed by the
-      user\'s master key.
-    example: {
-        "@alice:example.com": {
-            "ed25519:alice+base64+master+key": "signature+of+key"
-          }
-      }
-required:
-  - user_id
-  - usage
-  - keys
diff --git a/data/api/client-server/definitions/device_keys.yaml b/data/api/client-server/definitions/device_keys.yaml
deleted file mode 100644
index ab033941..00000000
--- a/data/api/client-server/definitions/device_keys.yaml
+++ /dev/null
@@ -1,68 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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: DeviceKeys
-description: Device identity keys
-properties:
-  user_id:
-    type: string
-    description: |-
-      The ID of the user the device belongs to. Must match the user ID used
-      when logging in.
-    example: "@alice:example.com"
-  device_id:
-    type: string
-    description: |-
-      The ID of the device these keys belong to. Must match the device ID used
-      when logging in.
-    example: "JLAFKJWSCS"
-  algorithms:
-    type: array
-    items:
-      type: string
-    description: |-
-      The encryption algorithms supported by this device.
-    example: ["m.olm.v1.curve25519-aes-sha2", "m.megolm.v1.aes-sha2"]
-  keys:
-    type: object
-    description: |-
-       Public identity keys. The names of the properties should be in the
-       format `<algorithm>:<device_id>`. The keys themselves should be
-       encoded as specified by the key algorithm.
-    additionalProperties:
-       type: string
-    example:
-      "curve25519:JLAFKJWSCS": "3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI"
-      "ed25519:JLAFKJWSCS": "lEuiRJBit0IG6nUf5pUzWTUEsRVVe/HJkoKuEww9ULI"
-  signatures:
-    type: object
-    title: Signatures
-    description: |-
-       Signatures for the device key object. A map from user ID, to a map from
-       `<algorithm>:<device_id>` to the signature.
-
-       The signature is calculated using the process described at [Signing JSON](/appendices/#signing-json).
-    additionalProperties:
-      type: object
-      additionalProperties:
-        type: string
-    example:
-      "@alice:example.com":
-        "ed25519:JLAFKJWSCS": "dSO80A01XiigH3uBiDVx/EjzaoycHcjq9lfQX0uWsqxl2giMIiSPR8a4d291W1ihKJL/a+myXS367WT6NAIcBA"
-required:
-  - user_id
-  - device_id
-  - algorithms
-  - keys
-  - signatures
diff --git a/data/api/client-server/definitions/errors/error.yaml b/data/api/client-server/definitions/errors/error.yaml
deleted file mode 100644
index 89a0d44f..00000000
--- a/data/api/client-server/definitions/errors/error.yaml
+++ /dev/null
@@ -1,26 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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: Error
-description: A Matrix-level Error
-properties:
-  errcode:
-    type: string
-    description: An error code.
-    example: M_UNKNOWN
-  error:
-    type: string
-    description: A human-readable error message.
-    example: An unknown error occurred
-required: ["errcode"]
diff --git a/data/api/client-server/definitions/errors/rate_limited.yaml b/data/api/client-server/definitions/errors/rate_limited.yaml
deleted file mode 100644
index 1530458b..00000000
--- a/data/api/client-server/definitions/errors/rate_limited.yaml
+++ /dev/null
@@ -1,33 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-$ref: error.yaml
-type: object
-title: RateLimitError
-description: The rate limit was reached for this request
-properties:
-  errcode:
-    type: string
-    description: The M_LIMIT_EXCEEDED error code
-    example: M_LIMIT_EXCEEDED
-  error:
-    type: string
-    description: A human-readable error message.
-    example: Too many requests
-  retry_after_ms:
-    type: integer
-    description: |-
-      The amount of time in milliseconds the client should wait
-      before trying the request again.
-    example: 2000
-required: ["errcode"]
diff --git a/data/api/client-server/definitions/event_batch.yaml b/data/api/client-server/definitions/event_batch.yaml
deleted file mode 100644
index e326184c..00000000
--- a/data/api/client-server/definitions/event_batch.yaml
+++ /dev/null
@@ -1,24 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-properties:
-  events:
-    description: List of events.
-    items:
-      allOf:
-      - $ref: ../../../event-schemas/schema/core-event-schema/event.yaml
-      type: object
-    type: array
-type: object
-title: EventBatch
diff --git a/data/api/client-server/definitions/event_filter.yaml b/data/api/client-server/definitions/event_filter.yaml
deleted file mode 100644
index b6888693..00000000
--- a/data/api/client-server/definitions/event_filter.yaml
+++ /dev/null
@@ -1,47 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-title: EventFilter
-properties:
-  limit:
-    description: The maximum number of events to return.
-    type: integer
-  not_senders:
-    description: A list of sender IDs to exclude. If this list is absent then no senders
-      are excluded. A matching sender will be excluded even if it is listed in the
-      `'senders'` filter.
-    items:
-      type: string
-    type: array
-  not_types:
-    description: A list of event types to exclude. If this list is absent then no
-      event types are excluded. A matching type will be excluded even if it is listed
-      in the `'types'` filter. A '*' can be used as a wildcard to match any sequence
-      of characters.
-    items:
-      type: string
-    type: array
-  senders:
-    description: A list of senders IDs to include. If this list is absent then all
-      senders are included.
-    items:
-      type: string
-    type: array
-  types:
-    description: A list of event types to include. If this list is absent then all
-      event types are included. A `'*'` can be used as a wildcard to match any sequence
-      of characters.
-    items:
-      type: string
-    type: array
-type: object
diff --git a/data/api/client-server/definitions/key_backup_data.yaml b/data/api/client-server/definitions/key_backup_data.yaml
deleted file mode 100644
index c6e6b29e..00000000
--- a/data/api/client-server/definitions/key_backup_data.yaml
+++ /dev/null
@@ -1,50 +0,0 @@
-# Copyright 2019 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: KeyBackupData
-description: "The key data"
-properties:
-  first_message_index:
-    description: |-
-      The index of the first message in the session that the key can decrypt.
-    type: integer
-    example: 1
-  forwarded_count:
-    description: |-
-      The number of times this key has been forwarded via key-sharing between devices.
-    type: integer
-    example: 0
-  is_verified:
-    description: |-
-      Whether the device backing up the key verified the device that the key
-      is from.
-    type: boolean
-    example: false
-  session_data:
-    description: |-
-      Algorithm-dependent data.  See the documentation for the backup
-      algorithms in [Server-side key backups](/client-server-api/#server-side-key-backups) for more information on the
-      expected format of the data.
-    type: object
-    example: {
-      "ephemeral": "base64+ephemeral+key",
-      "ciphertext": "base64+ciphertext+of+JSON+data",
-      "mac": "base64+mac+of+ciphertext"
-    }
-required:
-  - first_message_index
-  - forwarded_count
-  - is_verified
-  - session_data
diff --git a/data/api/client-server/definitions/openid_token.yaml b/data/api/client-server/definitions/openid_token.yaml
deleted file mode 100644
index e74ddfff..00000000
--- a/data/api/client-server/definitions/openid_token.yaml
+++ /dev/null
@@ -1,37 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2019 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: OpenIdCredentials
-properties:
-  access_token:
-    type: string
-    description: |-
-      An access token the consumer may use to verify the identity of
-      the person who generated the token. This is given to the federation
-      API `GET /openid/userinfo` to verify the user's identity.
-  token_type:
-    type: string
-    description: The string `Bearer`.
-  matrix_server_name:
-    type: string
-    description: |-
-      The homeserver domain the consumer should use when attempting to
-      verify the user's identity.
-  expires_in:
-    type: integer
-    description: |-
-      The number of seconds before this token expires and a new one must
-      be generated.
-required: ['access_token', 'token_type', 'matrix_server_name', 'expires_in']
diff --git a/data/api/client-server/definitions/public_rooms_chunk.yaml b/data/api/client-server/definitions/public_rooms_chunk.yaml
deleted file mode 100644
index ff563a3c..00000000
--- a/data/api/client-server/definitions/public_rooms_chunk.yaml
+++ /dev/null
@@ -1,64 +0,0 @@
-# Copyright 2021 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: "PublicRoomsChunk"
-properties:
-  canonical_alias:
-    type: string
-    description: The canonical alias of the room, if any.
-    example: "#general:example.org"
-  name:
-    type: string
-    description: The name of the room, if any.
-    example: "General Chat"
-  num_joined_members:
-    type: integer
-    description: The number of members joined to the room.
-    example: 42
-  room_id:
-    type: string
-    description: The ID of the room.
-    example: "!abcdefg:example.org"
-  topic:
-    type: string
-    description: The topic of the room, if any.
-    example: "All things general"
-  world_readable:
-    type: boolean
-    description: Whether the room may be viewed by guest users without joining.
-    example: false
-  guest_can_join:
-    type: boolean
-    description: |-
-      Whether guest users may join the room and participate in it.
-      If they can, they will be subject to ordinary power level
-      rules like any other user.
-    example: true
-  avatar_url:
-    type: string
-    format: uri
-    description: The URL for the room's avatar, if one is set.
-    example: "mxc://example.org/abcdef"
-  join_rule:
-    type: string
-    description: |-
-      The room's join rule. When not present, the room is assumed to
-      be `public`.
-    example: "public"
-required:
-  - room_id
-  - num_joined_members
-  - world_readable
-  - guest_can_join
diff --git a/data/api/client-server/definitions/public_rooms_response.yaml b/data/api/client-server/definitions/public_rooms_response.yaml
deleted file mode 100644
index eead831e..00000000
--- a/data/api/client-server/definitions/public_rooms_response.yaml
+++ /dev/null
@@ -1,71 +0,0 @@
-# Copyright 2018, 2021 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
-description: A list of the rooms on the server.
-required: ["chunk"]
-properties:
-  chunk:
-    title: "PublicRoomsChunks"
-    type: array
-    description: |-
-      A paginated chunk of public rooms.
-    items:
-      allOf:
-        - $ref: "public_rooms_chunk.yaml"
-        - type: object
-          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: |-
-      A pagination token for the response. The absence of this token
-      means there are no more results to fetch and the client should
-      stop paginating.
-  prev_batch:
-    type: string
-    description: |-
-      A pagination token that allows fetching previous results. The
-      absence of this token means there are no results before this
-      batch, i.e. this is the first batch.
-  total_room_count_estimate:
-    type: integer
-    description: |-
-        An estimate on the total number of public rooms, if the
-        server has an estimate.
-example: {
-  "chunk": [
-    {
-      "avatar_url": "mxc://bleecker.street/CHEDDARandBRIE",
-      "guest_can_join": false,
-      "name": "CHEESE",
-      "num_joined_members": 37,
-      "room_id": "!ol19s:bleecker.street",
-      "topic": "Tasty tasty cheese",
-      "world_readable": true,
-      "join_rule": "public"
-    }
-  ],
-  "next_batch": "p190q",
-  "prev_batch": "p1902",
-  "total_room_count_estimate": 115
-}
diff --git a/data/api/client-server/definitions/push_condition.yaml b/data/api/client-server/definitions/push_condition.yaml
deleted file mode 100644
index 044f8627..00000000
--- a/data/api/client-server/definitions/push_condition.yaml
+++ /dev/null
@@ -1,47 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-
-title: PushCondition
-type: object
-properties:
-  kind:
-    type: string
-    description: |-
-      The kind of condition to apply. See [conditions](/client-server-api/#conditions) for
-      more information on the allowed kinds and how they work.
-  key:
-    type: string
-    description: |-
-      Required for `event_match` conditions. The dot-separated field of the
-      event to match.
-
-      Required for `sender_notification_permission` conditions. The field in
-      the power level event the user needs a minimum power level for. Fields
-      must be specified under the `notifications` property in the power level
-      event's `content`.
-    x-example: content.body
-  pattern:
-    type: string
-    description: |-
-      Required for `event_match` conditions. The glob-style pattern to
-      match against.
-  is:
-    type: string
-    description: |-
-      Required for `room_member_count` conditions. A decimal integer
-      optionally prefixed by one of, ==, <, >, >= or <=. A prefix of < matches
-      rooms where the member count is strictly less than the given number and
-      so forth. If no prefix is present, this parameter defaults to ==.
-required:
-  - kind
diff --git a/data/api/client-server/definitions/push_rule.yaml b/data/api/client-server/definitions/push_rule.yaml
deleted file mode 100644
index 06efad74..00000000
--- a/data/api/client-server/definitions/push_rule.yaml
+++ /dev/null
@@ -1,56 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-
-title: PushRule
-type: object
-properties:
-  actions:
-    items:
-      type:
-      - object
-      - string
-    type: array
-    description: |-
-      The actions to perform when this rule is matched.
-  default:
-    type: boolean
-    description: |-
-      Whether this is a default rule, or has been set explicitly.
-  enabled:
-    type: boolean
-    description: |-
-      Whether the push rule is enabled or not.
-  rule_id:
-    type: string
-    description: |-
-      The ID of this rule.
-  conditions:
-    type: array
-    items:
-      allOf:
-      - $ref: push_condition.yaml
-    description: |-
-      The conditions that must hold true for an event in order for a rule to be
-      applied to an event. A rule with no conditions always matches. Only
-      applicable to `underride` and `override` rules.
-  pattern:
-    type: string
-    description: |-
-      The glob-style pattern to match against.  Only applicable to `content`
-      rules.
-required:
-  - actions
-  - default
-  - enabled
-  - rule_id
diff --git a/data/api/client-server/definitions/push_ruleset.yaml b/data/api/client-server/definitions/push_ruleset.yaml
deleted file mode 100644
index 2d8cd67c..00000000
--- a/data/api/client-server/definitions/push_ruleset.yaml
+++ /dev/null
@@ -1,50 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-properties:
-  content:
-    items:
-      allOf:
-      - $ref: push_rule.yaml
-      title: PushRule
-      type: object
-    type: array
-  override:
-    items:
-      allOf:
-      - $ref: push_rule.yaml
-      title: PushRule
-      type: object
-    type: array
-  room:
-    items:
-      allOf:
-      - $ref: push_rule.yaml
-      title: PushRule
-      type: object
-    type: array
-  sender:
-    items:
-      allOf:
-      - $ref: push_rule.yaml
-      title: PushRule
-      type: object
-    type: array
-  underride:
-    items:
-      allOf:
-      - $ref: push_rule.yaml
-      title: PushRule
-      type: object
-    type: array
-type: object
diff --git a/data/api/client-server/definitions/request_email_validation.yaml b/data/api/client-server/definitions/request_email_validation.yaml
deleted file mode 100644
index d52ea18e..00000000
--- a/data/api/client-server/definitions/request_email_validation.yaml
+++ /dev/null
@@ -1,36 +0,0 @@
-# Copyright 2019 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
-allOf:
-- $ref: "../../identity/definitions/request_email_validation.yaml"
-- type: object
-  properties:
-    id_server:
-      type: string
-      description: |-
-        The hostname of the identity server to communicate with. May optionally
-        include a port. This parameter is ignored when the homeserver handles
-        3PID verification.
-
-        This parameter is deprecated with a plan to be removed in a future specification
-        version for `/account/password` and `/register` requests.
-      example: "id.example.com"
-    id_access_token:
-      type: string
-      description: |-
-        An access token previously registered with the identity server. Servers
-        can treat this as optional to distinguish between r0.5-compatible clients
-        and this specification version.
-
-        Required if an `id_server` is supplied.
diff --git a/data/api/client-server/definitions/request_msisdn_validation.yaml b/data/api/client-server/definitions/request_msisdn_validation.yaml
deleted file mode 100644
index fba3a615..00000000
--- a/data/api/client-server/definitions/request_msisdn_validation.yaml
+++ /dev/null
@@ -1,36 +0,0 @@
-# Copyright 2019 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
-allOf:
-- $ref: "../../identity/definitions/request_msisdn_validation.yaml"
-- type: object
-  properties:
-    id_server:
-      type: string
-      description: |-
-        The hostname of the identity server to communicate with. May optionally
-        include a port. This parameter is ignored when the homeserver handles
-        3PID verification.
-
-        This parameter is deprecated with a plan to be removed in a future specification
-        version for `/account/password` and `/register` requests.
-      example: "id.example.com"
-    id_access_token:
-      type: string
-      description: |-
-        An access token previously registered with the identity server. Servers
-        can treat this as optional to distinguish between r0.5-compatible clients
-        and this specification version.
-
-        Required if an `id_server` is supplied.
diff --git a/data/api/client-server/definitions/request_token_response.yaml b/data/api/client-server/definitions/request_token_response.yaml
deleted file mode 100644
index 0f8c8cab..00000000
--- a/data/api/client-server/definitions/request_token_response.yaml
+++ /dev/null
@@ -1,39 +0,0 @@
-# Copyright 2019 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: RequestTokenResponse
-properties:
-  sid:
-    type: string
-    description: |-
-      The session ID. Session IDs are opaque strings that must consist entirely
-      of the characters `[0-9a-zA-Z.=_-]`. Their length must not exceed 255
-      characters and they must not be empty.
-    example: "123abc"
-  submit_url:
-    type: string
-    format: uri
-    description: |-
-      An optional field containing a URL where the client must submit the
-      validation token to, with identical parameters to the Identity Service
-      API's `POST /validate/email/submitToken` endpoint (without the requirement
-      for an access token). The homeserver must send this token to the user (if
-      applicable), who should then be prompted to provide it to the client.
-
-      If this field is not present, the client can assume that verification
-      will happen without the client's involvement provided the homeserver
-      advertises this specification version in the `/versions` response
-      (ie: r0.5.0).
-    example: "https://example.org/path/to/submitToken"
-required: ['sid']
diff --git a/data/api/client-server/definitions/room_event_filter.yaml b/data/api/client-server/definitions/room_event_filter.yaml
deleted file mode 100644
index 8d96a165..00000000
--- a/data/api/client-server/definitions/room_event_filter.yaml
+++ /dev/null
@@ -1,49 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-allOf:
-- $ref: event_filter.yaml
-- type: object
-  title: RoomEventFilter
-  properties:
-    lazy_load_members:
-      type: boolean
-      description: |-
-        If `true`, enables lazy-loading of membership events. See
-        [Lazy-loading room members](/client-server-api/#lazy-loading-room-members)
-        for more information. Defaults to `false`.
-    include_redundant_members:
-      type: boolean
-      description: |-
-        If `true`, sends all membership events for all events, even if they have already
-        been sent to the client. Does not
-        apply unless `lazy_load_members` is `true`. See
-        [Lazy-loading room members](/client-server-api/#lazy-loading-room-members)
-        for more information. Defaults to `false`.
-    not_rooms:
-      description: A list of room IDs to exclude. If this list is absent then no rooms
-        are excluded. A matching room will be excluded even if it is listed in the `'rooms'`
-        filter.
-      items:
-        type: string
-      type: array
-    rooms:
-      description: A list of room IDs to include. If this list is absent then all rooms
-        are included.
-      items:
-        type: string
-      type: array
-    contains_url:
-      type: boolean
-      description: If `true`, includes only events with a `url` key in their content. If
-        `false`, excludes those events. If omitted, `url` key is not considered for filtering.
diff --git a/data/api/client-server/definitions/room_key_backup.yaml b/data/api/client-server/definitions/room_key_backup.yaml
deleted file mode 100644
index 5c70850f..00000000
--- a/data/api/client-server/definitions/room_key_backup.yaml
+++ /dev/null
@@ -1,38 +0,0 @@
-# Copyright 2020 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: RoomKeyBackup
-description: "The backed up keys for a room."
-properties:
-  sessions:
-    type: object
-    description: "A map of session IDs to key data."
-    additionalProperties:
-      allOf:
-        - $ref: "key_backup_data.yaml"
-    example: {
-      "sessionid1": {
-        "first_message_index": 1,
-        "forwarded_count": 0,
-        "is_verified": true,
-        "session_data": {
-          "ephemeral": "base64+ephemeral+key",
-          "ciphertext": "base64+ciphertext+of+JSON+data",
-          "mac": "base64+mac+of+ciphertext"
-        }
-      }
-    }
-required:
-  - sessions
diff --git a/data/api/client-server/definitions/security.yaml b/data/api/client-server/definitions/security.yaml
deleted file mode 100644
index 963e1d43..00000000
--- a/data/api/client-server/definitions/security.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-accessToken:
-  type: apiKey
-  description: The access_token returned by a call to `/login` or `/register`
-  name: access_token
-  in: query
diff --git a/data/api/client-server/definitions/sso_login_flow.yaml b/data/api/client-server/definitions/sso_login_flow.yaml
deleted file mode 100644
index 464a5f89..00000000
--- a/data/api/client-server/definitions/sso_login_flow.yaml
+++ /dev/null
@@ -1,81 +0,0 @@
-# Copyright 2021 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.login.sso flow schema
-properties:
-  type:
-    type: enum
-    enum: ["m.login.sso"]
-    description: The string `m.login.sso`
-    example: "m.login.sso"
-  identity_providers:
-    type: array
-    description: |-
-      Optional identity providers (IdPs) to present to the user. These would
-      appear (typically) as distinct buttons for the user to interact with,
-      and would map to the appropriate IdP-dependent redirect endpoint for that
-      IdP.
-    example: [
-      {"id": "com.example.idp.github", "name": "GitHub", "brand": "github"},
-      {"id": "com.example.idp.gitlab", "name": "GitLab", "icon": "mxc://example.com/abc123"},
-    ]
-    items:
-      type: object
-      title: IdP
-      description: An identity provider.
-      properties:
-        id:
-          type: string
-          description: |-
-            Opaque string chosen by the homeserver, uniquely identifying
-            the IdP from other IdPs the homeserver might support. Should
-            be between 1 and 255 characters in length, containing unreserved
-            characters under [RFC 3986](http://www.ietf.org/rfc/rfc3986.txt)
-            (`ALPHA  DIGIT  "-" / "." / "_" / "~"`). Clients are not intended
-            to parse or infer meaning from opaque strings.
-          example: "com.example.idp.github"
-        name:
-          type: string
-          description: |-
-            Human readable description for the IdP, intended to be shown to
-            the user.
-          example: "Github"
-        icon:
-          type: string
-          description: |-
-            Optional MXC URI to provide an image/icon representing the IdP.
-            Intended to be shown alongside the `name` if provided.
-          example: "mxc://example.org/abc123"
-        brand:
-          type: string
-          description: |-
-            Optional UI hint for what kind of common SSO provider is being
-            described in this IdP. Matrix maintains a registry of identifiers
-            [in the matrix-doc repo](https://github.com/matrix-org/matrix-doc/blob/master/informal/idp-brands.md)
-            to ensure clients and servers are aligned on major/common brands.
-
-            Clients should prefer the `brand` over the `icon`, when both are
-            provided. Clients are not required to support any particular `brand`,
-            including those in the registry, though are expected to be able to
-            present any IdP based off the `name`/`icon` to the user regardless.
-
-            Unregistered brands are permitted using the [Common Namespaced Identifier Grammar](/appendices/#common-namespaced-identifier-grammar),
-            though excluding the namespace requirements. For example, `examplesso`
-            is a valid brand which is not in the registry but still permitted.
-            Servers should be mindful that clients might not support their unregistered
-            brand usage as intended by the server.
-          example: "github"
-      required: ['id', 'name']
-
-required: ['type']
diff --git a/data/api/client-server/definitions/state_event_batch.yaml b/data/api/client-server/definitions/state_event_batch.yaml
deleted file mode 100644
index d452d348..00000000
--- a/data/api/client-server/definitions/state_event_batch.yaml
+++ /dev/null
@@ -1,21 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-properties:
-  events:
-    description: List of events.
-    items:
-      $ref: client_event_without_room_id.yaml
-    type: array
-type: object
-title: StateEventBatch
diff --git a/data/api/client-server/definitions/sync_filter.yaml b/data/api/client-server/definitions/sync_filter.yaml
deleted file mode 100644
index 0b4a8dca..00000000
--- a/data/api/client-server/definitions/sync_filter.yaml
+++ /dev/null
@@ -1,83 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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: Filter
-properties:
-  event_fields:
-    description: List of event fields to include. If this list is absent then all
-      fields are included. The entries may include '.' characters to indicate sub-fields.
-      So ['content.body'] will include the 'body' field of the 'content' object. A
-      literal '.' character in a field name may be escaped using a '\\'. A server may
-      include more fields than were requested.
-    items:
-      type: string
-    type: array
-  event_format:
-    description: The format to use for events. 'client' will return the events in
-      a format suitable for clients. 'federation' will return the raw event as received
-      over federation. The default is 'client'.
-    enum:
-    - client
-    - federation
-    type: string
-  presence:
-    allOf:
-    - $ref: event_filter.yaml
-    description: The presence updates to include.
-  account_data:
-    allOf:
-    - $ref: event_filter.yaml
-    description: The user account data that isn't associated with rooms to include.
-  room:
-    title: RoomFilter
-    description: Filters to be applied to room data.
-    type: object
-    properties:
-      not_rooms:
-        description: A list of room IDs to exclude. If this list is absent then no rooms
-          are excluded. A matching room will be excluded even if it is listed in the `'rooms'`
-          filter. This filter is applied before the filters in `ephemeral`,
-          `state`, `timeline` or `account_data`
-        items:
-          type: string
-        type: array
-      rooms:
-        description: A list of room IDs to include. If this list is absent then all rooms
-          are included. This filter is applied before the filters in `ephemeral`,
-          `state`, `timeline` or `account_data`
-        items:
-          type: string
-        type: array
-      ephemeral:
-        allOf:
-        - $ref: room_event_filter.yaml
-        description: The events that aren't recorded in the room history, e.g. typing
-          and receipts, to include for rooms.
-      include_leave:
-        description: Include rooms that the user has left in the sync, default false
-        type: boolean
-      state:
-        type: object
-        title: StateFilter
-        allOf:
-        - $ref: room_event_filter.yaml
-        description: The state events to include for rooms.
-      timeline:
-        allOf:
-        - $ref: room_event_filter.yaml
-        description: The message and state update events to include for rooms.
-      account_data:
-        allOf:
-        - $ref: room_event_filter.yaml
-        description: The per user account data to include for rooms.
diff --git a/data/api/client-server/definitions/third_party_signed.yaml b/data/api/client-server/definitions/third_party_signed.yaml
deleted file mode 100644
index 4af422b4..00000000
--- a/data/api/client-server/definitions/third_party_signed.yaml
+++ /dev/null
@@ -1,45 +0,0 @@
-# Copyright 2019 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: Third Party Signed
-description: |-
-  A signature of an `m.third_party_invite` token to prove that this user
-  owns a third party identity which has been invited to the room.
-properties:
-  sender:
-    type: string
-    description: The Matrix ID of the user who issued the invite.
-    example: "@alice:example.org"
-  mxid:
-    type: string
-    description: The Matrix ID of the invitee.
-    example: "@bob:example.org"
-  token:
-    type: string
-    description: The state key of the m.third_party_invite event.
-    example: "random8nonce"
-  signatures:
-    type: object
-    description: A signatures object containing a signature of the entire signed object.
-    title: Signatures
-    additionalProperties:
-      type: object
-      additionalProperties:
-        type: string
-    example: {
-      "example.org": {
-        "ed25519:0": "some9signature"
-      }
-    }
-required: ["sender", "mxid", "token", "signatures"]
diff --git a/data/api/client-server/definitions/timeline_batch.yaml b/data/api/client-server/definitions/timeline_batch.yaml
deleted file mode 100644
index 1c4ba40e..00000000
--- a/data/api/client-server/definitions/timeline_batch.yaml
+++ /dev/null
@@ -1,36 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-properties:
-  limited:
-    description: True if the number of events returned was limited by the `limit`
-      on the filter.
-    type: boolean
-  prev_batch:
-    description: A token that can be supplied to the `from` parameter of the
-      [`/rooms/<room_id>/messages`](#get_matrixclientv3roomsroomidmessages)
-      endpoint in order to retrieve earlier events.
-
-      If no earlier events are available, this property may be omitted from
-      the response.
-    type: string
-  events:
-    description: List of events.
-    type: array
-    items:
-      $ref: "client_event_without_room_id.yaml"
-type: object
-title: TimelineBatch
-required:
-  - events
diff --git a/data/api/client-server/definitions/user_identifier.yaml b/data/api/client-server/definitions/user_identifier.yaml
deleted file mode 100644
index 7e6eca9c..00000000
--- a/data/api/client-server/definitions/user_identifier.yaml
+++ /dev/null
@@ -1,24 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-title: User identifier
-description: |-
-  Identification information for a user
-type: object
-properties:
-  type:
-    type: string
-    description: The type of identification.  See [Identifier types](/client-server-api/#identifier-types) for supported values and additional property descriptions.
-required:
-  - type
-additionalProperties: true
diff --git a/data/api/client-server/definitions/wellknown/full.yaml b/data/api/client-server/definitions/wellknown/full.yaml
deleted file mode 100644
index 8d8f4038..00000000
--- a/data/api/client-server/definitions/wellknown/full.yaml
+++ /dev/null
@@ -1,39 +0,0 @@
-# Copyright 2019 New Vector Ltd
-#
-# 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.
-title: Discovery Information
-description: |-
-  Used by clients to determine the homeserver, identity server, and other
-  optional components they should be interacting with.
-type: object
-properties:
-  "m.homeserver":
-    $ref: "homeserver.yaml"
-  "m.identity_server":
-    $ref: "identity_server.yaml"
-additionalProperties:
-  type: object
-  description: Application-dependent keys using Java package naming convention.
-required:
-  - m.homeserver
-example: {
-  "m.homeserver": {
-    "base_url": "https://matrix.example.com"
-  },
-  "m.identity_server": {
-    "base_url": "https://identity.example.com"
-  },
-  "org.example.custom.property": {
-    "app_url": "https://custom.app.example.org"
-  }
-}
diff --git a/data/api/client-server/definitions/wellknown/homeserver.yaml b/data/api/client-server/definitions/wellknown/homeserver.yaml
deleted file mode 100644
index 6f6d3cb9..00000000
--- a/data/api/client-server/definitions/wellknown/homeserver.yaml
+++ /dev/null
@@ -1,25 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-title: Homeserver Information
-description: |-
-  Used by clients to discover homeserver information.
-type: object
-properties:
-  base_url:
-    type: string
-    format: uri
-    description: The base URL for the homeserver for client-server connections.
-    example: https://matrix.example.com
-required:
-  - base_url
diff --git a/data/api/client-server/definitions/wellknown/identity_server.yaml b/data/api/client-server/definitions/wellknown/identity_server.yaml
deleted file mode 100644
index a86ad8b1..00000000
--- a/data/api/client-server/definitions/wellknown/identity_server.yaml
+++ /dev/null
@@ -1,25 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-title: Identity Server Information
-description: |-
-  Used by clients to discover identity server information.
-type: object
-properties:
-  base_url:
-    type: string
-    format: uri
-    description: The base URL for the identity server for client-server connections.
-    example: https://identity.example.com
-required:
-  - base_url
diff --git a/data/api/client-server/device_management.yaml b/data/api/client-server/device_management.yaml
deleted file mode 100644
index 84e5ee23..00000000
--- a/data/api/client-server/device_management.yaml
+++ /dev/null
@@ -1,230 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server device management API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/devices":
-    get:
-      summary: List registered devices for the current user
-      description: |-
-        Gets information about all devices for the current user.
-      operationId: getDevices
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: Device information
-          schema:
-            type: object
-            properties:
-              devices:
-                type: array
-                description: A list of all registered devices for this user.
-                items:
-                  type: object
-                  allOf:
-                    - $ref: "definitions/client_device.yaml"
-          examples:
-            application/json: {
-                "devices": [
-                  {
-                    "device_id": "QBUAZIFURK",
-                    "display_name": "android",
-                    "last_seen_ip": "1.2.3.4",
-                    "last_seen_ts": 1474491775024
-                  }
-                ]
-              }
-      tags:
-        - Device management
-  "/devices/{deviceId}":
-    get:
-      summary: Get a single device
-      description: |-
-        Gets information on a single device, by device id.
-      operationId: getDevice
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: deviceId
-          description: The device to retrieve.
-          required: true
-          x-example: "QBUAZIFURK"
-      responses:
-        200:
-          description: Device information
-          schema:
-            type: object
-            allOf:
-              - $ref: "definitions/client_device.yaml"
-          examples:
-            application/json: {
-                "device_id": "QBUAZIFURK",
-                "display_name": "android",
-                "last_seen_ip": "1.2.3.4",
-                "last_seen_ts": 1474491775024
-              }
-        404:
-          description: The current user has no device with the given ID.
-      tags:
-        - Device management
-    put:
-      summary: Update a device
-      description: |-
-        Updates the metadata on the given device.
-      operationId: updateDevice
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: deviceId
-          description: The device to update.
-          required: true
-          x-example: "QBUAZIFURK"
-        - in: body
-          name: body
-          required: true
-          description: New information for the device.
-          schema:
-            type: object
-            properties:
-              display_name:
-                type: string
-                description: |-
-                  The new display name for this device. If not given, the
-                  display name is unchanged.
-            example: { "display_name": "My other phone" }
-      responses:
-        200:
-          description: The device was successfully updated.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object  # empty json object
-        404:
-          description: The current user has no device with the given ID.
-      tags:
-        - Device management
-    delete:
-      summary: Delete a device
-      description: |-
-        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
-
-        Deletes the given device, and invalidates any access token associated with it.
-      operationId: deleteDevice
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: deviceId
-          description: The device to delete.
-          required: true
-          x-example: "QBUAZIFURK"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              auth:
-                description: |-
-                  Additional authentication information for the
-                  user-interactive authentication API.
-                allOf:
-                  - "$ref": "definitions/auth_data.yaml"
-      responses:
-        200:
-          description: |-
-            The device was successfully removed, or had been removed
-            previously.
-          schema:
-            type: object
-          examples:
-            application/json: {
-              }
-        401:
-          description: |-
-            The homeserver requires additional authentication information.
-          schema:
-            "$ref": "definitions/auth_response.yaml"
-      tags:
-        - Device management
-  "/delete_devices":
-    post:
-      summary: Bulk deletion of devices
-      description: |-
-        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api).
-
-        Deletes the given devices, and invalidates any access token associated with them.
-      operationId: deleteDevices
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              devices:
-                type: array
-                description: The list of device IDs to delete.
-                items:
-                  type: string
-                  description: A list of device IDs.
-                example: ["QBUAZIFURK", "AUIECTSRND"]
-              auth:
-                allOf:
-                  - "$ref": "definitions/auth_data.yaml"
-                description: |-
-                    Additional authentication information for the
-                    user-interactive authentication API.
-            required:
-              - devices
-      responses:
-        200:
-          description: |-
-            The devices were successfully removed, or had been removed
-            previously.
-          schema:
-            type: object
-          examples:
-            application/json: {
-              }
-        401:
-          description: |-
-            The homeserver requires additional authentication information.
-          schema:
-            "$ref": "definitions/auth_response.yaml"
-      tags:
-        - Device management
diff --git a/data/api/client-server/directory.yaml b/data/api/client-server/directory.yaml
deleted file mode 100644
index 1b128905..00000000
--- a/data/api/client-server/directory.yaml
+++ /dev/null
@@ -1,237 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Directory API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/directory/room/{roomAlias}":
-    put:
-      summary: Create a new mapping from room alias to room ID.
-      operationId: setRoomAlias
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomAlias
-          description: The room alias to set.
-          required: true
-          x-example: "#monkeys:matrix.org"
-        - in: body
-          name: body
-          description: Information about this room alias.
-          required: true
-          schema:
-            type: object
-            properties:
-              room_id:
-                type: string
-                description: The room ID to set.
-            required: ['room_id']
-            example: {
-              "room_id": "!abnjk1jdasj98:capuchins.com"
-            }
-      responses:
-        200:
-          description: The mapping was created.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-        409:
-          description: A room alias with that name already exists.
-          examples:
-            application/json: {
-              "errcode": "M_UNKNOWN",
-              "error": "Room alias #monkeys:matrix.org already exists."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room directory
-    get:
-      summary: Get the room ID corresponding to this room alias.
-      description: |-
-        Requests that the server resolve a room alias to a room ID.
-
-        The server will use the federation API to resolve the alias if the
-        domain part of the alias does not correspond to the server's own
-        domain.
-
-      operationId: getRoomIdByAlias
-      parameters:
-        - in: path
-          type: string
-          name: roomAlias
-          description: The room alias.
-          required: true
-          x-example: "#monkeys:matrix.org"
-      responses:
-        200:
-          description: The room ID and other information for this alias.
-          schema:
-            type: object
-            properties:
-              room_id:
-                type: string
-                description: The room ID for this room alias.
-              servers:
-                type: array
-                description: A list of servers that are aware of this room alias.
-                items:
-                  type: string
-                  description: A server which is aware of this room alias.
-          examples:
-            application/json: {
-                "room_id": "!abnjk1jdasj98:capuchins.com",
-                "servers": [
-                  "capuchins.com",
-                  "matrix.org",
-                  "another.com"
-                ]
-              }
-        404:
-          description: There is no mapped room ID for this room alias.
-          examples:
-            application/json: {
-                "errcode": "M_NOT_FOUND",
-                "error": "Room alias #monkeys:matrix.org not found."
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room directory
-    delete:
-      summary: Remove a mapping of room alias to room ID.
-      description: |-
-        Remove a mapping of room alias to room ID.
-
-        Servers may choose to implement additional access control checks here, for instance that
-        room aliases can only be deleted by their creator or a server administrator.
-
-        **Note:**
-        Servers may choose to update the `alt_aliases` for the `m.room.canonical_alias`
-        state event in the room when an alias is removed. Servers which choose to update the
-        canonical alias event are recommended to, in addition to their other relevant permission
-        checks, delete the alias and return a successful response even if the user does not
-        have permission to update the `m.room.canonical_alias` event.
-
-      operationId: deleteRoomAlias
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomAlias
-          description: The room alias to remove.
-          required: true
-          x-example: "#monkeys:matrix.org"
-      responses:
-        200:
-          description: The mapping was deleted.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object
-        404:
-          description: There is no mapped room ID for this room alias.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Room alias #monkeys:example.org not found."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room directory
-  "/rooms/{roomId}/aliases":
-    get:
-      summary: Get a list of local aliases on a given room.
-      description: |-
-        Get a list of aliases maintained by the local server for the
-        given room.
-
-        This endpoint can be called by users who are in the room (external
-        users receive an `M_FORBIDDEN` error response). If the room's
-        `m.room.history_visibility` maps to `world_readable`, any
-        user can call this endpoint.
-
-        Servers may choose to implement additional access control checks here,
-        such as allowing server administrators to view aliases regardless of
-        membership.
-
-        **Note:**
-        Clients are recommended not to display this list of aliases prominently
-        as they are not curated, unlike those listed in the `m.room.canonical_alias`
-        state event.
-
-      operationId: getLocalAliases
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room ID to find local aliases of.
-          required: true
-          x-example: "!abc123:example.org"
-      responses:
-        200:
-          description: |-
-            The list of local aliases for the room.
-          examples:
-            application/json: {
-              "aliases": [
-                "#somewhere:example.com",
-                "#another:example.com",
-                "#hat_trick:example.com"
-              ]
-            }
-          schema:
-            type: object
-            properties:
-              aliases:
-                type: array
-                description: The server's local aliases on the room. Can be empty.
-                items:
-                  type: string
-            required: ['aliases']
-        403:
-          description: The user is not permitted to retrieve the list of local aliases for the room.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "You are not a member of the room."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Room directory
diff --git a/data/api/client-server/event_context.yaml b/data/api/client-server/event_context.yaml
deleted file mode 100644
index cf3476b0..00000000
--- a/data/api/client-server/event_context.yaml
+++ /dev/null
@@ -1,147 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Event Context API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/context/{eventId}":
-    get:
-      summary: Get events and state around the specified event.
-      description: |-
-        This API returns a number of events that happened just before and
-        after the specified event. This allows clients to get the context
-        surrounding an event.
-
-        *Note*: This endpoint supports lazy-loading of room member events. See
-        [Lazy-loading room members](/client-server-api/#lazy-loading-room-members) for more information.
-      operationId: getEventContext
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room to get events from.
-          required: true
-          x-example: "!636q39766251:example.com"
-        - in: path
-          type: string
-          name: eventId
-          description: The event to get context around.
-          required: true
-          x-example: "$f3h4d129462ha:example.com"
-        - in: query
-          type: integer
-          name: limit
-          description: |-
-            The maximum number of events to return. Default: 10.
-          x-example: 3
-        - in: query
-          name: filter
-          type: string
-          description: |-
-            A JSON `RoomEventFilter` to filter the returned events with. The
-            filter is only applied to `events_before`, `events_after`, and
-            `state`. It is not applied to the `event` itself. The filter may
-            be applied before or/and after the `limit` parameter - whichever the
-            homeserver prefers.
-
-            See [Filtering](/client-server-api/#filtering) for more information.
-          x-example: "66696p746572"
-      responses:
-        200:
-          description: The events and state surrounding the requested event.
-          schema:
-            type: object
-            description: The events and state surrounding the requested event.
-            properties:
-              start:
-                type: string
-                description: |-
-                  A token that can be used to paginate backwards with.
-              end:
-                type: string
-                description: |-
-                  A token that can be used to paginate forwards with.
-              events_before:
-                type: array
-                description: |-
-                  A list of room events that happened just before the
-                  requested event, in reverse-chronological order.
-                items:
-                  $ref: "definitions/client_event.yaml"
-              event:
-                description: |-
-                  Details of the requested event.
-                allOf:
-                  - $ref: "definitions/client_event.yaml"
-              events_after:
-                type: array
-                description: |-
-                  A list of room events that happened just after the
-                  requested event, in chronological order.
-                items:
-                  $ref: "definitions/client_event.yaml"
-              state:
-                type: array
-                description: |-
-                  The state of the room at the last event returned.
-                items:
-                  $ref: "definitions/client_event.yaml"
-          examples:
-            application/json: {
-              "end": "t29-57_2_0_2",
-              "events_after": [
-                {
-                  "room_id": "!636q39766251:example.com",
-                  "$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"
-                }
-              ],
-              "event": {
-                "event_id": "$f3h4d129462ha:example.com",
-                "room_id": "!636q39766251:example.com",
-                "$ref": "../../event-schemas/examples/m.room.message$m.image.yaml"
-              },
-              "events_before": [
-                {
-                  "room_id": "!636q39766251:example.com",
-                  "$ref": "../../event-schemas/examples/m.room.message$m.file.yaml"
-                }
-              ],
-              "start": "t27-54_2_0_2",
-              "state": [
-                {
-                  "room_id": "!636q39766251:example.com",
-                  "$ref": "../../event-schemas/examples/m.room.create.yaml"
-                },
-                {
-                  "room_id": "!636q39766251:example.com",
-                  "$ref": "../../event-schemas/examples/m.room.member.yaml"
-                }
-              ]
-            }
-      tags:
-        - Room participation
diff --git a/data/api/client-server/filter.yaml b/data/api/client-server/filter.yaml
deleted file mode 100644
index d5575ff5..00000000
--- a/data/api/client-server/filter.yaml
+++ /dev/null
@@ -1,156 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server filter API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/user/{userId}/filter":
-    post:
-      summary: Upload a new filter.
-      description: |-
-        Uploads a new filter definition to the homeserver.
-        Returns a filter ID that may be used in future requests to
-        restrict which events are returned to the client.
-      operationId: defineFilter
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          required: true
-          description:
-            The id of the user uploading the filter. The access token must be
-            authorized to make requests for this user id.
-          x-example: "@alice:example.com"
-        - in: body
-          name: filter
-          required: true
-          description: The filter to upload.
-          schema:
-            type: object
-            allOf:
-              - $ref: "definitions/sync_filter.yaml"
-            example: {
-              "room": {
-                "state": {
-                  "types": ["m.room.*"],
-                  "not_rooms": ["!726s6s6q:example.com"]
-                },
-                "timeline": {
-                  "limit": 10,
-                  "types": ["m.room.message"],
-                  "not_rooms": ["!726s6s6q:example.com"],
-                  "not_senders": ["@spam:example.com"]
-                },
-                "ephemeral": {
-                  "types": ["m.receipt", "m.typing"],
-                  "not_rooms": ["!726s6s6q:example.com"],
-                  "not_senders": ["@spam:example.com"]
-                }
-              },
-              "presence": {
-                "types": ["m.presence"],
-                "not_senders": ["@alice:example.com"]
-              },
-              "event_format": "client",
-              "event_fields": ["type", "content", "sender"]
-            }
-      responses:
-        200:
-          description: The filter was created.
-          schema:
-            type: object
-            properties:
-              filter_id:
-                type: string
-                description: |-
-                  The ID of the filter that was created. Cannot start
-                  with a `{` as this character is used to determine
-                  if the filter provided is inline JSON or a previously
-                  declared filter by homeservers on some APIs.
-                example: "66696p746572"
-            required: ['filter_id']
-      tags:
-        - Room participation
-  "/user/{userId}/filter/{filterId}":
-    get:
-      summary: Download a filter
-      operationId: getFilter
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          name: userId
-          type: string
-          description: |-
-            The user ID to download a filter for.
-          x-example: "@alice:example.com"
-          required: true
-        - in: path
-          name: filterId
-          type: string
-          description: |-
-            The filter ID to download.
-          x-example: "66696p746572"
-          required: true
-      responses:
-        200:
-          description: |-
-            The filter definition.
-          examples:
-            application/json: {
-                "room": {
-                  "state": {
-                    "types": ["m.room.*"],
-                    "not_rooms": ["!726s6s6q:example.com"]
-                  },
-                  "timeline": {
-                    "limit": 10,
-                    "types": ["m.room.message"],
-                    "not_rooms": ["!726s6s6q:example.com"],
-                    "not_senders": ["@spam:example.com"]
-                  },
-                  "ephemeral": {
-                    "types": ["m.receipt", "m.typing"],
-                    "not_rooms": ["!726s6s6q:example.com"],
-                    "not_senders": ["@spam:example.com"]
-                  }
-                },
-                "presence": {
-                  "types": ["m.presence"],
-                  "not_senders": ["@alice:example.com"]
-                },
-                "event_format": "client",
-                "event_fields": ["type", "content", "sender"]
-              }
-          schema:
-            type: object
-            allOf:
-              - $ref: "definitions/sync_filter.yaml"
-        404:
-          description: "Unknown filter."
-      tags:
-        - Room participation
diff --git a/data/api/client-server/inviting.yaml b/data/api/client-server/inviting.yaml
deleted file mode 100644
index 9beda8a0..00000000
--- a/data/api/client-server/inviting.yaml
+++ /dev/null
@@ -1,121 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Joining API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  # With an extra " " to disambiguate from the 3pid invite endpoint
-  # The extra space makes it sort first for what I'm sure is a good reason.
-  "/rooms/{roomId}/invite ":
-    post:
-      summary: Invite a user to participate in a particular room.
-      description: |-
-        *Note that there are two forms of this API, which are documented separately.
-        This version of the API requires that the inviter knows the Matrix
-        identifier of the invitee. The other is documented in the*
-        [third party invites section](/client-server-api/#post_matrixclientv3roomsroomidinvite-1).
-
-        This API invites a user to participate in a particular room.
-        They do not start participating in the room until they actually join the
-        room.
-
-        Only users currently in a particular room can invite other users to
-        join that room.
-
-        If the user was invited to the room, the homeserver will append a
-        `m.room.member` event to the room.
-
-      operationId: inviteUser
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room identifier (not alias) to which to invite the user.
-          required: true
-          x-example: "!d41d8cd:matrix.org"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-              "user_id": "@cheeky_monkey:matrix.org",
-              "reason": "Welcome to the team!"
-            }
-            properties:
-              user_id:
-                type: string
-                description: The fully qualified user ID of the invitee.
-              reason:
-                x-addedInMatrixVersion: "1.1"
-                type: string
-                description: |-
-                  Optional reason to be included as the `reason` on the subsequent
-                  membership event.
-            required: ["user_id"]
-      responses:
-        200:
-          description: The user has been invited to join the room.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object
-        400:
-          description: |-
-
-            The request is invalid. A meaningful `errcode` and description
-            error text will be returned. Example reasons for rejection include:
-
-            - The request body is malformed (`errcode` set to `M_BAD_JSON`
-              or `M_NOT_JSON`).
-
-            - One or more users being invited to the room are residents of a
-              homeserver which does not support the requested room version. The
-              `errcode` will be `M_UNSUPPORTED_ROOM_VERSION` in these cases.
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        403:
-          description: |-
-            You do not have permission to invite the user to the room. A meaningful `errcode` and description error text will be returned. Example reasons for rejections are:
-
-            - The invitee has been banned from the room.
-            - The invitee is already a member of the room.
-            - The inviter is not currently in the room.
-            - The inviter's power level is insufficient to invite users to the room.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN", "error": "@cheeky_monkey:matrix.org is banned from the room"}
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Room membership
diff --git a/data/api/client-server/joining.yaml b/data/api/client-server/joining.yaml
deleted file mode 100644
index 70e7444e..00000000
--- a/data/api/client-server/joining.yaml
+++ /dev/null
@@ -1,197 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Inviting API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/join":
-    post:
-      summary: Start the requesting user participating in a particular room.
-      description: |-
-        *Note that this API requires a room ID, not alias.*
-        `/join/{roomIdOrAlias}` *exists if you have a room alias.*
-
-        This API starts a user participating in a particular room, if that user
-        is allowed to participate in that room. After this call, the client is
-        allowed to see all current state events in the room, and all subsequent
-        events associated with the room until the user leaves the room.
-
-        After a user has joined a room, the room will appear as an entry in the
-        response of the [`/initialSync`](/client-server-api/#get_matrixclientv3initialsync)
-        and [`/sync`](/client-server-api/#get_matrixclientv3sync) APIs.
-      operationId: joinRoomById
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room identifier (not alias) to join.
-          required: true
-          x-example: "!d41d8cd:matrix.org"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              third_party_signed:
-                allOf:
-                - $ref: "definitions/third_party_signed.yaml"
-                description: |-
-                  If supplied, the homeserver must verify that it matches a pending
-                  `m.room.third_party_invite` event in the room, and perform
-                  key validity checking if required by the event.
-              reason:
-                x-addedInMatrixVersion: "1.1"
-                type: string
-                description: |-
-                  Optional reason to be included as the `reason` on the subsequent
-                  membership event.
-                example: "Looking for support"
-      responses:
-        200:
-          description: |-
-            The room has been joined.
-
-            The joined room ID must be returned in the `room_id` field.
-          examples:
-            application/json: {
-              "room_id": "!d41d8cd:matrix.org"}
-          schema:
-            type: object
-            properties:
-              room_id:
-                type: string
-                description: The joined room ID.
-            required: ["room_id"]
-        403:
-          description: |-
-            You do not have permission to join the room. A meaningful `errcode`
-            and description error text will be returned. Example reasons for rejection are:
-
-            - The room is invite-only and the user was not invited.
-            - The user has been banned from the room.
-            - The room is restricted and the user failed to satisfy any of the conditions.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN", "error": "You are not invited to this room."}
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Room membership
-  "/join/{roomIdOrAlias}":
-    post:
-      summary: Start the requesting user participating in a particular room.
-      description: |-
-        *Note that this API takes either a room ID or alias, unlike* `/room/{roomId}/join`.
-
-        This API starts a user participating in a particular room, if that user
-        is allowed to participate in that room. After this call, the client is
-        allowed to see all current state events in the room, and all subsequent
-        events associated with the room until the user leaves the room.
-
-        After a user has joined a room, the room will appear as an entry in the
-        response of the [`/initialSync`](/client-server-api/#get_matrixclientv3initialsync)
-        and [`/sync`](/client-server-api/#get_matrixclientv3sync) APIs.
-      operationId: joinRoom
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomIdOrAlias
-          description: The room identifier or alias to join.
-          required: true
-          x-example: "#monkeys:matrix.org"
-        - in: query
-          type: array
-          items:
-            type: string
-          name: server_name
-          description: |-
-            The servers to attempt to join the room through. One of the servers
-            must be participating in the room.
-          x-example: ["matrix.org", "elsewhere.ca"]
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              third_party_signed:
-                allOf:
-                  - $ref: "definitions/third_party_signed.yaml"
-                description: |-
-                  If a `third_party_signed` was supplied, the homeserver must verify
-                  that it matches a pending `m.room.third_party_invite` event in the
-                  room, and perform key validity checking if required by the event.
-              reason:
-                x-addedInMatrixVersion: "1.1"
-                type: string
-                description: |-
-                  Optional reason to be included as the `reason` on the subsequent
-                  membership event.
-                example: "Looking for support"
-      responses:
-        200:
-          description: |-
-            The room has been joined.
-
-            The joined room ID must be returned in the `room_id` field.
-          examples:
-            application/json: {
-              "room_id": "!d41d8cd:matrix.org"}
-          schema:
-            type: object
-            properties:
-              room_id:
-                type: string
-                description: The joined room ID.
-            required: ["room_id"]
-        403:
-          description: |-
-            You do not have permission to join the room. A meaningful `errcode`
-            and description error text will be returned. Example reasons for rejection are:
-
-            - The room is invite-only and the user was not invited.
-            - The user has been banned from the room.
-            - The room is restricted and the user failed to satisfy any of the conditions.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN", "error": "You are not invited to this room."}
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Room membership
diff --git a/data/api/client-server/key_backup.yaml b/data/api/client-server/key_backup.yaml
deleted file mode 100644
index 0b438b9e..00000000
--- a/data/api/client-server/key_backup.yaml
+++ /dev/null
@@ -1,949 +0,0 @@
-# Copyright 2019-2020 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Key Backup API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/room_keys/version":
-    post:
-      x-addedInMatrixVersion: "1.1"
-      summary: Create a new backup.
-      description: |-
-        Creates a new backup.
-      operationId: postRoomKeysVersion
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: version
-          description: "The backup configuration."
-          required: true
-          schema:
-            type: object
-            properties:
-              algorithm:
-                description: The algorithm used for storing backups.
-                type: string
-                enum: ["m.megolm_backup.v1.curve25519-aes-sha2"]
-                example: "m.megolm_backup.v1.curve25519-aes-sha2"
-              auth_data:
-                description: |-
-                  Algorithm-dependent data. See the documentation for the backup
-                  algorithms in [Server-side key backups](/client-server-api/#server-side-key-backups) for more information on the
-                  expected format of the data.
-                type: object
-                example: {
-                  "public_key": "abcdefg",
-                  "signatures": {
-                    "@alice:example.org": {
-                      "ed25519:deviceid": "signature"
-                    }
-                  }
-                }
-            required:
-              - algorithm
-              - auth_data
-      responses:
-        200:
-          description:
-            The version id of the new backup.
-          schema:
-            type: object
-            properties:
-              version:
-                type: string
-                description: The backup version. This is an opaque string.
-                example: "1"
-            required:
-              - version
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-    get:
-      summary: Get information about the latest backup version.
-      description: |-
-        Get information about the latest backup version.
-      operationId: getRoomKeysVersionCurrent
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description:
-            The information about the backup.
-          schema:
-            type: object
-            properties:
-              algorithm:
-                type: string
-                description: The algorithm used for storing backups.
-                enum: ["m.megolm_backup.v1.curve25519-aes-sha2"]
-                example: "m.megolm_backup.v1.curve25519-aes-sha2"
-              auth_data:
-                description: |-
-                  Algorithm-dependent data. See the documentation for the backup
-                  algorithms in [Server-side key backups](/client-server-api/#server-side-key-backups) for more information on the
-                  expected format of the data.
-                type: object
-                example: {
-                  "public_key": "abcdefg",
-                  "signatures": {
-                    "@alice:example.org": {
-                      "ed25519:deviceid": "signature"
-                    }
-                  }
-                }
-              count:
-                description: The number of keys stored in the backup.
-                type: integer
-                example: 42
-              etag:
-                description: |-
-                  An opaque string representing stored keys in the backup.
-                  Clients can compare it with the `etag` value they received
-                  in the request of their last key storage request.  If not
-                  equal, another client has modified the backup.
-                type: string
-                example: "anopaquestring"
-              version:
-                type: string
-                description: The backup version.
-                example: "1"
-            required:
-              - algorithm
-              - auth_data
-              - count
-              - etag
-              - version
-        404:
-          description:
-            No backup exists.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "No current backup version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-  "/room_keys/version/{version}":
-    get:
-      x-addedInMatrixVersion: "1.1"
-      summary: Get information about an existing backup.
-      description: |-
-        Get information about an existing backup.
-      operationId: getRoomKeysVersion
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: version
-          description: |-
-            The backup version to get, as returned in the `version` parameter
-            of the response in
-            [`POST /_matrix/client/v3/room_keys/version`](/client-server-api/#post_matrixclientv3room_keysversion)
-            or this endpoint.
-          required: true
-          x-example: "1"
-      responses:
-        200:
-          description:
-            The information about the requested backup.
-          schema:
-            type: object
-            properties:
-              algorithm:
-                type: string
-                description: The algorithm used for storing backups.
-                enum: ["m.megolm_backup.v1.curve25519-aes-sha2"]
-                example: "m.megolm_backup.v1.curve25519-aes-sha2"
-              auth_data:
-                description: |-
-                  Algorithm-dependent data. See the documentation for the backup
-                  algorithms in [Server-side key backups](/client-server-api/#server-side-key-backups) for more information on the
-                  expected format of the data.
-                type: object
-                example: {
-                  "public_key": "abcdefg",
-                  "signatures": {
-                    "@alice:example.org": {
-                      "ed25519:deviceid": "signature"
-                    }
-                  }
-                }
-              count:
-                description: The number of keys stored in the backup.
-                type: integer
-                example: 42
-              etag:
-                description: |-
-                  An opaque string representing stored keys in the backup.
-                  Clients can compare it with the `etag` value they received
-                  in the request of their last key storage request.  If not
-                  equal, another client has modified the backup.
-                type: string
-                example: "anopaquestring"
-              version:
-                type: string
-                description: The backup version.
-                example: "1"
-            required:
-              - algorithm
-              - auth_data
-              - count
-              - etag
-              - version
-        404:
-          description:
-            The backup specified does not exist.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown backup version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-    put:
-      summary: Update information about an existing backup.
-      description: |-
-        Update information about an existing backup.  Only `auth_data` can be modified.
-      operationId: putRoomKeysVersion
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: version
-          description: |-
-            The backup version to update, as returned in the `version`
-            parameter in the response of
-            [`POST /_matrix/client/v3/room_keys/version`](/client-server-api/#post_matrixclientv3room_keysversion)
-            or [`GET /_matrix/client/v3/room_keys/version/{version}`](/client-server-api/#get_matrixclientv3room_keysversionversion).
-          required: true
-          x-example: "1"
-        - in: body
-          name: version
-          description: "The backup configuration"
-          required: true
-          schema:
-            type: object
-            properties:
-              algorithm:
-                description: |-
-                  The algorithm used for storing backups.  Must be the same as
-                  the algorithm currently used by the backup.
-                type: string
-                enum: ["m.megolm_backup.v1.curve25519-aes-sha2"]
-                example: "m.megolm_backup.v1.curve25519-aes-sha2"
-              auth_data:
-                description: |-
-                  Algorithm-dependent data. See the documentation for the backup
-                  algorithms in [Server-side key backups](/client-server-api/#server-side-key-backups) for more information on the
-                  expected format of the data.
-                type: object
-                example: {
-                  "public_key": "abcdefg",
-                  "signatures": {
-                    "@alice:example.org": {
-                      "ed25519:deviceid": "signature"
-                    }
-                  }
-                }
-              version:
-                description: |-
-                  The backup version.  If present, must be the same as the
-                  version in the path parameter.
-                type: string
-                example: "1"
-            required:
-              - algorithm
-              - auth_data
-      responses:
-        200:
-          description: The update succeeded.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-        400:
-          description: |-
-            A parameter was incorrect.  For example, the `algorithm` does not
-            match the current backup algorithm, or the `version` in the body
-            does not match the `version` in the path.
-          examples:
-            application/json: {
-              "errcode": "M_INVALID_PARAM",
-              "error": "Algorithm does not match"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        404:
-          description: The backup specified does not exist.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown backup version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-    delete:
-      summary: Delete an existing key backup.
-      description: |-
-        Delete an existing key backup. Both the information about the backup,
-        as well as all key data related to the backup will be deleted.
-      operationId: deleteRoomKeysVersion
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: version
-          description: |-
-            The backup version to delete, as returned in the `version`
-            parameter in the response of
-            [`POST /_matrix/client/v3/room_keys/version`](/client-server-api/#post_matrixclientv3room_keysversion)
-            or [`GET /_matrix/client/v3/room_keys/version/{version}`](/client-server-api/#get_matrixclientv3room_keysversionversion).
-          required: true
-          x-example: "1"
-      responses:
-        200:
-          description: |-
-            The delete succeeded, or the specified backup was previously
-            deleted.
-          schema:
-            type: object
-            properties: {}
-        404:
-          description: |-
-            The backup specified does not exist. If the backup was previously
-            deleted, the call should succeed rather than returning an error.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown backup version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-  "/room_keys/keys/{roomId}/{sessionId}":
-    put:
-      summary: Store a key in the backup.
-      description: |-
-        Store a key in the backup.
-      operationId: putRoomKeyBySessionId
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: version
-          description: |-
-            The backup in which to store the key. Must be the current backup.
-          required: true
-          x-example: "1"
-        - in: path
-          type: string
-          name: roomId
-          description: The ID of the room that the key is for.
-          required: true
-          x-example: "!roomid:example.org"
-        - in: path
-          type: string
-          name: sessionId
-          description: The ID of the megolm session that the key is for.
-          required: true
-          x-example: "sessionid"
-        - in: body
-          name: data
-          description: "The key data."
-          required: true
-          schema:
-            "$ref": "definitions/key_backup_data.yaml"
-      responses:
-        200:
-          description: The update succeeded.
-          schema:
-            type: object
-            title: RoomKeysUpdateResponse
-            properties:
-              etag:
-                description: |-
-                  The new etag value representing stored keys in the backup.
-                  See `GET /room_keys/version/{version}` for more details.
-                type: string
-                example: "abcdefg"
-              count:
-                description: The number of keys stored in the backup
-                type: integer
-                example: 10
-            required:
-              - etag
-              - count
-        403:
-          description: |-
-            The version specified does not match the current backup version.
-            The current version will be included in the `current_version`
-            field.
-          examples:
-            application/json: {
-              "errcode": "M_WRONG_ROOM_KEYS_VERSION",
-              "error": "Wrong backup version.",
-              "current_version": "42"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-    get:
-      summary: Retrieve a key from the backup.
-      description: |-
-        Retrieve a key from the backup.
-      operationId: getRoomKeyBySessionId
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: version
-          description: |-
-            The backup from which to retrieve the key.
-          required: true
-          x-example: "1"
-        - in: path
-          type: string
-          name: roomId
-          description: The ID of the room that the requested key is for.
-          required: true
-          x-example: "!roomid:example.org"
-        - in: path
-          type: string
-          name: sessionId
-          description: The ID of the megolm session whose key is requested.
-          required: true
-          x-example: "sessionid"
-      responses:
-        200:
-          description: The key data
-          schema:
-            "$ref": "definitions/key_backup_data.yaml"
-        404:
-          description: The key or backup was not found.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Key not found."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-    delete:
-      summary: Delete a key from the backup.
-      description: |-
-        Delete a key from the backup.
-      operationId: deleteRoomKeyBySessionId
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: version
-          description: |-
-            The backup from which to delete the key
-          required: true
-          x-example: "1"
-        - in: path
-          type: string
-          name: roomId
-          description: The ID of the room that the specified key is for.
-          required: true
-          x-example: "!roomid:example.org"
-        - in: path
-          type: string
-          name: sessionId
-          description: The ID of the megolm session whose key is to be deleted.
-          required: true
-          x-example: "sessionid"
-      responses:
-        200:
-          description: The update succeeded
-          schema:
-            type: object
-            title: RoomKeysUpdateResponse
-            properties:
-              etag:
-                description: |-
-                  The new etag value representing stored keys in the backup.
-                  See `GET /room_keys/version/{version}` for more details.
-                type: string
-                example: "abcdefg"
-              count:
-                description: The number of keys stored in the backup
-                type: integer
-                example: 10
-            required:
-              - etag
-              - count
-        404:
-          description: |-
-            The backup was not found.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown backup version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-  "/room_keys/keys/{roomId}":
-    put:
-      summary: Store several keys in the backup for a given room.
-      description: |-
-        Store several keys in the backup for a given room.
-      operationId: putRoomKeysByRoomId
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: version
-          description: |-
-            The backup in which to store the keys. Must be the current backup.
-          required: true
-          x-example: "1"
-        - in: path
-          type: string
-          name: roomId
-          description: The ID of the room that the keys are for.
-          required: true
-          x-example: "!roomid:example.org"
-        - in: body
-          description: "The backup data"
-          name: backupData
-          required: true
-          schema:
-            $ref: "definitions/room_key_backup.yaml"
-      responses:
-        200:
-          description: The update succeeded
-          schema:
-            type: object
-            title: RoomKeysUpdateResponse
-            properties:
-              etag:
-                description: |-
-                  The new etag value representing stored keys in the backup.
-                  See `GET /room_keys/version/{version}` for more details.
-                type: string
-                example: "abcdefg"
-              count:
-                description: The number of keys stored in the backup
-                type: integer
-                example: 10
-            required:
-              - etag
-              - count
-        403:
-          description: |-
-            The version specified does not match the current backup version.
-            The current version will be included in the `current_version`
-            field.
-          examples:
-            application/json: {
-                "errcode": "M_WRONG_ROOM_KEYS_VERSION",
-                "error": "Wrong backup version.",
-                "current_version": "42"
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        404:
-          description: |-
-            The backup was not found.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown backup version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-    get:
-      summary: Retrieve the keys from the backup for a given room.
-      description: |-
-        Retrieve the keys from the backup for a given room.
-      operationId: getRoomKeysByRoomId
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: version
-          description: |-
-            The backup from which to retrieve the key.
-          required: true
-          x-example: "1"
-        - in: path
-          type: string
-          name: roomId
-          description: The ID of the room that the requested key is for.
-          required: true
-          x-example: "!roomid:example.org"
-      responses:
-        200:
-          description: |-
-            The key data.  If no keys are found, then an object with an empty
-            `sessions` property will be returned (`{"sessions": {}}`).
-          schema:
-            type: object
-            $ref: "definitions/room_key_backup.yaml"
-        404:
-          description: |-
-            The backup was not found.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown backup version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-    delete:
-      summary: Delete the keys from the backup for a given room.
-      description: |-
-        Delete the keys from the backup for a given room.
-      operationId: deleteRoomKeysByRoomId
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: version
-          description: |-
-            The backup from which to delete the key.
-          required: true
-          x-example: "1"
-        - in: path
-          type: string
-          name: roomId
-          description: The ID of the room that the specified key is for.
-          required: true
-          x-example: "!roomid:example.org"
-      responses:
-        200:
-          description: The update succeeded
-          schema:
-            type: object
-            title: RoomKeysUpdateResponse
-            properties:
-              etag:
-                description: |-
-                  The new etag value representing stored keys in the backup.
-                  See `GET /room_keys/version/{version}` for more details.
-                type: string
-                example: "abcdefg"
-              count:
-                description: The number of keys stored in the backup
-                type: integer
-                example: 10
-            required:
-              - etag
-              - count
-        404:
-          description: |-
-            The backup was not found.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown backup version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-  "/room_keys/keys":
-    put:
-      x-addedInMatrixVersion: "1.1"
-      summary: Store several keys in the backup.
-      description: |-
-        Store several keys in the backup.
-      operationId: putRoomKeys
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: version
-          description: |-
-            The backup in which to store the keys. Must be the current backup.
-          required: true
-          x-example: "1"
-        - in: body
-          description: "The backup data."
-          name: backupData
-          required: true
-          schema:
-            type: object
-            properties:
-              rooms:
-                type: object
-                description: |-
-                  A map of room IDs to room key backup data.
-                additionalProperties:
-                  allOf:
-                    - $ref: "definitions/room_key_backup.yaml"
-                example: {
-                  "!room:example.org": {
-                    "sessions": {
-                      "sessionid1": {
-                        "first_message_index": 1,
-                        "forwarded_count": 0,
-                        "is_verified": true,
-                        "session_data": {
-                          "ephemeral": "base64+ephemeral+key",
-                          "ciphertext": "base64+ciphertext+of+JSON+data",
-                          "mac": "base64+mac+of+ciphertext"
-                        }
-                      }
-                    }
-                  }
-                }
-            required:
-              - rooms
-      responses:
-        200:
-          description: The update succeeded
-          schema:
-            type: object
-            title: RoomKeysUpdateResponse
-            properties:
-              etag:
-                description: |-
-                  The new etag value representing stored keys in the backup.
-                  See `GET /room_keys/version/{version}` for more details.
-                type: string
-                example: "abcdefg"
-              count:
-                description: The number of keys stored in the backup
-                type: integer
-                example: 10
-            required:
-              - etag
-              - count
-        403:
-          description: |-
-            The version specified does not match the current backup version.
-            The current version will be included in the `current_version`
-            field.
-          examples:
-            application/json: {
-              "errcode": "M_WRONG_ROOM_KEYS_VERSION",
-              "error": "Wrong backup version.",
-              "current_version": "42"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        404:
-          description: |-
-            The backup was not found.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown backup version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-    get:
-      summary: Retrieve the keys from the backup.
-      description: |-
-        Retrieve the keys from the backup.
-      operationId: getRoomKeys
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: version
-          description: |-
-            The backup from which to retrieve the keys.
-          required: true
-          x-example: "1"
-      responses:
-        200:
-          description: |-
-            The key data.  If no keys are found, then an object with an empty
-            `rooms` property will be returned (`{"rooms": {}}`).
-          schema:
-            type: object
-            properties:
-              rooms:
-                type: object
-                description: |-
-                  A map of room IDs to room key backup data.
-                additionalProperties:
-                  allOf:
-                    - $ref: "definitions/room_key_backup.yaml"
-                example: {
-                  "!room:example.org": {
-                    "sessions": {
-                      "sessionid1": {
-                        "first_message_index": 1,
-                        "forwarded_count": 0,
-                        "is_verified": true,
-                        "session_data": {
-                          "ephemeral": "base64+ephemeral+key",
-                          "ciphertext": "base64+ciphertext+of+JSON+data",
-                          "mac": "base64+mac+of+ciphertext"
-                        }
-                      }
-                    }
-                  }
-                }
-            required:
-              - rooms
-        404:
-          description: The backup was not found.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown backup version."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
-    delete:
-      summary: Delete the keys from the backup.
-      description: |-
-        Delete the keys from the backup.
-      operationId: deleteRoomKeys
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: version
-          description: |-
-            The backup from which to delete the key
-          required: true
-          x-example: "1"
-      responses:
-        200:
-          description: The update succeeded
-          schema:
-            type: object
-            title: RoomKeysUpdateResponse
-            properties:
-              etag:
-                description: |-
-                  The new etag value representing stored keys in the backup.
-                  See `GET /room_keys/version/{version}` for more details.
-                type: string
-                example: "abcdefg"
-              count:
-                description: The number of keys stored in the backup
-                type: integer
-                example: 10
-            required:
-              - etag
-              - count
-        404:
-          description: |-
-            The backup was not found.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown backup version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - End-to-end encryption
diff --git a/data/api/client-server/keys.yaml b/data/api/client-server/keys.yaml
deleted file mode 100644
index 116a661d..00000000
--- a/data/api/client-server/keys.yaml
+++ /dev/null
@@ -1,522 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-# Copyright 2020 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Client Config API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/keys/upload":
-    post:
-      summary: Upload end-to-end encryption keys.
-      description: |-
-        Publishes end-to-end encryption keys for the device.
-      operationId: uploadKeys
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: keys
-          description: |-
-            The keys to be published
-          required: true
-          schema:
-            type: object
-            properties:
-              device_keys:
-                description: |-
-                  Identity keys for the device. May be absent if no new
-                  identity keys are required.
-                allOf:
-                  - $ref: definitions/device_keys.yaml
-              one_time_keys:
-                type: object
-                description: |-
-                  One-time public keys for "pre-key" messages.  The names of
-                  the properties should be in the format
-                  `<algorithm>:<key_id>`. The format of the key is determined
-                  by the [key algorithm](/client-server-api/#key-algorithms).
-
-                  May be absent if no new one-time keys are required.
-                additionalProperties:
-                  type:
-                    - string
-                    - object
-                    # XXX: We can't define an actual object here, so we have to hope
-                    # that people will look at the swagger source or can figure it out
-                    # from the other endpoints/example.
-                    # - type: object
-                    #   title: KeyObject
-                    #   properties:
-                    #     key:
-                    #       type: string
-                    #       description: The key, encoded using unpadded base64.
-                    #     signatures:
-                    #       type: object
-                    #       description: |-
-                    #         Signature for the device. Mapped from user ID to signature object.
-                    #       additionalProperties:
-                    #         type: string
-                    #   required: ['key', 'signatures']
-                example: {
-                  "curve25519:AAAAAQ": "/qyvZvwjiTxGdGU0RCguDCLeR+nmsb3FfNG3/Ve4vU8",
-                  "signed_curve25519:AAAAHg": {
-                    "key": "zKbLg+NrIjpnagy+pIY6uPL4ZwEG2v+8F9lmgsnlZzs",
-                    "signatures": {
-                      "@alice:example.com": {
-                        "ed25519:JLAFKJWSCS": "FLWxXqGbwrb8SM3Y795eB6OA8bwBcoMZFXBqnTn58AYWZSqiD45tlBVcDa2L7RwdKXebW/VzDlnfVJ+9jok1Bw"
-                      }
-                    }
-                  },
-                  "signed_curve25519:AAAAHQ": {
-                    "key": "j3fR3HemM16M7CWhoI4Sk5ZsdmdfQHsKL1xuSft6MSw",
-                    "signatures": {
-                      "@alice:example.com": {
-                        "ed25519:JLAFKJWSCS": "IQeCEPb9HFk217cU9kw9EOiusC6kMIkoIRnbnfOh5Oc63S1ghgyjShBGpu34blQomoalCyXWyhaaT3MrLZYQAA"
-                      }
-                    }
-                  }
-                }
-              fallback_keys:
-                type: object
-                x-addedInMatrixVersion: "1.2"
-                description: |-
-                  The public key which should be used if the device's one-time keys
-                  are exhausted. The fallback key is not deleted once used, but should
-                  be replaced when additional one-time keys are being uploaded. The
-                  server will notify the client of the fallback key being used through
-                  `/sync`.
-
-                  There can only be at most one key per algorithm uploaded, and the server
-                  will only persist one key per algorithm.
-
-                  When uploading a signed key, an additional `fallback: true` key should
-                  be included to denote that the key is a fallback key.
-
-                  May be absent if a new fallback key is not required.
-                additionalProperties:
-                  type:
-                    - string
-                    - object
-                      # XXX: We can't define an actual object here - see one_time_keys.
-                example: {
-                  "curve25519:AAAAAG": "/qyvZvwjiTxGdGU0RCguDCLeR+nmsb3FfNG3/Ve4vU8",
-                  "signed_curve25519:AAAAGj": {
-                    "key": "zKbLg+NrIjpnagy+pIY6uPL4ZwEG2v+8F9lmgsnlZzs",
-                    "fallback": true,
-                    "signatures": {
-                      "@alice:example.com": {
-                        "ed25519:JLAFKJWSCS": "FLWxXqGbwrb8SM3Y795eB6OA8bwBcoMZFXBqnTn58AYWZSqiD45tlBVcDa2L7RwdKXebW/VzDlnfVJ+9jok1Bw"
-                      }
-                    }
-                  }
-                }
-      responses:
-        200:
-          description:
-            The provided keys were successfully uploaded.
-          schema:
-            type: object
-            properties:
-              one_time_key_counts:
-                type: object
-                additionalProperties:
-                  type: integer
-                description: |-
-                  For each key algorithm, the number of unclaimed one-time keys
-                  of that type currently held on the server for this device.
-                  If an algorithm is not listed, the count for that algorithm
-                  is to be assumed zero.
-                example:
-                  curve25519: 10
-                  signed_curve25519: 20
-            required:
-              - one_time_key_counts
-
-      tags:
-        - End-to-end encryption
-  "/keys/query":
-    post:
-      summary: Download device identity keys.
-      description: |-
-        Returns the current devices and identity keys for the given users.
-      operationId: queryKeys
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: query
-          description: |-
-            Query defining the keys to be downloaded
-          required: true
-          schema:
-            type: object
-            properties:
-              timeout:
-                type: integer
-                description: |-
-                  The time (in milliseconds) to wait when downloading keys from
-                  remote servers. 10 seconds is the recommended default.
-                example: 10000
-              device_keys:
-                type: object
-                description: |-
-                  The keys to be downloaded. A map from user ID, to a list of
-                  device IDs, or to an empty list to indicate all devices for the
-                  corresponding user.
-                additionalProperties:
-                  type: array
-                  items:
-                    type: string
-                    description: "device ID"
-                example:
-                  "@alice:example.com": []
-              token:
-                type: string
-                description: |-
-                  If the client is fetching keys as a result of a device update received
-                  in a sync request, this should be the 'since' token of that sync request,
-                  or any later sync token. This allows the server to ensure its response
-                  contains the keys advertised by the notification in that sync.
-            required:
-              - device_keys
-
-      responses:
-        200:
-          description:
-            The device information
-          schema:
-            type: object
-            properties:
-              failures:
-                type: object
-                description: |-
-                  If any remote homeservers could not be reached, they are
-                  recorded here. The names of the properties are the names of
-                  the unreachable servers.
-
-                  If the homeserver could be reached, but the user or device
-                  was unknown, no failure is recorded. Instead, the corresponding
-                  user or device is missing from the `device_keys` result.
-                additionalProperties:
-                  type: object
-                example: {}
-              device_keys:
-                type: object
-                description: |-
-                  Information on the queried devices. A map from user ID, to a
-                  map from device ID to device information.  For each device,
-                  the information returned will be the same as uploaded via
-                  `/keys/upload`, with the addition of an `unsigned`
-                  property.
-                additionalProperties:
-                  type: object
-                  additionalProperties:
-                    title: DeviceInformation
-                    allOf:
-                      - $ref: definitions/device_keys.yaml
-                    properties:
-                      unsigned:
-                        title: UnsignedDeviceInfo
-                        type: object
-                        description: |-
-                          Additional data added to the device key information
-                          by intermediate servers, and not covered by the
-                          signatures.
-                        properties:
-                          device_display_name:
-                            type: string
-                            description:
-                              The display name which the user set on the device.
-                example:
-                  "@alice:example.com":
-                    JLAFKJWSCS: {
-                      "user_id": "@alice:example.com",
-                      "device_id": "JLAFKJWSCS",
-                      "algorithms": [
-                        "m.olm.v1.curve25519-aes-sha2",
-                        "m.megolm.v1.aes-sha2"
-                      ],
-                      "keys": {
-                        "curve25519:JLAFKJWSCS": "3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI",
-                        "ed25519:JLAFKJWSCS": "lEuiRJBit0IG6nUf5pUzWTUEsRVVe/HJkoKuEww9ULI"
-                      },
-                      "signatures": {
-                        "@alice:example.com": {
-                          "ed25519:JLAFKJWSCS": "dSO80A01XiigH3uBiDVx/EjzaoycHcjq9lfQX0uWsqxl2giMIiSPR8a4d291W1ihKJL/a+myXS367WT6NAIcBA"
-                        }
-                      },
-                      "unsigned": {
-                        "device_display_name": "Alice's mobile phone"
-                      }
-                    }
-              master_keys:
-                x-addedInMatrixVersion: "1.1"
-                type: object
-                description: |-
-                  Information on the master cross-signing keys of the queried users.
-                  A map from user ID, to master key information.  For each key, the
-                  information returned will be the same as uploaded via
-                  `/keys/device_signing/upload`, along with the signatures
-                  uploaded via `/keys/signatures/upload` that the requesting user
-                  is allowed to see.
-                additionalProperties:
-                  allOf:
-                    - $ref: definitions/cross_signing_key.yaml
-                example: {
-                  "@alice:example.com": {
-                    "user_id": "@alice:example.com",
-                    "usage": ["master"],
-                    "keys": {
-                      "ed25519:base64+master+public+key": "base64+master+public+key",
-                    }
-                  }
-                }
-              self_signing_keys:
-                x-addedInMatrixVersion: "1.1"
-                type: object
-                description: |-
-                  Information on the self-signing keys of the queried users. A map
-                  from user ID, to self-signing key information.  For each key, the
-                  information returned will be the same as uploaded via
-                  `/keys/device_signing/upload`.
-                additionalProperties:
-                  allOf:
-                    - $ref: definitions/cross_signing_key.yaml
-                example: {
-                  "@alice:example.com": {
-                    "user_id": "@alice:example.com",
-                    "usage": ["self_signing"],
-                    "keys": {
-                      "ed25519:base64+self+signing+public+key": "base64+self+signing+master+public+key",
-                    },
-                    "signatures": {
-                      "@alice:example.com": {
-                        "ed25519:base64+master+public+key": "signature+of+self+signing+key"
-                      }
-                    }
-                  }
-                }
-              user_signing_keys:
-                type: object
-                description: |-
-                  Information on the user-signing key of the user making the
-                  request, if they queried their own device information. A map
-                  from user ID, to user-signing key information.  The
-                  information returned will be the same as uploaded via
-                  `/keys/device_signing/upload`.
-                additionalProperties:
-                  allOf:
-                    - $ref: definitions/cross_signing_key.yaml
-                example: {
-                  "@alice:example.com": {
-                    "user_id": "@alice:example.com",
-                    "usage": ["user_signing"],
-                    "keys": {
-                      "ed25519:base64+user+signing+public+key": "base64+user+signing+master+public+key",
-                    },
-                    "signatures": {
-                      "@alice:example.com": {
-                        "ed25519:base64+master+public+key": "signature+of+user+signing+key"
-                      }
-                    }
-                  }
-                }
-      tags:
-        - End-to-end encryption
-  "/keys/claim":
-    post:
-      summary: Claim one-time encryption keys.
-      description: |-
-        Claims one-time keys for use in pre-key messages.
-      operationId: claimKeys
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: query
-          description: |-
-            Query defining the keys to be claimed
-          required: true
-          schema:
-            type: object
-            properties:
-              timeout:
-                type: integer
-                description: |-
-                  The time (in milliseconds) to wait when downloading keys from
-                  remote servers. 10 seconds is the recommended default.
-                example: 10000
-              one_time_keys:
-                type: object
-                description: |-
-                  The keys to be claimed. A map from user ID, to a map from
-                  device ID to algorithm name.
-                additionalProperties:
-                  type: object
-                  additionalProperties:
-                    type: string
-                    description: algorithm
-                    example: "signed_curve25519"
-                example: {
-                  "@alice:example.com": { "JLAFKJWSCS": "signed_curve25519" }
-                }
-            required:
-              - one_time_keys
-      responses:
-        200:
-          description:
-            The claimed keys.
-          schema:
-            type: object
-            properties:
-              failures:
-                type: object
-                description: |-
-                  If any remote homeservers could not be reached, they are
-                  recorded here. The names of the properties are the names of
-                  the unreachable servers.
-
-                  If the homeserver could be reached, but the user or device
-                  was unknown, no failure is recorded. Instead, the corresponding
-                  user or device is missing from the `one_time_keys` result.
-                additionalProperties:
-                  type: object
-                example: {}
-              one_time_keys:
-                type: object
-                description: |-
-                  One-time keys for the queried devices. A map from user ID, to a
-                  map from devices to a map from `<algorithm>:<key_id>` to the key object.
-
-                  See the [key algorithms](/client-server-api/#key-algorithms) section for information
-                  on the Key Object format.
-
-                  If necessary, the claimed key might be a fallback key. Fallback
-                  keys are re-used by the server until replaced by the device.
-                additionalProperties:
-                  type: object
-                  additionalProperties:
-                    type:
-                      - string
-                      - object
-                      # XXX: We can't define an actual object here, so we have to hope
-                      # that people will look at the swagger source or can figure it out
-                      # from the other endpoints/example.
-                      # - type: object
-                      #   title: KeyObject
-                      #   properties:
-                      #     key:
-                      #       type: string
-                      #       description: The key, encoded using unpadded base64.
-                      #     signatures:
-                      #       type: object
-                      #       description: |-
-                      #         Signature for the device. Mapped from user ID to signature object.
-                      #       additionalProperties:
-                      #         type: string
-                      #   required: ['key', 'signatures']
-                example: {
-                  "@alice:example.com": {
-                    "JLAFKJWSCS": {
-                      "signed_curve25519:AAAAHg": {
-                        "key": "zKbLg+NrIjpnagy+pIY6uPL4ZwEG2v+8F9lmgsnlZzs",
-                        "signatures": {
-                          "@alice:example.com": {
-                            "ed25519:JLAFKJWSCS": "FLWxXqGbwrb8SM3Y795eB6OA8bwBcoMZFXBqnTn58AYWZSqiD45tlBVcDa2L7RwdKXebW/VzDlnfVJ+9jok1Bw"
-                          }
-                        }
-                      }
-                    }
-                  }
-                }
-            required: ['one_time_keys']
-      tags:
-        - End-to-end encryption
-  "/keys/changes":
-    get:
-      summary: Query users with recent device key updates.
-      description: |-
-        Gets a list of users who have updated their device identity keys since a
-        previous sync token.
-
-        The server should include in the results any users who:
-
-        * currently share a room with the calling user (ie, both users have
-          membership state `join`); *and*
-        * added new device identity keys or removed an existing device with
-          identity keys, between `from` and `to`.
-      operationId: getKeysChanges
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          name: from
-          type: string
-          description: |-
-             The desired start point of the list. Should be the `next_batch` field
-             from a response to an earlier call to [`/sync`](/client-server-api/#get_matrixclientv3sync). Users who have not
-             uploaded new device identity keys since this point, nor deleted
-             existing devices with identity keys since then, will be excluded
-             from the results.
-          required: true
-          x-example: "s72594_4483_1934"
-        - in: query
-          name: to
-          type: string
-          description: |-
-             The desired end point of the list. Should be the `next_batch`
-             field from a recent call to [`/sync`](/client-server-api/#get_matrixclientv3sync) - typically the most recent
-             such call. This may be used by the server as a hint to check its
-             caches are up to date.
-          required: true
-          x-example: "s75689_5632_2435"
-      responses:
-        200:
-          description:
-            The list of users who updated their devices.
-          schema:
-            type: object
-            properties:
-              changed:
-                type: array
-                items:
-                  type: string
-                description: |-
-                  The Matrix User IDs of all users who updated their device
-                  identity keys.
-                example: ["@alice:example.com", "@bob:example.org"]
-              left:
-                type: array
-                items:
-                  type: string
-                description: |-
-                  The Matrix User IDs of all users who may have left all
-                  the end-to-end encrypted rooms they previously shared
-                  with the user.
-                example: ["@clara:example.com", "@doug:example.org"]
-      tags:
-        - End-to-end encryption
diff --git a/data/api/client-server/kicking.yaml b/data/api/client-server/kicking.yaml
deleted file mode 100644
index c0d8f671..00000000
--- a/data/api/client-server/kicking.yaml
+++ /dev/null
@@ -1,94 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Kicking API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/kick":
-    post:
-      summary: Kick a user from the room.
-      description: |-
-        Kick a user from the room.
-
-        The caller must have the required power level in order to perform this operation.
-
-        Kicking a user adjusts the target member's membership state to be `leave` with an
-        optional `reason`. Like with other membership changes, a user can directly adjust
-        the target member's state by making a request to `/rooms/<room id>/state/m.room.member/<user id>`.
-      operationId: kick
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room identifier (not alias) from which the user should be kicked.
-          required: true
-          x-example: "!e42d8c:matrix.org"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-                "reason": "Telling unfunny jokes",
-                "user_id": "@cheeky_monkey:matrix.org"
-              }
-            properties:
-              user_id:
-                type: string
-                description: The fully qualified user ID of the user being kicked.
-              reason:
-                type: string
-                description: |-
-                  The reason the user has been kicked. This will be supplied as the
-                  `reason` on the target's updated [`m.room.member`](/client-server-api/#mroommember) event.
-            required: ["user_id"]
-      responses:
-        200:
-          description: The user has been kicked from the room.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object
-        403:
-          description: |-
-            You do not have permission to kick the user from the room. A meaningful `errcode` and
-            description error text will be returned. Example reasons for rejections are:
-
-            - The kicker is not currently in the room.
-            - The kickee is not currently in the room.
-            - The kicker's power level is insufficient to kick users from the room.
-          examples:
-            application/json: {
-                "errcode": "M_FORBIDDEN",
-                "error": "You do not have a high enough power level to kick from this room."
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room membership
diff --git a/data/api/client-server/knocking.yaml b/data/api/client-server/knocking.yaml
deleted file mode 100644
index c2a760ca..00000000
--- a/data/api/client-server/knocking.yaml
+++ /dev/null
@@ -1,125 +0,0 @@
-# Copyright 2021 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Knocking API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/knock/{roomIdOrAlias}":
-    post:
-      x-addedInMatrixVersion: "1.1"
-      summary: Knock on a room, requesting permission to join.
-      description: |-
-        *Note that this API takes either a room ID or alias, unlike other membership APIs.*
-
-        This API "knocks" on the room to ask for permission to join, if the user
-        is allowed to knock on the room. Acceptance of the knock happens out of
-        band from this API, meaning that the client will have to watch for updates
-        regarding the acceptance/rejection of the knock.
-
-        If the room history settings allow, the user will still be able to see
-        history of the room while being in the "knock" state. The user will have
-        to accept the invitation to join the room (acceptance of knock) to see
-        messages reliably. See the `/join` endpoints for more information about
-        history visibility to the user.
-
-        The knock will appear as an entry in the response of the
-        [`/sync`](/client-server-api/#get_matrixclientv3sync) API.
-      operationId: knockRoom
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomIdOrAlias
-          description: The room identifier or alias to knock upon.
-          required: true
-          x-example: "#monkeys:matrix.org"
-        - in: query
-          type: array
-          items:
-            type: string
-          name: server_name
-          description: |-
-            The servers to attempt to knock on the room through. One of the servers
-            must be participating in the room.
-          x-example: ["matrix.org", "elsewhere.ca"]
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              reason:
-                type: string
-                description: |-
-                  Optional reason to be included as the `reason` on the subsequent
-                  membership event.
-                example: "Looking for support"
-      responses:
-        200:
-          description: |-
-            The room has been knocked upon.
-
-            The knocked room ID must be returned in the `room_id` field.
-          examples:
-            application/json: {
-              "room_id": "!d41d8cd:matrix.org"
-            }
-          schema:
-            type: object
-            properties:
-              room_id:
-                type: string
-                description: The knocked room ID.
-            required: ["room_id"]
-        403:
-          description: |-
-            You do not have permission to knock on the room. A meaningful `errcode`
-            and description error text will be returned. Example reasons for rejection are:
-
-            - The room is not set up for knocking.
-            - The user has been banned from the room.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN", "error": "You are not allowed to knock on this room."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        404:
-          description: |-
-            The room could not be found or resolved to a room ID.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND", "error": "That room does not appear to exist."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Room membership
diff --git a/data/api/client-server/leaving.yaml b/data/api/client-server/leaving.yaml
deleted file mode 100644
index ce304883..00000000
--- a/data/api/client-server/leaving.yaml
+++ /dev/null
@@ -1,131 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Leaving API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/leave":
-    post:
-      summary: Stop the requesting user participating in a particular room.
-      description: |-
-        This API stops a user participating in a particular room.
-
-        If the user was already in the room, they will no longer be able to see
-        new events in the room. If the room requires an invite to join, they
-        will need to be re-invited before they can re-join.
-
-        If the user was invited to the room, but had not joined, this call
-        serves to reject the invite.
-
-        The user will still be allowed to retrieve history from the room which
-        they were previously allowed to see.
-      operationId: leaveRoom
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room identifier to leave.
-          required: true
-          x-example: "!nkl290a:matrix.org"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-              "reason": "Saying farewell - thanks for the support!"
-            }
-            properties:
-              reason:
-                x-addedInMatrixVersion: "1.1"
-                type: string
-                description: |-
-                  Optional reason to be included as the `reason` on the subsequent
-                  membership event.
-      responses:
-        200:
-          description: |-
-            The room has been left.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Room membership
-  "/rooms/{roomId}/forget":
-    post:
-      summary: Stop the requesting user remembering about a particular room.
-      description: |-
-        This API stops a user remembering about a particular room.
-
-        In general, history is a first class citizen in Matrix. After this API
-        is called, however, a user will no longer be able to retrieve history
-        for this room. If all users on a homeserver forget a room, the room is
-        eligible for deletion from that homeserver.
-
-        If the user is currently joined to the room, they must leave the room
-        before calling this API.
-      operationId: forgetRoom
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room identifier to forget.
-          required: true
-          x-example: "!au1ba7o:matrix.org"
-      responses:
-        200:
-          description: |-
-            The room has been forgotten.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object
-        400:
-          description: The user has not left the room
-          examples:
-            application/json: {
-              "errcode": "M_UNKNOWN",
-              "error": "User @example:matrix.org is in room !au1ba7o:matrix.org"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Room membership
diff --git a/data/api/client-server/list_joined_rooms.yaml b/data/api/client-server/list_joined_rooms.yaml
deleted file mode 100644
index 177949bf..00000000
--- a/data/api/client-server/list_joined_rooms.yaml
+++ /dev/null
@@ -1,58 +0,0 @@
-# Copyright 2017 Michael Telatynski <7t3chguy@gmail.com>
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Listing API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/joined_rooms":
-    get:
-      summary: Lists the user's current rooms.
-      description: |-
-        This API returns a list of the user's current rooms.
-      operationId: getJoinedRooms
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: A list of the rooms the user is in.
-          schema:
-            type: object
-            required: ["joined_rooms"]
-            properties:
-              joined_rooms:
-                type: array
-                description: |-
-                  The ID of each room in which the user has `joined` membership.
-                items:
-                  type: string
-          examples:
-            application/json: {
-                "joined_rooms": [
-                  "!foo:example.com"
-                ]
-              }
-      tags:
-        - Room membership
diff --git a/data/api/client-server/list_public_rooms.yaml b/data/api/client-server/list_public_rooms.yaml
deleted file mode 100644
index b702f1bf..00000000
--- a/data/api/client-server/list_public_rooms.yaml
+++ /dev/null
@@ -1,229 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Directory API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-paths:
-  "/directory/list/room/{roomId}":
-    get:
-      summary: Gets the visibility of a room in the directory
-      description: |-
-        Gets the visibility of a given room on the server's public room directory.
-      operationId: getRoomVisibilityOnDirectory
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room ID.
-          required: true
-          x-example: "!curbf:matrix.org"
-      responses:
-        200:
-          description: The visibility of the room in the directory
-          schema:
-            type: object
-            properties:
-              visibility:
-                type: string
-                enum: ['private', 'public']
-                description: The visibility of the room in the directory.
-          examples:
-            application/json: {
-              "visibility": "public"
-            }
-        404:
-          description: The room is not known to the server
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Room not found"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room discovery
-    put:
-      summary: Sets the visibility of a room in the room directory
-      description: |-
-        Sets the visibility of a given room in the server's public room
-        directory.
-
-        Servers may choose to implement additional access control checks
-        here, for instance that room visibility can only be changed by
-        the room creator or a server administrator.
-      operationId: setRoomVisibilityOnDirectory
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room ID.
-          required: true
-          x-example: "!curbf:matrix.org"
-        - in: body
-          name: body
-          required: true
-          description: |-
-            The new visibility for the room on the room directory.
-          schema:
-            type: object
-            properties:
-              visibility:
-                type: string
-                enum: ["private", "public"]
-                description: |-
-                  The new visibility setting for the room.
-                  Defaults to 'public'.
-            example: {
-               "visibility": "public"
-            }
-      responses:
-        200:
-          description: The visibility was updated, or no change was needed.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-        404:
-          description: The room is not known to the server
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Room not found"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room discovery
-  "/publicRooms":
-    get:
-      summary: Lists the public rooms on the server.
-      description: |-
-        Lists the public rooms on the server.
-
-        This API returns paginated responses. The rooms are ordered by the number
-        of joined members, with the largest rooms first.
-      operationId: getPublicRooms
-      parameters:
-        - in: query
-          name: limit
-          type: integer
-          description: |-
-            Limit the number of results returned.
-        - in: query
-          name: since
-          type: string
-          description: |-
-            A pagination token from a previous request, allowing clients to
-            get the next (or previous) batch of rooms.
-            The direction of pagination is specified solely by which token
-            is supplied, rather than via an explicit flag.
-        - in: query
-          name: server
-          type: string
-          description: |-
-            The server to fetch the public room lists from. Defaults to the
-            local server.
-      responses:
-        200:
-          description: A list of the rooms on the server.
-          schema:
-            $ref: "definitions/public_rooms_response.yaml"
-      tags:
-        - Room discovery
-    post:
-      summary: Lists the public rooms on the server with optional filter.
-      description: |-
-        Lists the public rooms on the server, with optional filter.
-
-        This API returns paginated responses. The rooms are ordered by the number
-        of joined members, with the largest rooms first.
-      operationId: queryPublicRooms
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          name: server
-          type: string
-          description: |-
-            The server to fetch the public room lists from. Defaults to the
-            local server.
-        - in: body
-          name: body
-          required: true
-          description: |-
-            Options for which rooms to return.
-          schema:
-            type: object
-            properties:
-              limit:
-                type: integer
-                description: |-
-                  Limit the number of results returned.
-              since:
-                type: string
-                description: |-
-                  A pagination token from a previous request, allowing clients
-                  to get the next (or previous) batch of rooms.  The direction
-                  of pagination is specified solely by which token is supplied,
-                  rather than via an explicit flag.
-              filter:
-                type: object
-                title: "Filter"
-                description: |-
-                  Filter to apply to the results.
-                properties:
-                    generic_search_term:
-                      type: string
-                      description: |-
-                        A string to search for in the room metadata, e.g. name,
-                        topic, canonical alias etc. (Optional).
-              include_all_networks:
-                type: boolean
-                description: |-
-                  Whether or not to include all known networks/protocols from
-                  application services on the homeserver. Defaults to false.
-                example: false
-              third_party_instance_id:
-                type: string
-                description: |-
-                  The specific third party network/protocol to request from the
-                  homeserver. Can only be used if `include_all_networks` is false.
-                example: "irc"
-            example: {
-              "limit": 10,
-              "filter": {
-                "generic_search_term": "foo"
-              },
-              "include_all_networks": false,
-              "third_party_instance_id": "irc"
-            }
-      responses:
-        200:
-          description: A list of the rooms on the server.
-          schema:
-            $ref: "definitions/public_rooms_response.yaml"
-      tags:
-        - Room discovery
diff --git a/data/api/client-server/login.yaml b/data/api/client-server/login.yaml
deleted file mode 100644
index 8865665f..00000000
--- a/data/api/client-server/login.yaml
+++ /dev/null
@@ -1,216 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Registration and Login API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/login":
-    get:
-      summary: Get the supported login types to authenticate users
-      description: |-
-        Gets the homeserver's supported login types to authenticate users. Clients
-        should pick one of these and supply it as the `type` when logging in.
-      operationId: getLoginFlows
-      responses:
-        200:
-          description: The login types the homeserver supports
-          examples:
-            application/json: {
-              "flows": [
-                {"type": "m.login.password"}
-              ]
-            }
-          schema:
-            type: object
-            properties:
-              flows:
-                type: array
-                description: The homeserver's supported login types
-                items:
-                  type: object
-                  title: LoginFlow
-                  properties:
-                    type:
-                      description: |-
-                        The login type. This is supplied as the `type` when
-                        logging in.
-                      type: string
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Session management
-    post:
-      summary: Authenticates the user.
-      description: |-
-        Authenticates the user, and issues an access token they can
-        use to authorize themself in subsequent requests.
-
-        If the client does not supply a `device_id`, the server must
-        auto-generate one.
-
-        The returned access token must be associated with the `device_id`
-        supplied by the client or generated by the server. The server may
-        invalidate any access token previously associated with that device. See
-        [Relationship between access tokens and devices](/client-server-api/#relationship-between-access-tokens-and-devices).
-      operationId: login
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-                "type": "m.login.password",
-                "identifier": {
-                  "type": "m.id.user",
-                  "user": "cheeky_monkey"
-                },
-                "password": "ilovebananas",
-                "initial_device_display_name": "Jungle Phone"
-              }
-            properties:
-              type:
-                type: string
-                enum: ["m.login.password", "m.login.token"]
-                description: The login type being used.
-              identifier:
-                "$ref": "definitions/user_identifier.yaml"
-              user:
-                type: string
-                description: The fully qualified user ID or just local part of the user ID, to log in.  Deprecated in favour of `identifier`.
-              medium:
-                type: string
-                description: When logging in using a third party identifier, the medium of the identifier. Must be 'email'.  Deprecated in favour of `identifier`.
-              address:
-                type: string
-                description: Third party identifier for the user.  Deprecated in favour of `identifier`.
-              password:
-                type: string
-                description: |-
-                  Required when `type` is `m.login.password`. The user's
-                  password.
-              token:
-                type: string
-                description: |-
-                  Required when `type` is `m.login.token`. Part of Token-based login.
-              device_id:
-                type: string
-                description: |-
-                  ID of the client device. If this does not correspond to a
-                  known client device, a new device will be created. The given
-                  device ID must not be the same as a
-                  [cross-signing](/client-server-api/#cross-signing) key ID.
-                  The server will auto-generate a device_id
-                  if this is not specified.
-              initial_device_display_name:
-                type: string
-                description: |-
-                  A display name to assign to the newly-created device. Ignored
-                  if `device_id` corresponds to a known device.
-            required: ["type"]
-
-      responses:
-        200:
-          description: The user has been authenticated.
-          examples:
-            application/json: {
-                "user_id": "@cheeky_monkey:matrix.org",
-                "access_token": "abc123",
-                "device_id": "GHTYAJCE",
-                "well_known": {
-                  "m.homeserver": {
-                    "base_url": "https://example.org"
-                  },
-                  "m.identity_server": {
-                    "base_url": "https://id.example.org"
-                  }
-                }
-              }
-          schema:
-            type: object
-            properties:
-              user_id:
-                type: string
-                description: The fully-qualified Matrix ID for the account.
-              access_token:
-                type: string
-                description: |-
-                  An access token for the account.
-                  This access token can then be used to authorize other requests.
-              home_server:
-                type: string
-                description: |-
-                  The server_name of the homeserver on which the account has
-                  been registered.
-
-                  **Deprecated**. Clients should extract the server_name from
-                  `user_id` (by splitting at the first colon) if they require
-                  it. Note also that `homeserver` is not spelt this way.
-              device_id:
-                type: string
-                description: |-
-                  ID of the logged-in device. Will be the same as the
-                  corresponding parameter in the request, if one was specified.
-              well_known:
-                description: |-
-                  Optional client configuration provided by the server. If present,
-                  clients SHOULD use the provided object to reconfigure themselves,
-                  optionally validating the URLs within. This object takes the same
-                  form as the one returned from .well-known autodiscovery.
-                allOf:
-                  - "$ref": "definitions/wellknown/full.yaml"
-        400:
-          description: |-
-            Part of the request was invalid. For example, the login type may not be recognised.
-          examples:
-            application/json: {
-                  "errcode": "M_UNKNOWN",
-                  "error": "Bad login type."
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        403:
-          description: |-
-            The login attempt failed. This can include one of the following error codes:
-              * `M_FORBIDDEN`: The provided authentication data was incorrect
-                or the requested device ID is the same as a cross-signing key
-                ID.
-              * `M_USER_DEACTIVATED`: The user has been deactivated.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Session management
diff --git a/data/api/client-server/logout.yaml b/data/api/client-server/logout.yaml
deleted file mode 100644
index ad809de0..00000000
--- a/data/api/client-server/logout.yaml
+++ /dev/null
@@ -1,73 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Registration and Login API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/logout":
-    post:
-      summary: Invalidates a user access token
-      description: |-
-        Invalidates an existing access token, so that it can no longer be used for
-        authorization. The device associated with the access token is also deleted.
-        [Device keys](/client-server-api/#device-keys) for the device are deleted alongside the device.
-      operationId: logout
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: The access token used in the request was successfully invalidated.
-          schema:
-            type: object
-            properties: {}
-      tags:
-        - Session management
-  "/logout/all":
-    post:
-      summary: Invalidates all access tokens for a user
-      description: |-
-        Invalidates all access tokens for a user, so that they can no longer be used for
-        authorization. This includes the access token that made this request. All devices
-        for the user are also deleted. [Device keys](/client-server-api/#device-keys) for the device are
-        deleted alongside the device.
-
-        This endpoint does not use the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api) because
-        User-Interactive Authentication is designed to protect against attacks where the
-        someone gets hold of a single access token then takes over the account. This
-        endpoint invalidates all access tokens for the user, including the token used in
-        the request, and therefore the attacker is unable to take over the account in
-        this way.
-      operationId: logout_all
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: The user's access tokens were successfully invalidated.
-          schema:
-            type: object
-            properties: {}
-      tags:
-        - Session management
diff --git a/data/api/client-server/message_pagination.yaml b/data/api/client-server/message_pagination.yaml
deleted file mode 100644
index b63f9e17..00000000
--- a/data/api/client-server/message_pagination.yaml
+++ /dev/null
@@ -1,166 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Rooms API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/messages":
-    get:
-      summary: Get a list of events for this room
-      description: |-
-        This API returns a list of message and state events for a room. It uses
-        pagination query parameters to paginate history in the room.
-
-        *Note*: This endpoint supports lazy-loading of room member events. See
-        [Lazy-loading room members](/client-server-api/#lazy-loading-room-members) for more information.
-      operationId: getRoomEvents
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room to get events from.
-          required: true
-          x-example: "!636q39766251:example.com"
-        - in: query
-          type: string
-          name: from
-          description: |-
-            The token to start returning events from. This token can be obtained
-            from a `prev_batch` or `next_batch` token returned by the `/sync` endpoint,
-            or from an `end` token returned by a previous request to this endpoint.
-
-            This endpoint can also accept a value returned as a `start` token
-            by a previous request to this endpoint, though servers are not
-            required to support this. Clients should not rely on the behaviour.
-          required: true
-          x-example: "s345_678_333"
-        - in: query
-          type: string
-          name: to
-          description: |-
-            The token to stop returning events at. This token can be obtained from
-            a `prev_batch` or `next_batch` token returned by the `/sync` endpoint,
-            or from an `end` token returned by a previous request to this endpoint.
-          required: false
-        - in: query
-          type: string
-          enum: ["b", "f"]
-          name: dir
-          description: |-
-            The direction to return events from. If this is set to `f`, events
-            will be returned in chronological order starting at `from`. If it
-            is set to `b`, events will be returned in *reverse* chronological
-            order, again starting at `from`.
-          required: true
-          x-example: "b"
-        - in: query
-          type: integer
-          name: limit
-          description: |-
-            The maximum number of events to return. Default: 10.
-          x-example: "3"
-        - in: query
-          type: string
-          name: filter
-          description: |-
-            A JSON RoomEventFilter to filter returned events with.
-          x-example: |-
-            {"contains_url":true}
-      responses:
-        200:
-          description: A list of messages with a new token to request more.
-          schema:
-            type: object
-            description: A list of messages with a new token to request more.
-            properties:
-              start:
-                type: string
-                description: |-
-                  A token corresponding to the start of `chunk`. This will be the same as
-                  the value given in `from`.
-              end:
-                type: string
-                description: |-
-                  A token corresponding to the end of `chunk`. This token can be passed
-                  back to this endpoint to request further events.
-
-                  If no further events are available (either because we have
-                  reached the start of the timeline, or because the user does
-                  not have permission to see any more events), this property
-                  is omitted from the response.
-              chunk:
-                type: array
-                description: |-
-                  A list of room events. The order depends on the `dir` parameter.
-                  For `dir=b` events will be in reverse-chronological order,
-                  for `dir=f` in chronological order. (The exact definition of `chronological`
-                  is dependent on the server implementation.)
-
-                  Note that an empty `chunk` does not *necessarily* imply that no more events
-                  are available. Clients should continue to paginate until no `end` property
-                  is returned.
-                items:
-                  "$ref": "definitions/client_event.yaml"
-              state:
-                type: array
-                description: |-
-                  A list of state events relevant to showing the `chunk`. For example, if
-                  `lazy_load_members` is enabled in the filter then this may contain
-                  the membership events for the senders of events in the `chunk`.
-
-                  Unless `include_redundant_members` is `true`, the server
-                  may remove membership events which would have already been
-                  sent to the client in prior calls to this endpoint, assuming
-                  the membership of those members has not changed.
-                items:
-                  $ref: "definitions/client_event.yaml"
-            required: [start, chunk]
-          examples:
-            application/json: {
-                "start": "t47429-4392820_219380_26003_2265",
-                "end": "t47409-4357353_219380_26003_2265",
-                "chunk": [
-                  {
-                    "room_id": "!636q39766251:example.com",
-                    "$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"
-                  },
-                  {
-                    "room_id": "!636q39766251:example.com",
-                    "$ref": "../../event-schemas/examples/m.room.name.yaml"
-                  },
-                  {
-                    "room_id": "!636q39766251:example.com",
-                    "$ref": "../../event-schemas/examples/m.room.message$m.video.yaml"
-                  }
-                ]
-              }
-        403:
-          description: >
-            You aren't a member of the room.
-      tags:
-        - Room participation
diff --git a/data/api/client-server/notifications.yaml b/data/api/client-server/notifications.yaml
deleted file mode 100644
index 6d141ff8..00000000
--- a/data/api/client-server/notifications.yaml
+++ /dev/null
@@ -1,134 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Notifications API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/notifications":
-    get:
-      summary: Gets a list of events that the user has been notified about
-      description: |-
-        This API is used to paginate through the list of events that the
-        user has been, or would have been notified about.
-      operationId: getNotifications
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: from
-          description: |-
-            Pagination token to continue from. This should be the `next_token`
-            returned from an earlier call to this endpoint.
-          required: false
-          x-example: "xxxxx"
-        - in: query
-          type: integer
-          name: limit
-          description: Limit on the number of events to return in this request.
-          required: false
-          x-example: 20
-        - in: query
-          name: only
-          type: string
-          description: |-
-            Allows basic filtering of events returned. Supply `highlight`
-            to return only events where the notification had the highlight
-            tweak set.
-          required: false
-          x-example: "highlight"
-      responses:
-        200:
-          description: A batch of events is being returned
-          examples:
-            application/json: {
-                "next_token": "abcdef",
-                "notifications": [
-                  {
-                    "actions": [
-                      "notify"
-                    ],
-                    "profile_tag": "hcbvkzxhcvb",
-                    "read": true,
-                    "room_id": "!abcdefg:example.com",
-                    "ts": 1475508881945,
-                    "event": {
-                      "$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"
-                    }
-                  }
-                ]
-              }
-          schema:
-            type: object
-            required: ["notifications"]
-            properties:
-              next_token:
-                type: string
-                description: |-
-                  The token to supply in the `from` param of the next
-                  `/notifications` request in order to request more
-                  events. If this is absent, there are no more results.
-              notifications:
-                type: array
-                items:
-                  type: object
-                  required: ["actions", "event", "read", "room_id", "ts"]
-                  title: Notification
-                  properties:
-                    actions:
-                      type: array
-                      description: |-
-                        The action(s) to perform when the conditions for this rule are met.
-                        See [Push Rules: API](/client-server-api/#push-rules-api).
-                      items:
-                        type:
-                        - object
-                        - string
-                    event:
-                      type: object
-                      title: Event
-                      description: The Event object for the event that triggered the notification.
-                      "$ref": "definitions/client_event_without_room_id.yaml"
-                    profile_tag:
-                      type: string
-                      description: The profile tag of the rule that matched this event.
-                    read:
-                      type: boolean
-                      description: |-
-                        Indicates whether the user has sent a read receipt indicating
-                        that they have read this message.
-                    room_id:
-                      type: string
-                      description: The ID of the room in which the event was posted.
-                    ts:
-                      type: integer
-                      description: |-
-                        The unix timestamp at which the event notification was sent,
-                        in milliseconds.
-                description: The list of events that triggered notifications.
-      tags:
-        - Push notifications
diff --git a/data/api/client-server/old_sync.yaml b/data/api/client-server/old_sync.yaml
deleted file mode 100644
index 8813d10f..00000000
--- a/data/api/client-server/old_sync.yaml
+++ /dev/null
@@ -1,328 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Sync API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/events":
-    get:
-      summary: Listen on the event stream.
-      description: |-
-        This will listen for new events and return them to the caller. This will
-        block until an event is received, or until the `timeout` is reached.
-
-        This endpoint was deprecated in r0 of this specification. Clients
-        should instead call the [`/sync`](/client-server-api/#get_matrixclientv3sync)
-        endpoint with a `since` parameter. See
-        the [migration guide](https://matrix.org/docs/guides/migrating-from-client-server-api-v-1#deprecated-endpoints).
-      operationId: getEvents
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: from
-          description: |-
-            The token to stream from. This token is either from a previous
-            request to this API or from the initial sync API.
-          required: false
-          x-example: "s3456_9_0"
-        - in: query
-          type: integer
-          name: timeout
-          description: The maximum time in milliseconds to wait for an event.
-          required: false
-          x-example: "35000"
-      responses:
-        200:
-          description: "The events received, which may be none."
-          examples:
-            application/json: {
-                "start": "s3456_9_0",
-                "end": "s3457_9_0",
-                "chunk": [
-                  {"$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"}
-                ]
-              }
-          schema:
-            type: object
-            properties:
-              start:
-                type: string
-                description: |-
-                  A token which correlates to the start of `chunk`. This
-                  is usually the same token supplied to `from=`.
-              end:
-                type: string
-                description: |-
-                  A token which correlates to the end of `chunk`. This
-                  token should be used in the next request to `/events`.
-              chunk:
-                type: array
-                description: "An array of events."
-                items:
-                  $ref: "definitions/client_event.yaml"
-        400:
-          description: "Bad pagination `from` parameter."
-      tags:
-        - Room participation
-      deprecated: true
-  "/initialSync":
-    get:
-      summary: Get the user's current state.
-      description: |-
-        This returns the full state for this user, with an optional limit on the
-        number of messages per room to return.
-
-        This endpoint was deprecated in r0 of this specification. Clients
-        should instead call the [`/sync`](/client-server-api/#get_matrixclientv3sync)
-        endpoint with no `since` parameter. See
-        the [migration guide](https://matrix.org/docs/guides/migrating-from-client-server-api-v-1#deprecated-endpoints).
-      operationId: initialSync
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: integer
-          name: limit
-          description: The maximum number of messages to return for each room.
-          required: false
-          x-example: "2"
-        - in: query
-          type: boolean
-          name: archived
-          description: |-
-            Whether to include rooms that the user has left. If `false` then
-            only rooms that the user has been invited to or has joined are
-            included. If set to `true` then rooms that the user has left are
-            included as well. By default this is `false`.
-          required: false
-          x-example: "true"
-      responses:
-        200:
-          description: The user's current state.
-          examples:
-            application/json: {
-                  "end": "s3456_9_0",
-                  "presence": [
-                      {"$ref": "../../event-schemas/examples/m.presence.yaml"}
-                  ],
-                  "account_data": [
-                    {
-                      "type": "org.example.custom.config",
-                      "content": {
-                        "custom_config_key": "custom_config_value"
-                      }
-                    }
-                  ],
-                  "rooms": [
-                      {
-                          "membership": "join",
-                          "messages": {
-                              "chunk": [
-                                  {
-                                    "room_id": "!TmaZBKYIFrIPVGoUYp:localhost",
-                                    "$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"
-                                  },
-                                  {
-                                    "room_id": "!TmaZBKYIFrIPVGoUYp:localhost",
-                                    "$ref": "../../event-schemas/examples/m.room.message$m.video.yaml"
-                                  }
-                              ],
-                              "end": "s3456_9_0",
-                              "start": "t44-3453_9_0"
-                          },
-                          "room_id": "!TmaZBKYIFrIPVGoUYp:localhost",
-                          "state": [
-                              {
-                                "room_id": "!TmaZBKYIFrIPVGoUYp:localhost",
-                                "$ref": "../../event-schemas/examples/m.room.join_rules.yaml"
-                              },
-                              {
-                                "room_id": "!TmaZBKYIFrIPVGoUYp:localhost",
-                                "$ref": "../../event-schemas/examples/m.room.member.yaml"
-                              },
-                              {
-                                "room_id": "!TmaZBKYIFrIPVGoUYp:localhost",
-                                "$ref": "../../event-schemas/examples/m.room.create.yaml"
-                              },
-                              {
-                                "room_id": "!TmaZBKYIFrIPVGoUYp:localhost",
-                                "$ref": "../../event-schemas/examples/m.room.power_levels.yaml"
-                              }
-                          ],
-                          "visibility": "private",
-                          "account_data": [
-                            {
-                              "type": "m.tag",
-                              "content": {"tags": {"work": {"order": 1}}}
-                            },
-                            {
-                              "type": "org.example.custom.room.config",
-                              "content": {
-                                "custom_config_key": "custom_config_value"
-                              }
-                            }
-                          ]
-                      }
-                  ]
-              }
-          schema:
-            type: object
-            properties:
-              end:
-                type: string
-                description: |-
-                  A token which correlates to the end of the timelines returned. This
-                  token should be used with the `/events` endpoint to listen for new
-                  events.
-              presence:
-                type: array
-                description: A list of presence events.
-                items:
-                  $ref: "definitions/client_event.yaml"
-              rooms:
-                type: array
-                items:
-                  type: object
-                  title: RoomInfo
-                  properties:
-                    room_id:
-                      type: string
-                      description: "The ID of this room."
-                    membership:
-                      type: string
-                      description: "The user's membership state in this room."
-                      enum: ["invite", "join", "leave", "ban"]
-                    invite:
-                        type: object
-                        title: "InviteEvent"
-                        description: "The invite event if `membership` is `invite`"
-                        $ref: "definitions/client_event.yaml"
-                    messages:
-                      type: object
-                      title: PaginationChunk
-                      description: "The pagination chunk for this room."
-                      properties:
-                        start:
-                          type: string
-                          description: |-
-                            A token which correlates to the start of `chunk`.
-                            Can be passed to
-                            [`/rooms/<room_id>/messages`](#get_matrixclientv3roomsroomidmessages)
-                            to retrieve earlier events.
-
-                            If no earlier events are available, this property may be omitted from
-                            the response.
-                        end:
-                          type: string
-                          description: |-
-                            A token which correlates to the end of `chunk`.
-                            Can be passed to
-                            [`/rooms/<room_id>/messages`](#get_matrixclientv3roomsroomidmessages)
-                            to retrieve later events.
-                        chunk:
-                          type: array
-                          description: |-
-                            If the user is a member of the room this will be a
-                            list of the most recent messages for this room. If
-                            the user has left the room this will be the
-                            messages that preceded them leaving. This array
-                            will consist of at most `limit` elements.
-                          items:
-                            $ref: "definitions/client_event.yaml"
-                      required: ["end", "chunk"]
-                    state:
-                      type: array
-                      description: |-
-                        If the user is a member of the room this will be the
-                        current state of the room as a list of events. If the
-                        user has left the room this will be the state of the
-                        room when they left it.
-                      items:
-                        $ref: "definitions/client_event.yaml"
-                    visibility:
-                      type: string
-                      enum: ["private", "public"]
-                      description: |-
-                        Whether this room is visible to the `/publicRooms` API
-                        or not."
-                    account_data:
-                      type: array
-                      description: |-
-                        The private data that this user has attached to
-                        this room.
-                      items:
-                        $ref: "definitions/client_event.yaml"
-                  required: ["room_id", "membership"]
-              account_data:
-                type: array
-                description: |-
-                  The global private data created by this user.
-                items:
-                  title: Event
-                  type: object
-                  allOf:
-                    - "$ref": "../../event-schemas/schema/core-event-schema/event.yaml"
-            required: ["end", "rooms", "presence"]
-        404:
-          description: There is no avatar URL for this user or this user does not exist.
-      tags:
-        - Room participation
-      deprecated: true
-  "/events/{eventId}":
-    get:
-      summary: Get a single event by event ID.
-      description: |-
-        Get a single event based on `event_id`. You must have permission to
-        retrieve this event e.g. by being a member in the room for this event.
-
-        This endpoint was deprecated in r0 of this specification. Clients
-        should instead call the
-        [/rooms/{roomId}/event/{eventId}](/client-server-api/#get_matrixclientv3roomsroomideventeventid) API
-        or the [/rooms/{roomId}/context/{eventId](/client-server-api/#get_matrixclientv3roomsroomidcontexteventid) API.
-      operationId: getOneEvent
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: eventId
-          description: The event ID to get.
-          required: true
-          x-example: "$asfDuShaf7Gafaw:matrix.org"
-      responses:
-        200:
-          description: The full event.
-          examples:
-            application/json: {"$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"}
-          schema:
-            $ref: "definitions/client_event.yaml"
-        404:
-          description: The event was not found or you do not have permission to read this event.
-      tags:
-        - Room participation
-      deprecated: true
diff --git a/data/api/client-server/openid.yaml b/data/api/client-server/openid.yaml
deleted file mode 100644
index a6adeb7f..00000000
--- a/data/api/client-server/openid.yaml
+++ /dev/null
@@ -1,83 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server OpenID API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/user/{userId}/openid/request_token":
-    post:
-      summary: Get an OpenID token object to verify the requester's identity.
-      description: |-
-        Gets an OpenID token object that the requester may supply to another
-        service to verify their identity in Matrix. The generated token is only
-        valid for exchanging for user information from the federation API for
-        OpenID.
-
-        The access token generated is only valid for the OpenID API. It cannot
-        be used to request another OpenID access token or call `/sync`, for
-        example.
-      operationId: requestOpenIdToken
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          description: |-
-            The user to request and OpenID token for. Should be the user who
-            is authenticated for the request.
-          required: true
-          x-example: "@alice:example.com"
-        - in: body
-          name: body
-          description: An empty object. Reserved for future expansion.
-          required: true
-          schema:
-            type: object
-            example: {}
-      responses:
-        200:
-          description: |-
-            OpenID token information. This response is nearly compatible with the
-            response documented in the
-            [OpenID Connect 1.0 Specification](http://openid.net/specs/openid-connect-core-1_0.html#TokenResponse)
-            with the only difference being the lack of an `id_token`. Instead,
-            the Matrix homeserver's name is provided.
-          examples:
-            application/json: {
-              "access_token": "SomeT0kenHere",
-              "token_type": "Bearer",
-              "matrix_server_name": "example.com",
-              "expires_in": 3600,
-            }
-          schema:
-            $ref: "definitions/openid_token.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - OpenID
diff --git a/data/api/client-server/peeking_events.yaml b/data/api/client-server/peeking_events.yaml
deleted file mode 100644
index 4b8a6a96..00000000
--- a/data/api/client-server/peeking_events.yaml
+++ /dev/null
@@ -1,109 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Sync Guest API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  # With an extra " " to disambiguate from the getEvents endpoint
-  # The extra space makes it sort first for what I'm sure is a good reason.
-  "/events ":
-    get:
-      summary: Listen on the event stream of a particular room.
-      description: |-
-        This will listen for new events related to a particular room and return
-        them to the caller. This will block until an event is received, or until
-        the `timeout` is reached.
-
-        This API is the same as the normal `/events` endpoint, but can be
-        called by users who have not joined the room.
-
-        Note that the normal `/events` endpoint has been deprecated. This
-        API will also be deprecated at some point, but its replacement is not
-        yet known.
-      operationId: peekEvents
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: from
-          description: |-
-            The token to stream from. This token is either from a previous
-            request to this API or from the initial sync API.
-          required: false
-          x-example: "s3456_9_0"
-        - in: query
-          type: integer
-          name: timeout
-          description: The maximum time in milliseconds to wait for an event.
-          required: false
-          x-example: "35000"
-        - in: query
-          type: string
-          name: room_id
-          description: |-
-            The room ID for which events should be returned.
-          x-example:
-            - "!somewhere:over.the.rainbow"
-      responses:
-        200:
-          description: "The events received, which may be none."
-          examples:
-            application/json: {
-                "start": "s3456_9_0",
-                "end": "s3457_9_0",
-                "chunk": [
-                  {
-                    "room_id": "!somewhere:over.the.rainbow",
-                    "$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"
-                  }
-                ]
-              }
-          schema:
-            type: object
-            properties:
-              start:
-                type: string
-                description: |-
-                  A token which correlates to the first value in `chunk`. This
-                  is usually the same token supplied to `from=`.
-              end:
-                type: string
-                description: |-
-                  A token which correlates to the last value in `chunk`. This
-                  token should be used in the next request to `/events`.
-              chunk:
-                type: array
-                description: "An array of events."
-                items:
-                  type: object
-                  title: Event
-                  allOf:
-                    - "$ref": "definitions/client_event.yaml"
-        400:
-          description: "Bad pagination `from` parameter."
-      tags:
-        - Room participation
diff --git a/data/api/client-server/presence.yaml b/data/api/client-server/presence.yaml
deleted file mode 100644
index 6d144db2..00000000
--- a/data/api/client-server/presence.yaml
+++ /dev/null
@@ -1,138 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Presence API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/presence/{userId}/status":
-    put:
-      summary: Update this user's presence state.
-      description: |-
-        This API sets the given user's presence state. When setting the status,
-        the activity time is updated to reflect that activity; the client does
-        not need to specify the `last_active_ago` field. You cannot set the
-        presence state of another user.
-      operationId: setPresence
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          description: The user whose presence state to update.
-          required: true
-          x-example: "@alice:example.com"
-        - in: body
-          name: presenceState
-          description: The updated presence state.
-          required: true
-          schema:
-            type: object
-            example: {
-                "presence": "online",
-                "status_msg": "I am here."
-              }
-            properties:
-              presence:
-                type: string
-                enum: ["online", "offline", "unavailable"]
-                description: The new presence state.
-              status_msg:
-                type: string
-                description: The status message to attach to this state.
-            required: ["presence"]
-      responses:
-        200:
-          description: The new presence state was set.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object  # empty json object
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Presence
-    get:
-      summary: Get this user's presence state.
-      description: |-
-        Get the given user's presence state.
-      operationId: getPresence
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          description: The user whose presence state to get.
-          required: true
-          x-example: "@alice:example.com"
-      responses:
-        200:
-          description: The presence state for this user.
-          examples:
-            application/json: {
-                "presence": "unavailable",
-                "last_active_ago": 420845
-              }
-          schema:
-            type: object
-            properties:
-              presence:
-                type: string
-                enum: ["online", "offline", "unavailable"]
-                description: This user's presence.
-              last_active_ago:
-                type: integer
-                description: |-
-                  The length of time in milliseconds since an action was performed
-                  by this user.
-              status_msg:
-                type: [string, "null"]
-                description: The state message for this user if one was set.
-              currently_active:
-                type: boolean
-                description: "Whether the user is currently active"
-            required: ["presence"]
-        404:
-          description: |-
-            There is no presence state for this user. This user may not exist or
-            isn't exposing presence information to you.
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        403:
-          description: You are not allowed to see this user's presence status.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "You are not allowed to see their presence"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Presence
diff --git a/data/api/client-server/profile.yaml b/data/api/client-server/profile.yaml
deleted file mode 100644
index e8bdc4de..00000000
--- a/data/api/client-server/profile.yaml
+++ /dev/null
@@ -1,234 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Profile API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/profile/{userId}/displayname":
-    put:
-      summary: Set the user's display name.
-      description: |-
-        This API sets the given user's display name. You must have permission to
-        set this user's display name, e.g. you need to have their `access_token`.
-      operationId: setDisplayName
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          description: The user whose display name to set.
-          required: true
-          x-example: "@alice:example.com"
-        - in: body
-          name: displayName
-          description: The new display name information.
-          required: true
-          schema:
-            type: object
-            example: {
-                "displayname": "Alice Margatroid"
-              }
-            properties:
-              displayname:
-                type: string
-                description: The new display name for this user.
-      responses:
-        200:
-          description: The display name was set.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object  # empty json object
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - User data
-    get:
-      summary: Get the user's display name.
-      description: |-
-        Get the user's display name. This API may be used to fetch the user's
-        own displayname or to query the name of other users; either locally or
-        on remote homeservers.
-      operationId: getDisplayName
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          description: The user whose display name to get.
-          required: true
-          x-example: "@alice:example.com"
-      responses:
-        200:
-          description: The display name for this user.
-          examples:
-            application/json: {
-                "displayname": "Alice Margatroid"
-              }
-          schema:
-            type: object
-            properties:
-              displayname:
-                type: string
-                description: The user's display name if they have set one, otherwise not present.
-        404:
-          description: There is no display name for this user or this user does not exist.
-      tags:
-        - User data
-  "/profile/{userId}/avatar_url":
-    put:
-      summary: Set the user's avatar URL.
-      description: |-
-        This API sets the given user's avatar URL. You must have permission to
-        set this user's avatar URL, e.g. you need to have their `access_token`.
-      operationId: setAvatarUrl
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          description: The user whose avatar URL to set.
-          required: true
-          x-example: "@alice:example.com"
-        - in: body
-          name: avatar_url
-          description: The new avatar information.
-          required: true
-          schema:
-            type: object
-            example: {
-                "avatar_url": "mxc://matrix.org/wefh34uihSDRGhw34"
-              }
-            properties:
-              avatar_url:
-                type: string
-                format: uri
-                description: The new avatar URL for this user.
-      responses:
-        200:
-          description: The avatar URL was set.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object  # empty json object
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - User data
-    get:
-      summary: Get the user's avatar URL.
-      description: |-
-        Get the user's avatar URL. This API may be used to fetch the user's
-        own avatar URL or to query the URL of other users; either locally or
-        on remote homeservers.
-      operationId: getAvatarUrl
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          description: The user whose avatar URL to get.
-          required: true
-          x-example: "@alice:example.com"
-      responses:
-        200:
-          description: The avatar URL for this user.
-          examples:
-            application/json: {
-                "avatar_url": "mxc://matrix.org/SDGdghriugerRg"
-              }
-          schema:
-            type: object
-            properties:
-              avatar_url:
-                type: string
-                format: uri
-                description: The user's avatar URL if they have set one, otherwise not present.
-        404:
-          description: There is no avatar URL for this user or this user does not exist.
-      tags:
-        - User data
-  "/profile/{userId}":
-    get:
-      summary: Get this user's profile information.
-      description: |-
-        Get the combined profile information for this user. This API may be used
-        to fetch the user's own profile information or other users; either
-        locally or on remote homeservers. This API may return keys which are not
-        limited to `displayname` or `avatar_url`.
-      operationId: getUserProfile
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          description: The user whose profile information to get.
-          required: true
-          x-example: "@alice:example.com"
-      responses:
-        200:
-          description: The avatar URL for this user.
-          examples:
-            application/json: {
-                "avatar_url": "mxc://matrix.org/SDGdghriugerRg",
-                "displayname": "Alice Margatroid"
-              }
-          schema:
-            type: object
-            properties:
-              avatar_url:
-                type: string
-                format: uri
-                description: The user's avatar URL if they have set one, otherwise not present.
-              displayname:
-                type: string
-                description: The user's display name if they have set one, otherwise not present.
-        403:
-          x-addedInMatrixVersion: "1.2"
-          description: The server is unwilling to disclose whether the user exists and/or has profile information.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "Profile lookup over federation is disabled on this homeserver"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        404:
-          description: There is no profile information for this user or this user does not exist.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Profile not found"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - User data
diff --git a/data/api/client-server/pusher.yaml b/data/api/client-server/pusher.yaml
deleted file mode 100644
index ec46c353..00000000
--- a/data/api/client-server/pusher.yaml
+++ /dev/null
@@ -1,270 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Push API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/pushers":
-    get:
-      summary: Gets the current pushers for the authenticated user
-      description: |-
-          Gets all currently active pushers for the authenticated user.
-      operationId: getPushers
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: The pushers for this user.
-          examples:
-            application/json: {
-              "pushers": [
-                {
-                  "pushkey": "Xp/MzCt8/9DcSNE9cuiaoT5Ac55job3TdLSSmtmYl4A=",
-                  "kind": "http",
-                  "app_id": "face.mcapp.appy.prod",
-                  "app_display_name": "Appy McAppface",
-                  "device_display_name": "Alice's Phone",
-                  "profile_tag": "xyz",
-                  "lang": "en-US",
-                  "data": {
-                    "url": "https://example.com/_matrix/push/v1/notify"
-                  }
-                }
-              ]
-            }
-          schema:
-            type: object
-            properties:
-              pushers:
-                type: array
-                title: Pushers
-                description: |-
-                  An array containing the current pushers for the user
-                items:
-                  type: object
-                  title: Pusher
-                  properties:
-                    pushkey:
-                      type: string
-                      description: |-
-                        This is a unique identifier for this pusher. See `/set` for
-                        more detail.
-                        Max length, 512 bytes.
-                    kind:
-                      type: string
-                      description: |-
-                        The kind of pusher. `"http"` is a pusher that
-                        sends HTTP pokes.
-                    app_id:
-                      type: string
-                      description: |-
-                        This is a reverse-DNS style identifier for the application.
-                        Max length, 64 chars.
-                    app_display_name:
-                      type: string
-                      description: |-
-                        A string that will allow the user to identify what application
-                        owns this pusher.
-                    device_display_name:
-                      type: string
-                      description: |-
-                        A string that will allow the user to identify what device owns
-                        this pusher.
-                    profile_tag:
-                      type: string
-                      description: |-
-                        This string determines which set of device specific rules this
-                        pusher executes.
-                    lang:
-                      type: string
-                      description: |-
-                        The preferred language for receiving notifications (e.g. 'en'
-                        or 'en-US')
-                    data:
-                      type: object
-                      description: |-
-                        A dictionary of information for the pusher implementation
-                        itself.
-                      title: PusherData
-                      properties:
-                        url:
-                          type: string
-                          format: uri
-                          description: |-
-                            Required if `kind` is `http`. The URL to use to send
-                            notifications to.
-                        format:
-                          type: string
-                          description: |-
-                            The format to use when sending notifications to the Push
-                            Gateway.
-                  required:
-                    - pushkey
-                    - app_id
-                    - kind
-                    - app_display_name
-                    - device_display_name
-                    - lang
-                    - data
-      tags:
-        - Push notifications
-  "/pushers/set":
-    post:
-      summary: Modify a pusher for this user on the homeserver.
-      description: |-
-        This endpoint allows the creation, modification and deletion of [pushers](/client-server-api/#push-notifications)
-        for this user ID. The behaviour of this endpoint varies depending on the
-        values in the JSON body.
-      operationId: postPusher
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: pusher
-          description: The pusher information.
-          required: true
-          schema:
-            type: object
-            example: {
-              "lang": "en",
-              "kind": "http",
-              "app_display_name": "Mat Rix",
-              "device_display_name": "iPhone 9",
-              "profile_tag": "xxyyzz",
-              "app_id": "com.example.app.ios",
-              "pushkey": "APA91bHPRgkF3JUikC4ENAHEeMrd41Zxv3hVZjC9KtT8OvPVGJ-hQMRKRrZuJAEcl7B338qju59zJMjw2DELjzEvxwYv7hH5Ynpc1ODQ0aT4U4OFEeco8ohsN5PjL1iC2dNtk2BAokeMCg2ZXKqpc8FXKmhX94kIxQ",
-              "data": {
-                "url": "https://push-gateway.location.here/_matrix/push/v1/notify",
-                "format": "event_id_only"
-              },
-              "append": false
-            }
-            properties:
-              pushkey:
-                type: string
-                description: |-
-                  This is a unique identifier for this pusher. The value you
-                  should use for this is the routing or destination address
-                  information for the notification, for example, the APNS token
-                  for APNS or the Registration ID for GCM. If your notification
-                  client has no such concept, use any unique identifier.
-                  Max length, 512 bytes.
-
-                  If the `kind` is `"email"`, this is the email address to
-                  send notifications to.
-              kind:
-                type: string
-                description: |-
-                  The kind of pusher to configure. `"http"` makes a pusher that
-                  sends HTTP pokes. `"email"` makes a pusher that emails the
-                  user with unread notifications. `null` deletes the pusher.
-              app_id:
-                type: string
-                description: |-
-                  This is a reverse-DNS style identifier for the application.
-                  It is recommended that this end with the platform, such that
-                  different platform versions get different app identifiers.
-                  Max length, 64 chars.
-
-                  If the `kind` is `"email"`, this is `"m.email"`.
-              app_display_name:
-                type: string
-                description: |-
-                  A string that will allow the user to identify what application
-                  owns this pusher.
-              device_display_name:
-                type: string
-                description: |-
-                  A string that will allow the user to identify what device owns
-                  this pusher.
-              profile_tag:
-                type: string
-                description: |-
-                  This string determines which set of device specific rules this
-                  pusher executes.
-              lang:
-                type: string
-                description: |-
-                  The preferred language for receiving notifications (e.g. 'en'
-                  or 'en-US').
-              data:
-                type: object
-                description: |-
-                  A dictionary of information for the pusher implementation
-                  itself. If `kind` is `http`, this should contain `url`
-                  which is the URL to use to send notifications to.
-                title: PusherData
-                properties:
-                  url:
-                    type: string
-                    format: uri
-                    description: |-
-                      Required if `kind` is `http`. The URL to use to send
-                      notifications to. MUST be an HTTPS URL with a path of
-                      `/_matrix/push/v1/notify`.
-                    example: "https://push-gateway.location.here/_matrix/push/v1/notify"
-                  format:
-                    type: string
-                    description: |-
-                      The format to send notifications in to Push Gateways if the
-                      `kind` is `http`. The details about what fields the
-                      homeserver should send to the push gateway are defined in the
-                      [Push Gateway Specification](/push-gateway-api/). Currently the only format
-                      available is 'event_id_only'.
-              append:
-                type: boolean
-                description: |-
-                  If true, the homeserver should add another pusher with the
-                  given pushkey and App ID in addition to any others with
-                  different user IDs. Otherwise, the homeserver must remove any
-                  other pushers with the same App ID and pushkey for different
-                  users. The default is `false`.
-            required: ['kind', 'app_id', 'app_display_name',
-                'device_display_name', 'pushkey', 'lang', 'data']
-      responses:
-        200:
-          description: The pusher was set.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-            description: An empty object.
-        400:
-          description: One or more of the pusher values were invalid.
-          examples:
-            application/json: {
-              "error": "Missing parameters: lang, data",
-              "errcode": "M_MISSING_PARAM"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Push notifications
diff --git a/data/api/client-server/pushrules.yaml b/data/api/client-server/pushrules.yaml
deleted file mode 100644
index 5432df54..00000000
--- a/data/api/client-server/pushrules.yaml
+++ /dev/null
@@ -1,745 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Push Rules API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/pushrules/":
-    get:
-      summary: Retrieve all push rulesets.
-      description: |-
-        Retrieve all push rulesets for this user. Clients can "drill-down" on
-        the rulesets by suffixing a `scope` to this path e.g.
-        `/pushrules/global/`. This will return a subset of this data under the
-        specified key e.g. the `global` key.
-      operationId: getPushRules
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: All the push rulesets for this user.
-          schema:
-            type: object
-            required: ["global"]
-            properties:
-              global:
-                type: object
-                description: The global ruleset.
-                title: Ruleset
-                allOf: [
-                  "$ref": "definitions/push_ruleset.yaml"
-                ]
-          examples:
-            application/json: {
-                "global": {
-                    "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": [
-                                "dont_notify"
-                            ],
-                            "conditions": [],
-                            "default": true,
-                            "enabled": false,
-                            "rule_id": ".m.rule.master"
-                        },
-                        {
-                            "actions": [
-                                "dont_notify"
-                            ],
-                            "conditions": [
-                                {
-                                    "key": "content.msgtype",
-                                    "kind": "event_match",
-                                    "pattern": "m.notice"
-                                }
-                            ],
-                            "default": true,
-                            "enabled": true,
-                            "rule_id": ".m.rule.suppress_notices"
-                        }
-                    ],
-                    "room": [],
-                    "sender": [],
-                    "underride": [
-                        {
-                            "actions": [
-                                "notify",
-                                {
-                                    "set_tweak": "sound",
-                                    "value": "ring"
-                                },
-                                {
-                                    "set_tweak": "highlight",
-                                    "value": false
-                                }
-                            ],
-                            "conditions": [
-                                {
-                                    "key": "type",
-                                    "kind": "event_match",
-                                    "pattern": "m.call.invite"
-                                }
-                            ],
-                            "default": true,
-                            "enabled": true,
-                            "rule_id": ".m.rule.call"
-                        },
-                        {
-                            "actions": [
-                                "notify",
-                                {
-                                    "set_tweak": "sound",
-                                    "value": "default"
-                                },
-                                {
-                                    "set_tweak": "highlight"
-                                }
-                            ],
-                            "conditions": [
-                                {
-                                    "kind": "contains_display_name"
-                                }
-                            ],
-                            "default": true,
-                            "enabled": true,
-                            "rule_id": ".m.rule.contains_display_name"
-                        },
-                        {
-                            "actions": [
-                                "notify",
-                                {
-                                    "set_tweak": "sound",
-                                    "value": "default"
-                                },
-                                {
-                                    "set_tweak": "highlight",
-                                    "value": false
-                                }
-                            ],
-                            "conditions": [
-                                {
-                                    "kind": "room_member_count",
-                                    "is": "2"
-                                },
-                                {
-                                    "kind": "event_match",
-                                    "key": "type",
-                                    "pattern": "m.room.message"
-                                }
-                            ],
-                            "default": true,
-                            "enabled": true,
-                            "rule_id": ".m.rule.room_one_to_one"
-                        },
-                        {
-                            "actions": [
-                                "notify",
-                                {
-                                    "set_tweak": "sound",
-                                    "value": "default"
-                                },
-                                {
-                                    "set_tweak": "highlight",
-                                    "value": false
-                                }
-                            ],
-                            "conditions": [
-                                {
-                                    "key": "type",
-                                    "kind": "event_match",
-                                    "pattern": "m.room.member"
-                                },
-                                {
-                                    "key": "content.membership",
-                                    "kind": "event_match",
-                                    "pattern": "invite"
-                                },
-                                {
-                                    "key": "state_key",
-                                    "kind": "event_match",
-                                    "pattern": "@alice:example.com"
-                                }
-                            ],
-                            "default": true,
-                            "enabled": true,
-                            "rule_id": ".m.rule.invite_for_me"
-                        },
-                        {
-                            "actions": [
-                                "notify",
-                                {
-                                    "set_tweak": "highlight",
-                                    "value": false
-                                }
-                            ],
-                            "conditions": [
-                                {
-                                    "key": "type",
-                                    "kind": "event_match",
-                                    "pattern": "m.room.member"
-                                }
-                            ],
-                            "default": true,
-                            "enabled": true,
-                            "rule_id": ".m.rule.member_event"
-                        },
-                        {
-                            "actions": [
-                                "notify",
-                                {
-                                    "set_tweak": "highlight",
-                                    "value": false
-                                }
-                            ],
-                            "conditions": [
-                                {
-                                    "key": "type",
-                                    "kind": "event_match",
-                                    "pattern": "m.room.message"
-                                }
-                            ],
-                            "default": true,
-                            "enabled": true,
-                            "rule_id": ".m.rule.message"
-                        }
-                    ]
-                }
-              }
-      tags:
-        - Push notifications
-  "/pushrules/{scope}/{kind}/{ruleId}":
-    get:
-      summary: Retrieve a push rule.
-      description: |-
-        Retrieve a single specified push rule.
-      operationId: getPushRule
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: scope
-          required: true
-          x-example: "global"
-          description: |-
-            `global` to specify global rules.
-        - in: path
-          type: string
-          name: kind
-          required: true
-          x-example: content
-          enum: ["override", "underride", "sender", "room", "content"]
-          description: |
-            The kind of rule
-        - in: path
-          type: string
-          name: ruleId
-          required: true
-          x-example: "nocake"
-          description: |
-            The identifier for the rule.
-      responses:
-        200:
-          description: |-
-            The specific push rule. This will also include keys specific to the
-            rule itself such as the rule's `actions` and `conditions` if set.
-          examples:
-            application/json: {
-                "actions": [
-                    "dont_notify"
-                ],
-                "pattern": "cake*lie",
-                "rule_id": "nocake",
-                "enabled": true,
-                "default": false
-              }
-          schema:
-            type: object
-            description: The push rule.
-            allOf: [
-              "$ref": "definitions/push_rule.yaml"
-            ]
-        404:
-          description: |-
-            The push rule does not exist.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "The push rule was not found."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Push notifications
-    delete:
-      summary: Delete a push rule.
-      description: |-
-        This endpoint removes the push rule defined in the path.
-      operationId: deletePushRule
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: scope
-          required: true
-          x-example: "global"
-          description: |-
-            `global` to specify global rules.
-        - in: path
-          type: string
-          name: kind
-          required: true
-          x-example: content
-          enum: ["override", "underride", "sender", "room", "content"]
-          description: |
-            The kind of rule
-        - in: path
-          type: string
-          name: ruleId
-          required: true
-          x-example: "nocake"
-          description: |
-            The identifier for the rule.
-      responses:
-        200:
-          description: The push rule was deleted.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object  # empty json object
-        404:
-          description: |-
-            The push rule does not exist.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "The push rule was not found."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Push notifications
-    put:
-      summary: Add or change a push rule.
-      description: |-
-        This endpoint allows the creation, modification and deletion of pushers
-        for this user ID. The behaviour of this endpoint varies depending on the
-        values in the JSON body.
-
-        When creating push rules, they MUST be enabled by default.
-      operationId: setPushRule
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: scope
-          required: true
-          x-example: "global"
-          description: |-
-            `global` to specify global rules.
-        - in: path
-          type: string
-          name: kind
-          required: true
-          x-example: content
-          enum: ["override", "underride", "sender", "room", "content"]
-          description: |
-            The kind of rule
-        - in: path
-          type: string
-          name: ruleId
-          required: true
-          x-example: "nocake"
-          description: |
-            The identifier for the rule.
-        - in: query
-          type: string
-          name: before
-          required: false
-          x-example: someRuleId
-          description: |-
-            Use 'before' with a `rule_id` as its value to make the new rule the
-            next-most important rule with respect to the given user defined rule.
-            It is not possible to add a rule relative to a predefined server rule.
-        - in: query
-          type: string
-          name: after
-          required: false
-          x-example: anotherRuleId
-          description: |-
-            This makes the new rule the next-less important rule relative to the
-            given user defined rule. It is not possible to add a rule relative
-            to a predefined server rule.
-        - in: body
-          name: pushrule
-          description: |-
-            The push rule data. Additional top-level keys may be present depending
-            on the parameters for the rule `kind`.
-          required: true
-          schema:
-            type: object
-            example: {
-                "pattern": "cake*lie",
-                "actions": ["notify"]
-              }
-            properties:
-              actions:
-                type: array
-                description: |-
-                  The action(s) to perform when the conditions for this rule are met.
-                items:
-                  type:
-                    - string
-                    - object
-              conditions:
-                type: array
-                description: |-
-                  The conditions that must hold true for an event in order for a
-                  rule to be applied to an event. A rule with no conditions
-                  always matches. Only applicable to `underride` and `override` rules.
-                items:
-                  type: object
-                  allOf: [ "$ref": "definitions/push_condition.yaml" ]
-              pattern:
-                type: string
-                description: |-
-                  Only applicable to `content` rules. The glob-style pattern to match against.
-            required: ["actions"]
-      responses:
-        200:
-          description: The push rule was created/updated.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object  # empty json object
-        400:
-          description: There was a problem configuring this push rule.
-          examples:
-            application/json: {
-                "error": "before/after rule not found: someRuleId",
-                "errcode": "M_UNKNOWN"
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        404:
-          description: |-
-            The push rule does not exist (when updating a push rule).
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "The push rule was not found."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Push notifications
-  "/pushrules/{scope}/{kind}/{ruleId}/enabled":
-    get:
-      summary: "Get whether a push rule is enabled"
-      description:
-        This endpoint gets whether the specified push rule is enabled.
-      operationId: isPushRuleEnabled
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: scope
-          required: true
-          x-example: "global"
-          description: |-
-            Either `global` or `device/<profile_tag>` to specify global
-            rules or device rules for the given `profile_tag`.
-        - in: path
-          type: string
-          name: kind
-          required: true
-          x-example: cake
-          enum: ["override", "underride", "sender", "room", "content"]
-          description: |
-            The kind of rule
-        - in: path
-          type: string
-          name: ruleId
-          required: true
-          x-example: nocake
-          description: |
-            The identifier for the rule.
-      responses:
-        200:
-          description: Whether the push rule is enabled.
-          examples:
-            application/json: {
-                "enabled": true
-              }
-          schema:
-            type: object
-            properties:
-              enabled:
-                type: boolean
-                description: Whether the push rule is enabled or not.
-            required: ["enabled"]
-        404:
-          description: |-
-            The push rule does not exist.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "The push rule was not found."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Push notifications
-    put:
-      summary: "Enable or disable a push rule."
-      description: |-
-        This endpoint allows clients to enable or disable the specified push rule.
-      operationId: setPushRuleEnabled
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: scope
-          required: true
-          x-example: "global"
-          description: |-
-            `global` to specify global rules.
-        - in: path
-          type: string
-          name: kind
-          required: true
-          x-example: content
-          enum: ["override", "underride", "sender", "room", "content"]
-          description: |
-            The kind of rule
-        - in: path
-          type: string
-          name: ruleId
-          required: true
-          x-example: "nocake"
-          description: |
-            The identifier for the rule.
-        - in: body
-          name: body
-          description: |
-            Whether the push rule is enabled or not.
-          required: true
-          schema:
-            type: object
-            properties:
-              enabled:
-                type: boolean
-                description: Whether the push rule is enabled or not.
-            required: ["enabled"]
-            example: {
-                "enabled": true
-              }
-      responses:
-        200:
-          description: The push rule was enabled or disabled.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object
-        404:
-          description: |-
-            The push rule does not exist.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "The push rule was not found."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Push notifications
-  "/pushrules/{scope}/{kind}/{ruleId}/actions":
-    get:
-      summary: "The actions for a push rule"
-      description:
-        This endpoint get the actions for the specified push rule.
-      operationId: getPushRuleActions
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: scope
-          required: true
-          x-example: "global"
-          description: |-
-            Either `global` or `device/<profile_tag>` to specify global
-            rules or device rules for the given `profile_tag`.
-        - in: path
-          type: string
-          name: kind
-          required: true
-          x-example: content
-          enum: ["override", "underride", "sender", "room", "content"]
-          description: |
-            The kind of rule
-        - in: path
-          type: string
-          name: ruleId
-          required: true
-          x-example: nocake
-          description: |
-            The identifier for the rule.
-      responses:
-        200:
-          description: The actions for this push rule.
-          examples:
-            application/json: {
-                "actions": [
-                  "notify",
-                  {"set_tweak": "sound", "value": "bing"}
-                ]
-              }
-          schema:
-            type: object
-            properties:
-              actions:
-                type: array
-                description:  The action(s) to perform for this rule.
-                items:
-                  type:
-                    - string
-                    - object
-            required: ["actions"]
-        404:
-          description: |-
-            The push rule does not exist.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "The push rule was not found."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Push notifications
-    put:
-      summary: "Set the actions for a push rule."
-      description: |-
-        This endpoint allows clients to change the actions of a push rule.
-        This can be used to change the actions of builtin rules.
-      operationId: setPushRuleActions
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: scope
-          required: true
-          x-example: "global"
-          description: |-
-            `global` to specify global rules.
-        - in: path
-          type: string
-          name: kind
-          required: true
-          x-example: room
-          enum: ["override", "underride", "sender", "room", "content"]
-          description: |
-            The kind of rule
-        - in: path
-          type: string
-          name: ruleId
-          required: true
-          x-example: "#spam:example.com"
-          description: |
-            The identifier for the rule.
-        - in: body
-          name: body
-          description: |
-            The action(s) to perform when the conditions for this rule are met.
-          required: true
-          schema:
-            type: object
-            properties:
-              actions:
-                type: array
-                description: The action(s) to perform for this rule.
-                items:
-                  type:
-                    - string
-                    - object
-            required: ["actions"]
-            example: {
-                "actions": [
-                  "notify",
-                  {"set_tweak": "highlight"}
-                ]
-              }
-      responses:
-        200:
-          description: The actions for the push rule were set.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object
-        404:
-          description: |-
-            The push rule does not exist.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "The push rule was not found."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Push notifications
diff --git a/data/api/client-server/read_markers.yaml b/data/api/client-server/read_markers.yaml
deleted file mode 100644
index ccfd0657..00000000
--- a/data/api/client-server/read_markers.yaml
+++ /dev/null
@@ -1,79 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Read Marker API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/read_markers":
-    post:
-      summary: Set the position of the read marker for a room.
-      description: |-
-        Sets the position of the read marker for a given room, and optionally
-        the read receipt's location.
-      operationId: setReadMarker
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room ID to set the read marker in for the user.
-          required: true
-          x-example: "!somewhere:example.org"
-        - in: body
-          name: body
-          description: The read marker and optional read receipt locations.
-          required: true
-          schema:
-            type: object
-            properties:
-              "m.fully_read":
-                type: string
-                description: |-
-                  The event ID the read marker should be located at. The
-                  event MUST belong to the room.
-                example: "$somewhere:example.org"
-              "m.read":
-                type: string
-                description: |-
-                  The event ID to set the read receipt location at. This is
-                  equivalent to calling `/receipt/m.read/$elsewhere:example.org`
-                  and is provided here to save that extra call.
-                example: "$elsewhere:example.org"
-            required: ['m.fully_read']
-      responses:
-        200:
-          description: |-
-            The read marker, and read receipt if provided, have been updated.
-          schema:
-            type: object
-            properties: {}
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Read Markers
diff --git a/data/api/client-server/receipts.yaml b/data/api/client-server/receipts.yaml
deleted file mode 100644
index df720cbd..00000000
--- a/data/api/client-server/receipts.yaml
+++ /dev/null
@@ -1,82 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Receipts API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/receipt/{receiptType}/{eventId}":
-    post:
-      summary: Send a receipt for the given event ID.
-      description: |-
-        This API updates the marker for the given receipt type to the event ID
-        specified.
-      operationId: postReceipt
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room in which to send the event.
-          required: true
-          x-example: "!wefuh21ffskfuh345:example.com"
-        - in: path
-          type: string
-          name: receiptType
-          description: The type of receipt to send.
-          required: true
-          x-example: "m.read"
-          enum: ["m.read"]
-        - in: path
-          type: string
-          name: eventId
-          description: The event ID to acknowledge up to.
-          required: true
-          x-example: "$1924376522eioj:example.com"
-        - in: body
-          name: receipt
-          description: |-
-            Extra receipt information to attach to `content` if any. The
-            server will automatically set the `ts` field.
-          required: true
-          schema:
-            type: object
-            example: {
-              }
-      responses:
-        200:
-          description: The receipt was sent.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object  # empty json object
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Room participation
diff --git a/data/api/client-server/redaction.yaml b/data/api/client-server/redaction.yaml
deleted file mode 100644
index 37ff9741..00000000
--- a/data/api/client-server/redaction.yaml
+++ /dev/null
@@ -1,96 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server message redaction API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/redact/{eventId}/{txnId}":
-    put:
-      summary: Strips all non-integrity-critical information out of an event.
-      description: |-
-        Strips all information out of an event which isn't critical to the
-        integrity of the server-side representation of the room.
-
-        This cannot be undone.
-
-        Any user with a power level greater than or equal to the `m.room.redaction`
-        event power level may send redaction events in the room. If the user's power
-        level greater is also greater than or equal to the `redact` power level
-        of the room, the user may redact events sent by other users.
-
-        Server administrators may redact events sent by users on their server.
-      operationId: redactEvent
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room from which to redact the event.
-          required: true
-          x-example: "!637q39766251:example.com"
-        - in: path
-          type: string
-          name: eventId
-          description: The ID of the event to redact
-          required: true
-          x-example: "bai2b1i9:matrix.org"
-        - in: path
-          name: txnId
-          type: string
-          description: |-
-            The transaction ID for this event. Clients should generate a
-            unique ID; it will be used by the server to ensure idempotency of requests.
-          required: true
-          x-example: "37"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-                "reason": "Indecent material"
-              }
-            properties:
-              reason:
-                type: string
-                description: The reason for the event being redacted.
-      responses:
-        200:
-          description: "An ID for the redaction event."
-          examples:
-            application/json: {
-                  "event_id": "$YUwQidLecu:example.com"
-              }
-          schema:
-            type: object
-            properties:
-              event_id:
-                type: string
-                description: |-
-                  A unique identifier for the event.
-      tags:
-        - Room participation
diff --git a/data/api/client-server/registration.yaml b/data/api/client-server/registration.yaml
deleted file mode 100644
index 810d8bc9..00000000
--- a/data/api/client-server/registration.yaml
+++ /dev/null
@@ -1,638 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Registration API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-paths:
-  "/register":
-    post:
-      summary: Register for an account on this homeserver.
-      description: |-
-        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api), except in
-        the cases where a guest account is being registered.
-
-        Register for an account on this homeserver.
-
-        There are two kinds of user account:
-
-        - `user` accounts. These accounts may use the full API described in this specification.
-
-        - `guest` accounts. These accounts may have limited permissions and may not be supported by all servers.
-
-        If registration is successful, this endpoint will issue an access token
-        the client can use to authorize itself in subsequent requests.
-
-        If the client does not supply a `device_id`, the server must
-        auto-generate one.
-
-        The server SHOULD register an account with a User ID based on the
-        `username` provided, if any. Note that the grammar of Matrix User ID
-        localparts is restricted, so the server MUST either map the provided
-        `username` onto a `user_id` in a logical manner, or reject
-        `username`\s which do not comply to the grammar, with
-        `M_INVALID_USERNAME`.
-
-        Matrix clients MUST NOT assume that localpart of the registered
-        `user_id` matches the provided `username`.
-
-        The returned access token must be associated with the `device_id`
-        supplied by the client or generated by the server. The server may
-        invalidate any access token previously associated with that device. See
-        [Relationship between access tokens and devices](/client-server-api/#relationship-between-access-tokens-and-devices).
-
-        When registering a guest account, all parameters in the request body
-        with the exception of `initial_device_display_name` MUST BE ignored
-        by the server. The server MUST pick a `device_id` for the account
-        regardless of input.
-
-        Any user ID returned by this API must conform to the grammar given in the
-        [Matrix specification](/appendices/#user-identifiers).
-      operationId: register
-      parameters:
-        - in: query
-          name: kind
-          type: string
-          # swagger-UI overrides the default with the example, so better make the
-          # example the default.
-          x-example: user
-          required: false
-          default: user
-          enum:
-            - guest
-            - user
-          description: The kind of account to register. Defaults to `user`.
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              auth:
-                description: |-
-                    Additional authentication information for the
-                    user-interactive authentication API. Note that this
-                    information is *not* used to define how the registered user
-                    should be authenticated, but is instead used to
-                    authenticate the `register` call itself.
-                allOf:
-                - "$ref": "definitions/auth_data.yaml"
-              username:
-                type: string
-                description: |-
-                  The basis for the localpart of the desired Matrix ID. If omitted,
-                  the homeserver MUST generate a Matrix ID local part.
-                example: cheeky_monkey
-              password:
-                type: string
-                description: The desired password for the account.
-                example: ilovebananas
-              device_id:
-                type: string
-                description: |-
-                  ID of the client device. If this does not correspond to a
-                  known client device, a new device will be created. The server
-                  will auto-generate a device_id if this is not specified.
-                example: GHTYAJCE
-              initial_device_display_name:
-                type: string
-                description: |-
-                  A display name to assign to the newly-created device. Ignored
-                  if `device_id` corresponds to a known device.
-                example: Jungle Phone
-              inhibit_login:
-                type: boolean
-                description: |-
-                  If true, an `access_token` and `device_id` should not be
-                  returned from this call, therefore preventing an automatic
-                  login. Defaults to false.
-                example: false
-      responses:
-        200:
-          description: The account has been registered.
-          examples:
-            application/json: {
-                "user_id": "@cheeky_monkey:matrix.org",
-                "access_token": "abc123",
-                "device_id": "GHTYAJCE"
-              }
-          schema:
-            type: object
-            properties:
-              user_id:
-                type: string
-                description: |-
-                  The fully-qualified Matrix user ID (MXID) that has been registered.
-
-                  Any user ID returned by this API must conform to the grammar given in the
-                  [Matrix specification](/appendices/#user-identifiers).
-              access_token:
-                type: string
-                description: |-
-                  An access token for the account.
-                  This access token can then be used to authorize other requests.
-                  Required if the `inhibit_login` option is false.
-              home_server:
-                type: string
-                description: |-
-                  The server_name of the homeserver on which the account has
-                  been registered.
-
-                  **Deprecated**. Clients should extract the server_name from
-                  `user_id` (by splitting at the first colon) if they require
-                  it. Note also that `homeserver` is not spelt this way.
-              device_id:
-                type: string
-                description: |-
-                  ID of the registered device. Will be the same as the
-                  corresponding parameter in the request, if one was specified.
-                  Required if the `inhibit_login` option is false.
-            required: ['user_id']
-        400:
-          description: |-
-            Part of the request was invalid. This may include one of the following error codes:
-
-            * `M_USER_IN_USE` : The desired user ID is already taken.
-            * `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.
-
-            These errors may be returned at any stage of the registration process,
-            including after authentication if the requested user ID was registered
-            whilst the client was performing authentication.
-
-            Homeservers MUST perform the relevant checks and return these codes before
-            performing User-Interactive Authentication, although they may also return
-            them after authentication is completed if, for example, the requested user ID
-            was registered whilst the client was performing authentication.
-          examples:
-            application/json: {
-                  "errcode": "M_USER_IN_USE",
-                  "error": "Desired user ID is already taken."
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        401:
-          description: |-
-            The homeserver requires additional authentication information.
-          schema:
-            "$ref": "definitions/auth_response.yaml"
-        403:
-          description: |-
-            The homeserver does not permit registering the account. This response
-            can be used to identify that a particular `kind` of account is not
-            allowed, or that registration is generally not supported by the homeserver.
-          examples:
-            application/json: {
-                "errcode": "M_FORBIDDEN",
-                "error": "Registration is disabled"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Account management
-  "/register/email/requestToken":
-    post:
-      summary: Begins the validation process for an email to be used during registration.
-      description: |-
-        The homeserver must check that the given email address is **not**
-        already associated with an account on this homeserver. The homeserver
-        should validate the email itself, either by sending a validation email
-        itself or by using a service it has control over.
-      operationId: requestTokenToRegisterEmail
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            $ref: "definitions/request_email_validation.yaml"
-      responses:
-        200:
-          description: |-
-            An email has been sent to the specified address. Note that this
-            may be an email containing the validation token or it may be
-            informing the user of an error.
-          schema:
-            $ref: "definitions/request_token_response.yaml"
-        403:
-          description: The homeserver does not permit the address to be bound.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_DENIED",
-              "error": "Third party identifier is not allowed"
-            }
-        400:
-          description: |-
-            Part of the request was invalid. This may include one of the following error codes:
-
-            * `M_THREEPID_IN_USE` : The email address is already registered to an account on this server.
-              However, if the homeserver has the ability to send email, it is recommended that the server
-              instead send an email to the user with instructions on how to reset their password.
-              This prevents malicious parties from being able to determine if a given email address
-              has an account on the homeserver in question.
-            * `M_SERVER_NOT_TRUSTED` : The `id_server` parameter refers to an identity server
-              that is not trusted by this homeserver.
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_IN_USE",
-              "error": "The specified address is already in use"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Account management
-  "/register/msisdn/requestToken":
-    post:
-      summary: Requests a validation token be sent to the given phone number for the purpose of registering an account
-      description: |-
-        The homeserver must check that the given phone number is **not**
-        already associated with an account on this homeserver. The homeserver
-        should validate the phone number itself, either by sending a validation
-        message itself or by using a service it has control over.
-      operationId: requestTokenToRegisterMSISDN
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            $ref: "definitions/request_msisdn_validation.yaml"
-      responses:
-        200:
-          description: |-
-            An SMS message has been sent to the specified phone number. Note
-            that this may be an SMS message containing the validation token or
-            it may be informing the user of an error.
-          schema:
-            $ref: "definitions/request_token_response.yaml"
-        403:
-          description: The homeserver does not permit the address to be bound.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_DENIED",
-              "error": "Third party identifier is not allowed"
-            }
-        400:
-          description: |-
-            Part of the request was invalid. This may include one of the following error codes:
-
-            * `M_THREEPID_IN_USE` : The phone number is already registered to an account on this server.
-              However, if the homeserver has the ability to send SMS message, it is recommended that the server
-              instead send an SMS message to the user with instructions on how to reset their password.
-              This prevents malicious parties from being able to determine if a given phone number
-              has an account on the homeserver in question.
-            * `M_SERVER_NOT_TRUSTED` : The `id_server` parameter refers to an identity server
-              that is not trusted by this homeserver.
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_IN_USE",
-              "error": "The specified address is already in use"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Account management
-  "/account/password":
-    post:
-      summary: "Changes a user's password."
-      description: |-
-        Changes the password for an account on this homeserver.
-
-        This API endpoint uses the [User-Interactive Authentication API](/client-server-api/#user-interactive-authentication-api) to
-        ensure the user changing the password is actually the owner of the
-        account.
-
-        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. The homeserver SHOULD NOT revoke the
-        access token provided in the request. Whether other access tokens for
-        the user are revoked depends on the request parameters.
-      security:
-        - accessToken: []
-      operationId: changePassword
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              new_password:
-                type: string
-                description: The new password for the account.
-                example: "ihatebananas"
-              logout_devices:
-                type: boolean
-                description: |-
-                  Whether the user's other access tokens, and their associated devices, should be
-                  revoked if the request succeeds. Defaults to true.
-
-                  When `false`, the server can still take advantage of the [soft logout method](/client-server-api/#soft-logout)
-                  for the user's remaining devices.
-                example: true
-              auth:
-                description: |-
-                    Additional authentication information for the user-interactive authentication API.
-                allOf:
-                - "$ref": "definitions/auth_data.yaml"
-            required: ["new_password"]
-      responses:
-        200:
-          description: The password has been changed.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-        401:
-          description: |-
-            The homeserver requires additional authentication information.
-          schema:
-            "$ref": "definitions/auth_response.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Account management
-  "/account/password/email/requestToken":
-    post:
-      summary: Requests a validation token be sent to the given email address for the purpose of resetting a user's password
-      description: |-
-        The homeserver must check that the given email address **is
-        associated** with an account on this homeserver. This API should be
-        used to request validation tokens when authenticating for the
-        `/account/password` endpoint.
-
-        This API's parameters and response are identical to that of the
-        [`/register/email/requestToken`](/client-server-api/#post_matrixclientv3registeremailrequesttoken)
-        endpoint, except that
-        `M_THREEPID_NOT_FOUND` may be returned if no account matching the
-        given email address could be found. The server may instead send an
-        email to the given address prompting the user to create an account.
-        `M_THREEPID_IN_USE` may not be returned.
-
-        The homeserver should validate the email itself, either by sending a
-        validation email itself or by using a service it has control over.
-      operationId: requestTokenToResetPasswordEmail
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            $ref: "definitions/request_email_validation.yaml"
-      responses:
-        200:
-          description: An email was sent to the given address.
-          schema:
-            $ref: "definitions/request_token_response.yaml"
-        403:
-          description: |-
-            The homeserver does not allow the third party identifier as a
-            contact option.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_DENIED",
-              "error": "Third party identifier is not allowed"
-            }
-        400:
-          description: |-
-            The referenced third party identifier is not recognised by the
-            homeserver, or the request was invalid. The error code `M_SERVER_NOT_TRUSTED`
-            can be returned if the server does not trust/support the identity server
-            provided in the request.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_NOT_FOUND",
-              "error": "Email not found"
-            }
-      tags:
-        - Account management
-  "/account/password/msisdn/requestToken":
-    post:
-      summary: Requests a validation token be sent to the given phone number for the purpose of resetting a user's password.
-      description: |-
-        The homeserver must check that the given phone number **is
-        associated** with an account on this homeserver. This API should be
-        used to request validation tokens when authenticating for the
-        `/account/password` endpoint.
-
-        This API's parameters and response are identical to that of the
-        [`/register/msisdn/requestToken`](/client-server-api/#post_matrixclientv3registermsisdnrequesttoken)
-        endpoint, except that
-        `M_THREEPID_NOT_FOUND` may be returned if no account matching the
-        given phone number could be found. The server may instead send the SMS
-        to the given phone number prompting the user to create an account.
-        `M_THREEPID_IN_USE` may not be returned.
-
-        The homeserver should validate the phone number itself, either by sending a
-        validation message itself or by using a service it has control over.
-      operationId: requestTokenToResetPasswordMSISDN
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            $ref: "definitions/request_msisdn_validation.yaml"
-      responses:
-        200:
-          description: An SMS message was sent to the given phone number.
-          schema:
-            $ref: "definitions/request_token_response.yaml"
-        403:
-          description: |-
-            The homeserver does not allow the third party identifier as a
-            contact option.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_DENIED",
-              "error": "Third party identifier is not allowed"
-            }
-        400:
-          description: |-
-            The referenced third party identifier is not recognised by the
-            homeserver, or the request was invalid. The error code `M_SERVER_NOT_TRUSTED`
-            can be returned if the server does not trust/support the identity server
-            provided in the request.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_NOT_FOUND",
-              "error": "Phone number not found"
-            }
-      tags:
-        - Account management
-  "/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:
-        - accessToken: []
-      operationId: deactivateAccount
-      parameters:
-        - in: body
-          name: body
-          required: true
-          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"
-      responses:
-        200:
-          description: The account has been deactivated.
-          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.
-          schema:
-            "$ref": "definitions/auth_response.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Account management
-  "/register/available":
-    get:
-      summary: Checks to see if a username is available on the server.
-      description: |-
-        Checks to see if a username is available, and valid, for the server.
-
-        The server should check to ensure that, at the time of the request, the
-        username requested is available for use. This includes verifying that an
-        application service has not claimed the username and that the username
-        fits the server's desired requirements (for example, a server could dictate
-        that it does not permit usernames with underscores).
-
-        Matrix clients may wish to use this API prior to attempting registration,
-        however the clients must also be aware that using this API does not normally
-        reserve the username. This can mean that the username becomes unavailable
-        between checking its availability and attempting to register it.
-      operationId: checkUsernameAvailability
-      parameters:
-        - in: query
-          name: username
-          type: string
-          x-example: my_cool_localpart
-          required: true
-          default: my_cool_localpart
-          description: The username to check the availability of.
-      responses:
-        200:
-          description: The username is available
-          examples:
-            application/json: {
-              "available": true
-            }
-          schema:
-            type: object
-            properties:
-              available:
-                type: boolean
-                description: |-
-                  A flag to indicate that the username is available. This should always
-                  be `true` when the server replies with 200 OK.
-        400:
-          description: |-
-            Part of the request was invalid or the username is not available. This may
-            include one of the following error codes:
-
-            * `M_USER_IN_USE` : The desired username is already taken.
-            * `M_INVALID_USERNAME` : The desired username is not a valid user name.
-            * `M_EXCLUSIVE` : The desired username is in the exclusive namespace
-              claimed by an application service.
-          examples:
-            application/json: {
-              "errcode": "M_USER_IN_USE",
-              "error": "Desired user ID is already taken."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Account management
diff --git a/data/api/client-server/registration_tokens.yaml b/data/api/client-server/registration_tokens.yaml
deleted file mode 100644
index 11241b57..00000000
--- a/data/api/client-server/registration_tokens.yaml
+++ /dev/null
@@ -1,80 +0,0 @@
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Registration Token API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-paths:
-  "/register/m.login.registration_token/validity":
-    get:
-      x-addedInMatrixVersion: "1.2"
-      summary: Query if a given registration token is still valid.
-      description: |-
-        Queries the server to determine if a given registration token is still
-        valid at the time of request. This is a point-in-time check where the
-        token might still expire by the time it is used.
-
-        Servers should be sure to rate limit this endpoint to avoid brute force
-        attacks.
-      operationId: registrationTokenValidity
-      parameters:
-        - in: query
-          name: token
-          type: string
-          x-example: "fBVFdqVE"
-          required: true
-          description: The token to check validity of.
-      responses:
-        200:
-          description: The check has a result.
-          examples:
-            application/json: {
-              "valid": true
-            }
-          schema:
-            type: object
-            properties:
-              valid:
-                type: boolean
-                description: |-
-                  True if the token is still valid, false otherwise. This should
-                  additionally be false if the token is not a recognised token by
-                  the server.
-            required: ['valid']
-        403:
-          description: |-
-            The homeserver does not permit registration and thus all tokens are
-            considered invalid.
-          examples:
-            application/json: {
-                  "errcode": "M_FORBIDDEN",
-                  "error": "Registration is not enabled on this homeserver."
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Account management
diff --git a/data/api/client-server/report_content.yaml b/data/api/client-server/report_content.yaml
deleted file mode 100644
index 7f8b3425..00000000
--- a/data/api/client-server/report_content.yaml
+++ /dev/null
@@ -1,78 +0,0 @@
-# Copyright 2018 Travis Ralston
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Report Content API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/report/{eventId}":
-    post:
-      summary: Reports an event as inappropriate.
-      description: |-
-        Reports an event as inappropriate to the server, which may then notify
-        the appropriate people.
-      operationId: reportContent
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room in which the event being reported is located.
-          required: true
-          x-example: "!637q39766251:example.com"
-        - in: path
-          type: string
-          name: eventId
-          description: The event to report.
-          required: true
-          x-example: "$something:example.org"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-              "score": -100,
-              "reason": "this makes me sad"
-            }
-            properties:
-              score:
-                type: integer
-                description: |-
-                  The score to rate this content as where -100 is most offensive
-                  and 0 is inoffensive.
-              reason:
-                type: string
-                description: The reason the content is being reported. May be blank.
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: The event has been reported successfully.
-          schema:
-            type: object
-          examples:
-            application/json: {}
-      tags:
-        - Reporting content
diff --git a/data/api/client-server/room_initial_sync.yaml b/data/api/client-server/room_initial_sync.yaml
deleted file mode 100644
index 64e7f4f2..00000000
--- a/data/api/client-server/room_initial_sync.yaml
+++ /dev/null
@@ -1,155 +0,0 @@
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Rooms API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/initialSync":
-    get:
-      summary: Snapshot the current state of a room and its most recent messages.
-      description: |-
-        Get a copy of the current state and the most recent messages in a room.
-
-        This endpoint was deprecated in r0 of this specification. There is no
-        direct replacement; the relevant information is returned by the
-        [`/sync`](/client-server-api/#get_matrixclientv3sync) API. See the
-        [migration guide](https://matrix.org/docs/guides/migrating-from-client-server-api-v-1#deprecated-endpoints).
-      operationId: roomInitialSync
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room to get the data.
-          required: true
-          x-example: "!636q39766251:example.com"
-      responses:
-        200:
-          description: The current state of the room
-          examples:
-            application/json: {
-                "membership": "join",
-                "messages": {
-                  "chunk": [
-                    {
-                      "room_id": "!636q39766251:example.com",
-                      "$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"
-                    },
-                    {
-                      "room_id": "!636q39766251:example.com",
-                      "$ref": "../../event-schemas/examples/m.room.message$m.file.yaml"
-                    }
-                  ],
-                  "end": "s3456_9_0",
-                  "start": "t44-3453_9_0"
-                },
-                "room_id": "!636q39766251:example.com",
-                "state": [
-                  {
-                    "room_id": "!636q39766251:example.com",
-                    "$ref": "../../event-schemas/examples/m.room.join_rules.yaml"
-                  },
-                  {
-                    "room_id": "!636q39766251:example.com",
-                    "$ref": "../../event-schemas/examples/m.room.member.yaml"
-                  },
-                  {
-                    "room_id": "!636q39766251:example.com",
-                    "$ref": "../../event-schemas/examples/m.room.create.yaml"
-                  },
-                  {
-                    "room_id": "!636q39766251:example.com",
-                    "$ref": "../../event-schemas/examples/m.room.power_levels.yaml"
-                  }
-                ],
-                "visibility": "private",
-                "account_data": [{
-                    "type": "m.tag",
-                    "content": {"tags": {"work": {"order": "1"}}}
-                }]
-              }
-          schema:
-            title: RoomInfo
-            type: object
-            properties:
-              room_id:
-                type: string
-                description: "The ID of this room."
-              membership:
-                type: string
-                description: "The user's membership state in this room."
-                enum: ["invite", "join", "leave", "ban"]
-              messages:
-                type: object
-                title: PaginationChunk
-                description: "The pagination chunk for this room."
-                properties:
-                  start:
-                    type: string
-                    description: |-
-                      A token which correlates to the start of `chunk`. Can be passed to
-                      [`/rooms/<room_id>/messages`](#get_matrixclientv3roomsroomidmessages)
-                      to retrieve earlier events.
-
-                      If no earlier events are available, this property may be omitted from
-                      the response.
-                  end:
-                    type: string
-                    description: |-
-                      A token which correlates to the end of `chunk`. Can be passed to
-                      [`/rooms/<room_id>/messages`](#get_matrixclientv3roomsroomidmessages)
-                      to retrieve later events.
-                  chunk:
-                    type: array
-                    description: |-
-                      If the user is a member of the room this will be a
-                      list of the most recent messages for this room. If
-                      the user has left the room this will be the
-                      messages that preceded them leaving. This array
-                      will consist of at most `limit` elements.
-                    items:
-                      "$ref": "definitions/client_event.yaml"
-                required: ["end", "chunk"]
-              state:
-                type: array
-                description: |-
-                  If the user is a member of the room this will be the
-                  current state of the room as a list of events. If the
-                  user has left the room this will be the state of the
-                  room when they left it.
-                items:
-                  "$ref": "definitions/client_event.yaml"
-              visibility:
-                type: string
-                enum: ["private", "public"]
-                description: |-
-                  Whether this room is visible to the `/publicRooms` API
-                  or not."
-              account_data:
-                type: array
-                description: |-
-                  The private data that this user has attached to this room.
-                items:
-                  title: Event
-                  type: object
-                  allOf:
-                    - "$ref": "../../event-schemas/schema/core-event-schema/event.yaml"
-            required: ["room_id"]
-        403:
-          description: >
-            You aren't a member of the room and weren't previously a
-            member of the room.
-      tags:
-        - Room participation
-      deprecated: true
diff --git a/data/api/client-server/room_send.yaml b/data/api/client-server/room_send.yaml
deleted file mode 100644
index 28591a3a..00000000
--- a/data/api/client-server/room_send.yaml
+++ /dev/null
@@ -1,92 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server message event send API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/send/{eventType}/{txnId}":
-    put:
-      summary: Send a message event to the given room.
-      description: |-
-        This endpoint is used to send a message event to a room. Message events
-        allow access to historical events and pagination, making them suited
-        for "once-off" activity in a room.
-
-        The body of the request should be the content object of the event; the
-        fields in this object will vary depending on the type of event. See
-        [Room Events](/client-server-api/#room-events) for the m. event specification.
-      operationId: sendMessage
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room to send the event to.
-          required: true
-          x-example: "!636q39766251:example.com"
-        - in: path
-          type: string
-          name: eventType
-          description: The type of event to send.
-          required: true
-          x-example: "m.room.message"
-        - in: path
-          name: txnId
-          type: string
-          description: |-
-            The transaction ID for this event. Clients should generate an
-            ID unique across requests with the same access token; it will be
-            used by the server to ensure idempotency of requests.
-          required: true
-          x-example: "35"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-                "msgtype": "m.text",
-                "body": "hello"
-              }
-      responses:
-        200:
-          description: "An ID for the sent event."
-          examples:
-            application/json: {
-                  "event_id": "$YUwRidLecu:example.com"
-              }
-          schema:
-            type: object
-            properties:
-              event_id:
-                type: string
-                description: |-
-                  A unique identifier for the event.
-            required:
-              - event_id
-      tags:
-        - Room participation
diff --git a/data/api/client-server/room_state.yaml b/data/api/client-server/room_state.yaml
deleted file mode 100644
index 89792e63..00000000
--- a/data/api/client-server/room_state.yaml
+++ /dev/null
@@ -1,130 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server state event send API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/state/{eventType}/{stateKey}":
-    put:
-      summary: Send a state event to the given room.
-      description: |
-        State events can be sent using this endpoint.  These events will be
-        overwritten if `<room id>`, `<event type>` and `<state key>` all
-        match.
-
-        Requests to this endpoint **cannot use transaction IDs**
-        like other `PUT` paths because they cannot be differentiated from the
-        `state_key`. Furthermore, `POST` is unsupported on state paths.
-
-        The body of the request should be the content object of the event; the
-        fields in this object will vary depending on the type of event. See
-        [Room Events](/client-server-api/#room-events) for the `m.` event specification.
-
-        If the event type being sent is `m.room.canonical_alias` servers
-        SHOULD ensure that any new aliases being listed in the event are valid
-        per their grammar/syntax and that they point to the room ID where the
-        state event is to be sent. Servers do not validate aliases which are
-        being removed or are already present in the state event.
-      operationId: setRoomStateWithKey
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room to set the state in
-          required: true
-          x-example: "!636q39766251:example.com"
-        - in: path
-          type: string
-          name: eventType
-          description: The type of event to send.
-          required: true
-          x-example: "m.room.member"
-        - in: path
-          type: string
-          name: stateKey
-          description: |-
-            The state_key for the state to send. Defaults to the empty string. When
-            an empty string, the trailing slash on this endpoint is optional.
-          required: true
-          x-example: "@alice:example.com"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-                "membership": "join",
-                "avatar_url": "mxc://localhost/SEsfnsuifSDFSSEF",
-                "displayname": "Alice Margatroid"
-              }
-      responses:
-        200:
-          description: "An ID for the sent event."
-          examples:
-            application/json: {
-                  "event_id": "$YUwRidLecu:example.com"
-              }
-          schema:
-            type: object
-            properties:
-              event_id:
-                type: string
-                description: |-
-                  A unique identifier for the event.
-            required:
-              - event_id
-        403:
-          description: |-
-            The sender doesn't have permission to send the event into the room.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "You do not have permission to send the event."
-            }
-        400:
-          description: |-
-            The sender's request is malformed.
-
-            Some example error codes include:
-
-            * `M_INVALID_PARAMETER`: One or more aliases within the `m.room.canonical_alias`
-              event have invalid syntax.
-
-            * `M_BAD_ALIAS`: One or more aliases within the `m.room.canonical_alias` event
-              do not point to the room ID for which the state event is to be sent to.
-          schema:
-            $ref: "definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_BAD_ALIAS",
-              "error": "The alias '#hello:example.org' does not point to this room."
-            }
-      tags:
-        - Room participation
diff --git a/data/api/client-server/room_upgrades.yaml b/data/api/client-server/room_upgrades.yaml
deleted file mode 100644
index 41b3a7af..00000000
--- a/data/api/client-server/room_upgrades.yaml
+++ /dev/null
@@ -1,92 +0,0 @@
-# Copyright 2019 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Upgrades API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/upgrade":
-    post:
-      summary: Upgrades a room to a new room version.
-      description: |-
-        Upgrades the given room to a particular room version.
-      operationId: upgradeRoom
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          required: true
-          description: The ID of the room to upgrade.
-          x-example: "!oldroom:example.org"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              new_version:
-                type: string
-                description: The new version for the room.
-            example: {"new_version": "2"}
-            required: [new_version]
-      responses:
-        200:
-          description: The room was successfully upgraded.
-          examples:
-            application/json: {
-              "replacement_room": "!newroom:example.org"
-            }
-          schema:
-            type: object
-            properties:
-              replacement_room:
-                type: string
-                description: The ID of the new room.
-            required: [replacement_room]
-        400:
-          description: |-
-            The request was invalid. One way this can happen is if the room version
-            requested is not supported by the homeserver.
-          examples:
-            application/json: {
-              "errcode": "M_UNSUPPORTED_ROOM_VERSION",
-              "error": "This server does not support that room version"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        403:
-          description: |-
-            The user is not permitted to upgrade the room.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "You cannot upgrade this room"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room upgrades
diff --git a/data/api/client-server/rooms.yaml b/data/api/client-server/rooms.yaml
deleted file mode 100644
index 343b6c49..00000000
--- a/data/api/client-server/rooms.yaml
+++ /dev/null
@@ -1,307 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Rooms API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/event/{eventId}":
-    get:
-      summary: Get a single event by event ID.
-      description: |-
-        Get a single event based on `roomId/eventId`. You must have permission to
-        retrieve this event e.g. by being a member in the room for this event.
-      operationId: getOneRoomEvent
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The ID of the room the event is in.
-          required: true
-          x-example: "!636q39766251:matrix.org"
-        - in: path
-          type: string
-          name: eventId
-          description: The event ID to get.
-          required: true
-          x-example: "$asfDuShaf7Gafaw:matrix.org"
-      responses:
-        200:
-          description: The full event.
-          examples:
-            application/json: {
-              "room_id": "!636q39766251:matrix.org",
-              "$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"
-            }
-          schema:
-            "$ref": "definitions/client_event.yaml"
-        404:
-          description: The event was not found or you do not have permission to read this event.
-          examples:
-            application/json: {
-                "errcode": "M_NOT_FOUND",
-                "error": "Event not found."
-              }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-      tags:
-        - Room participation
-  "/rooms/{roomId}/state/{eventType}/{stateKey}":
-    get:
-      summary: Get the state identified by the type and key.
-      description: |-
-        Looks up the contents of a state event in a room. If the user is
-        joined to the room then the state is taken from the current
-        state of the room. If the user has left the room then the state is
-        taken from the state of the room when they left.
-      operationId: getRoomStateWithKey
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room to look up the state in.
-          required: true
-          x-example: "!636q39766251:example.com"
-        - in: path
-          type: string
-          name: eventType
-          description: The type of state to look up.
-          required: true
-          x-example: "m.room.name"
-        - in: path
-          type: string
-          name: stateKey
-          description: |-
-            The key of the state to look up. Defaults to an empty string. When
-            an empty string, the trailing slash on this endpoint is optional.
-          required: true
-          x-example: ""
-      responses:
-        200:
-          description: The content of the state event.
-          examples:
-            application/json: {
-              "name": "Example room name"}
-          schema:
-            type: object
-        404:
-          description: The room has no state with the given type or key.
-        403:
-          description: >
-            You aren't a member of the room and weren't previously a
-            member of the room.
-      tags:
-        - Room participation
-  "/rooms/{roomId}/state":
-    get:
-      summary: Get all state events in the current state of a room.
-      description: |-
-        Get the state events for the current state of a room.
-      operationId: getRoomState
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room to look up the state for.
-          required: true
-          x-example: "!636q39766251:example.com"
-      responses:
-        200:
-          description: The current state of the room
-          examples:
-            application/json: [
-              {
-                "room_id": "!636q39766251:example.com",
-                "$ref": "../../event-schemas/examples/m.room.join_rules.yaml"
-              },
-              {
-                "room_id": "!636q39766251:example.com",
-                "$ref": "../../event-schemas/examples/m.room.member.yaml"
-              },
-              {
-                "room_id": "!636q39766251:example.com",
-                "$ref": "../../event-schemas/examples/m.room.create.yaml"
-              },
-              {
-                "room_id": "!636q39766251:example.com",
-                "$ref": "../../event-schemas/examples/m.room.power_levels.yaml"
-              }
-            ]
-          schema:
-            type: array
-            title: RoomState
-            description: |-
-              If the user is a member of the room this will be the
-              current state of the room as a list of events. If the user
-              has left the room then this will be the state of the room
-              when they left as a list of events.
-            items:
-              $ref: "definitions/client_event.yaml"
-        403:
-          description: >
-            You aren't a member of the room and weren't previously a
-            member of the room.
-      tags:
-        - Room participation
-  "/rooms/{roomId}/members":
-    get:
-      summary: Get the m.room.member events for the room.
-      description:
-        Get the list of members for this room.
-      operationId: getMembersByRoom
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room to get the member events for.
-          required: true
-          x-example: "!636q39766251:example.com"
-        - in: query
-          name: at
-          type: string
-          description: |-
-            The point in time (pagination token) to return members for in the room.
-            This token can be obtained from a `prev_batch` token returned for
-            each room by the sync API. Defaults to the current state of the room,
-            as determined by the server.
-          x-example: "YWxsCgpOb25lLDM1ODcwOA"
-        # 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
-        - in: query
-          name: membership
-          type: string
-          enum:
-            - join
-            - invite
-            - knock
-            - leave
-            - ban
-          description: |-
-            The kind of membership to filter for. Defaults to no filtering if
-            unspecified. When specified alongside `not_membership`, the two
-            parameters create an 'or' condition: either the membership *is*
-            the same as `membership` **or** *is not* the same as `not_membership`.
-          x-example: "join"
-        - in: query
-          name: not_membership
-          type: string
-          enum:
-            - join
-            - invite
-            - knock
-            - leave
-            - ban
-          description: |-
-            The kind of membership to exclude from the results. Defaults to no
-            filtering if unspecified.
-          x-example: leave
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: |-
-            A list of members of the room. If you are joined to the room then
-            this will be the current members of the room. If you have left the
-            room then this will be the members of the room when you left.
-          examples:
-            application/json: {
-                "chunk": [
-                  {
-                    "room_id": "!636q39766251:example.com",
-                    "$ref": "../../event-schemas/examples/m.room.member.yaml"
-                  }
-                ]
-              }
-          schema:
-            type: object
-            properties:
-              chunk:
-                type: array
-                items:
-                  $ref: "definitions/client_event.yaml"
-        403:
-          description: >
-            You aren't a member of the room and weren't previously a
-            member of the room.
-      tags:
-        - Room participation
-  "/rooms/{roomId}/joined_members":
-    get:
-      summary: Gets the list of currently joined users and their profile data.
-      description:
-        This API returns a map of MXIDs to member info objects for members of the room. The current user must be in the room for it to work, unless it is an Application Service in which case any of the AS's users must be in the room.
-        This API is primarily for Application Services and should be faster to respond than `/members` as it can be implemented more efficiently on the server.
-      operationId: getJoinedMembersByRoom
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room to get the members of.
-          required: true
-          x-example: "!636q39766251:example.com"
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: |-
-            A map of MXID to room member objects.
-          examples:
-            application/json: {
-                "joined": {
-                  "@bar:example.com": {
-                    "display_name": "Bar",
-                    "avatar_url": "mxc://riot.ovh/printErCATzZijQsSDWorRaK"
-                  }
-                }
-              }
-          schema:
-            type: object
-            properties:
-              joined:
-                additionalProperties:
-                  title: RoomMember
-                  type: object
-                  properties:
-                    display_name:
-                      type: string
-                      description: The display name of the user this object is representing.
-                    avatar_url:
-                      type: string
-                      format: uri
-                      description: The mxc avatar url of the user this object is representing.
-                description: A map from user ID to a RoomMember object.
-                type: object
-        403:
-          description: >
-            You aren't a member of the room.
-      tags:
-        - Room participation
diff --git a/data/api/client-server/search.yaml b/data/api/client-server/search.yaml
deleted file mode 100644
index 5454f0a1..00000000
--- a/data/api/client-server/search.yaml
+++ /dev/null
@@ -1,365 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Search API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/search":
-    post:
-      summary: Perform a server-side search.
-      description: |-
-        Performs a full text search across different categories.
-      operationId: search
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          name: next_batch
-          type: string
-          description: |-
-            The point to return events from. If given, this should be a
-            `next_batch` result from a previous call to this endpoint.
-          x-example: "YWxsCgpOb25lLDM1ODcwOA"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-                "search_categories": {
-                  "room_events": {
-                    "keys": [
-                      "content.body"
-                    ],
-                    "search_term": "martians and men",
-                    "order_by": "recent",
-                    "groupings": {
-                      "group_by": [
-                        {
-                          "key": "room_id"
-                        }
-                      ]
-                    }
-                  }
-                }
-              }
-            properties:
-              search_categories:
-                type: object
-                title: "Categories"
-                description: Describes which categories to search in and
-                  their criteria.
-                properties:
-                  room_events:
-                    type: object
-                    title: Room Events Criteria
-                    description: Mapping of category name to search criteria.
-                    properties:
-                      search_term:
-                        type: string
-                        description: The string to search events for
-                      keys:
-                        type: array
-                        items:
-                          type: string
-                          enum: ["content.body", "content.name", "content.topic"]
-                        description: The keys to search. Defaults to all.
-                      filter:
-                        type: object
-                        title: Filter
-                        description: |-
-                          This takes a [filter](/client-server-api/#filtering).
-                        allOf:
-                          - $ref: "definitions/room_event_filter.yaml"
-                      order_by:
-                        title: "Ordering"
-                        type: string
-                        enum: ["recent", "rank"]
-                        description: |-
-                          The order in which to search for results.
-                          By default, this is `"rank"`.
-                      event_context:
-                        title: Include Event Context
-                        type: object
-                        description: |-
-                          Configures whether any context for the events
-                          returned are included in the response.
-                        properties:
-                            before_limit:
-                                type: integer
-                                title: "Before limit"
-                                description: |-
-                                  How many events before the result are
-                                  returned. By default, this is `5`.
-                            after_limit:
-                                type: integer
-                                title: "After limit"
-                                description: |-
-                                  How many events after the result are
-                                  returned. By default, this is `5`.
-                            include_profile:
-                                type: boolean
-                                title: "Return profile information"
-                                description: |-
-                                  Requests that the server returns the
-                                  historic profile information for the users
-                                  that sent the events that were returned.
-                                  By default, this is `false`.
-                      include_state:
-                        type: boolean
-                        title: Include current state
-                        description: |-
-                          Requests the server return the current state for
-                          each room returned.
-                      groupings:
-                        type: object
-                        title: Groupings
-                        description: |-
-                          Requests that the server partitions the result set
-                          based on the provided list of keys.
-                        properties:
-                          group_by:
-                            type: array
-                            title: Groups
-                            description: List of groups to request.
-                            items:
-                              type: object
-                              title: Group
-                              description: Configuration for group.
-                              properties:
-                                key:
-                                  type: string
-                                  title: Group Key
-                                  description: |-
-                                    Key that defines the group.
-                                  enum: ["room_id", "sender"]
-                    required: ["search_term"]
-            required: ["search_categories"]
-      responses:
-        200:
-          description: Results of the search.
-          schema:
-            type: object
-            title: Results
-            required: ["search_categories"]
-            properties:
-              search_categories:
-                type: object
-                title: Result Categories
-                description: Describes which categories to search in and
-                  their criteria.
-                properties:
-                  room_events:
-                    type: object
-                    title: Result Room Events
-                    description: Mapping of category name to search criteria.
-                    properties:
-                      count:
-                        type: integer
-                        description: An approximate count of the total number of results found.
-                      highlights:
-                        type: array
-                        title: Highlights
-                        description: List of words which should be highlighted, useful for stemming which may change the query terms.
-                        items:
-                          type: string
-                      results:
-                        type: array
-                        title: Results
-                        description: List of results in the requested order.
-                        items:
-                          type: object
-                          title: Result
-                          description: The result object.
-                          properties:
-                            rank:
-                              type: number
-                              description: A number that describes how closely
-                                this result matches the search. Higher is
-                                closer.
-                            result:
-                              type: object
-                              title: Event
-                              description: The event that matched.
-                              "$ref": "definitions/client_event.yaml"
-                            context:
-                              type: object
-                              title: Event Context
-                              description: Context for result, if requested.
-                              properties:
-                                start:
-                                  type: string
-                                  title: Start Token
-                                  description: |-
-                                    Pagination token for the start of the chunk
-                                end:
-                                  type: string
-                                  title: End Token
-                                  description: |-
-                                    Pagination token for the end of the chunk
-                                profile_info:
-                                  type: object
-                                  title: Profile Information
-                                  description: |-
-                                    The historic profile information of the
-                                    users that sent the events returned.
-
-                                    The `string` key is the user ID for which
-                                    the profile belongs to.
-                                  additionalProperties:
-                                    type: object
-                                    title: User Profile
-                                    properties:
-                                      displayname:
-                                        type: string
-                                        title: Display name
-                                      avatar_url:
-                                        type: string
-                                        format: uri
-                                        title: Avatar Url
-                                events_before:
-                                  type: array
-                                  title: Events Before
-                                  description: Events just before the result.
-                                  items:
-                                    title: Event
-                                    type: object
-                                    "$ref": "definitions/client_event.yaml"
-                                events_after:
-                                  type: array
-                                  title: Events After
-                                  description: Events just after the result.
-                                  items:
-                                    title: Event
-                                    type: object
-                                    "$ref": "definitions/client_event.yaml"
-                      state:
-                        type: object
-                        title: Current state
-                        description: |-
-                          The current state for every room in the results.
-                          This is included if the request had the
-                          `include_state` key set with a value of `true`.
-
-                          The `string` key is the room ID for which the `State
-                          Event` array belongs to.
-                        additionalProperties:
-                          type: array
-                          title: Room State
-                          items:
-                            type: object
-                            "$ref": "definitions/client_event.yaml"
-                      groups:
-                        type: object
-                        title: Groups
-                        description: |-
-                          Any groups that were requested.
-
-                          The outer `string` key is the group key requested (eg: `room_id`
-                          or `sender`). The inner `string` key is the grouped value (eg:
-                          a room's ID or a user's ID).
-                        additionalProperties:
-                          type: object
-                          title: Group Key
-                          description: The results for a given group.
-                          additionalProperties:
-                            type: object
-                            title: Group Value
-                            description: |-
-                                The results for a particular group value.
-                            properties:
-                              next_batch:
-                                type: string
-                                title: Next Batch in Group
-                                description: |-
-                                  Token that can be used to get the next batch
-                                  of results in the group, by passing as the
-                                  `next_batch` parameter to the next call. If
-                                  this field is absent, there are no more
-                                  results in this group.
-                              order:
-                                type: integer
-                                title: Group Order
-                                description: |-
-                                  Key that can be used to order different
-                                  groups.
-                              results:
-                                type: array
-                                description: |-
-                                  Which results are in this group.
-                                items:
-                                  type: string
-                                  title: Result Event ID
-                      next_batch:
-                        type: string
-                        title: Next Batch
-                        description: |-
-                          Token that can be used to get the next batch of
-                          results, by passing as the `next_batch` parameter to
-                          the next call. If this field is absent, there are no
-                          more results.
-          examples:
-            application/json: {
-                  "search_categories": {
-                    "room_events": {
-                      "groups": {
-                        "room_id": {
-                          "!qPewotXpIctQySfjSy:localhost": {
-                            "order": 1,
-                            "next_batch": "BdgFsdfHSf-dsFD",
-                            "results": [
-                              "$144429830826TWwbB:localhost"
-                            ]
-                          }
-                        }
-                      },
-                      "highlights": [
-                        "martians",
-                        "men"
-                      ],
-                      "next_batch": "5FdgFsd234dfgsdfFD",
-                      "count": 1224,
-                      "results": [
-                        {
-                          "rank": 0.00424866,
-                          "result": {
-                            "room_id": "!qPewotXpIctQySfjSy:localhost",
-                            "event_id": "$144429830826TWwbB:localhost",
-                            "$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"
-                          }
-                        }
-                      ]
-                    }
-                  }
-                }
-        400:
-          description: Part of the request was invalid.
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Search
diff --git a/data/api/client-server/space_hierarchy.yaml b/data/api/client-server/space_hierarchy.yaml
deleted file mode 100644
index 607eb8d1..00000000
--- a/data/api/client-server/space_hierarchy.yaml
+++ /dev/null
@@ -1,193 +0,0 @@
-# Copyright 2021 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Space Hierarchy API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/hierarchy":
-    get:
-      x-addedInMatrixVersion: "1.2"
-      summary: Retrieve a portion of a space tree.
-      description: |-
-        Paginates over the space tree in a depth-first manner to locate child rooms of a given space.
-
-        Where a child room is unknown to the local server, federation is used to fill in the details.
-        The servers listed in the `via` array should be contacted to attempt to fill in missing rooms.
-
-        Only [`m.space.child`](#mspacechild) state events of the room are considered. Invalid child
-        rooms and parent events are not covered by this endpoint.
-      operationId: getSpaceHierarchy
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room ID of the space to get a hierarchy for.
-          required: true
-          x-example: "!space:example.org"
-        - in: query
-          type: boolean
-          name: suggested_only
-          description: |-
-            Optional (default `false`) flag to indicate whether or not the server should only consider
-            suggested rooms. Suggested rooms are annotated in their [`m.space.child`](#mspacechild) event
-            contents.
-          x-example: true
-        - in: query
-          type: number
-          name: limit
-          description: |-
-            Optional limit for the maximum number of rooms to include per response. Must be an integer
-            greater than zero.
-
-            Servers should apply a default value, and impose a maximum value to avoid resource exhaustion.
-          x-example: 20
-        - in: query
-          type: number
-          name: max_depth
-          description: |-
-            Optional limit for how far to go into the space. Must be a non-negative integer.
-
-            When reached, no further child rooms will be returned.
-
-            Servers should apply a default value, and impose a maximum value to avoid resource exhaustion.
-          x-example: 5
-        - in: query
-          type: string
-          name: from
-          description: |-
-            A pagination token from a previous result. If specified, `max_depth` and `suggested_only` cannot
-            be changed from the first request.
-          x-example: "next_batch_token"
-      responses:
-        200:
-          description: |-
-            A portion of the space tree, starting at the provided room ID.
-          examples:
-            application/json: {
-              "rooms": [
-                {
-                  "room_id": "!space:example.org",
-                  "avatar_url": "mxc://example.org/abcdef",
-                  "guest_can_join": false,
-                  "name": "The First Space",
-                  "topic": "No other spaces were created first, ever",
-                  "world_readable": true,
-                  "join_rule": "public",
-                  "room_type": "m.space",
-                  "num_joined_members": 42,
-                  "canonical_alias": "#general:example.org",
-                  "children_state": [
-                    {
-                      "type": "m.space.child",
-                      "state_key": "!a:example.org",
-                      "content": {
-                        "via": ["example.org"]
-                      },
-                      "sender": "@alice:example.org",
-                      "origin_server_ts": 1629413349153
-                    }
-                  ]
-                }
-              ],
-              "next_batch": "next_batch_token"
-            }
-          schema:
-            type: object
-            properties:
-              rooms:
-                type: array
-                description: |-
-                  The rooms for the current page, with the current filters.
-                items:
-                  allOf:
-                    - $ref: "definitions/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.
-                        children_state:
-                          type: array
-                          description: |-
-                            The [`m.space.child`](#mspacechild) events of the space-room, represented
-                            as [Stripped State Events](#stripped-state) with an added `origin_server_ts` key.
-
-                            If the room is not a space-room, this should be empty.
-                          items:
-                            allOf:
-                              - $ref: "../../event-schemas/schema/core-event-schema/stripped_state.yaml"
-                              - type: object
-                                properties:
-                                  origin_server_ts:
-                                    type: number
-                                    format: int64
-                                    description: The `origin_server_ts` for the event.
-                                required: [origin_server_ts]
-                      required: [room_type, children_state]
-              next_batch:
-                type: string
-                description: |-
-                  A token to supply to `from` to keep paginating the responses. Not present when there are
-                  no further results.
-            required: [rooms]
-        403:
-          description: |-
-            The user cannot view or peek on the room. A meaningful `errcode`
-            and description error text will be returned. Example reasons for rejection are:
-
-            - The room is not set up for peeking.
-            - The user has been banned from the room.
-            - The room does not exist.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "You are not allowed to view this room."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        400:
-          description: |-
-            The request was invalid in some way. A meaningful `errcode`
-            and description error text will be returned. Example reasons for rejection are:
-
-            - The `from` token is unknown to the server.
-            - `suggested_only` or `max_depth` changed during pagination.
-          examples:
-            application/json: {
-              "errcode": "M_INVALID_PARAM",
-              "error": "suggested_only and max_depth cannot change on paginated requests"
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Spaces
diff --git a/data/api/client-server/sso_login_redirect.yaml b/data/api/client-server/sso_login_redirect.yaml
deleted file mode 100644
index 07278aaf..00000000
--- a/data/api/client-server/sso_login_redirect.yaml
+++ /dev/null
@@ -1,91 +0,0 @@
-# Copyright 2019 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server SSO Login API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-paths:
-  "/login/sso/redirect":
-    get:
-      x-addedInMatrixVersion: "1.1"
-      summary: Redirect the user's browser to the SSO interface.
-      description: |-
-        A web-based Matrix client should instruct the user's browser to
-        navigate to this endpoint in order to log in via SSO.
-
-        The server MUST respond with an HTTP redirect to the SSO interface,
-        or present a page which lets the user select an IdP to continue
-        with in the event multiple are supported by the server.
-      operationId: redirectToSSO
-      parameters:
-        - in: query
-          type: string
-          name: redirectUrl
-          description: |-
-            URI to which the user will be redirected after the homeserver has
-            authenticated the user with SSO.
-          required: true
-      responses:
-        302:
-          description: A redirect to the SSO interface.
-          headers:
-            Location:
-              type: "string"
-      tags:
-       - Session management
-  "/login/sso/redirect/{idpId}":
-    get:
-      x-addedInMatrixVersion: "1.1"
-      summary: Redirect the user's browser to the SSO interface for an IdP.
-      description: |-
-        This endpoint is the same as `/login/sso/redirect`, though with an
-        IdP ID from the original `identity_providers` array to inform the
-        server of which IdP the client/user would like to continue with.
-
-        The server MUST respond with an HTTP redirect to the SSO interface
-        for that IdP.
-      operationId: redirectToIdP
-      parameters:
-        - in: path
-          type: string
-          name: idpId
-          required: true
-          description: |-
-            The `id` of the IdP from the `m.login.sso` `identity_providers`
-            array denoting the user's selection.
-        - in: query
-          type: string
-          name: redirectUrl
-          description: |-
-            URI to which the user will be redirected after the homeserver has
-            authenticated the user with SSO.
-          required: true
-      responses:
-        302:
-          description: A redirect to the SSO interface.
-          headers:
-            Location:
-              type: "string"
-        404:
-          description: |-
-            The IdP ID was not recognized by the server. The server is encouraged
-            to provide a user-friendly page explaining the error given the user
-            will be navigated to it.
-      tags:
-       - Session management
diff --git a/data/api/client-server/sync.yaml b/data/api/client-server/sync.yaml
deleted file mode 100644
index f8127bf5..00000000
--- a/data/api/client-server/sync.yaml
+++ /dev/null
@@ -1,474 +0,0 @@
-# Copyright 2016, 2021 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server sync API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/sync":
-    get:
-      summary: Synchronise the client's state and receive new messages.
-      description: |-
-        Synchronise the client's state with the latest state on the server.
-        Clients use this API when they first log in to get an initial snapshot
-        of the state on the server, and then continue to call this API to get
-        incremental deltas to the state, and to receive new messages.
-
-        *Note*: This endpoint supports lazy-loading. See [Filtering](/client-server-api/#filtering)
-        for more information. Lazy-loading members is only supported on a `StateFilter`
-        for this endpoint. When lazy-loading is enabled, servers MUST include the
-        syncing user's own membership event when they join a room, or when the
-        full state of rooms is requested, to aid discovering the user's avatar &
-        displayname.
-
-        Further, like other members, the user's own membership event is eligible
-        for being considered redundant by the server. When a sync is `limited`,
-        the server MUST return membership events for events in the gap
-        (between `since` and the start of the returned timeline), regardless
-        as to whether or not they are redundant. This ensures that joins/leaves
-        and profile changes which occur during the gap are not lost.
-
-        Note that the default behaviour of `state` is to include all membership
-        events, alongside other state, when lazy-loading is not enabled.
-      operationId: sync
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          name: filter
-          type: string
-          description: |-
-            The ID of a filter created using the filter API or a filter JSON
-            object encoded as a string. The server will detect whether it is
-            an ID or a JSON object by whether the first character is a `"{"`
-            open brace. Passing the JSON inline is best suited to one off
-            requests. Creating a filter using the filter API is recommended for
-            clients that reuse the same filter multiple times, for example in
-            long poll requests.
-
-            See [Filtering](/client-server-api/#filtering) for more information.
-          x-example: "66696p746572"
-        - in: query
-          name: since
-          type: string
-          description: |-
-            A point in time to continue a sync from. This should be the
-            `next_batch` token returned by an earlier call to this endpoint.
-          x-example: "s72594_4483_1934"
-        - in: query
-          name: full_state
-          type: boolean
-          description: |-
-            Controls whether to include the full state for all rooms the user
-            is a member of.
-
-            If this is set to `true`, then all state events will be returned,
-            even if `since` is non-empty. The timeline will still be limited
-            by the `since` parameter. In this case, the `timeout` parameter
-            will be ignored and the query will return immediately, possibly with
-            an empty timeline.
-
-            If `false`, and `since` is non-empty, only state which has
-            changed since the point indicated by `since` will be returned.
-
-            By default, this is `false`.
-          x-example: "false"
-        - in: query
-          name: set_presence
-          type: string
-          enum: ["offline", "online", "unavailable"]
-          description: |-
-            Controls whether the client is automatically marked as online by
-            polling this API. If this parameter is omitted then the client is
-            automatically marked as online when it uses this API. Otherwise if
-            the parameter is set to "offline" then the client is not marked as
-            being online when it uses this API. When set to "unavailable", the
-            client is marked as being idle.
-          x-example: "offline"
-        - in: query
-          name: timeout
-          type: integer
-          description: |-
-            The maximum time to wait, in milliseconds, before returning this
-            request. If no events (or other data) become available before this
-            time elapses, the server will return a response with empty fields.
-
-            By default, this is `0`, so the server will return immediately
-            even if the response is empty.
-          x-example: 30000
-      responses:
-        200:
-          description:
-            The initial snapshot or delta for the client to use to update their
-            state.
-          schema:
-            type: object
-            properties:
-              next_batch:
-                type: string
-                description: |-
-                  The batch token to supply in the `since` param of the next
-                  `/sync` request.
-              rooms:
-                title: Rooms
-                type: object
-                description: |-
-                  Updates to rooms.
-                properties:
-                  join:
-                    title: Joined Rooms
-                    type: object
-                    description: |-
-                      The rooms that the user has joined, mapped as room ID to
-                      room information.
-                    additionalProperties:
-                      title: Joined Room
-                      type: object
-                      properties:
-                        summary:
-                          title: RoomSummary
-                          type: object
-                          description: |-
-                            Information about the room which clients may need to
-                            correctly render it to users.
-                          properties:
-                            "m.heroes":
-                              type: array
-                              description: |-
-                                The users which can be used to generate a room name
-                                if the room does not have one. Required if the room's
-                                `m.room.name` or `m.room.canonical_alias` state events
-                                are unset or empty.
-
-                                This should be the first 5 members of the room, ordered
-                                by stream ordering, which are joined or invited. The
-                                list must never include the client's own user ID. When
-                                no joined or invited members are available, this should
-                                consist of the banned and left users. More than 5 members
-                                may be provided, however less than 5 should only be provided
-                                when there are less than 5 members to represent.
-
-                                When lazy-loading room members is enabled, the membership
-                                events for the heroes MUST be included in the `state`,
-                                unless they are redundant. When the list of users changes,
-                                the server notifies the client by sending a fresh list of
-                                heroes. If there are no changes since the last sync, this
-                                field may be omitted.
-                              items:
-                                type: string
-                            "m.joined_member_count":
-                              type: integer
-                              description: |-
-                                 The number of users with `membership` of `join`,
-                                 including the client's own user ID. If this field has
-                                 not changed since the last sync, it may be omitted.
-                                 Required otherwise.
-                            "m.invited_member_count":
-                              type: integer
-                              description: |-
-                                 The number of users with `membership` of `invite`.
-                                 If this field has not changed since the last sync, it
-                                 may be omitted. Required otherwise.
-                        state:
-                          title: State
-                          type: object
-                          description: |-
-                            Updates to the state, between the time indicated by
-                            the `since` parameter, and the start of the
-                            `timeline` (or all state up to the start of the
-                            `timeline`, if `since` is not given, or
-                            `full_state` is true).
-
-                            N.B. state updates for `m.room.member` events will
-                            be incomplete if `lazy_load_members` is enabled in
-                            the `/sync` filter, and only return the member events
-                            required to display the senders of the timeline events
-                            in this response.
-                          allOf:
-                            - $ref: "definitions/state_event_batch.yaml"
-                        timeline:
-                          title: Timeline
-                          type: object
-                          description: |-
-                            The timeline of messages and state changes in the
-                            room.
-                          allOf:
-                            - $ref: "definitions/timeline_batch.yaml"
-                        ephemeral:
-                          title: Ephemeral
-                          type: object
-                          description: |-
-                            The ephemeral events in the room that aren't
-                            recorded in the timeline or state of the room.
-                            e.g. typing.
-                          allOf:
-                            - $ref: "definitions/event_batch.yaml"
-                        account_data:
-                          title: Account Data
-                          type: object
-                          description: |-
-                            The private data that this user has attached to
-                            this room.
-                          allOf:
-                          - $ref: "definitions/event_batch.yaml"
-                        unread_notifications:
-                          title: Unread Notification Counts
-                          type: object
-                          description: |-
-                            Counts of unread notifications for this room. See the
-                            [Receiving notifications](/client-server-api/#receiving-notifications) section
-                            for more information on how these are calculated.
-                          properties:
-                            highlight_count:
-                                title: Highlighted notification count
-                                type: integer
-                                description: The number of unread notifications
-                                             for this room with the highlight flag set
-                            notification_count:
-                                title: Total notification count
-                                type: integer
-                                description: The total number of unread notifications
-                                             for this room
-                  invite:
-                    title: Invited Rooms
-                    type: object
-                    description: |-
-                      The rooms that the user has been invited to, mapped as room ID to
-                      room information.
-                    additionalProperties:
-                      title: Invited Room
-                      type: object
-                      properties:
-                        invite_state:
-                          title: InviteState
-                          type: object
-                          description: |-
-                            The [stripped state](#stripped-state) of a room that the user has been invited
-                            to.
-                          properties:
-                            events:
-                              description: The [stripped state events](#stripped-state) that form the invite state.
-                              items:
-                                $ref: "../../event-schemas/schema/core-event-schema/stripped_state.yaml"
-                              type: array
-                  knock:
-                    title: Knocked rooms
-                    type: object
-                    description: |-
-                      The rooms that the user has knocked upon, mapped as room ID to room information.
-                    additionalProperties:
-                      title: Knocked Room
-                      type: object
-                      properties:
-                        knock_state:
-                          title: KnockState
-                          type: object
-                          description: |-
-                            The [stripped state](#stripped-state) of a room that the user has knocked upon.
-                          properties:
-                            events:
-                              description: The [stripped state events](#stripped-state) that form the knock state.
-                              items:
-                                $ref: "../../event-schemas/schema/core-event-schema/stripped_state.yaml"
-                              type: array
-                  leave:
-                    title: Left rooms
-                    type: object
-                    description: |-
-                      The rooms that the user has left or been banned from, mapped as room ID to
-                      room information.
-                    additionalProperties:
-                      title: Left Room
-                      type: object
-                      properties:
-                        state:
-                          title: State
-                          type: object
-                          description: |-
-                            The state updates for the room up to the start of the timeline.
-                          allOf:
-                            - $ref: "definitions/state_event_batch.yaml"
-                        timeline:
-                          title: Timeline
-                          type: object
-                          description: |-
-                            The timeline of messages and state changes in the
-                            room up to the point when the user left.
-                          allOf:
-                            - $ref: "definitions/timeline_batch.yaml"
-                        account_data:
-                          title: Account Data
-                          type: object
-                          description: |-
-                            The private data that this user has attached to
-                            this room.
-                          allOf:
-                          - $ref: "definitions/event_batch.yaml"
-              presence:
-                title: Presence
-                type: object
-                description: |-
-                  The updates to the presence status of other users.
-                allOf:
-                  - $ref: "definitions/event_batch.yaml"
-              account_data:
-                title: Account Data
-                type: object
-                description: |-
-                  The global private data created by this user.
-                allOf:
-                  - $ref: "definitions/event_batch.yaml"
-              to_device:
-                title: ToDevice
-                type: object
-                description: |-
-                  Information on the send-to-device messages for the client
-                  device, as defined in [Send-to-Device messaging](/client-server-api/#extensions-to-sync).
-              device_lists:
-                title: DeviceLists
-                type: object
-                description: |-
-                  Information on end-to-end device updates, as specified in
-                  [End-to-end encryption](/client-server-api/#extensions-to-sync-1).
-              device_one_time_keys_count:
-                title: One-time keys count
-                type: object
-                additionalProperties:
-                  type: integer
-                description: |-
-                  Information on end-to-end encryption keys, as specified
-                  in [End-to-end encryption](/client-server-api/#extensions-to-sync-1).
-            required:
-              - next_batch
-          examples:
-            application/json: {
-                "next_batch": "s72595_4483_1934",
-                "presence": {
-                  "events": [
-                    {"$ref": "../../event-schemas/examples/m.presence.yaml"}
-                  ]
-                },
-                "account_data": {
-                  "events": [
-                    {
-                      "type": "org.example.custom.config",
-                      "content": {
-                        "custom_config_key": "custom_config_value"
-                      }
-                    }
-                  ]
-                },
-                "rooms": {
-                  "join": {
-                    "!726s6s6q:example.com": {
-                      "summary": {
-                        "m.heroes": [
-                          "@alice:example.com",
-                          "@bob:example.com"
-                        ],
-                        "m.joined_member_count": 2,
-                        "m.invited_member_count": 0
-                      },
-                      "state": {
-                        "events": [
-                          {
-                            "$ref": "../../event-schemas/examples/m.room.member.yaml"
-                          }
-                        ]
-                      },
-                      "timeline": {
-                        "events": [
-                          {
-                            "$ref": "../../event-schemas/examples/m.room.member.yaml"
-                          },
-                          {
-                            "$ref": "../../event-schemas/examples/m.room.message$m.text.yaml"
-                          }
-                        ],
-                        "limited": true,
-                        "prev_batch": "t34-23535_0_0"
-                      },
-                      "ephemeral": {
-                        "events": [
-                          {"$ref": "../../event-schemas/examples/m.typing.yaml"}
-                        ]
-                      },
-                      "account_data": {
-                        "events": [
-                          {"$ref": "../../event-schemas/examples/m.tag.yaml"},
-                          {
-                            "type": "org.example.custom.room.config",
-                            "content": {
-                              "custom_config_key": "custom_config_value"
-                            }
-                          }
-                        ]
-                      }
-                    }
-                  },
-                  "invite": {
-                    "!696r7674:example.com": {
-                      "invite_state": {
-                        "events": [
-                          {
-                            "sender": "@alice:example.com",
-                            "type": "m.room.name",
-                            "state_key": "",
-                            "content": {"name": "My Room Name"}
-                          },
-                          {
-                            "sender": "@alice:example.com",
-                            "type": "m.room.member",
-                            "state_key": "@bob:example.com",
-                            "content": {"membership": "invite"}
-                          }
-                        ]
-                      }
-                    }
-                  },
-                  "knock": {
-                    "!223asd456:example.com": {
-                      "knock_state": {
-                        "events": [
-                          {
-                            "sender": "@alice:example.com",
-                            "type": "m.room.name",
-                            "state_key": "",
-                            "content": {"name": "My Room Name"}
-                          },
-                          {
-                            "sender": "@bob:example.com",
-                            "type": "m.room.member",
-                            "state_key": "@bob:example.com",
-                            "content": {"membership": "knock"}
-                          }
-                        ]
-                      }
-                    }
-                  },
-                  "leave": {}
-                }
-              }
-      tags:
-        - Room participation
diff --git a/data/api/client-server/tags.yaml b/data/api/client-server/tags.yaml
deleted file mode 100644
index f04a884a..00000000
--- a/data/api/client-server/tags.yaml
+++ /dev/null
@@ -1,183 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server tag API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/user/{userId}/rooms/{roomId}/tags":
-    get:
-      summary: List the tags for a room.
-      description: |-
-        List the tags set by a user on a room.
-      operationId: getRoomTags
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          required: true
-          description: |-
-            The id of the user to get tags for. The access token must be
-            authorized to make requests for this user ID.
-          x-example: "@alice:example.com"
-        - in: path
-          type: string
-          name: roomId
-          required: true
-          description: |-
-            The ID of the room to get tags for.
-          x-example: "!726s6s6q:example.com"
-      responses:
-        200:
-          description:
-            The list of tags for the user for the room.
-          schema:
-            type: object
-            properties:
-              tags:
-                type: object
-                additionalProperties:
-                  title: Tag
-                  type: object
-                  properties:
-                    order:
-                      type: number
-                      format: float
-                      description: |-
-                        A number in a range `[0,1]` describing a relative
-                        position of the room under the given tag.
-                  additionalProperties: true
-          examples:
-            application/json: {
-              "tags": {
-                "m.favourite": {"order": 0.1},
-                "u.Work": {"order": 0.7},
-                "u.Customers": {}
-              }
-            }
-      tags:
-        - User data
-  "/user/{userId}/rooms/{roomId}/tags/{tag}":
-    put:
-      summary: Add a tag to a room.
-      description: |-
-        Add a tag to the room.
-      operationId: setRoomTag
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          required: true
-          description: |-
-            The id of the user to add a tag for. The access token must be
-            authorized to make requests for this user ID.
-          x-example: "@alice:example.com"
-        - in: path
-          type: string
-          name: roomId
-          required: true
-          description: |-
-            The ID of the room to add a tag to.
-          x-example: "!726s6s6q:example.com"
-        - in: path
-          type: string
-          name: tag
-          required: true
-          description: |-
-            The tag to add.
-          x-example: "u.work"
-        - in: body
-          name: body
-          required: true
-          description: |-
-            Extra data for the tag, e.g. ordering.
-          schema:
-            type: object
-            properties:
-              order:
-                type: number
-                format: float
-                description: |-
-                  A number in a range `[0,1]` describing a relative
-                  position of the room under the given tag.
-            additionalProperties: true
-            example: {
-              "order": 0.25
-            }
-      responses:
-        200:
-          description:
-            The tag was successfully added.
-          schema:
-            type: object
-          examples:
-            application/json: {}
-      tags:
-        - User data
-    delete:
-      summary: Remove a tag from the room.
-      description: |-
-        Remove a tag from the room.
-      operationId: deleteRoomTag
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          required: true
-          description: |-
-            The id of the user to remove a tag for. The access token must be
-            authorized to make requests for this user ID.
-          x-example: "@alice:example.com"
-        - in: path
-          type: string
-          name: roomId
-          required: true
-          description: |-
-            The ID of the room to remove a tag from.
-          x-example: "!726s6s6q:example.com"
-        - in: path
-          type: string
-          name: tag
-          required: true
-          description: |-
-            The tag to remove.
-          x-example: "u.work"
-      responses:
-        200:
-          description:
-            The tag was successfully removed.
-          schema:
-            type: object
-          examples:
-            application/json: {}
-      tags:
-        - User data
diff --git a/data/api/client-server/third_party_lookup.yaml b/data/api/client-server/third_party_lookup.yaml
deleted file mode 100644
index f56554e3..00000000
--- a/data/api/client-server/third_party_lookup.yaml
+++ /dev/null
@@ -1,220 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Third Party Lookup API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/thirdparty/protocols":
-    get:
-      summary: Retrieve metadata about all protocols that a homeserver supports.
-      description: |-
-        Fetches the overall metadata about protocols supported by the
-        homeserver. Includes both the available protocols and all fields
-        required for queries against each protocol.
-      operationId: getProtocols
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: The protocols supported by the homeserver.
-          schema:
-            $ref: ../application-service/definitions/protocol_metadata.yaml
-      tags:
-        - Third Party Lookup
-  "/thirdparty/protocol/{protocol}":
-    get:
-      summary: Retrieve metadata about a specific protocol that the homeserver supports.
-      description: |-
-        Fetches the metadata from the homeserver about a particular third party protocol.
-      operationId: getProtocolMetadata
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          name: protocol
-          type: string
-          description: |-
-            The name of the protocol.
-          required: true
-          x-example: "irc"
-      responses:
-        200:
-          description: The protocol was found and metadata returned.
-          schema:
-            $ref: ../application-service/definitions/protocol.yaml
-        404:
-          description: The protocol is unknown.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND"
-            }
-          schema:
-            $ref: definitions/errors/error.yaml
-      tags:
-        - Third Party Lookup
-  "/thirdparty/location/{protocol}":
-    get:
-      summary: Retrieve Matrix-side portals rooms leading to a third party location.
-      description: |-
-        Requesting this endpoint with a valid protocol name results in a list
-        of successful mapping results in a JSON array. Each result contains
-        objects to represent the Matrix room or rooms that represent a portal
-        to this third party network. Each has the Matrix room alias string,
-        an identifier for the particular third party network protocol, and an
-        object containing the network-specific fields that comprise this
-        identifier. It should attempt to canonicalise the identifier as much
-        as reasonably possible given the network type.
-      operationId: queryLocationByProtocol
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          name: protocol
-          type: string
-          description: The protocol used to communicate to the third party network.
-          required: true
-          x-example: irc
-        - in: query
-          name: searchFields
-          type: string
-          description: |-
-            One or more custom fields to help identify the third party
-            location.
-      responses:
-        200:
-          description: At least one portal room was found.
-          schema:
-            $ref: ../application-service/definitions/location_batch.yaml
-        404:
-          description: No portal rooms were found.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND"
-            }
-          schema:
-            $ref: definitions/errors/error.yaml
-      tags:
-        - Third Party Lookup
-  "/thirdparty/user/{protocol}":
-    get:
-      summary: Retrieve the Matrix User ID of a corresponding third party user.
-      description: |-
-        Retrieve a Matrix User ID linked to a user on the third party service, given
-        a set of user parameters.
-      operationId: queryUserByProtocol
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          name: protocol
-          type: string
-          description: |-
-            The name of the protocol.
-          required: true
-          x-example: irc
-        - in: query
-          name: fields...
-          type: string
-          description: |-
-            One or more custom fields that are passed to the AS to help identify the user.
-      responses:
-        200:
-          description: The Matrix User IDs found with the given parameters.
-          schema:
-            $ref: ../application-service/definitions/user_batch.yaml
-        404:
-          description: The Matrix User ID was not found
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND"
-            }
-          schema:
-            $ref: definitions/errors/error.yaml
-      tags:
-        - Third Party Lookup
-  "/thirdparty/location":
-    get:
-      summary: Reverse-lookup third party locations given a Matrix room alias.
-      description: |-
-        Retrieve an array of third party network locations from a Matrix room
-        alias.
-      operationId: queryLocationByAlias
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          name: alias
-          type: string
-          description: The Matrix room alias to look up.
-          required: true
-          x-example: "#matrix:matrix.org"
-      responses:
-        200:
-          description: |-
-            All found third party locations.
-          schema:
-            $ref: ../application-service/definitions/location_batch.yaml
-        404:
-          description: The Matrix room alias was not found
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND"
-            }
-          schema:
-            $ref: definitions/errors/error.yaml
-      tags:
-        - Third Party Lookup
-  "/thirdparty/user":
-    get:
-      summary: Reverse-lookup third party users given a Matrix User ID.
-      description: |-
-        Retrieve an array of third party users from a Matrix User ID.
-      operationId: queryUserByID
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          name: userid
-          type: string
-          description: The Matrix User ID to look up.
-          required: true
-          x-example: "@bob:matrix.org"
-      responses:
-        200:
-          description: |-
-            An array of third party users.
-          schema:
-            $ref: ../application-service/definitions/user_batch.yaml
-        404:
-          description: The Matrix User ID was not found
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND"
-            }
-          schema:
-            $ref: definitions/errors/error.yaml
-      tags:
-        - Third Party Lookup
diff --git a/data/api/client-server/third_party_membership.yaml b/data/api/client-server/third_party_membership.yaml
deleted file mode 100644
index cf4a0d34..00000000
--- a/data/api/client-server/third_party_membership.yaml
+++ /dev/null
@@ -1,140 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Room Membership API for third party identifiers"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/invite":
-    post:
-      summary: Invite a user to participate in a particular room.
-      description: |-
-        *Note that there are two forms of this API, which are documented separately.
-        This version of the API does not require that the inviter know the Matrix
-        identifier of the invitee, and instead relies on third party identifiers.
-        The homeserver uses an identity server to perform the mapping from
-        third party identifier to a Matrix identifier. The other is documented in the*
-        [joining rooms section](/client-server-api/#post_matrixclientv3roomsroomidinvite).
-
-        This API invites a user to participate in a particular room.
-        They do not start participating in the room until they actually join the
-        room.
-
-        Only users currently in a particular room can invite other users to
-        join that room.
-
-        If the identity server did know the Matrix user identifier for the
-        third party identifier, the homeserver will append a `m.room.member`
-        event to the room.
-
-        If the identity server does not know a Matrix user identifier for the
-        passed third party identifier, the homeserver will issue an invitation
-        which can be accepted upon providing proof of ownership of the third
-        party identifier. This is achieved by the identity server generating a
-        token, which it gives to the inviting homeserver. The homeserver will
-        add an `m.room.third_party_invite` event into the graph for the room,
-        containing that token.
-
-        When the invitee binds the invited third party identifier to a Matrix
-        user ID, the identity server will give the user a list of pending
-        invitations, each containing:
-
-        - The room ID to which they were invited
-
-        - The token given to the homeserver
-
-        - A signature of the token, signed with the identity server's private key
-
-        - The matrix user ID who invited them to the room
-
-        If a token is requested from the identity server, the homeserver will
-        append a `m.room.third_party_invite` event to the room.
-
-      operationId: inviteBy3PID
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room identifier (not alias) to which to invite the user.
-          required: true
-          x-example: "!d41d8cd:matrix.org"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            example: {
-                "id_server": "matrix.org",
-                "id_access_token": "abc123_OpaqueString",
-                "medium": "email",
-                "address": "cheeky@monkey.com"
-              }
-            properties:
-              id_server:
-                type: string
-                description: The hostname+port of the identity server which should be used for third party identifier lookups.
-              id_access_token:
-                type: string
-                description: |-
-                  An access token previously registered with the identity server. Servers
-                  can treat this as optional to distinguish between r0.5-compatible clients
-                  and this specification version.
-              medium:
-                type: string
-                # TODO: Link to Identity Service spec when it eixsts
-                description: The kind of address being passed in the address field, for example `email`.
-              address:
-                type: string
-                description: The invitee's third party identifier.
-            required: ["id_server", "id_access_token", "medium", "address"]
-      responses:
-        200:
-          description: The user has been invited to join the room.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object
-        403:
-          description: |-
-            You do not have permission to invite the user to the room. A meaningful `errcode` and description error text will be returned. Example reasons for rejections are:
-
-            - The invitee has been banned from the room.
-            - The invitee is already a member of the room.
-            - The inviter is not currently in the room.
-            - The inviter's power level is insufficient to invite users to the room.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN", "error": "@cheeky_monkey:matrix.org is banned from the room"}
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Room membership
diff --git a/data/api/client-server/to_device.yaml b/data/api/client-server/to_device.yaml
deleted file mode 100644
index fb0c1d37..00000000
--- a/data/api/client-server/to_device.yaml
+++ /dev/null
@@ -1,92 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Send-to-device API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/sendToDevice/{eventType}/{txnId}":
-    put:
-      summary: Send an event to a given set of devices.
-      description: |-
-        This endpoint is used to send send-to-device events to a set of
-        client devices.
-      operationId: sendToDevice
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: eventType
-          description: The type of event to send.
-          required: true
-          x-example: "m.new_device"
-        - in: path
-          name: txnId
-          type: string
-          description: |-
-            The transaction ID for this event. Clients should generate an
-            ID unique across requests with the same access token; it will be
-            used by the server to ensure idempotency of requests.
-          required: true
-          x-example: "35"
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            title: body
-            properties:
-              messages:
-                type: object
-                description: |-
-                  The messages to send. A map from user ID, to a map from
-                  device ID to message body. The device ID may also be `*`,
-                  meaning all known devices for the user.
-                additionalProperties:
-                  type: object
-                  additionalProperties:
-                    type: object
-                    title: EventContent
-                    description: Message content
-                example: {
-                    "@alice:example.com": {
-                      "TLLBEANAAG": {
-                        "example_content_key": "value"
-                      }
-                    }
-                  }
-            required: ["messages"]
-      responses:
-        200:
-          description:
-            The message was successfully sent.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-      tags:
-        - Send-to-Device messaging
diff --git a/data/api/client-server/typing.yaml b/data/api/client-server/typing.yaml
deleted file mode 100644
index 65a1225d..00000000
--- a/data/api/client-server/typing.yaml
+++ /dev/null
@@ -1,87 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Typing API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/rooms/{roomId}/typing/{userId}":
-    put:
-      summary: Informs the server that the user has started or stopped typing.
-      description: |-
-        This tells the server that the user is typing for the next N
-        milliseconds where N is the value specified in the `timeout` key.
-        Alternatively, if `typing` is `false`, it tells the server that the
-        user has stopped typing.
-      operationId: setTyping
-      security:
-        - accessToken: []
-      parameters:
-        - in: path
-          type: string
-          name: userId
-          description: The user who has started to type.
-          required: true
-          x-example: "@alice:example.com"
-        - in: path
-          type: string
-          name: roomId
-          description: The room in which the user is typing.
-          required: true
-          x-example: "!wefh3sfukhs:example.com"
-        - in: body
-          name: typingState
-          description: The current typing state.
-          required: true
-          schema:
-            type: object
-            example: {
-                "typing": true,
-                "timeout": 30000
-              }
-            properties:
-              typing:
-                type: boolean
-                description: |-
-                  Whether the user is typing or not. If `false`, the `timeout`
-                  key can be omitted.
-              timeout:
-                type: integer
-                description: The length of time in milliseconds to mark this user as typing.
-            required: ["typing"]
-      responses:
-        200:
-          description: The new typing state was set.
-          examples:
-            application/json: {
-              }
-          schema:
-            type: object  # empty json object
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Room participation
diff --git a/data/api/client-server/users.yaml b/data/api/client-server/users.yaml
deleted file mode 100644
index 7a6f6856..00000000
--- a/data/api/client-server/users.yaml
+++ /dev/null
@@ -1,110 +0,0 @@
-# Copyright 2017 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server User Directory API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/user_directory/search":
-    post:
-      summary: Searches the user directory.
-      description: |-
-        Performs a search for users. The homeserver may
-        determine which subset of users are searched, however the homeserver
-        MUST at a minimum consider the users the requesting user shares a
-        room with and those who reside in public rooms (known to the homeserver).
-        The search MUST consider local users to the homeserver, and SHOULD
-        query remote users as part of the search.
-
-        The search is performed case-insensitively on user IDs and display
-        names preferably using a collation determined based upon the
-        `Accept-Language` header provided in the request, if present.
-      operationId: searchUserDirectory
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          required: true
-          schema:
-            type: object
-            properties:
-              search_term:
-                type: string
-                description: The term to search for
-                example: "foo"
-              limit:
-                type: integer
-                description: The maximum number of results to return. Defaults to 10.
-                example: 10
-            required: ["search_term"]
-      responses:
-        200:
-          description: The results of the search.
-          examples:
-            application/json: {
-              "results": [
-                {
-                  "user_id": "@foo:bar.com",
-                  "display_name": "Foo",
-                  "avatar_url": "mxc://bar.com/foo"
-                }
-              ],
-              "limited": false
-            }
-          schema:
-            type: object
-            required: ["results", "limited"]
-            properties:
-              results:
-                type: array
-                description: Ordered by rank and then whether or not profile info is available.
-                items:
-                  title: User
-                  type: object
-                  required: ["user_id"]
-                  properties:
-                    user_id:
-                      type: string
-                      example: "@foo:bar.com"
-                      description: The user's matrix user ID.
-                    display_name:
-                      type: string
-                      example: "Foo"
-                      description: The display name of the user, if one exists.
-                    avatar_url:
-                      type: string
-                      format: uri
-                      example: "mxc://bar.com/foo"
-                      description: The avatar url, as an MXC, if one exists.
-              limited:
-                type: boolean
-                description: Indicates if the result list has been truncated by the limit.
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - User directory
diff --git a/data/api/client-server/versions.yaml b/data/api/client-server/versions.yaml
deleted file mode 100644
index 58c1fbe0..00000000
--- a/data/api/client-server/versions.yaml
+++ /dev/null
@@ -1,79 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Versions API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client
-produces:
-  - application/json
-paths:
-  "/versions":
-    get:
-      summary: Gets the versions of the specification supported by the server.
-      description: |-
-        Gets the versions of the specification supported by the server.
-
-        Values will take the form `vX.Y` or `rX.Y.Z` in historical cases. See
-        [the Specification Versioning](../#specification-versions) for more
-        information.
-
-        The server may additionally advertise experimental features it supports
-        through `unstable_features`. These features should be namespaced and
-        may optionally include version information within their name if desired.
-        Features listed here are not for optionally toggling parts of the Matrix
-        specification and should only be used to advertise support for a feature
-        which has not yet landed in the spec. For example, a feature currently
-        undergoing the proposal process may appear here and eventually be taken
-        off this list once the feature lands in the spec and the server deems it
-        reasonable to do so. Servers may wish to keep advertising features here
-        after they've been released into the spec to give clients a chance to
-        upgrade appropriately. Additionally, clients should avoid using unstable
-        features in their stable releases.
-      operationId: getVersions
-      responses:
-        200:
-          description: The versions supported by the server.
-          examples:
-            application/json: {
-                "versions": ["r0.0.1", "v1.1"],
-                "unstable_features": {
-                  "org.example.my_feature": true
-                }
-              }
-          schema:
-            type: object
-            properties:
-              versions:
-                type: array
-                description: The supported versions.
-                items:
-                  type: string
-                  description: The supported versions
-              unstable_features:
-                type: object
-                description: |-
-                  Experimental features the server supports. Features not listed here,
-                  or the lack of this property all together, indicate that a feature is
-                  not supported.
-                additionalProperties:
-                  type: boolean
-                  description: Whether or not the namespaced feature is supported.
-            required: ['versions']
-      tags:
-        - Server administration
diff --git a/data/api/client-server/voip.yaml b/data/api/client-server/voip.yaml
deleted file mode 100644
index 6c0d1816..00000000
--- a/data/api/client-server/voip.yaml
+++ /dev/null
@@ -1,78 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Voice over IP API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/voip/turnServer":
-    get:
-      summary: Obtain TURN server credentials.
-      description: |-
-        This API provides credentials for the client to use when initiating
-        calls.
-      operationId: getTurnServer
-      security:
-        - accessToken: []
-      responses:
-        200:
-          description: The TURN server credentials.
-          examples:
-            application/json: {
-                "username":"1443779631:@user:example.com",
-                "password":"JlKfBy1QwLrO20385QyAtEyIv0=",
-                "uris":[
-                  "turn:turn.example.com:3478?transport=udp",
-                  "turn:10.20.30.40:3478?transport=tcp",
-                  "turns:10.20.30.40:443?transport=tcp"
-                ],
-                "ttl":86400
-              }
-          schema:
-            type: object
-            properties:
-              username:
-                type: string
-                description: |-
-                  The username to use.
-              password:
-                type: string
-                description: |-
-                  The password to use.
-              uris:
-                type: array
-                items:
-                  type: string
-                description: A list of TURN URIs
-              ttl:
-                type: integer
-                description: The time-to-live in seconds
-            required: ["username", "password", "uris", "ttl"]
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - VOIP
diff --git a/data/api/client-server/wellknown.yaml b/data/api/client-server/wellknown.yaml
deleted file mode 100644
index 9fff7ea7..00000000
--- a/data/api/client-server/wellknown.yaml
+++ /dev/null
@@ -1,46 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Server Discovery API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-basePath: /.well-known
-produces:
-  - application/json
-paths:
-  "/matrix/client":
-    get:
-      summary: Gets Matrix server discovery information about the domain.
-      description: |-
-        Gets discovery information about the domain. The file may include
-        additional keys, which MUST follow the Java package naming convention,
-        e.g. `com.example.myapp.property`. This ensures property names are
-        suitably namespaced for each application and reduces the risk of
-        clashes.
-
-        Note that this endpoint is not necessarily handled by the homeserver,
-        but by another webserver, to be used for discovering the homeserver URL.
-      operationId: getWellknown
-      responses:
-        200:
-          description: Server discovery information.
-          schema:
-            "$ref": "definitions/wellknown/full.yaml"
-        404:
-          description: No server discovery information available.
-      tags:
-        - Server administration
diff --git a/data/api/client-server/whoami.yaml b/data/api/client-server/whoami.yaml
deleted file mode 100644
index 727f7e64..00000000
--- a/data/api/client-server/whoami.yaml
+++ /dev/null
@@ -1,100 +0,0 @@
-# Copyright 2017 Travis Ralston
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Client-Server Account Identification API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/client/v3
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/account/whoami":
-    get:
-      summary: Gets information about the owner of an access token.
-      description: |-
-        Gets information about the owner of a given access token.
-
-        Note that, as with the rest of the Client-Server API,
-        Application Services may masquerade as users within their
-        namespace by giving a `user_id` query parameter. In this
-        situation, the server should verify that the given `user_id`
-        is registered by the appservice, and return it in the response
-        body.
-      operationId: getTokenOwner
-      security:
-        - accessToken: []
-      parameters: []
-      responses:
-        200:
-          description:
-            The token belongs to a known user.
-          examples:
-            application/json: {
-              "user_id": "@joe:example.org",
-              "device_id": "ABC1234"
-            }
-          schema:
-            type: object
-            required: ["user_id"]
-            properties:
-              user_id:
-                type: string
-                description: The user ID that owns the access token.
-              device_id:
-                x-addedInMatrixVersion: "1.1"
-                type: string
-                description: |-
-                  Device ID associated with the access token. If no device
-                  is associated with the access token (such as in the case
-                  of application services) then this field can be omitted.
-                  Otherwise this is required.
-              is_guest:
-                x-addedInMatrixVersion: "1.2"
-                type: boolean
-                description: |-
-                  When `true`, the user is a [Guest User](#guest-access). When
-                  not present or `false`, the user is presumed to be a non-guest
-                  user.
-        401:
-          description:
-            The token is not recognised
-          examples:
-            application/json: {
-              "errcode": "M_UNKNOWN_TOKEN",
-              "error": "Unrecognised access token."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        403:
-          description:
-            The appservice cannot masquerade as the user or has not registered them.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "Application service has not registered this user."
-            }
-          schema:
-            "$ref": "definitions/errors/error.yaml"
-        429:
-          description: This request was rate-limited.
-          schema:
-            "$ref": "definitions/errors/rate_limited.yaml"
-      tags:
-        - Session management
diff --git a/data/api/identity/definitions/request_email_validation.yaml b/data/api/identity/definitions/request_email_validation.yaml
deleted file mode 100644
index c8a3af6a..00000000
--- a/data/api/identity/definitions/request_email_validation.yaml
+++ /dev/null
@@ -1,52 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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
-example: {
-  "client_secret": "monkeys_are_GREAT",
-  "email": "foo@example.com",
-  "send_attempt": 1
-}
-properties:
-  client_secret:
-    type: string
-    description: |
-      A unique string generated by the client, and used to identify the
-      validation attempt. It must be a string consisting of the characters
-      `[0-9a-zA-Z.=_-]`. Its length must not exceed 255 characters and it
-      must not be empty.
-    example: "monkeys_are_GREAT"
-  email:
-    type: string
-    description: The email address to validate.
-    example: "alice@example.org"
-  send_attempt:
-    type: integer
-    description: |-
-      The server will only send an email if the `send_attempt`
-      is a number greater than the most recent one which it has seen,
-      scoped to that `email` + `client_secret` pair. This is to
-      avoid repeatedly sending the same email in the case of request
-      retries between the POSTing user and the identity server.
-      The client should increment this value if they desire a new
-      email (e.g. a reminder) to be sent. If they do not, the server
-      should respond with success but not resend the email.
-    example: 1
-  next_link:
-    type: string
-    description: |-
-      Optional. When the validation is completed, the identity server will
-      redirect the user to this URL. This option is ignored when submitting
-      3PID validation information through a POST request.
-    example: "https://example.org/congratulations.html"
-required: ["client_secret", "email", "send_attempt"]
diff --git a/data/api/identity/definitions/request_msisdn_validation.yaml b/data/api/identity/definitions/request_msisdn_validation.yaml
deleted file mode 100644
index 2b1c8708..00000000
--- a/data/api/identity/definitions/request_msisdn_validation.yaml
+++ /dev/null
@@ -1,58 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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
-example: {
-  "client_secret": "monkeys_are_GREAT",
-  "country": "GB",
-  "phone_number": "07700900001",
-  "send_attempt": 1
-}
-properties:
-  client_secret:
-    type: string
-    description: |
-      A unique string generated by the client, and used to identify the
-      validation attempt. It must be a string consisting of the characters
-      `[0-9a-zA-Z.=_-]`. Its length must not exceed 255 characters and it
-      must not be empty.
-    example: "monkeys_are_GREAT"
-  country:
-    type: string
-    description: |-
-      The two-letter uppercase ISO-3166-1 alpha-2 country code that the
-      number in `phone_number` should be parsed as if it were dialled from.
-    example: "GB"
-  phone_number:
-    type: string
-    description: The phone number to validate.
-    example: "07700900001"
-  send_attempt:
-    type: integer
-    description: |-
-      The server will only send an SMS if the `send_attempt` is a
-      number greater than the most recent one which it has seen,
-      scoped to that `country` + `phone_number` + `client_secret`
-      triple. This is to avoid repeatedly sending the same SMS in
-      the case of request retries between the POSTing user and the
-      identity server. The client should increment this value if
-      they desire a new SMS (e.g. a reminder) to be sent.
-    example: 1
-  next_link:
-    type: string
-    description: |-
-      Optional. When the validation is completed, the identity server will
-      redirect the user to this URL. This option is ignored when submitting
-      3PID validation information through a POST request.
-    example: "https://example.org/congratulations.html"
-required: ["client_secret", "country", "phone_number", "send_attempt"]
diff --git a/data/api/identity/definitions/security.yaml b/data/api/identity/definitions/security.yaml
deleted file mode 100644
index 64225ec4..00000000
--- a/data/api/identity/definitions/security.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-# Copyright 2019 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.
-accessToken:
-  type: apiKey
-  description: The access_token returned by a call to `/register`.
-  name: access_token
-  in: query
diff --git a/data/api/identity/definitions/sid.yaml b/data/api/identity/definitions/sid.yaml
deleted file mode 100644
index 904f79e1..00000000
--- a/data/api/identity/definitions/sid.yaml
+++ /dev/null
@@ -1,24 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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
-properties:
-  sid:
-    type: string
-    description: |
-      The session ID. Session IDs are opaque strings generated by the identity
-      server. They must consist entirely of the characters
-      `[0-9a-zA-Z.=_-]`. Their length must not exceed 255 characters and they
-      must not be empty.
-    example: "123abc"
-required: ['sid']
diff --git a/data/api/identity/v2_associations.yaml b/data/api/identity/v2_associations.yaml
deleted file mode 100644
index e08ac1da..00000000
--- a/data/api/identity/v2_associations.yaml
+++ /dev/null
@@ -1,333 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Identity Service Establishing Associations API"
-  version: "2.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/3pid/getValidated3pid":
-    get:
-      summary: Check whether ownership of a 3pid was validated.
-      description: |-
-        Determines if a given 3pid has been validated by a user.
-      operationId: getValidated3pidV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: sid
-          description: The Session ID generated by the `requestToken` call.
-          required: true
-          x-example: 1234
-        - in: query
-          type: string
-          name: client_secret
-          description: The client secret passed to the `requestToken` call.
-          required: true
-          x-example: monkeys_are_GREAT
-      responses:
-        200:
-          description: Validation information for the session.
-          examples:
-            application/json: {
-              "medium": "email",
-              "validated_at": 1457622739026,
-              "address": "louise@bobs.burgers"
-            }
-          schema:
-            type: object
-            properties:
-              medium:
-                type: string
-                description: The medium type of the 3pid.
-              address:
-                type: string
-                description: The address of the 3pid being looked up.
-              validated_at:
-                type: integer
-                description: |-
-                  Timestamp, in milliseconds, indicating the time that the 3pid
-                  was validated.
-            required: ['medium', 'address', 'validated_at']
-        400:
-          description: |-
-            The session has not been validated.
-
-            If the session has not been validated, then `errcode` will be
-            `M_SESSION_NOT_VALIDATED`.  If the session has timed out, then
-            `errcode` will be `M_SESSION_EXPIRED`.
-          examples:
-            application/json: {
-              "errcode": "M_SESSION_NOT_VALIDATED",
-              "error": "This validation session has not yet been completed"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-        404:
-          description: The Session ID or client secret were not found.
-          examples:
-            application/json: {
-              "errcode": "M_NO_VALID_SESSION",
-              "error": "No valid session was found matching that sid and client secret"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-  "/3pid/bind":
-    post:
-      summary: Publish an association between a session and a Matrix user ID.
-      description: |-
-        Publish an association between a session and a Matrix user ID.
-
-        Future calls to `/lookup` for any of the session\'s 3pids will return
-        this association.
-
-        Note: for backwards compatibility with previous drafts of this
-        specification, the parameters may also be specified as
-        `application/x-form-www-urlencoded` data.  However, this usage is
-        deprecated.
-      operationId: bindV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          schema:
-            type: object
-            example: {
-              "sid": "1234",
-              "client_secret": "monkeys_are_GREAT",
-              "mxid": "@ears:matrix.org"
-            }
-            properties:
-              sid:
-                type: string
-                description: The Session ID generated by the `requestToken` call.
-              client_secret:
-                type: string
-                description: The client secret passed to the `requestToken` call.
-              mxid:
-                type: string
-                description: The Matrix user ID to associate with the 3pids.
-            required: ["sid", "client_secret", "mxid"]
-      responses:
-        200:
-          description: The association was published.
-          examples:
-            application/json: {
-              "address": "louise@bobs.burgers",
-              "medium": "email",
-              "mxid": "@ears:matrix.org",
-              "not_before": 1428825849161,
-              "not_after": 4582425849161,
-              "ts": 1428825849161,
-              "signatures": {
-                "matrix.org": {
-                  "ed25519:0": "ENiU2YORYUJgE6WBMitU0mppbQjidDLanAusj8XS2nVRHPu+0t42OKA/r6zV6i2MzUbNQ3c3MiLScJuSsOiVDQ"
-                }
-              }
-            }
-          schema:
-            type: object
-            properties:
-              address:
-                type: string
-                description: The 3pid address of the user being looked up.
-              medium:
-                type: string
-                description: The medium type of the 3pid.
-              mxid:
-                type: string
-                description: The Matrix user ID associated with the 3pid.
-              not_before:
-                type: integer
-                description: A unix timestamp before which the association is not known to be valid.
-              not_after:
-                type: integer
-                description: A unix timestamp after which the association is not known to be valid.
-              ts:
-                type: integer
-                description: The unix timestamp at which the association was verified.
-              signatures:
-                type: object
-                description: |-
-                  The signatures of the verifying identity servers which show that the
-                  association should be trusted, if you trust the verifying identity
-                  services.
-                $ref: "../../schemas/server-signatures.yaml"
-            required:
-              - address
-              - medium
-              - mxid
-              - not_before
-              - not_after
-              - ts
-              - signatures
-        400:
-          description: |-
-            The association was not published.
-
-            If the session has not been validated, then `errcode` will be
-            `M_SESSION_NOT_VALIDATED`.  If the session has timed out, then
-            `errcode` will be `M_SESSION_EXPIRED`.
-          examples:
-            application/json: {
-              "errcode": "M_SESSION_NOT_VALIDATED",
-              "error": "This validation session has not yet been completed"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-        404:
-          description: The Session ID or client secret were not found
-          examples:
-            application/json: {
-              "errcode": "M_NO_VALID_SESSION",
-              "error": "No valid session was found matching that sid and client secret"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-  "/3pid/unbind":
-    post:
-      summary: Remove an association between a session and a Matrix user ID.
-      description: |-
-        Remove an association between a session and a Matrix user ID.
-
-        Future calls to `/lookup` for any of the session's 3pids will not
-        return the removed association.
-
-        The identity server should authenticate the request in one of two
-        ways:
-
-        1. The request is signed by the homeserver which controls the `user_id`.
-        2. The request includes the `sid` and `client_secret` parameters,
-           as per `/3pid/bind`, which proves ownership of the 3PID.
-
-        If this endpoint returns a JSON Matrix error, that error should be passed
-        through to the client requesting an unbind through a homeserver, if the
-        homeserver is acting on behalf of a client.
-      operationId: unbindV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          schema:
-            type: object
-            example: {
-              "sid": "1234",
-              "client_secret": "monkeys_are_GREAT",
-              "mxid": "@ears:example.org",
-              "threepid": {
-                "medium": "email",
-                "address": "monkeys_have_ears@example.org"
-              }
-            }
-            properties:
-              sid:
-                type: string
-                description: The Session ID generated by the `requestToken` call.
-              client_secret:
-                type: string
-                description: The client secret passed to the `requestToken` call.
-              mxid:
-                type: string
-                description: The Matrix user ID to remove from the 3pids.
-              threepid:
-                type: object
-                title: 3PID
-                description: |-
-                  The 3PID to remove. Must match the 3PID used to generate the session
-                  if using `sid` and `client_secret` to authenticate this request.
-                properties:
-                  medium:
-                    type: string
-                    description: |-
-                      A medium from the [3PID Types](/appendices/#3pid-types) Appendix, matching the medium
-                      of the identifier to unbind.
-                  address:
-                    type: string
-                    description: The 3PID address to remove.
-                required: ['medium', 'address']
-            required: ["threepid", "mxid"]
-      responses:
-        200:
-          description: The association was successfully removed.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-        400:
-          description: |-
-            If the response body is not a JSON Matrix error, the identity server
-            does not support unbinds. If a JSON Matrix error is in the response
-            body, the requesting party should respect the error.
-        404:
-          description: |-
-            If the response body is not a JSON Matrix error, the identity server
-            does not support unbinds. If a JSON Matrix error is in the response
-            body, the requesting party should respect the error.
-        403:
-          description: |-
-            The credentials supplied to authenticate the request were invalid.
-            This may also be returned if the identity server does not support
-            the chosen authentication method (such as blocking homeservers from
-            unbinding identifiers).
-
-            Another common error code is `M_TERMS_NOT_SIGNED` where the user
-            needs to [agree to more terms](/identity-service-api/#terms-of-service) in order to continue.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "Invalid homeserver signature"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-        501:
-          description: |-
-            If the response body is not a JSON Matrix error, the identity server
-            does not support unbinds. If a JSON Matrix error is in the response
-            body, the requesting party should respect the error.
diff --git a/data/api/identity/v2_auth.yaml b/data/api/identity/v2_auth.yaml
deleted file mode 100644
index b5d1a41c..00000000
--- a/data/api/identity/v2_auth.yaml
+++ /dev/null
@@ -1,131 +0,0 @@
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Identity Service Authentication API"
-  version: "2.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/account/register":
-    post:
-      summary: Exchanges an OpenID token for an access token.
-      description: |-
-        Exchanges an OpenID token from the homeserver for an access token to
-        access the identity server. The request body is the same as the values
-        returned by `/openid/request_token` in the Client-Server API.
-      operationId: registerAccount
-      parameters:
-        - in: body
-          name: body
-          schema:
-            $ref: "../client-server/definitions/openid_token.yaml"
-      responses:
-        200:
-          description: |-
-            A token which can be used to authenticate future requests to the
-            identity server.
-          examples:
-            application/json: {
-              "token": "abc123_OpaqueString"
-            }
-          schema:
-            type: object
-            properties:
-              token:
-                type: string
-                description: |-
-                  An opaque string representing the token to authenticate future
-                  requests to the identity server with.
-            required: ['token']
-  "/account":
-    get:
-      summary: Gets account holder information for a given token.
-      description: |-
-        Gets information about what user owns the access token used in the request.
-      operationId: getAccount
-      security:
-        - accessToken: []
-      parameters: []
-      responses:
-        200:
-          description: The token holder's information.
-          examples:
-            application/json: {
-              "user_id": "@alice:example.org"
-            }
-          schema:
-            type: object
-            properties:
-              user_id:
-                type: string
-                description: The user ID which registered the token.
-            required: ['user_id']
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-  "/account/logout":
-    post:
-      summary: Logs out an access token, rendering it unusable.
-      description: |-
-        Logs out the access token, preventing it from being used to authenticate
-        future requests to the server.
-      operationId: logout
-      security:
-        - accessToken: []
-      parameters: []
-      responses:
-        200:
-          description: The token was successfully logged out.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-        401:
-          description: |-
-            The token is not registered or is otherwise unknown to the server.
-          examples:
-            application/json: {
-              "errcode": "M_UNKNOWN_TOKEN",
-              "error": "Unrecognised access token"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
diff --git a/data/api/identity/v2_email_associations.yaml b/data/api/identity/v2_email_associations.yaml
deleted file mode 100644
index 600fea41..00000000
--- a/data/api/identity/v2_email_associations.yaml
+++ /dev/null
@@ -1,216 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Identity Service Email Associations API"
-  version: "2.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/validate/email/requestToken":
-    post:
-      summary: Request a token for validating an email address.
-      description: |-
-        Create a session for validating an email address.
-
-        The identity server will send an email containing a token. If that
-        token is presented to the identity server in the future, it indicates
-        that that user was able to read the email for that email address, and
-        so we validate ownership of the email address.
-
-        Note that homeservers offer APIs that proxy this API, adding
-        additional behaviour on top, for example,
-        `/register/email/requestToken` is designed specifically for use when
-        registering an account and therefore will inform the user if the email
-        address given is already registered on the server.
-
-        Note: for backwards compatibility with previous drafts of this
-        specification, the parameters may also be specified as
-        `application/x-form-www-urlencoded` data.  However, this usage is
-        deprecated.
-      operationId: emailRequestTokenV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          schema:
-            $ref: "definitions/request_email_validation.yaml"
-      responses:
-        200:
-          description: Session created.
-          schema:
-            $ref: "definitions/sid.yaml"
-        400:
-          description: |
-            An error occurred.  Some possible errors are:
-
-            - `M_INVALID_EMAIL`: The email address provided was invalid.
-            - `M_EMAIL_SEND_ERROR`: The validation email could not be sent.
-          examples:
-            application/json: {
-              "errcode": "M_INVALID_EMAIL",
-              "error": "The email address is not valid"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-  "/validate/email/submitToken":
-    post:
-      summary: Validate ownership of an email address.
-      description: |-
-        Validate ownership of an email address.
-
-        If the three parameters are consistent with a set generated by a
-        `requestToken` call, ownership of the email address is considered to
-        have been validated. This does not publish any information publicly, or
-        associate the email address with any Matrix user ID. Specifically,
-        calls to `/lookup` will not show a binding.
-
-        The identity server is free to match the token case-insensitively, or
-        carry out other mapping operations such as unicode
-        normalisation. Whether to do so is an implementation detail for the
-        identity server. Clients must always pass on the token without
-        modification.
-
-        Note: for backwards compatibility with previous drafts of this
-        specification, the parameters may also be specified as
-        `application/x-form-www-urlencoded` data.  However, this usage is
-        deprecated.
-      operationId: emailSubmitTokenPostV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          schema:
-            type: object
-            example: {
-              "sid": "1234",
-              "client_secret": "monkeys_are_GREAT",
-              "token": "atoken"
-            }
-            properties:
-              sid:
-                type: string
-                description: The session ID, generated by the `requestToken` call.
-              client_secret:
-                type: string
-                description: The client secret that was supplied to the `requestToken` call.
-              token:
-                type: string
-                description: The token generated by the `requestToken` call and emailed to the user.
-            required: ["sid", "client_secret", "token"]
-      responses:
-        200:
-          description:
-            The success of the validation.
-          examples:
-            application/json: {
-              "success": true
-            }
-          schema:
-            type: object
-            properties:
-              success:
-                type: boolean
-                description: Whether the validation was successful or not.
-            required: ['success']
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-    get:
-      summary: Validate ownership of an email address.
-      description: |-
-        Validate ownership of an email address.
-
-        If the three parameters are consistent with a set generated by a
-        `requestToken` call, ownership of the email address is considered to
-        have been validated. This does not publish any information publicly, or
-        associate the email address with any Matrix user ID. Specifically,
-        calls to `/lookup` will not show a binding.
-
-        Note that, in contrast with the POST version, this endpoint will be
-        used by end-users, and so the response should be human-readable.
-      operationId: emailSubmitTokenGetV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: sid
-          required: true
-          description: The session ID, generated by the `requestToken` call.
-          x-example: 1234
-        - in: query
-          type: string
-          name: client_secret
-          required: true
-          description: The client secret that was supplied to the `requestToken` call.
-          x-example: monkeys_are_GREAT
-        - in: query
-          type: string
-          name: token
-          required: true
-          description: The token generated by the `requestToken` call and emailed to the user.
-          x-example: atoken
-      responses:
-        200:
-          description: Email address is validated.
-        "3xx":
-          description: |-
-            Email address is validated, and the `next_link` parameter was
-            provided to the `requestToken` call.  The user must be redirected
-            to the URL provided by the `next_link` parameter.
-        "4xx":
-          description:
-            Validation failed.
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
diff --git a/data/api/identity/v2_invitation_signing.yaml b/data/api/identity/v2_invitation_signing.yaml
deleted file mode 100644
index d81b973d..00000000
--- a/data/api/identity/v2_invitation_signing.yaml
+++ /dev/null
@@ -1,112 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Identity Service Ephemeral Invitation Signing API"
-  version: "2.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/sign-ed25519":
-    post:
-      summary: Sign invitation details
-      description: |-
-        Sign invitation details.
-
-        The identity server will look up `token` which was stored in a call
-        to `store-invite`, and fetch the sender of the invite.
-      operationId: blindlySignStuffV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          schema:
-            type: object
-            example: {
-              "mxid": "@foo:bar.com",
-              "token": "sometoken",
-              "private_key": "base64encodedkey"
-            }
-            properties:
-              mxid:
-                type: string
-                description: The Matrix user ID of the user accepting the invitation.
-              token:
-                type: string
-                description: The token from the call to `store-invite`.
-              private_key:
-                type: string
-                description: The private key, encoded as [Unpadded base64](/appendices/#unpadded-base64).
-            required: ["mxid", "token", "private_key"]
-      responses:
-        200:
-          description: The signed JSON of the mxid, sender, and token.
-          schema:
-            type: object
-            properties:
-              mxid:
-                type: string
-                description: The Matrix user ID of the user accepting the invitation.
-              sender:
-                type: string
-                description: The Matrix user ID of the user who sent the invitation.
-              signatures:
-                type: object
-                description: The signature of the mxid, sender, and token.
-                $ref: "../../schemas/server-signatures.yaml"
-              token:
-                type: string
-                description: The token for the invitation.
-            required: ['mxid', 'sender', 'signatures', 'token']
-          examples:
-            application/json: {
-              "mxid": "@foo:bar.com",
-              "sender": "@baz:bar.com",
-              "signatures": {
-                "my.id.server": {
-                  "ed25519:0": "def987"
-                }
-              },
-              "token": "abc123"
-            }
-        404:
-          description: The token was not found.
-          examples:
-            application/json: {
-              "errcode": "M_UNRECOGNIZED",
-              "error": "Didn't recognize token"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
diff --git a/data/api/identity/v2_lookup.yaml b/data/api/identity/v2_lookup.yaml
deleted file mode 100644
index 66ac1a0a..00000000
--- a/data/api/identity/v2_lookup.yaml
+++ /dev/null
@@ -1,152 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2017 Kamax.io
-# Copyright 2017 New Vector Ltd
-# Copyright 2018 New Vector Ltd
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Identity Service Lookup API"
-  version: "2.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/hash_details":
-    get:
-      summary: Gets hash function information from the server.
-      description: |-
-        Gets parameters for hashing identifiers from the server. This can include
-        any of the algorithms defined in this specification.
-      operationId: getHashDetails
-      security:
-        - accessToken: []
-      parameters: []
-      responses:
-        200:
-          description: The hash function information.
-          examples:
-            application/json: {
-              "lookup_pepper": "matrixrocks",
-              "algorithms": ["none", "sha256"]
-            }
-          schema:
-            type: object
-            properties:
-              lookup_pepper:
-                type: string
-                description: |-
-                  The pepper the client MUST use in hashing identifiers, and MUST
-                  supply to the `/lookup` endpoint when performing lookups.
-
-                  Servers SHOULD rotate this string often.
-              algorithms:
-                type: array
-                items:
-                  type: string
-                description: |-
-                  The algorithms the server supports. Must contain at least `sha256`.
-            required: ['lookup_pepper', 'algorithms']
-  "/lookup":
-    post:
-      summary: Look up Matrix User IDs for a set of 3PIDs.
-      description: |-
-        Looks up the set of Matrix User IDs which have bound the 3PIDs given, if
-        bindings are available. Note that the format of the addresses is defined
-        later in this specification.
-      operationId: lookupUsersV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          schema:
-            type: object
-            properties:
-              algorithm:
-                type: string
-                description: |-
-                  The algorithm the client is using to encode the `addresses`. This
-                  should be one of the available options from `/hash_details`.
-                example: "sha256"
-              pepper:
-                type: string
-                description: |-
-                  The pepper from `/hash_details`. This is required even when the
-                  `algorithm` does not make use of it.
-                example: "matrixrocks"
-              addresses:
-                type: array
-                items:
-                  type: string
-                description: |-
-                  The addresses to look up. The format of the entries here depend on
-                  the `algorithm` used. Note that queries which have been incorrectly
-                  hashed or formatted will lead to no matches.
-
-                  Note that addresses are case sensitive: review the
-                  [3PID Types](/appendices#pid-types) to verify the intended case an
-                  identifier should be prior to submission/hashing.
-                example: [
-                  "4kenr7N9drpCJ4AfalmlGQVsOn3o2RHjkADUpXJWZUc",
-                  "nlo35_T5fzSGZzJApqu8lgIudJvmOQtDaHtr-I4rU7I"
-                ]
-            required: ['algorithm', 'pepper', 'addresses']
-      responses:
-        200:
-          description:
-            The associations for any matched `addresses`.
-          examples:
-            application/json: {
-              "mappings": {
-                "4kenr7N9drpCJ4AfalmlGQVsOn3o2RHjkADUpXJWZUc": "@alice:example.org"
-              }
-            }
-          schema:
-            type: object
-            properties:
-              mappings:
-                type: object
-                description: |-
-                  Any applicable mappings of `addresses` to Matrix User IDs. Addresses
-                  which do not have associations will not be included, which can make
-                  this property be an empty object.
-                title: AssociatedMappings
-                additionalProperties:
-                  type: string
-            required: ['mappings']
-        400:
-          description:
-            The client's request was invalid in some way. One possible problem could
-            be the `pepper` being invalid after the server has rotated it - this is
-            presented with the `M_INVALID_PEPPER` error code. Clients SHOULD make
-            a call to `/hash_details` to get a new pepper in this scenario, being
-            careful to avoid retry loops.
-
-            `M_INVALID_PARAM` can also be returned to indicate the client supplied
-            an `algorithm` that is unknown to the server.
-          examples:
-            application/json: {
-              "errcode": "M_INVALID_PEPPER",
-              "error": "Unknown or invalid pepper - has it been rotated?"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
diff --git a/data/api/identity/v2_phone_associations.yaml b/data/api/identity/v2_phone_associations.yaml
deleted file mode 100644
index 85b523e4..00000000
--- a/data/api/identity/v2_phone_associations.yaml
+++ /dev/null
@@ -1,218 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Identity Service Phone Number Associations API"
-  version: "2.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/validate/msisdn/requestToken":
-    post:
-      summary: Request a token for validating a phone number.
-      description: |-
-        Create a session for validating a phone number.
-
-        The identity server will send an SMS message containing a token. If
-        that token is presented to the identity server in the future, it
-        indicates that that user was able to read the SMS for that phone
-        number, and so we validate ownership of the phone number.
-
-        Note that homeservers offer APIs that proxy this API, adding
-        additional behaviour on top, for example,
-        `/register/msisdn/requestToken` is designed specifically for use when
-        registering an account and therefore will inform the user if the phone
-        number given is already registered on the server.
-
-        Note: for backwards compatibility with previous drafts of this
-        specification, the parameters may also be specified as
-        `application/x-form-www-urlencoded` data. However, this usage is
-        deprecated.
-      operationId: msisdnRequestTokenV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          schema:
-            $ref: "definitions/request_msisdn_validation.yaml"
-      responses:
-        200:
-          description: Session created.
-          schema:
-            $ref: "definitions/sid.yaml"
-        400:
-          description: |
-            An error occurred. Some possible errors are:
-
-            - `M_INVALID_ADDRESS`: The phone number provided was invalid.
-            - `M_SEND_ERROR`: The validation SMS could not be sent.
-            - `M_DESTINATION_REJECTED`: The identity server cannot deliver an
-              SMS to the provided country or region.
-          examples:
-            application/json: {
-              "errcode": "M_INVALID_ADDRESS",
-              "error": "The phone number is not valid"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-  "/validate/msisdn/submitToken":
-    post:
-      summary: Validate ownership of a phone number.
-      description: |-
-        Validate ownership of a phone number.
-
-        If the three parameters are consistent with a set generated by a
-        `requestToken` call, ownership of the phone number is considered to
-        have been validated. This does not publish any information publicly, or
-        associate the phone number address with any Matrix user
-        ID. Specifically, calls to `/lookup` will not show a binding.
-
-        The identity server is free to match the token case-insensitively, or
-        carry out other mapping operations such as unicode
-        normalisation. Whether to do so is an implementation detail for the
-        identity server. Clients must always pass on the token without
-        modification.
-
-        Note: for backwards compatibility with previous drafts of this
-        specification, the parameters may also be specified as
-        `application/x-form-www-urlencoded` data. However, this usage is
-        deprecated.
-      operationId: msisdnSubmitTokenPostV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          schema:
-            type: object
-            example: {
-              "sid": "1234",
-              "client_secret": "monkeys_are_GREAT",
-              "token": "atoken"
-            }
-            properties:
-              sid:
-                type: string
-                description: The session ID, generated by the `requestToken` call.
-              client_secret:
-                type: string
-                description: The client secret that was supplied to the `requestToken` call.
-              token:
-                type: string
-                description: The token generated by the `requestToken` call and sent to the user.
-            required: ["sid", "client_secret", "token"]
-      responses:
-        200:
-          description:
-            The success of the validation.
-          examples:
-            application/json: {
-              "success": true
-            }
-          schema:
-            type: object
-            properties:
-              success:
-                type: boolean
-                description: Whether the validation was successful or not.
-            required: ['success']
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-    get:
-      summary: Validate ownership of a phone number.
-      description: |-
-        Validate ownership of a phone number.
-
-        If the three parameters are consistent with a set generated by a
-        `requestToken` call, ownership of the phone number address is
-        considered to have been validated. This does not publish any
-        information publicly, or associate the phone number with any Matrix
-        user ID. Specifically, calls to `/lookup` will not show a binding.
-
-        Note that, in contrast with the POST version, this endpoint will be
-        used by end-users, and so the response should be human-readable.
-      operationId: msisdnSubmitTokenGetV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: query
-          type: string
-          name: sid
-          required: true
-          description: The session ID, generated by the `requestToken` call.
-          x-example: 1234
-        - in: query
-          type: string
-          name: client_secret
-          required: true
-          description: The client secret that was supplied to the `requestToken` call.
-          x-example: monkeys_are_GREAT
-        - in: query
-          type: string
-          name: token
-          required: true
-          description: The token generated by the `requestToken` call and sent to the user.
-          x-example: atoken
-      responses:
-        200:
-          description: Phone number is validated.
-        "3xx":
-          description: |-
-            Phone number address is validated, and the `next_link` parameter
-            was provided to the `requestToken` call. The user must be
-            redirected to the URL provided by the `next_link` parameter.
-        "4xx":
-          description:
-            Validation failed.
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
diff --git a/data/api/identity/v2_ping.yaml b/data/api/identity/v2_ping.yaml
deleted file mode 100644
index e056e321..00000000
--- a/data/api/identity/v2_ping.yaml
+++ /dev/null
@@ -1,46 +0,0 @@
-# Copyright 2018 Kamax Sàrl
-# Copyright 2018 New Vector Ltd
-# Copyright 2019 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.
-
-swagger: "2.0"
-info:
-  title: "Matrix Identity Service Ping API"
-  version: "2.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity
-produces:
-  - application/json
-paths:
-  "/v2":
-    get:
-      summary: Checks that an identity server is available at this API endpoint.
-      description: |-
-        Checks that an identity server is available at this API endpoint.
-
-        To discover that an identity server is available at a specific URL,
-        this endpoint can be queried and will return an empty object.
-
-        This is primarily used for auto-discovery and health check purposes
-        by entities acting as a client for the identity server.
-      operationId: pingV2
-      responses:
-        200:
-          description: An identity server is ready to serve requests.
-          examples:
-            application/json: {}
-          schema:
-            type: object
diff --git a/data/api/identity/v2_pubkey.yaml b/data/api/identity/v2_pubkey.yaml
deleted file mode 100644
index 68facd68..00000000
--- a/data/api/identity/v2_pubkey.yaml
+++ /dev/null
@@ -1,127 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Identity Service Public Key API"
-  version: "2.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-paths:
-  "/pubkey/{keyId}":
-    get:
-      summary: Get a public key.
-      description: |-
-        Get the public key for the passed key ID.
-      operationId: getPubKeyV2
-      parameters:
-        - in: path
-          type: string
-          name: keyId
-          required: true
-          description: |-
-            The ID of the key. This should take the form algorithm:identifier
-            where algorithm identifies the signing algorithm, and the identifier
-            is an opaque string.
-          x-example: "ed25519:0"
-      responses:
-        200:
-          description:
-            The public key exists.
-          examples:
-            application/json: {
-              "public_key": "VXuGitF39UH5iRfvbIknlvlAVKgD1BsLDMvBf0pmp7c"
-            }
-          schema:
-            type: object
-            properties:
-              public_key:
-                type: string
-                description: Unpadded Base64 encoded public key.
-            required: ['public_key']
-        404:
-          description:
-            The public key was not found.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "The public key was not found"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-  "/pubkey/isvalid":
-    get:
-      summary: Check whether a long-term public key is valid.
-      description: |-
-        Check whether a long-term public key is valid. The response should always
-        be the same, provided the key exists.
-      operationId: isPubKeyValidV2
-      parameters:
-        - in: query
-          type: string
-          name: public_key
-          required: true
-          description: |-
-            The unpadded base64-encoded public key to check.
-          x-example: "VXuGitF39UH5iRfvbIknlvlAVKgD1BsLDMvBf0pmp7c"
-      responses:
-        200:
-          description:
-            The validity of the public key.
-          examples:
-            application/json: {
-              "valid": true
-            }
-          schema:
-            type: object
-            properties:
-              valid:
-                type: boolean
-                description: Whether the public key is recognised and is currently valid.
-            required: ['valid']
-  "/pubkey/ephemeral/isvalid":
-    get:
-      summary: Check whether a short-term public key is valid.
-      description: |-
-        Check whether a short-term public key is valid.
-      operationId: isEphemeralPubKeyValidV2
-      parameters:
-        - in: query
-          type: string
-          name: public_key
-          required: true
-          description: |-
-            The unpadded base64-encoded public key to check.
-          x-example: "VXuGitF39UH5iRfvbIknlvlAVKgD1BsLDMvBf0pmp7c"
-      responses:
-        200:
-          description:
-            The validity of the public key.
-          examples:
-            application/json: {
-              "valid": true
-            }
-          schema:
-            type: object
-            properties:
-              valid:
-                type: boolean
-                description: Whether the public key is recognised and is currently valid.
-            required: ['valid']
diff --git a/data/api/identity/v2_store_invite.yaml b/data/api/identity/v2_store_invite.yaml
deleted file mode 100644
index 86845eff..00000000
--- a/data/api/identity/v2_store_invite.yaml
+++ /dev/null
@@ -1,184 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Identity Service Store Invitations API"
-  version: "2.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/store-invite":
-    post:
-      summary: Store pending invitations to a user's 3pid.
-      description: |-
-        Store pending invitations to a user's 3pid.
-
-        In addition to the request parameters specified below, an arbitrary
-        number of other parameters may also be specified. These may be used in
-        the invite message generation described below.
-
-        The service will generate a random token and an ephemeral key used for
-        accepting the invite.
-
-        The service also generates a `display_name` for the inviter, which is
-        a redacted version of `address` which does not leak the full contents
-        of the `address`.
-
-        The service records persistently all of the above information.
-
-        It also generates an email containing all of this data, sent to the
-        `address` parameter, notifying them of the invitation. The email should
-        reference the `inviter_name`, `room_name`, `room_avatar`, and `room_type`
-        (if present) from the request here.
-
-        Also, the generated ephemeral public key will be listed as valid on
-        requests to `/_matrix/identity/v2/pubkey/ephemeral/isvalid`.
-
-        Currently, invites may only be issued for 3pids of the `email` medium.
-
-        Optional fields in the request should be populated to the best of the
-        server's ability. Identity servers may use these variables when notifying
-        the `address` of the pending invite for display purposes.
-      operationId: storeInviteV2
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          schema:
-            type: object
-            properties:
-              medium:
-                type: string
-                description: The literal string `email`.
-                example: "email"
-              address:
-                type: string
-                description: The email address of the invited user.
-                example: "foo@example.com"
-              room_id:
-                type: string
-                description: The Matrix room ID to which the user is invited
-                example: "!something:example.org"
-              sender:
-                type: string
-                description: The Matrix user ID of the inviting user
-                example: "@bob:example.com"
-              room_alias:
-                type: string
-                description: |-
-                  The Matrix room alias for the room to which the user is
-                  invited. This should be retrieved from the `m.room.canonical_alias`
-                  state event.
-                example: "#somewhere:example.org"
-              room_avatar_url:
-                type: string
-                description: |-
-                  The Content URI for the room to which the user is invited. This should
-                  be retrieved from the `m.room.avatar` state event.
-                example: "mxc://example.org/s0meM3dia"
-              room_join_rules:
-                type: string
-                description: |-
-                  The `join_rule` for the room to which the user is invited. This should
-                  be retrieved from the `m.room.join_rules` state event.
-                example: "public"
-              room_name:
-                type: string
-                description: |-
-                  The name of the room to which the user is invited. This should be retrieved
-                  from the `m.room.name` state event.
-                example: "Bob's Emporium of Messages"
-              sender_display_name:
-                type: string
-                description: The display name of the user ID initiating the invite.
-                example: "Bob Smith"
-              sender_avatar_url:
-                type: string
-                description: The Content URI for the avatar of the user ID initiating the invite.
-                example: "mxc://example.org/an0th3rM3dia"
-              room_type:
-                type: string
-                description: |-
-                  The `type` from the `m.room.create` event's `content`. If the create event doesn't
-                  have a specified `type`, this field is not included.
-                example: "m.space"
-            required: ["medium", "address", "room_id", "sender"]
-      responses:
-        200:
-          description: The invitation was stored.
-          schema:
-            type: object
-            properties:
-              token:
-                type: string
-                description: |
-                  The generated token. Must be a string consisting of the
-                  characters `[0-9a-zA-Z.=_-]`. Its length must not exceed
-                  255 characters and it must not be empty.
-              public_keys:
-                type: array
-                description: |
-                  A list of [server's long-term public key, generated ephemeral
-                  public key].
-                items:
-                  type: string
-              display_name:
-                type: string
-                description: The generated (redacted) display_name.
-            required: ['token', 'public_keys', 'display_name']
-            example:
-              application/json: {
-                "token": "sometoken",
-                "public_keys": [
-                  "serverpublickey",
-                  "ephemeralpublickey"
-                ],
-                "display_name": "f...@b..."
-              }
-        400:
-          description: |
-            An error has occurred.
-
-            If the 3pid is already bound to a Matrix user ID, the error code
-            will be `M_THREEPID_IN_USE`.  If the medium is unsupported, the
-            error code will be `M_UNRECOGNIZED`.
-          examples:
-            application/json: {
-              "errcode": "M_THREEPID_IN_USE",
-              "error": "Binding already known",
-              "mxid": "@alice:example.com"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-        403:
-          description: |
-            The user must do something in order to use this endpoint. One example
-            is an `M_TERMS_NOT_SIGNED` error where the user must [agree to more terms](/identity-service-api/#terms-of-service).
-          examples:
-            application/json: {
-              "errcode": "M_TERMS_NOT_SIGNED",
-              "error": "Please accept our updated terms of service before continuing"
-            }
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
diff --git a/data/api/identity/v2_terms.yaml b/data/api/identity/v2_terms.yaml
deleted file mode 100644
index fcab28b7..00000000
--- a/data/api/identity/v2_terms.yaml
+++ /dev/null
@@ -1,149 +0,0 @@
-# Copyright 2019 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.
-swagger: '2.0'
-info:
-  title: "Matrix Identity Service Terms of Service API"
-  version: "2.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/terms":
-    get:
-      summary: Gets the terms of service offered by the server.
-      description: |-
-        Gets all the terms of service offered by the server. The client is expected
-        to filter through the terms to determine which terms need acceptance from the
-        user. Note that this endpoint does not require authentication.
-      operationId: getTerms
-      parameters: []
-      responses:
-        200:
-          description: |-
-            The terms of service offered by the server.
-          examples:
-            application/json: {
-              "policies": {
-                "terms_of_service": {
-                  "version": "2.0",
-                  "en": {
-                    "name": "Terms of Service",
-                    "url": "https://example.org/somewhere/terms-2.0-en.html"
-                  },
-                  "fr": {
-                    "name": "Conditions d'utilisation",
-                    "url": "https://example.org/somewhere/terms-2.0-fr.html"
-                  }
-                },
-                "privacy_policy": {
-                  "version": "1.2",
-                  "en": {
-                    "name": "Privacy Policy",
-                    "url": "https://example.org/somewhere/privacy-1.2-en.html"
-                  },
-                  "fr": {
-                    "name": "Politique de confidentialité",
-                    "url": "https://example.org/somewhere/privacy-1.2-fr.html"
-                  }
-                }
-              }
-            }
-          schema:
-            type: object
-            properties:
-              policies:
-                type: object
-                title: Policy Map
-                description: |-
-                  The policies the server offers. Mapped from arbitrary ID (unused in
-                  this version of the specification) to a Policy Object.
-                additionalProperties:
-                  type: object
-                  title: Policy Object
-                  description: |-
-                    The policy. Includes a map of language (ISO 639-2) to language-specific
-                    policy information.
-                  properties:
-                    version:
-                      type: string
-                      description: |-
-                        The version for the policy. There are no requirements on what this
-                        might be and could be "alpha", semantically versioned, or arbitrary.
-                  required: ['version']
-                  # TODO: TravisR - Make this render
-                  additionalProperties:
-                    type: object
-                    title: Internationalised Policy
-                    description: |-
-                      The policy information for the specified language.
-                    properties:
-                      name:
-                        type: string
-                        description: The translated name of the policy.
-                      url:
-                        type: string
-                        description: |-
-                          The URL, which should include the policy ID, version, and language
-                          in it, to be presented to the user as the policy. URLs should have
-                          all three criteria to avoid conflicts when the policy is updated
-                          in the future: for example, if this was "https://example.org/terms.html"
-                          then the server would be unable to update it because the client would
-                          have already added that URL to the `m.accepted_terms` collection.
-                    required: ['name', 'url']
-            required: ['policies']
-    post:
-      summary: Indicates acceptance of terms to the server.
-      description: |-
-        Called by a client to indicate that the user has accepted/agreed to the included
-        set of URLs. Servers MUST NOT assume that the client will be sending all previously
-        accepted URLs and should therefore append the provided URLs to what the server
-        already knows has been accepted.
-
-        Clients MUST provide the URL of the policy in the language that was presented
-        to the user. Servers SHOULD consider acceptance of any one language's URL as
-        acceptance for all other languages of that policy.
-
-        The server should avoid returning `M_TERMS_NOT_SIGNED` because the client
-        may not be accepting all terms at once.
-      operationId: agreeToTerms
-      security:
-        - accessToken: []
-      parameters:
-        - in: body
-          name: body
-          schema:
-            type: object
-            properties:
-              user_accepts:
-                type: array
-                items:
-                  type: string
-                description: The URLs the user is accepting in this request.
-                example: "https://example.org/somewhere/terms-2.0-en.html"
-            required: ['user_accepts']
-      responses:
-        200:
-          description: |-
-            The server has considered the user as having accepted the provided URLs.
-          examples:
-            application/json: {}
-          schema:
-            type: object
diff --git a/data/api/identity/versions.yaml b/data/api/identity/versions.yaml
deleted file mode 100644
index ff821e22..00000000
--- a/data/api/identity/versions.yaml
+++ /dev/null
@@ -1,54 +0,0 @@
-# Copyright 2021 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.
-swagger: '2.0'
-info:
-  title: "Matrix Identity Service Versions API"
-  version: "1.0.0"
-host: localhost:8090
-schemes:
-  - https
-basePath: /_matrix/identity
-produces:
-  - application/json
-paths:
-  "/versions":
-    get:
-      x-addedInMatrixVersion: "1.1"
-      summary: Gets the versions of the specification supported by the server.
-      description: |-
-        Gets the versions of the specification supported by the server.
-
-        Values will take the form `vX.Y` or `rX.Y.Z` in historical cases. See
-        [the Specification Versioning](../#specification-versions) for more
-        information.
-
-        All supported versions, including patch versions, are reported by the server.
-      operationId: getVersions
-      responses:
-        200:
-          description: The versions supported by the server.
-          examples:
-            application/json: {
-              "versions": ["r0.2.0", "r0.2.1", "v1.1"]
-            }
-          schema:
-            type: object
-            properties:
-              versions:
-                type: array
-                description: The supported versions.
-                items:
-                  type: string
-                  description: The supported versions.
-            required: ['versions']
diff --git a/data/api/push-gateway/push_notifier.yaml b/data/api/push-gateway/push_notifier.yaml
deleted file mode 100644
index 2f03433b..00000000
--- a/data/api/push-gateway/push_notifier.yaml
+++ /dev/null
@@ -1,228 +0,0 @@
-# Copyright 2016 OpenMarket Ltd
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Push Notification API"
-  version: "1.0.0"
-host: localhost:8008
-schemes:
-  - https
-  - http
-basePath: /_matrix/push/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-paths:
-  "/notify":
-    post:
-      summary: Notify a push gateway about an event.
-      description: |-
-        This endpoint is invoked by HTTP pushers to notify a push gateway about
-        an event or update the number of unread notifications a user has.
-        In the former case it will contain selected information about the event.
-        In either case it may contain numeric counts of the number of unread
-        events of different types the user has. The counts may be sent along
-        with a notification about an event or by themselves.
-
-        Notifications about a particular event will normally cause the user to be
-        alerted in some way. It is therefore necessary to perform duplicate
-        suppression for such notifications using the `event_id` field to avoid
-        retries of this HTTP API causing duplicate alerts. The operation of
-        updating counts of unread notifications should be idempotent and
-        therefore do not require duplicate suppression.
-
-        Notifications are sent to the URL configured when the pusher is created.
-        This means that the HTTP path may be different depending on the push
-        gateway.
-      operationId: notify
-      parameters:
-        - in: body
-          name: notification
-          description: Information about the push notification.
-          required: true
-          schema:
-            type: object
-            example: {
-              "notification": {
-                "event_id": "$3957tyerfgewrf384",
-                "room_id": "!slw48wfj34rtnrf:example.com",
-                "type": "m.room.message",
-                "sender": "@exampleuser:matrix.org",
-                "sender_display_name": "Major Tom",
-                "room_name": "Mission Control",
-                "room_alias": "#exampleroom:matrix.org",
-                "prio": "high",
-                "content": {
-                  "msgtype": "m.text",
-                  "body": "I'm floating in a most peculiar way."
-                },
-                "counts": {
-                  "unread" : 2,
-                  "missed_calls": 1
-                },
-                "devices": [
-                  {
-                    "app_id": "org.matrix.matrixConsole.ios",
-                    "pushkey": "V2h5IG9uIGVhcnRoIGRpZCB5b3UgZGVjb2RlIHRoaXM/",
-                    "pushkey_ts": 12345678,
-                    "data" : {},
-                    "tweaks": {
-                      "sound": "bing"
-                    }
-                  }
-                ]
-              }
-            }
-            required: ["notification"]
-            properties:
-              notification:
-                type: object
-                title: Notification
-                description: Information about the push notification
-                required: ["devices"]
-                properties:
-                  event_id:
-                    type: string
-                    description: |-
-                      The Matrix event ID of the event being notified about.
-                      This is required if the notification is about a
-                      particular Matrix event. It may be omitted for notifications
-                      that only contain updated badge counts. This ID can and
-                      should be used to detect duplicate notification requests.
-                  room_id:
-                    type: string
-                    description: |-
-                      The ID of the room in which this event occurred.
-                      Required if the notification relates to a specific
-                      Matrix event.
-                  type:
-                    type: string
-                    description: |-
-                      The type of the event as in the event's `type` field.
-                  sender:
-                    type: string
-                    description: |-
-                      The sender of the event as in the corresponding event field.
-                  sender_display_name:
-                    type: string
-                    description: |-
-                      The current display name of the sender in the room in which
-                      the event occurred.
-                  room_name:
-                    type: string
-                    description: The name of the room in which the event occurred.
-                  room_alias:
-                    type: string
-                    description: An alias to display for the room in which the event occurred.
-                  user_is_target:
-                    type: boolean
-                    description: |-
-                      This is true if the user receiving the notification is the
-                      subject of a member event (i.e. the `state_key` of the
-                      member event is equal to the user's Matrix ID).
-                  prio:
-                    type: string
-                    enum: ["high", "low"]
-                    description: |-
-                      The priority of the notification. If omitted, `high` is
-                      assumed. This may be used by push gateways to deliver less
-                      time-sensitive notifications in a way that will preserve
-                      battery power on mobile devices.
-                  content:
-                    type: object
-                    title: EventContent
-                    description: |-
-                      The `content` field from the event, if present. The pusher
-                      may omit this if the event had no content or for any other
-                      reason.
-                  counts:
-                    type: object
-                    title: Counts
-                    description: |-
-                      This is a dictionary of the current number of unacknowledged
-                      communications for the recipient user. Counts whose value is
-                      zero should be omitted.
-                    properties:
-                      unread:
-                        type: integer
-                        description: |-
-                          The number of unread messages a user has across all of the
-                          rooms they are a member of.
-                      missed_calls:
-                        type: integer
-                        description: |-
-                          The number of unacknowledged missed calls a user has
-                          across all rooms of which they are a member.
-                  devices:
-                    type: array
-                    title: Devices
-                    description: |-
-                      This is an array of devices that the notification should be sent to.
-                    items:
-                      type: object
-                      title: Device
-                      properties:
-                        app_id:
-                          type: string
-                          description: |-
-                            The `app_id` given when the pusher was created.
-                        pushkey:
-                          type: string
-                          description: The `pushkey` given when the pusher was created.
-                        pushkey_ts:
-                          type: integer
-                          description: |-
-                            The unix timestamp (in seconds) when the
-                            pushkey was last updated.
-                        data:
-                          type: object
-                          title: PusherData
-                          description: |-
-                            A dictionary of additional pusher-specific data. For
-                            'http' pushers, this is the data dictionary passed in at
-                            pusher creation minus the `url` key.
-                        tweaks:
-                          type: object
-                          title: Tweaks
-                          description: |-
-                            A dictionary of customisations made to the way this
-                            notification is to be presented. These are added by push rules.
-                      required: ['app_id', 'pushkey']
-      responses:
-        200:
-          description: A list of rejected push keys.
-          examples:
-            application/json: {
-              "rejected": [ "V2h5IG9uIGVhcnRoIGRpZCB5b3UgZGVjb2RlIHRoaXM/" ]
-            }
-          schema:
-            type: object  # empty json object
-            properties:
-              rejected:
-                type: array
-                description: |-
-                  A list of all pushkeys given in the notification request that
-                  are not valid. These could have been rejected by an upstream
-                  gateway because they have expired or have never been valid.
-                  Homeservers must cease sending notification requests for these
-                  pushkeys and remove the associated pushers. It may not
-                  necessarily be the notification in the request that failed:
-                  it could be that a previous notification to the same pushkey
-                  failed. May be empty.
-                items:
-                  type: string
-                  description: A pushkey that has been rejected.
-            required: ['rejected']
diff --git a/data/api/server-server/backfill.yaml b/data/api/server-server/backfill.yaml
deleted file mode 100644
index 6adeb26c..00000000
--- a/data/api/server-server/backfill.yaml
+++ /dev/null
@@ -1,143 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Events API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/backfill/{roomId}":
-    get:
-      summary: Retrieves the events which precede the given event
-      description: |-
-        Retrieves a sliding-window history of previous PDUs that occurred in the given room.
-        Starting from the PDU ID(s) given in the `v` argument, the PDUs given in `v` and
-        the PDUs that preceded them are retrieved, up to the total number given by the `limit`.
-      operationId: backfillRoom
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID to backfill.
-          required: true
-          x-example: "!SomeRoom:matrix.org"
-        - in: query
-          name: v
-          type: array
-          items:
-            type: string
-          description: The event IDs to backfill from.
-          required: true
-          x-example: ["$abc123:matrix.org"]
-        - in: query
-          name: limit
-          type: integer
-          description: The maximum number of PDUs to retrieve, including the given events.
-          required: true
-          x-example: 2
-      responses:
-        200:
-          description: |-
-            A transaction containing the PDUs that preceded the given event(s), including the given
-            event(s), up to the given limit.
-
-            **Note:**
-            Though the PDU definitions require that `prev_events` and `auth_events` be limited
-            in number, the response of backfill MUST NOT be validated on these specific restrictions.
-
-            Due to historical reasons, it is possible that events which were previously accepted
-            would now be rejected by these limitations. The events should be rejected per usual by
-            the `/send`, `/get_missing_events`, and remaining endpoints.
-          schema:
-            $ref: "definitions/unlimited_pdu_transaction.yaml"
-  "/get_missing_events/{roomId}":
-    post:
-      summary: Retrieves events that the sender is missing
-      description: |-
-        Retrieves previous events that the sender is missing. This is done by doing a breadth-first
-        walk of the `prev_events` for the `latest_events`, ignoring any events in `earliest_events`
-        and stopping at the `limit`.
-      operationId: getMissingPreviousEvents
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID to search in.
-          required: true
-          x-example: "!SomeRoom:matrix.org"
-        - in: body
-          name: body
-          schema:
-            type: object
-            properties:
-              limit:
-                type: integer
-                description: The maximum number of events to retrieve. Defaults to 10.
-                example: 10
-              min_depth:
-                type: integer
-                description: The minimum depth of events to retrieve. Defaults to 0.
-                example: 0
-              earliest_events:
-                type: array
-                description: |-
-                  The latest event IDs that the sender already has. These are skipped when retrieving
-                  the previous events of `latest_events`.
-                items:
-                  type: string
-                example: ["$missing_event:example.org"]
-              latest_events:
-                type: array
-                description: The event IDs to retrieve the previous events for.
-                items:
-                  type: string
-                example: ["$event_that_has_the_missing_event_as_a_previous_event:example.org"]
-            required: ['earliest_events', 'latest_events']
-      responses:
-        200:
-          description: |-
-            The previous events for `latest_events`, excluding any `earliest_events`, up to the
-            provided `limit`.
-          schema:
-            type: object
-            properties:
-              events:
-                type: array
-                description: |-
-                  The missing events. The event format varies depending on the room version - check
-                  the [room version specification](/rooms) for precise event formats.
-                items:
-                  type: object
-                  title: PDU
-            required: ['events']
-          examples:
-            application/json: {
-              "events": [
-                {"$ref": "examples/minimal_pdu.json"}
-              ]
-            }
diff --git a/data/api/server-server/definitions/edu.yaml b/data/api/server-server/definitions/edu.yaml
deleted file mode 100644
index 0e4edcc6..00000000
--- a/data/api/server-server/definitions/edu.yaml
+++ /dev/null
@@ -1,28 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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: Ephemeral Data Unit
-description: An ephemeral data unit.
-example:
-  $ref: "../examples/edu.json"
-properties:
-  edu_type:
-    type: string
-    description: The type of ephemeral message.
-    example: "m.presence"
-  content:
-    type: object
-    description: The content of the ephemeral message.
-required: ['edu_type', 'content']
\ No newline at end of file
diff --git a/data/api/server-server/definitions/event-schemas/m.device_list_update.yaml b/data/api/server-server/definitions/event-schemas/m.device_list_update.yaml
deleted file mode 100644
index 2221ad5f..00000000
--- a/data/api/server-server/definitions/event-schemas/m.device_list_update.yaml
+++ /dev/null
@@ -1,92 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2020 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.
-
-x-addedInMatrixVersion: "1.1"
-type: object
-title: m.device_list_update
-description: |-
-  An EDU that lets servers push details to each other when one of their users
-  adds a new device to their account, required for E2E encryption to correctly
-  target the current set of devices for a given user. This event will also be
-  sent when an existing device gets a new cross-signing signature.
-
-# FIXME: It's very unclear why we have this API surface for synchronising
-# device lists, rather than just using a room (which could also be used for
-# profile info, etc).  But documenting what we have for now...
-
-allOf:
-  - $ref: ../edu.yaml
-  - type: object
-    properties:
-      edu_type:
-        type: enum
-        enum: ['m.device_list_update']
-        description: The string `m.device_list_update`.
-        example: "m.device_list_update"
-      content:
-        type: object
-        description: The description of the device whose details has changed.
-        title: Device List Update
-        properties:
-          user_id:
-            type: string
-            description: The user ID who owns this device.
-            example: "@john:example.com"
-          device_id:
-            type: string
-            description: The ID of the device whose details are changing.
-            example: "QBUAZIFURK"
-          device_display_name:
-            type: string
-            description: |-
-              The public human-readable name of this device. Will be absent
-              if the device has no name.
-            example: "Mobile"
-          stream_id:
-            type: integer
-            description: |-
-              An ID sent by the server for this update, unique for a given
-              user_id.  Used to identify any gaps in the sequence of `m.device_list_update`
-              EDUs broadcast by a server.
-            example: 6
-          prev_id:
-            type: array
-            description: |-
-              The stream_ids of any prior m.device_list_update EDUs sent for this user
-              which have not been referred to already in an EDU's prev_id field.  If the
-              receiving server does not recognise any of the prev_ids, it means an EDU
-              has been lost and the server should query a snapshot of the device list
-              via `/user/keys/query` in order to correctly interpret future `m.device_list_update`
-              EDUs.  May be missing or empty for the first EDU in a sequence.
-            items:
-              type: integer
-              description: |-
-                The stream_id of a prior EDU in this sequence which has not been referred
-                to already in an EDU's prev_id field.
-              example: 5
-          deleted:
-            type: boolean
-            description: |-
-              True if the server is announcing that this device has been deleted.
-            example: false
-          keys:
-            description: |-
-              The updated identity keys (if any) for this device.  May be absent if the
-              device has no E2E keys defined.
-            $ref: ../../../client-server/definitions/device_keys.yaml
-        required:
-          - user_id
-          - device_id
-          - stream_id
diff --git a/data/api/server-server/definitions/event-schemas/m.direct_to_device.yaml b/data/api/server-server/definitions/event-schemas/m.direct_to_device.yaml
deleted file mode 100644
index f628ebe0..00000000
--- a/data/api/server-server/definitions/event-schemas/m.direct_to_device.yaml
+++ /dev/null
@@ -1,75 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.direct_to_device
-description: |-
-  An EDU that lets servers push send events directly to a specific device on
-  a remote server - for instance, to maintain an Olm E2E encrypted message channel
-  between a local and remote device.
-allOf:
-  - $ref: ../edu.yaml
-  - type: object
-    properties:
-      edu_type:
-        type: enum
-        enum: ['m.direct_to_device']
-        description: The string `m.direct_to_device`.
-        example: "m.direct_to_device"
-      content:
-        type: object
-        description: The description of the direct-to-device message.
-        title: To Device Message
-        properties:
-          sender:
-            type: string
-            description: User ID of the sender.
-            example: "@john:example.com"
-          type:
-            type: string
-            description: Event type for the message.
-            example: "m.room_key_request"
-          message_id:
-            type: string
-            description: Unique ID for the message, used for idempotence.  Arbitrary
-              utf8 string, of maximum length 32 codepoints.
-            example: "hiezohf6Hoo7kaev"
-          messages:
-            type: object
-            description: |-
-              The contents of the messages to be sent.  These are arranged in
-              a map of user IDs to a map of device IDs to message bodies.
-              The device ID may also be `*`, meaning all known devices for the user.
-            additionalProperties:
-              type: object
-              title: User Devices
-              additionalProperties:
-                type: object
-                title: Device Message Contents
-                properties: {}
-            example: {
-              "@alice:example.org": {
-                "IWHQUZUIAH": {
-                  "algorithm": "m.megolm.v1.aes-sha2",
-                  "room_id": "!Cuyf34gef24t:localhost",
-                  "session_id": "X3lUlvLELLYxeTx4yOVu6UDpasGEVO0Jbu+QFnm0cKQ",
-                  "session_key": "AgAAAADxKHa9uFxcXzwYoNueL5Xqi69IkD4sni8LlfJL7qNBEY..."
-                }
-              }
-            }
-        required:
-          - sender
-          - type
-          - message_id
-          - messages
diff --git a/data/api/server-server/definitions/event-schemas/m.presence.yaml b/data/api/server-server/definitions/event-schemas/m.presence.yaml
deleted file mode 100644
index 09d5d0d2..00000000
--- a/data/api/server-server/definitions/event-schemas/m.presence.yaml
+++ /dev/null
@@ -1,71 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.presence
-description: |-
-  An EDU representing presence updates for users of the sending homeserver.
-allOf:
-  - $ref: ../edu.yaml
-  - type: object
-    properties:
-      edu_type:
-        type: enum
-        enum: ['m.presence']
-        description: The string `m.presence`
-        example: "m.presence"
-      content:
-        type: object
-        description: The presence updates and requests.
-        title: Presence Update
-        properties:
-          push:
-            type: array
-            description: |-
-              A list of presence updates that the receiving server is likely
-              to be interested in.
-            items:
-              type: object
-              title: User Presence Update
-              properties:
-                user_id:
-                  type: string
-                  description: The user ID this presence EDU is for.
-                  example: "@john:matrix.org"
-                presence:
-                  type: enum
-                  enum: ['offline', 'unavailable', 'online']
-                  description: The presence of the user.
-                  example: "online"
-                status_msg:
-                  type: string
-                  description: An optional description to accompany the presence.
-                  example: "Making cupcakes"
-                last_active_ago:
-                  type: integer
-                  format: int64
-                  description: |-
-                    The number of milliseconds that have elapsed since the user
-                    last did something.
-                  example: 5000
-                currently_active:
-                  type: boolean
-                  description: |-
-                    True if the user is likely to be interacting with their
-                    client. This may be indicated by the user having a
-                    `last_active_ago` within the last few minutes. Defaults
-                    to false.
-                  example: true
-              required: ['user_id', 'presence', 'last_active_ago']
-        required: ['push']
diff --git a/data/api/server-server/definitions/event-schemas/m.receipt.yaml b/data/api/server-server/definitions/event-schemas/m.receipt.yaml
deleted file mode 100644
index 335e7c27..00000000
--- a/data/api/server-server/definitions/event-schemas/m.receipt.yaml
+++ /dev/null
@@ -1,82 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.receipt
-description: |-
-  An EDU representing receipt updates for users of the sending homeserver.
-  When receiving receipts, the server should only update entries that are
-  listed in the EDU. Receipts previously received that do not appear in the
-  EDU should not be removed or otherwise manipulated.
-allOf:
-  - $ref: ../edu.yaml
-  - type: object
-    properties:
-      edu_type:
-        type: enum
-        enum: ['m.receipt']
-        description: The string `m.receipt`
-        example: "m.receipt"
-      content:
-        type: object
-        description: |-
-          Receipts for a particular room. The string key is the room ID for
-          which the receipts under it belong.
-        additionalProperties:
-          type: object
-          title: Room Receipts
-          properties:
-            # We strongly define the receipt type to help spec future ones later
-            # on. At that point, m.read can become optional (maybe).
-            "m.read":
-              type: object
-              description: Read receipts for users in the room.
-              title: User Read Receipt
-              properties:
-                event_ids:
-                  type: array
-                  description: |-
-                    The extremity event IDs that the user has read up to.
-                  minItems: 1
-                  maxItems: 1
-                  items:
-                    type: string
-                  example: ['$read_this_event:matrix.org']
-                data:
-                  type: object
-                  description: Metadata for the read receipt.
-                  title: Read Receipt Metadata
-                  properties:
-                    ts:
-                      type: integer
-                      format: int64
-                      description: |-
-                        A POSIX timestamp in milliseconds for when the user read
-                        the event specified in the read receipt.
-                      example: 1533358089009
-                  required: ['ts']
-              required: ['event_ids', 'data']
-          required: ['m.read']
-        example: {
-          "!some_room:example.org": {
-            "m.read": {
-              "@john:matrix.org": {
-                "event_ids": ["$read_this_event:matrix.org"],
-                "data": {
-                  "ts": 1533358089009
-                }
-              }
-            }
-          }
-        }
diff --git a/data/api/server-server/definitions/event-schemas/m.signing_key_update.yaml b/data/api/server-server/definitions/event-schemas/m.signing_key_update.yaml
deleted file mode 100644
index 55d91141..00000000
--- a/data/api/server-server/definitions/event-schemas/m.signing_key_update.yaml
+++ /dev/null
@@ -1,65 +0,0 @@
-# Copyright 2020 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.
-
-x-addedInMatrixVersion: "1.1"
-type: object
-title: m.signing_key_update
-description: |-
-  An EDU that lets servers push details to each other when one of their users
-  updates their cross-signing keys.
-allOf:
-  - $ref: ../edu.yaml
-  - type: object
-    properties:
-      edu_type:
-        type: enum
-        enum: ['m.signing_key_update']
-        description: The string `m.signing_update`.
-        example: "m.signing_key_update"
-      content:
-        type: object
-        description: The updated signing keys.
-        title: Signing Key Update
-        properties:
-          user_id:
-            type: string
-            description: The user ID whose cross-signing keys have changed.
-            example: "@alice:example.com"
-          master_key:
-            type: object
-            $ref: ../../../client-server/definitions/cross_signing_key.yaml
-            example: {
-              "user_id": "@alice:example.com",
-              "usage": ["master"],
-              "keys": {
-                "ed25519:base64+master+public+key": "base64+master+public+key",
-              }
-            }
-          self_signing_key:
-            type: object
-            $ref: ../../../client-server/definitions/cross_signing_key.yaml
-            example: {
-              "user_id": "@alice:example.com",
-              "usage": ["self_signing"],
-              "keys": {
-                "ed25519:base64+self+signing+public+key": "base64+self+signing+master+public+key",
-              },
-              "signatures": {
-                "@alice:example.com": {
-                  "ed25519:base64+master+public+key": "signature+of+self+signing+key"
-                }
-              }
-            }
-        required:
-          - user_id
diff --git a/data/api/server-server/definitions/event-schemas/m.typing.yaml b/data/api/server-server/definitions/event-schemas/m.typing.yaml
deleted file mode 100644
index 7f23bae1..00000000
--- a/data/api/server-server/definitions/event-schemas/m.typing.yaml
+++ /dev/null
@@ -1,46 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.typing
-description: A typing notification EDU for a user in a room.
-allOf:
-  - $ref: ../edu.yaml
-  - type: object
-    properties:
-      edu_type:
-        type: enum
-        enum: ['m.typing']
-        description: The string `m.typing`
-        example: "m.typing"
-      content:
-        type: object
-        description: The typing notification.
-        title: Typing Notification
-        properties:
-          room_id:
-            type: string
-            description: |-
-              The room where the user's typing status has been updated.
-            example: "!somewhere:matrix.org"
-          user_id:
-            type: string
-            description: |-
-              The user ID that has had their typing status changed.
-            example: "@john:matrix.org"
-          typing:
-            type: boolean
-            description: Whether the user is typing in the room or not.
-            example: true
-        required: ['room_id', 'user_id', 'typing']
diff --git a/data/api/server-server/definitions/invite_event.yaml b/data/api/server-server/definitions/invite_event.yaml
deleted file mode 100644
index 439a6833..00000000
--- a/data/api/server-server/definitions/invite_event.yaml
+++ /dev/null
@@ -1,63 +0,0 @@
-# Copyright 2018-2019 New Vector Ltd
-#
-# 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: InviteEvent
-description: |-
-  An invite event. Note that events have a different format depending on the
-  room version - check the [room version specification](/rooms) for precise event formats.
-allOf:
-  - type: object
-    properties:
-      sender:
-        type: string
-        description: |-
-          The matrix ID of the user who sent the original `m.room.third_party_invite`.
-        example: "@someone:example.org"
-      origin:
-        type: string
-        description: The name of the inviting homeserver.
-        example: "matrix.org"
-      origin_server_ts:
-        type: integer
-        format: int64
-        description: A timestamp added by the inviting homeserver.
-        example: 1234567890
-      type:
-        type: string
-        description: The value `m.room.member`.
-        example: "m.room.member"
-      state_key:
-        type: string
-        description: The user ID of the invited member.
-        example: "@joe:elsewhere.com"
-      content:
-        type: object
-        title: Membership Event Content
-        description: |-
-          The content of the event, matching what is available in the
-          [Client-Server API](/client-server-api/). Must include a `membership` of `invite`.
-        example: {"membership": "invite"}
-        properties:
-          membership:
-            type: string
-            description: The value `invite`.
-            example: "invite"
-        required: ['membership']
-    required:
-      - state_key
-      - sender
-      - origin
-      - origin_server_ts
-      - type
-      - content
diff --git a/data/api/server-server/definitions/keys.yaml b/data/api/server-server/definitions/keys.yaml
deleted file mode 100644
index 135e81ac..00000000
--- a/data/api/server-server/definitions/keys.yaml
+++ /dev/null
@@ -1,100 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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: Server Keys
-description: Server keys
-example:
-  $ref: "../examples/server_key.json"
-properties:
-  server_name:
-    type: string
-    description: DNS name of the homeserver.
-    example: "example.org"
-  verify_keys:
-    type: object
-    description: |-
-      Public keys of the homeserver for verifying digital signatures.
-
-      The object's key is the algorithm and version combined (`ed25519` being the
-      algorithm and `abc123` being the version in the example below). Together,
-      this forms the Key ID. The version must have characters matching the regular
-      expression `[a-zA-Z0-9_]`.
-    additionalProperties:
-      type: object
-      title: Verify Key
-      example: {
-        "ed25519:abc123": {
-          "key": "VGhpcyBzaG91bGQgYmUgYSByZWFsIGVkMjU1MTkgcGF5bG9hZA"
-        }
-      }
-      properties:
-        key:
-          type: string
-          description: The [Unpadded base64](/appendices/#unpadded-base64) encoded key.
-          example: "VGhpcyBzaG91bGQgYmUgYSByZWFsIGVkMjU1MTkgcGF5bG9hZA"
-      required: ["key"]
-  old_verify_keys:
-    type: object
-    description: |-
-      The public keys that the server used to use and when it stopped using them.
-
-      The object's key is the algorithm and version combined (`ed25519` being the
-      algorithm and `0ldK3y` being the version in the example below). Together,
-      this forms the Key ID. The version must have characters matching the regular
-      expression `[a-zA-Z0-9_]`.
-    additionalProperties:
-      type: object
-      title: Old Verify Key
-      example: {
-        "ed25519:0ldK3y": {
-          "expired_ts": 1532645052628,
-          "key": "VGhpcyBzaG91bGQgYmUgeW91ciBvbGQga2V5J3MgZWQyNTUxOSBwYXlsb2FkLg"
-        }
-      }
-      properties:
-        expired_ts:
-          type: integer
-          format: int64
-          description: POSIX timestamp in milliseconds for when this key expired.
-          example: 1532645052628
-        key:
-          type: string
-          description: The [Unpadded base64](/appendices/#unpadded-base64) encoded key.
-          example: "VGhpcyBzaG91bGQgYmUgeW91ciBvbGQga2V5J3MgZWQyNTUxOSBwYXlsb2FkLg"
-      required: ["expired_ts", "key"]
-  signatures:
-    type: object
-    description: |-
-      Digital signatures for this object signed using the `verify_keys`.
-
-      The signature is calculated using the process described at [Signing JSON](/appendices/#signing-json).
-    title: Signatures
-    additionalProperties:
-      type: object
-      additionalProperties:
-        type: string
-  valid_until_ts:
-    type: integer
-    format: int64
-    description: |-
-      POSIX timestamp when the list of valid keys should be refreshed. This field MUST
-      be ignored in room versions 1, 2, 3, and 4. Keys used beyond this timestamp MUST
-      be considered invalid, depending on the [room version specification](/rooms).
-
-      Servers MUST use the lesser of this field and 7 days into the future when
-      determining if a key is valid. This is to avoid a situation where an attacker
-      publishes a key which is valid for a significant amount of time without a way
-      for the homeserver owner to revoke it.
-    example: 1052262000000
-required: ["server_name", "verify_keys"]
diff --git a/data/api/server-server/definitions/keys_query_response.yaml b/data/api/server-server/definitions/keys_query_response.yaml
deleted file mode 100644
index 52ad506c..00000000
--- a/data/api/server-server/definitions/keys_query_response.yaml
+++ /dev/null
@@ -1,27 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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
-description: Server keys
-example: {
-  "server_keys": [{
-    $ref: "../examples/server_key_notary_signed.json"
-  }]
-}
-properties:
-  server_keys:
-    type: array
-    title: Server Keys
-    description: The queried server's keys, signed by the notary server.
-    items:
-      $ref: "keys.yaml"
diff --git a/data/api/server-server/definitions/pdu.yaml b/data/api/server-server/definitions/pdu.yaml
deleted file mode 100644
index d87db1a3..00000000
--- a/data/api/server-server/definitions/pdu.yaml
+++ /dev/null
@@ -1,53 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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: Persistent Data Unit
-description: A persistent data unit (event) for room versions 1 and 2.
-example:
-  $ref: "../examples/pdu.json"
-allOf:
-  - $ref: "unsigned_pdu.yaml"
-  - type: object
-    properties:
-      hashes:
-        type: object
-        title: Event Hash
-        description: |-
-          Content hashes of the PDU, following the algorithm specified in [Signing Events](/server-server-api/#signing-events).
-        example: {
-          "sha256": "ThisHashCoversAllFieldsInCaseThisIsRedacted"
-        }
-        properties:
-          sha256:
-            type: string
-            description: The hash.
-            example: ThisHashCoversAllFieldsInCaseThisIsRedacted
-        required: ['sha256']
-      signatures:
-        type: object
-        description: |-
-          Signatures for the PDU, following the algorithm specified in [Signing Events](/server-server-api/#signing-events).
-        example: {
-          "example.com": {
-            "ed25519:key_version:": "86BytesOfSignatureOfTheRedactedEvent"
-          }
-        }
-        additionalProperties:
-          type: object
-          title: Server Signatures
-          additionalProperties:
-            type: string
-    required:
-      - hashes
-      - signatures
diff --git a/data/api/server-server/definitions/pdu_v3.yaml b/data/api/server-server/definitions/pdu_v3.yaml
deleted file mode 100644
index 32d05b36..00000000
--- a/data/api/server-server/definitions/pdu_v3.yaml
+++ /dev/null
@@ -1,83 +0,0 @@
-# Copyright 2019 New Vector Ltd
-#
-# 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: Persistent Data Unit
-description: A persistent data unit (event) for room version 3 and beyond.
-example:
-  $ref: "../examples/pdu_v3.json"
-allOf:
-  - $ref: "unsigned_pdu_base.yaml"
-  - type: object
-    properties:
-      redacts:
-        type: string
-        description: For redaction events, the ID of the event being redacted.
-        example: "$def/456+oldevent"
-      auth_events:
-        type: array
-        items:
-          type: string
-          description: Event ID.
-        description: |-
-          Event IDs for the authorization events that would
-          allow this event to be in the room.
-
-          Must contain less than or equal to 10 events. Note that if the relevant
-          auth event selection rules are used, this restriction should never be
-          encountered.
-        example: ["$base64EncodedHash", "$AnotherEvent"]
-      prev_events:
-        type: array
-        items:
-          type: string
-          description: Event ID.
-        description: |-
-          Event IDs for the most recent events in the room
-          that the homeserver was aware of when it made this event.
-
-          Must contain less than or equal to 20 events.
-        example: ["$base64EncodedHash", "$AnotherEvent"]
-      hashes:
-        type: object
-        title: Event Hash
-        description: |-
-          Content hashes of the PDU, following the algorithm specified in [Signing Events](/server-server-api/#signing-events).
-        example: {
-          "sha256": "ThisHashCoversAllFieldsInCaseThisIsRedacted"
-        }
-        properties:
-          sha256:
-            type: string
-            description: The hash.
-            example: ThisHashCoversAllFieldsInCaseThisIsRedacted
-        required: ['sha256']
-      signatures:
-        type: object
-        description: |-
-          Signatures for the PDU, following the algorithm specified in [Signing Events](/server-server-api/#signing-events).
-        example: {
-          "example.com": {
-            "ed25519:key_version:": "86BytesOfSignatureOfTheRedactedEvent"
-          }
-        }
-        additionalProperties:
-          type: object
-          title: Server Signatures
-          additionalProperties:
-            type: string
-    required:
-      - auth_events
-      - prev_events
-      - hashes
-      - signatures
diff --git a/data/api/server-server/definitions/pdu_v4.yaml b/data/api/server-server/definitions/pdu_v4.yaml
deleted file mode 100644
index d22956c6..00000000
--- a/data/api/server-server/definitions/pdu_v4.yaml
+++ /dev/null
@@ -1,53 +0,0 @@
-# Copyright 2019 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: Persistent Data Unit
-description: A persistent data unit (event) for room version 4 and beyond.
-example:
-  $ref: "../examples/pdu_v4.json"
-allOf:
-  - $ref: "pdu_v3.yaml"
-  - type: object
-    properties:
-      redacts:
-        type: string
-        description: For redaction events, the ID of the event being redacted.
-        example: "$def_456-oldevent"
-      auth_events:
-        type: array
-        items:
-          type: string
-          description: Event ID.
-        description: |-
-          Event IDs for the authorization events that would
-          allow this event to be in the room.
-
-          Must contain less than or equal to 10 events. Note that if the relevant
-          auth event selection rules are used, this restriction should never be
-          encountered.
-        example: ["$URLsafe-base64EncodedHash", "$Another_Event"]
-      prev_events:
-        type: array
-        items:
-          type: string
-          description: Event ID.
-        description: |-
-          Event IDs for the most recent events in the room
-          that the homeserver was aware of when it made this event.
-
-          Must contain less than or equal to 20 events.
-        example: ["$URLsafe-base64EncodedHash", "$Another_Event"]
-    required:
-      - auth_events
-      - prev_events
diff --git a/data/api/server-server/definitions/security.yaml b/data/api/server-server/definitions/security.yaml
deleted file mode 100644
index 822b3fdf..00000000
--- a/data/api/server-server/definitions/security.yaml
+++ /dev/null
@@ -1,19 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-signedRequest:
-  type: apiKey
-  description: |-
-    The `Authorization` header defined in the [Authentication](/server-server-api/#authentication) section.
-  name: Authorization
-  in: header
diff --git a/data/api/server-server/definitions/send_join_response.yaml b/data/api/server-server/definitions/send_join_response.yaml
deleted file mode 100644
index 12b020a2..00000000
--- a/data/api/server-server/definitions/send_join_response.yaml
+++ /dev/null
@@ -1,68 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2020 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: Room State
-description: The state for the room.
-properties:
-  origin:
-    type: string
-    description: The resident server's DNS name.
-  auth_chain:
-    type: array
-    description: |-
-      The auth chain for the entire current room state prior to the join event.
-
-      Note that events have a different format depending on the room version - check the
-      [room version specification](/rooms) for precise event formats.
-    items:
-      type: object
-      title: PDU
-      description: |-
-        The [PDUs](/server-server-api/#pdus) that make up the auth chain. The event format varies depending
-        on the room version - check the [room version specification](/rooms) for precise event formats.
-      schema:
-        type: object
-        properties: {}
-      example:
-        $ref: "../examples/minimal_pdu.json"
-  state:
-    type: array
-    description: |-
-      The resolved current room state prior to the join event.
-
-      The event format varies depending on the room version - check the [room version specification](/rooms)
-      for precise event formats.
-    items:
-      type: object
-      title: PDU
-      description: |-
-        The [PDUs](/server-server-api/#pdus) for the fully resolved state of the room. The event format varies depending
-        on the room version - check the [room version specification](/rooms) for precise event formats.
-      schema:
-        type: object
-        properties: {}
-      example:
-        $ref: "../examples/minimal_pdu.json"
-  event:
-    type: object
-    title: SignedMembershipEvent
-    x-addedInMatrixVersion: "1.2"
-    description: |-
-      Required if the room version [supports restricted join rules](/rooms/#feature-matrix). The signed
-      copy of the membership event sent to other servers by the resident server, including the resident
-      server's signature.
-    example:
-      $ref: "../examples/minimal_pdu.json"
-required: ["auth_chain", "state", "origin"]
diff --git a/data/api/server-server/definitions/single_pdu_transaction.yaml b/data/api/server-server/definitions/single_pdu_transaction.yaml
deleted file mode 100644
index 74b9744d..00000000
--- a/data/api/server-server/definitions/single_pdu_transaction.yaml
+++ /dev/null
@@ -1,32 +0,0 @@
-# Copyright 2019 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
-allOf:
-  - $ref: "transaction.yaml"
-properties:
-  pdus:
-    type: array
-    description: |-
-      A single PDU. Note that events have a different format depending on the room
-      version - check the [room version specification](/rooms) for precise event formats.
-    items:
-      type: object
-      title: PDU
-      description: |-
-        The [PDUs](/server-server-api/#pdus) contained in the transaction. The event format varies depending
-        on the room version - check the [room version specification](/rooms) for precise event formats.
-      properties: {}
-      example:
-        $ref: "../examples/minimal_pdu.json"
-required: ['origin', 'origin_server_ts', 'pdus']
diff --git a/data/api/server-server/definitions/transaction.yaml b/data/api/server-server/definitions/transaction.yaml
deleted file mode 100644
index e20204e0..00000000
--- a/data/api/server-server/definitions/transaction.yaml
+++ /dev/null
@@ -1,47 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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: Transaction
-description: Transaction
-example:
-  $ref: "../examples/transaction.json"
-properties:
-  origin:
-    type: string
-    description: |-
-      The `server_name` of the homeserver sending this transaction.
-    example: "example.org"
-  origin_server_ts:
-    type: integer
-    format: int64
-    description: |-
-      POSIX timestamp in milliseconds on originating homeserver when this
-      transaction started.
-    example: 1532991320875
-  pdus:
-    type: array
-    description: |-
-      List of persistent updates to rooms. Must not include more than 50 PDUs. Note that
-      events have a different format depending on the room version - check the
-      [room version specification](/rooms) for precise event formats.
-    items:
-      type: object
-      title: PDU
-      description: |-
-        The [PDUs](/server-server-api/#pdus) contained in the transaction. The event format varies depending
-        on the room version - check the [room version specification](/rooms) for precise event formats.
-      properties: {}
-      example:
-        $ref: "../examples/minimal_pdu.json"
-required: ['origin', 'origin_server_ts', 'pdus']
diff --git a/data/api/server-server/definitions/unlimited_pdu_transaction.yaml b/data/api/server-server/definitions/unlimited_pdu_transaction.yaml
deleted file mode 100644
index 003daee5..00000000
--- a/data/api/server-server/definitions/unlimited_pdu_transaction.yaml
+++ /dev/null
@@ -1,33 +0,0 @@
-# Copyright 2019 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
-allOf:
-  - $ref: "transaction.yaml"
-properties:
-  pdus:
-    type: array
-    description: |-
-      List of persistent updates to rooms. Note that events have a different format
-      depending on the room version - check the [room version specification](/rooms) for
-      precise event formats.
-    items:
-      type: object
-      title: PDU
-      description: |-
-        The [PDUs](/server-server-api/#pdus) contained in the transaction. The event format varies depending
-        on the room version - check the [room version specification](/rooms) for precise event formats.
-      properties: {}
-      example:
-        $ref: "../examples/minimal_pdu.json"
-required: ['origin', 'origin_server_ts', 'pdus']
diff --git a/data/api/server-server/definitions/unsigned_pdu.yaml b/data/api/server-server/definitions/unsigned_pdu.yaml
deleted file mode 100644
index a27a21cd..00000000
--- a/data/api/server-server/definitions/unsigned_pdu.yaml
+++ /dev/null
@@ -1,28 +0,0 @@
-# Copyright 2018-2019 New Vector Ltd
-#
-# 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: Unsigned Persistent Data Unit
-description: An unsigned persistent data unit (event)
-example:
-  $ref: "../examples/unsigned_pdu.json"
-allOf:
-  - $ref: "unsigned_pdu_base.yaml"
-  - type: object
-    properties:
-      event_id:
-        type: string
-        description: The event ID for the PDU.
-        example: "$a4ecee13e2accdadf56c1025:example.com"
-    required:
-      - event_id
diff --git a/data/api/server-server/definitions/unsigned_pdu_base.yaml b/data/api/server-server/definitions/unsigned_pdu_base.yaml
deleted file mode 100644
index a2bed9c3..00000000
--- a/data/api/server-server/definitions/unsigned_pdu_base.yaml
+++ /dev/null
@@ -1,137 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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: Unsigned Persistent Data Unit
-description: An unsigned persistent data unit (event)
-example:
-  $ref: "../examples/unsigned_pdu_base.json"
-properties:
-  room_id:
-    type: string
-    description: Room identifier.
-    example: "!abc123:matrix.org"
-  sender:
-    type: string
-    description: The ID of the user sending the event.
-    example: "@someone:matrix.org"
-  origin:
-    type: string
-    description: The `server_name` of the homeserver that created this event.
-    example: "matrix.org"
-  origin_server_ts:
-    type: integer
-    format: int64
-    description: Timestamp in milliseconds on origin homeserver when this event was created.
-    example: 1234567890
-  type:
-    type: string
-    description: Event type
-    example: "m.room.message"
-  state_key:
-    type: string
-    description: |-
-      If this key is present, the event is a state event, and it will replace previous events
-      with the same `type` and `state_key` in the room state.
-    example: "my_key"
-  content:
-    type: object
-    description: The content of the event.
-    example: {"key": "value"}
-  prev_events:
-    type: array
-    description: |-
-      Event IDs and reference hashes for the most recent events in the room
-      that the homeserver was aware of when it made this event.
-
-      Must contain less than or equal to 20 events.
-    items:
-      type: array
-      maxItems: 2
-      minItems: 2
-      items:
-        - type: string
-          title: Event ID
-          example: "$abc123:matrix.org"
-        - type: object
-          title: Event Hash
-          example: {
-            "sha256": "Base64EncodedSha256HashesShouldBe43BytesLong"
-          }
-          properties:
-            sha256:
-              type: string
-              description: The event hash.
-              example: Base64EncodedSha256HashesShouldBe43BytesLong
-          required: ['sha256']
-  depth:
-    type: integer
-    description: |-
-      The maximum depth of the `prev_events`, plus one. Must be less than the
-      maximum value for an integer (2^63 - 1). If the room's depth is already at
-      the limit, the depth must be set to the limit.
-    example: 12
-  auth_events:
-    type: array
-    description: |-
-      Event IDs and reference hashes for the authorization events that would
-      allow this event to be in the room.
-
-      Must contain less than or equal to 10 events. Note that if the relevant
-      auth event selection rules are used, this restriction should never be
-      encountered.
-    items:
-      type: array
-      maxItems: 2
-      minItems: 2
-      items:
-        - type: string
-          title: Event ID
-          example: "$abc123:matrix.org"
-        - type: object
-          title: Event Hash
-          example: {
-            "sha256": "Base64EncodedSha256HashesShouldBe43BytesLong"
-          }
-          properties:
-            sha256:
-              type: string
-              description: The event hash.
-              example: Base64EncodedSha256HashesShouldBe43BytesLong
-          required: ['sha256']
-  redacts:
-    type: string
-    description: For redaction events, the ID of the event being redacted.
-    example: "$def456:matrix.org"
-  unsigned:
-    type: object
-    title: UnsignedData
-    description: |-
-      Additional data added by the origin server but not covered by the `signatures`.
-    example: {"key": "value"}
-    properties:
-      age:
-        type: integer
-        description: The number of milliseconds that have passed since this message was sent.
-        example: 4612
-required:
-  - event_id
-  - room_id
-  - sender
-  - origin
-  - origin_server_ts
-  - type
-  - content
-  - prev_events
-  - depth
-  - auth_events
diff --git a/data/api/server-server/event_auth.yaml b/data/api/server-server/event_auth.yaml
deleted file mode 100644
index ae4db262..00000000
--- a/data/api/server-server/event_auth.yaml
+++ /dev/null
@@ -1,70 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Event Authorization API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/event_auth/{roomId}/{eventId}":
-    get:
-      summary: Get the auth chain for a given event
-      description: |-
-        Retrieves the complete auth chain for a given event.
-      operationId: getEventAuth
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID to get the auth chain for.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: path
-          name: eventId
-          type: string
-          description: The event ID to get the auth chain of.
-          required: true
-          x-example: "$helloworld:example.org"
-      responses:
-        200:
-          description: The auth chain for the event.
-          schema:
-            type: object
-            properties:
-              auth_chain:
-                type: array
-                description: |-
-                  The [PDUs](/server-server-api/#pdus) forming the auth chain
-                  of the given event. The event format varies depending on the
-                  room version - check the [room version specification](/rooms)
-                  for precise event formats.
-                items:
-                  type: object
-                  title: PDU
-                  properties: {}
-                  example:
-                    $ref: "examples/minimal_pdu.json"
-            required: ['auth_chain']
diff --git a/data/api/server-server/events.yaml b/data/api/server-server/events.yaml
deleted file mode 100644
index 4eef23b6..00000000
--- a/data/api/server-server/events.yaml
+++ /dev/null
@@ -1,159 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Events API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/state/{roomId}":
-    get:
-      summary: Get all the state of a given room
-      description: |-
-        Retrieves a snapshot of a room's state at a given event.
-      operationId: getRoomState
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID to get state for.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: query
-          name: event_id
-          type: string
-          description: An event ID in the room to retrieve the state at.
-          required: true
-          x-example: "$helloworld:matrix.org"
-      responses:
-        200:
-          description: |-
-            The fully resolved state for the room, prior to considering any state
-            changes induced by the requested event. Includes the authorization
-            chain for the events.
-          schema:
-            type: object
-            properties:
-              auth_chain:
-                type: array
-                description: |-
-                  The full set of authorization events that make up the state
-                  of the room, and their authorization events, recursively. Note that
-                  events have a different format depending on the room version -
-                  check the [room version specification](/rooms) for precise event formats.
-                items:
-                  type: object
-                  title: PDU
-                  description: |-
-                    The [PDUs](/server-server-api/#pdus) contained in the auth chain. The event format
-                    varies depending on the room version - check the [room version specification](/rooms)
-                    for precise event formats.
-                  properties: {}
-                  example:
-                    $ref: "examples/minimal_pdu.json"
-              pdus:
-                type: array
-                description: |-
-                  The fully resolved state of the room at the given event. Note that
-                  events have a different format depending on the room version -
-                  check the [room version specification](/rooms) for precise event formats.
-                items:
-                  type: object
-                  title: PDU
-                  description: |-
-                    The [PDUs](/server-server-api/#pdus) for the fully resolved state of the room. The event format
-                    varies depending on the room version - check the [room version specification](/rooms)
-                    for precise event formats.
-                  properties: {}
-                  example:
-                    $ref: "examples/minimal_pdu.json"
-            required: ['auth_chain', 'pdus']
-  "/state_ids/{roomId}":
-    get:
-      summary: Get all the state event IDs of a given room
-      description: |-
-        Retrieves a snapshot of a room's state at a given event, in the form of
-        event IDs. This performs the same function as calling `/state/{roomId}`,
-        however this returns just the event IDs rather than the full events.
-      operationId: getRoomStateIds
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID to get state for.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: query
-          name: event_id
-          type: string
-          description: An event ID in the room to retrieve the state at.
-          required: true
-          x-example: "$helloworld:matrix.org"
-      responses:
-        200:
-          description: |-
-            The fully resolved state for the room, prior to considering any state
-            changes induced by the requested event. Includes the authorization
-            chain for the events.
-          schema:
-            type: object
-            properties:
-              auth_chain_ids:
-                type: array
-                description: |-
-                  The full set of authorization events that make up the state
-                  of the room, and their authorization events, recursively.
-                items:
-                  type: string
-                example: ["$an_event:example.org"]
-              pdu_ids:
-                type: array
-                description: |-
-                  The fully resolved state of the room at the given event.
-                items:
-                  type: string
-                example: ["$an_event:example.org"]
-            required: ['auth_chain_ids', 'pdu_ids']
-  "/event/{eventId}":
-    get:
-      summary: Get a single event
-      description: |-
-        Retrieves a single event.
-      operationId: getEvent
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: eventId
-          type: string
-          description: The event ID to get.
-          required: true
-          x-example: "$abc123:matrix.org"
-      responses:
-        200:
-          description: A transaction containing a single PDU which is the event requested.
-          schema:
-            $ref: "definitions/single_pdu_transaction.yaml"
diff --git a/data/api/server-server/examples/edu.json b/data/api/server-server/examples/edu.json
deleted file mode 100644
index f5a58e21..00000000
--- a/data/api/server-server/examples/edu.json
+++ /dev/null
@@ -1,6 +0,0 @@
-{
-    "edu_type": "m.presence",
-    "content": {
-        "key": "value"
-    }
-}
\ No newline at end of file
diff --git a/data/api/server-server/examples/minimal_pdu.json b/data/api/server-server/examples/minimal_pdu.json
deleted file mode 100644
index f8b8efc3..00000000
--- a/data/api/server-server/examples/minimal_pdu.json
+++ /dev/null
@@ -1,7 +0,0 @@
-{
-    "type": "m.room.minimal_pdu",
-    "room_id": "!somewhere:example.org",
-    "content": {
-        "see_room_version_spec": "The event format changes depending on the room version."
-    }
-}
diff --git a/data/api/server-server/examples/pdu.json b/data/api/server-server/examples/pdu.json
deleted file mode 100644
index 81981b23..00000000
--- a/data/api/server-server/examples/pdu.json
+++ /dev/null
@@ -1,11 +0,0 @@
-{
-    "$ref": "unsigned_pdu.json",
-    "hashes": {
-        "sha256": "thishashcoversallfieldsincasethisisredacted"
-    },
-    "signatures": {
-        "example.com": {
-            "ed25519:key_version:": "these86bytesofbase64signaturecoveressentialfieldsincludinghashessocancheckredactedpdus"
-        }
-    }
-}
\ No newline at end of file
diff --git a/data/api/server-server/examples/pdu_v3.json b/data/api/server-server/examples/pdu_v3.json
deleted file mode 100644
index acffdf26..00000000
--- a/data/api/server-server/examples/pdu_v3.json
+++ /dev/null
@@ -1,20 +0,0 @@
-{
-    "$ref": "unsigned_pdu_base.json",
-    "hashes": {
-        "sha256": "thishashcoversallfieldsincasethisisredacted"
-    },
-    "signatures": {
-        "example.com": {
-            "ed25519:key_version:": "these86bytesofbase64signaturecoveressentialfieldsincludinghashessocancheckredactedpdus"
-        }
-    },
-    "auth_events": [
-        "$base64encodedeventid",
-        "$adifferenteventid"
-    ],
-    "prev_events": [
-        "$base64encodedeventid",
-        "$adifferenteventid"
-    ],
-    "redacts": "$some/old+event"
-}
diff --git a/data/api/server-server/examples/pdu_v4.json b/data/api/server-server/examples/pdu_v4.json
deleted file mode 100644
index 3c2f0e22..00000000
--- a/data/api/server-server/examples/pdu_v4.json
+++ /dev/null
@@ -1,12 +0,0 @@
-{
-    "$ref": "pdu_v3.json",
-    "auth_events": [
-        "$urlsafe_base64_encoded_eventid",
-        "$a-different-event-id"
-    ],
-    "prev_events": [
-        "$urlsafe_base64_encoded_eventid",
-        "$a-different-event-id"
-    ],
-    "redacts": "$some-old_event"
-}
diff --git a/data/api/server-server/examples/pdu_v4_join_membership.json b/data/api/server-server/examples/pdu_v4_join_membership.json
deleted file mode 100644
index 1057ea94..00000000
--- a/data/api/server-server/examples/pdu_v4_join_membership.json
+++ /dev/null
@@ -1,28 +0,0 @@
-{
-    "$ref": "unsigned_pdu_base.json",
-    "hashes": {
-        "sha256": "thishashcoversallfieldsincasethisisredacted"
-    },
-    "signatures": {
-        "example.com": {
-            "ed25519:key_version": "these86bytesofbase64signaturecoveressentialfieldsincludinghashessocancheckredactedpdus"
-        },
-        "resident.example.com": {
-            "ed25519:other_key_version": "a different signature"
-        }
-    },
-    "auth_events": [
-        "$urlsafe_base64_encoded_eventid",
-        "$a-different-event-id"
-    ],
-    "prev_events": [
-        "$urlsafe_base64_encoded_eventid",
-        "$a-different-event-id"
-    ],
-    "type": "m.room.member",
-    "state_key": "@alice:example.com",
-    "content": {
-        "membership": "join",
-        "join_authorised_via_users_server": "@arbitrary:resident.example.com"
-    }
-}
diff --git a/data/api/server-server/examples/server_key.json b/data/api/server-server/examples/server_key.json
deleted file mode 100644
index ffdfcb5a..00000000
--- a/data/api/server-server/examples/server_key.json
+++ /dev/null
@@ -1,20 +0,0 @@
-{
-    "server_name": "example.org",
-    "verify_keys": {
-        "ed25519:abc123": {
-            "key": "VGhpcyBzaG91bGQgYmUgYSByZWFsIGVkMjU1MTkgcGF5bG9hZA"
-        }
-    },
-    "old_verify_keys": {
-        "ed25519:0ldk3y": {
-        "expired_ts": 1532645052628,
-            "key": "VGhpcyBzaG91bGQgYmUgeW91ciBvbGQga2V5J3MgZWQyNTUxOSBwYXlsb2FkLg"
-        }
-    },
-    "signatures": {
-        "example.org": {
-            "ed25519:auto2": "VGhpcyBzaG91bGQgYWN0dWFsbHkgYmUgYSBzaWduYXR1cmU"
-        }
-    },
-    "valid_until_ts": 1652262000000
-}
diff --git a/data/api/server-server/examples/server_key_notary_signed.json b/data/api/server-server/examples/server_key_notary_signed.json
deleted file mode 100644
index d3a461ba..00000000
--- a/data/api/server-server/examples/server_key_notary_signed.json
+++ /dev/null
@@ -1,11 +0,0 @@
-{
-    "$ref": "server_key.json",
-    "signatures": {
-        "example.org": {
-            "ed25519:abc123": "VGhpcyBzaG91bGQgYWN0dWFsbHkgYmUgYSBzaWduYXR1cmU"
-        },
-        "notary.server.com": {
-            "ed25519:010203": "VGhpcyBpcyBhbm90aGVyIHNpZ25hdHVyZQ"
-        }
-    }
-}
\ No newline at end of file
diff --git a/data/api/server-server/examples/transaction.json b/data/api/server-server/examples/transaction.json
deleted file mode 100644
index bbc661d9..00000000
--- a/data/api/server-server/examples/transaction.json
+++ /dev/null
@@ -1,7 +0,0 @@
-{
-    "origin": "matrix.org",
-    "origin_server_ts": 1234567890,
-    "pdus": [{
-        "$ref": "minimal_pdu.json"
-    }]
-}
diff --git a/data/api/server-server/examples/unsigned_pdu.json b/data/api/server-server/examples/unsigned_pdu.json
deleted file mode 100644
index b886a365..00000000
--- a/data/api/server-server/examples/unsigned_pdu.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
-    "$ref": "unsigned_pdu_base.json",
-    "event_id": "$a4ecee13e2accdadf56c1025:example.com"
-}
diff --git a/data/api/server-server/examples/unsigned_pdu_base.json b/data/api/server-server/examples/unsigned_pdu_base.json
deleted file mode 100644
index 4826ccef..00000000
--- a/data/api/server-server/examples/unsigned_pdu_base.json
+++ /dev/null
@@ -1,26 +0,0 @@
-{
-    "room_id": "!UcYsUzyxTGDxLBEvLy:example.org",
-    "sender": "@alice:example.com",
-    "origin": "example.com",
-    "origin_server_ts": 1404838188000,
-    "depth": 12,
-    "auth_events": [
-        [
-            "$af232176:example.org",
-            {"sha256": "abase64encodedsha256hashshouldbe43byteslong"}
-        ]
-    ],
-    "type": "m.room.message",
-    "prev_events": [
-        [
-            "$af232176:example.org",
-            {"sha256": "abase64encodedsha256hashshouldbe43byteslong"}
-        ]
-    ],
-    "content": {
-        "key": "value"
-    },
-    "unsigned": {
-        "age": 4612
-    }
-}
diff --git a/data/api/server-server/invites-v1.yaml b/data/api/server-server/invites-v1.yaml
deleted file mode 100644
index cd9812c0..00000000
--- a/data/api/server-server/invites-v1.yaml
+++ /dev/null
@@ -1,167 +0,0 @@
-# Copyright 2018-2019 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Invite User To Room API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/invite/{roomId}/{eventId}":
-    put:
-      summary: Invites a remote user to a room
-      description: |-
-        Invites a remote user to a room. Once the event has been  signed by both the inviting
-        homeserver and the invited homeserver, it can be sent to all of the servers in the
-        room by the inviting homeserver.
-
-        Servers should prefer to use the v2 API for invites instead of the v1 API. Servers
-        which receive a v1 invite request must assume that the room version is either `"1"`
-        or `"2"`.
-
-        Note that events have a different format depending on the room version - check the
-        [room version specification](/rooms) for precise event formats. **The request and response
-        bodies here describe the common event fields in more detail and may be missing other
-        required fields for a PDU.**
-      operationId: sendInviteV1
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID that the user is being invited to.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: path
-          name: eventId
-          type: string
-          description: The event ID for the invite event, generated by the inviting server.
-          required: true
-          x-example: "$abc123:example.org"
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            allOf:
-              - $ref: "definitions/invite_event.yaml"
-              - type: object
-                properties:
-                  unsigned:
-                    type: object
-                    title: UnsignedData
-                    description: |-
-                      Information included alongside the event that is not signed. May include more
-                      than what is listed here.
-                    properties:
-                      invite_room_state:
-                        type: array
-                        description: |-
-                          An optional list of [stripped state events](/client-server-api/#stripped-state)
-                          to help the receiver of the invite identify the room.
-                        items:
-                          $ref: "../../event-schemas/schema/core-event-schema/stripped_state.yaml"
-                        example:
-                          $ref: "../../event-schemas/examples/invite_room_state.json"
-          example: {
-            "$ref": "examples/minimal_pdu.json",
-            "type": "m.room.member",
-            "state_key": "@joe:elsewhere.com",
-            "origin": "example.org",
-            "origin_server_ts": 1549041175876,
-            "sender": "@someone:example.org",
-            "content": {
-                "membership": "invite"
-            },
-            "signatures": {
-              "example.com": {
-                "ed25519:key_version": "SomeSignatureHere"
-              },
-            }
-          }
-      responses:
-        200:
-          description: |-
-            The event with the invited server's signature added. All other fields of the events
-            should remain untouched. Note that events have a different format depending on the
-            room version - check the [room version specification](/rooms) for precise event formats.
-          schema:
-            type: array
-            minItems: 2
-            maxItems: 2
-            items:
-              - type: integer
-                description: The value `200`.
-                example: 200
-              - type: object
-                description: An object containing the signed invite event.
-                title: Event Container
-                properties:
-                  event:
-                    $ref: "definitions/invite_event.yaml"
-                required: ['event']
-          examples:
-            application/json: [
-              200,
-              {
-                "event":  {
-                  "$ref": "examples/minimal_pdu.json",
-                  "type": "m.room.member",
-                  "state_key": "@someone:example.org",
-                  "origin": "example.org",
-                  "origin_server_ts": 1549041175876,
-                  "sender": "@someone:example.org",
-                  "unsigned": {
-                    "invite_room_state": {
-                      "$ref": "../../event-schemas/examples/invite_room_state.json"
-                    }
-                  },
-                  "content": {
-                      "membership": "invite"
-                  },
-                  "signatures": {
-                    "example.com": {
-                      "ed25519:key_version": "SomeSignatureHere"
-                    },
-                    "elsewhere.com": {
-                      "ed25519:k3y_versi0n": "SomeOtherSignatureHere"
-                    }
-                  }
-                }
-              }
-            ]
-        403:
-          description: |-
-            The invite is not allowed. This could be for a number of reasons, including:
-
-            * The sender is not allowed to send invites to the target user/homeserver.
-            * The homeserver does not permit anyone to invite its users.
-            * The homeserver refuses to participate in the room.
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "User cannot invite the target user."
-            }
diff --git a/data/api/server-server/invites-v2.yaml b/data/api/server-server/invites-v2.yaml
deleted file mode 100644
index b8b66f13..00000000
--- a/data/api/server-server/invites-v2.yaml
+++ /dev/null
@@ -1,186 +0,0 @@
-# Copyright 2018-2019 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Invite User To Room API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/invite/{roomId}/{eventId}":
-    put:
-      summary: Invites a remote user to a room
-      description: |-
-        **Note:**
-        This API is nearly identical to the v1 API with the exception of the request
-        body being different, and the response format fixed.
-
-        Invites a remote user to a room. Once the event has been  signed by both the inviting
-        homeserver and the invited homeserver, it can be sent to all of the servers in the
-        room by the inviting homeserver.
-
-        This endpoint is preferred over the v1 API as it is more useful for servers. Senders
-        which receive a 400 or 404 response to this endpoint should retry using the v1
-        API as the server may be older, if the room version is "1" or "2".
-
-        Note that events have a different format depending on the room version - check the
-        [room version specification](/rooms) for precise event formats. **The request and response
-        bodies here describe the common event fields in more detail and may be missing other
-        required fields for a PDU.**
-      operationId: sendInviteV2
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID that the user is being invited to.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: path
-          name: eventId
-          type: string
-          description: The event ID for the invite event, generated by the inviting server.
-          required: true
-          x-example: "$abc123:example.org"
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            type: object
-            properties:
-              room_version:
-                type: string
-                description: The version of the room where the user is being invited to.
-                example: "2"
-              event:
-                $ref: "definitions/invite_event.yaml"
-              invite_room_state:
-                type: array
-                description: |-
-                  An optional list of [stripped state events](/client-server-api/#stripped-state)
-                  to help the receiver of the invite identify the room.
-                items:
-                  $ref: "../../event-schemas/schema/core-event-schema/stripped_state.yaml"
-                example:
-                  $ref: "../../event-schemas/examples/invite_room_state.json"
-            required: ['room_version', 'event']
-          example: {
-            "room_version": "2",
-            "event": {
-              "$ref": "examples/minimal_pdu.json",
-              "type": "m.room.member",
-              "state_key": "@joe:elsewhere.com",
-              "origin": "example.org",
-              "origin_server_ts": 1549041175876,
-              "sender": "@someone:example.org",
-              "content": {
-                  "membership": "invite"
-              },
-              "signatures": {
-                "example.com": {
-                  "ed25519:key_version": "SomeSignatureHere"
-                },
-              }
-            }
-          }
-      responses:
-        200:
-          description: |-
-            The event with the invited server's signature added. All other fields of the events
-            should remain untouched. Note that events have a different format depending on the
-            room version - check the [room version specification](/rooms) for precise event formats.
-          schema:
-            type: object
-            description: An object containing the signed invite event.
-            title: Event Container
-            properties:
-              event:
-                $ref: "definitions/invite_event.yaml"
-            required: ['event']
-          examples:
-            application/json: {
-              "event":  {
-                "$ref": "examples/minimal_pdu.json",
-                "type": "m.room.member",
-                "state_key": "@someone:example.org",
-                "origin": "example.org",
-                "origin_server_ts": 1549041175876,
-                "sender": "@someone:example.org",
-                "unsigned": {
-                  "invite_room_state": {
-                    "$ref": "../../event-schemas/examples/invite_room_state.json"
-                  }
-                },
-                "content": {
-                    "membership": "invite"
-                },
-                "signatures": {
-                  "example.com": {
-                    "ed25519:key_version": "SomeSignatureHere"
-                  },
-                  "elsewhere.com": {
-                    "ed25519:k3y_versi0n": "SomeOtherSignatureHere"
-                  }
-                }
-              }
-            }
-        403:
-          description: |-
-            The invite is not allowed. This could be for a number of reasons, including:
-
-            * The sender is not allowed to send invites to the target user/homeserver.
-            * The homeserver does not permit anyone to invite its users.
-            * The homeserver refuses to participate in the room.
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "User cannot invite the target user."
-            }
-        400:
-          description: |-
-            The request is invalid or the room the server is attempting
-            to join has a version that is not listed in the `ver`
-            parameters.
-
-            The error should be passed through to clients so that they
-            may give better feedback to users.
-          schema:
-            allOf:
-              - $ref: "../client-server/definitions/errors/error.yaml"
-              - type: object
-                properties:
-                  room_version:
-                    type: string
-                    description: |-
-                      The version of the room. Required if the `errcode`
-                      is `M_INCOMPATIBLE_ROOM_VERSION`.
-          examples:
-            application/json: {
-              "errcode": "M_INCOMPATIBLE_ROOM_VERSION",
-              "error": "Your homeserver does not support the features required to join this room",
-              "room_version": "3"
-            }
diff --git a/data/api/server-server/joins-v1.yaml b/data/api/server-server/joins-v1.yaml
deleted file mode 100644
index b45a49e2..00000000
--- a/data/api/server-server/joins-v1.yaml
+++ /dev/null
@@ -1,346 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2020 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Join Room API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/make_join/{roomId}/{userId}":
-    get:
-      summary: Get information required to make a join event for a room
-      description: |-
-        Asks the receiving server to return information that the sending
-        server will need to prepare a join event to get into the room.
-      operationId: makeJoin
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID that is about to be joined.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: path
-          name: userId
-          type: string
-          description: The user ID the join event will be for.
-          required: true
-          x-example: "@someone:example.org"
-        - in: query
-          type: array
-          items:
-            type: string
-          name: ver
-          description: |-
-            The room versions the sending server has support for. Defaults
-            to `[1]`.
-          x-example: ["1", "2"]
-      responses:
-        200:
-          description: |-
-            A template to be used for the rest of the [Joining Rooms](/server-server-api/#joining-rooms) handshake. Note that
-            events have a different format depending on the room version - check the
-            [room version specification](/rooms) for precise event formats. **The response body
-            here describes the common event fields in more detail and may be missing other
-            required fields for a PDU.**
-          schema:
-            type: object
-            properties:
-              room_version:
-                type: string
-                description: |-
-                  The version of the room where the server is trying to join. If not provided,
-                  the room version is assumed to be either "1" or "2".
-                example: "2"
-              event:
-                description: |-
-                  An unsigned template event. Note that events have a different format
-                  depending on the room version - check the [room version specification](/rooms)
-                  for precise event formats.
-                type: object
-                title: Event Template
-                properties:
-                  sender:
-                    type: string
-                    description: The user ID of the joining member.
-                    example: "@someone:example.org"
-                  origin:
-                    type: string
-                    description: The name of the resident homeserver.
-                    example: "matrix.org"
-                  origin_server_ts:
-                    type: integer
-                    format: int64
-                    description: A timestamp added by the resident homeserver.
-                    example: 1234567890
-                  type:
-                    type: string
-                    description: The value `m.room.member`.
-                    example: "m.room.member"
-                  state_key:
-                    type: string
-                    description: The user ID of the joining member.
-                    example: "@someone:example.org"
-                  content:
-                    type: object
-                    title: Membership Event Content
-                    description: The content of the event.
-                    example: {"membership": "join"}
-                    properties:
-                      membership:
-                        type: string
-                        description: The value `join`.
-                        example: "join"
-                      join_authorised_via_users_server:
-                        type: string
-                        x-addedInMatrixVersion: "1.2"
-                        description: |-
-                          Required if the room is [restricted](/client-server-api/#restricted-rooms)
-                          and is joining through one of the conditions available. If the
-                          user is responding to an invite, this is not required.
-
-                          An arbitrary user ID belonging to the resident server in
-                          the room being joined that is able to issue invites to other
-                          users. This is used in later validation of the auth rules for
-                          the `m.room.member` event.
-                    required: ['membership']
-                required:
-                  - state_key
-                  - origin
-                  - origin_server_ts
-                  - type
-                  - content
-                  - sender
-          examples:
-            application/json: {
-              "room_version": "2",
-              "event": {
-                "$ref": "examples/minimal_pdu.json",
-                "type": "m.room.member",
-                "state_key": "@someone:example.org",
-                "origin": "example.org",
-                "origin_server_ts": 1549041175876,
-                "sender": "@someone:example.org",
-                "content": {
-                  "membership": "join",
-                  "join_authorised_via_users_server": "@anyone:resident.example.org"
-                }
-              }
-            }
-        400:
-          description: |-
-            The request is invalid, the room the server is attempting
-            to join has a version that is not listed in the `ver`
-            parameters, or the server was unable to validate
-            [restricted room conditions](#restricted-rooms).
-
-            The error should be passed through to clients so that they
-            may give better feedback to users.
-
-            New in `v1.2`, the following error conditions might happen:
-
-            If the room is [restricted](/client-server-api/#restricted-rooms)
-            and none of the conditions can be validated by the server then
-            the `errcode` `M_UNABLE_TO_AUTHORISE_JOIN` must be used. This can
-            happen if the server does not know about any of the rooms listed
-            as conditions, for example.
-
-            `M_UNABLE_TO_GRANT_JOIN` is returned to denote that a different
-            server should be attempted for the join. This is typically because
-            the resident server can see that the joining user satisfies one or
-            more conditions, such as in the case of
-            [restricted rooms](/client-server-api/#restricted-rooms), but the
-            resident server would be unable to meet the auth rules governing
-            `join_authorised_via_users_server` on the resulting `m.room.member`
-            event.
-          schema:
-            allOf:
-              - $ref: "../client-server/definitions/errors/error.yaml"
-              - type: object
-                properties:
-                  room_version:
-                    type: string
-                    description: |-
-                      The version of the room. Required if the `errcode`
-                      is `M_INCOMPATIBLE_ROOM_VERSION`.
-          examples:
-            application/json: {
-              "errcode": "M_INCOMPATIBLE_ROOM_VERSION",
-              "error": "Your homeserver does not support the features required to join this room",
-              "room_version": "3"
-            }
-        403:
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-          description: |-
-            The room that the joining server is attempting to join does not permit the user
-            to join.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "You are not invited to this room",
-            }
-        404:
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-          description: |-
-            The room that the joining server is attempting to join is unknown
-            to the receiving server.
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown room",
-            }
-
-  "/send_join/{roomId}/{eventId}":
-    put:
-      summary: Submit a signed join event to a resident server
-      description: |-
-        **Note:**
-        Servers should instead prefer to use the v2 `/send_join` endpoint.
-
-        Submits a signed join event to the resident server for it
-        to accept it into the room's graph. Note that events have
-        a different format depending on the room version - check
-        the [room version specification](/rooms) for precise event formats.
-        **The request and response body here describe the common
-        event fields in more detail and may be missing other required
-        fields for a PDU.**
-      operationId: sendJoinV1
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID that is about to be joined.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: path
-          name: eventId
-          type: string
-          description: The event ID for the join event.
-          required: true
-          x-example: "$abc123:example.org"
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            type: object
-            properties:
-              sender:
-                type: string
-                description: The user ID of the joining member.
-                example: "@someone:example.org"
-              origin:
-                type: string
-                description: The name of the joining homeserver.
-                example: "matrix.org"
-              origin_server_ts:
-                type: integer
-                format: int64
-                description: A timestamp added by the joining homeserver.
-                example: 1234567890
-              type:
-                type: string
-                description: The value `m.room.member`.
-                example: "m.room.member"
-              state_key:
-                type: string
-                description: The user ID of the joining member.
-                example: "@someone:example.org"
-              content:
-                type: object
-                title: Membership Event Content
-                description: The content of the event.
-                example: {"membership": "join"}
-                properties:
-                  membership:
-                    type: string
-                    description: The value `join`.
-                    example: "join"
-                  join_authorised_via_users_server:
-                    type: string
-                    x-addedInMatrixVersion: "1.2"
-                    description: |-
-                      Required if the room is [restricted](/client-server-api/#restricted-rooms)
-                      and is joining through one of the conditions available. If the
-                      user is responding to an invite, this is not required.
-
-                      An arbitrary user ID belonging to the resident server in
-                      the room being joined that is able to issue invites to other
-                      users. This is used in later validation of the auth rules for
-                      the `m.room.member` event.
-
-                      The resident server which owns the provided user ID must have a
-                      valid signature on the event. If the resident server is receiving
-                      the `/send_join` request, the signature must be added before sending
-                      or persisting the event to other servers.
-                required: ['membership']
-            required:
-              - state_key
-              - sender
-              - origin
-              - origin_server_ts
-              - type
-              - content
-          example: {
-            "$ref": "examples/minimal_pdu.json",
-            "type": "m.room.member",
-            "state_key": "@someone:example.org",
-            "origin": "example.org",
-            "origin_server_ts": 1549041175876,
-            "sender": "@someone:example.org",
-            "content": {
-                "membership": "join",
-                "join_authorised_via_users_server": "@anyone:resident.example.org"
-            }
-          }
-      responses:
-        200:
-          description: |-
-            The join event has been accepted into the room.
-          schema:
-            type: array
-            minItems: 2
-            maxItems: 2
-            items:
-              - type: integer
-                description: The value `200`.
-                example: 200
-              - $ref: "./definitions/send_join_response.yaml"
-          examples:
-            application/json: [
-              200,
-              {
-                "origin": "matrix.org",
-                "auth_chain": [{"$ref": "examples/minimal_pdu.json"}],
-                "state": [{"$ref": "examples/minimal_pdu.json"}],
-                "event": {"$ref": "examples/pdu_v4_join_membership.json"}
-              }
-            ]
diff --git a/data/api/server-server/joins-v2.yaml b/data/api/server-server/joins-v2.yaml
deleted file mode 100644
index 78560c86..00000000
--- a/data/api/server-server/joins-v2.yaml
+++ /dev/null
@@ -1,196 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2020 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Join Room API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  # Note: there is no v2 of make_join (yet)
-  "/send_join/{roomId}/{eventId}":
-    put:
-      summary: Submit a signed join event to a resident server
-      description: |-
-        **Note:**
-        This API is nearly identical to the v1 API with the
-        exception of the response format being fixed.
-
-        This endpoint is preferred over the v1 API as it provides
-        a more standarised response format. Senders which receive
-        a 400, 404, or other status code which indicates this endpoint
-        is not available should retry using the v1 API instead.
-
-        Submits a signed join event to the resident server for it
-        to accept it into the room's graph. Note that events have
-        a different format depending on the room version - check
-        the [room version specification](/rooms) for precise event formats.
-        **The request and response body here describe the common
-        event fields in more detail and may be missing other required
-        fields for a PDU.**
-      operationId: sendJoinV2
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID that is about to be joined.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: path
-          name: eventId
-          type: string
-          description: The event ID for the join event.
-          required: true
-          x-example: "$abc123:example.org"
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            type: object
-            properties:
-              sender:
-                type: string
-                description: The user ID of the joining member.
-                example: "@someone:example.org"
-              origin:
-                type: string
-                description: The name of the joining homeserver.
-                example: "matrix.org"
-              origin_server_ts:
-                type: integer
-                format: int64
-                description: A timestamp added by the joining homeserver.
-                example: 1234567890
-              type:
-                type: string
-                description: The value `m.room.member`.
-                example: "m.room.member"
-              state_key:
-                type: string
-                description: The user ID of the joining member.
-                example: "@someone:example.org"
-              content:
-                type: object
-                title: Membership Event Content
-                description: The content of the event.
-                example: {"membership": "join"}
-                properties:
-                  membership:
-                    type: string
-                    description: The value `join`.
-                    example: "join"
-                  join_authorised_via_users_server:
-                    type: string
-                    x-addedInMatrixVersion: "1.2"
-                    description: |-
-                      Required if the room is [restricted](/client-server-api/#restricted-rooms)
-                      and is joining through one of the conditions available. If the
-                      user is responding to an invite, this is not required.
-
-                      An arbitrary user ID belonging to the resident server in
-                      the room being joined that is able to issue invites to other
-                      users. This is used in later validation of the auth rules for
-                      the `m.room.member` event.
-
-                      The resident server which owns the provided user ID must have a
-                      valid signature on the event. If the resident server is receiving
-                      the `/send_join` request, the signature must be added before sending
-                      or persisting the event to other servers.
-                required: ['membership']
-            required:
-              - state_key
-              - sender
-              - origin
-              - origin_server_ts
-              - type
-              - content
-          example: {
-            "$ref": "examples/minimal_pdu.json",
-            "type": "m.room.member",
-            "state_key": "@someone:example.org",
-            "origin": "example.org",
-            "origin_server_ts": 1549041175876,
-            "sender": "@someone:example.org",
-            "content": {
-                "membership": "join",
-                "join_authorised_via_users_server": "@anyone:resident.example.org"
-            }
-          }
-      responses:
-        400:
-          description: |-
-            The request is invalid in some way.
-
-            The error should be passed through to clients so that they
-            may give better feedback to users.
-
-            New in `v1.2`, the following error conditions might happen:
-
-            If the room is [restricted](/client-server-api/#restricted-rooms)
-            and none of the conditions can be validated by the server then
-            the `errcode` `M_UNABLE_TO_AUTHORISE_JOIN` must be used. This can
-            happen if the server does not know about any of the rooms listed
-            as conditions, for example.
-
-            `M_UNABLE_TO_GRANT_JOIN` is returned to denote that a different
-            server should be attempted for the join. This is typically because
-            the resident server can see that the joining user satisfies one or
-            more conditions, such as in the case of
-            [restricted rooms](/client-server-api/#restricted-rooms), but the
-            resident server would be unable to meet the auth rules governing
-            `join_authorised_via_users_server` on the resulting `m.room.member`
-            event.
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_UNABLE_TO_GRANT_JOIN",
-              "error": "This server cannot send invites to you."
-            }
-        403:
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-          description: |-
-            The room that the joining server is attempting to join does not permit the user
-            to join.
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "You are not invited to this room",
-            }
-        200:
-          description: |-
-            The join event has been accepted into the room.
-          schema:
-            $ref: "./definitions/send_join_response.yaml"
-          examples:
-            application/json: {
-              "origin": "matrix.org",
-              "auth_chain": [{"$ref": "examples/minimal_pdu.json"}],
-              "state": [{"$ref": "examples/minimal_pdu.json"}],
-              "event": {"$ref": "examples/pdu_v4_join_membership.json"}
-            }
diff --git a/data/api/server-server/keys_query.yaml b/data/api/server-server/keys_query.yaml
deleted file mode 100644
index cad6b882..00000000
--- a/data/api/server-server/keys_query.yaml
+++ /dev/null
@@ -1,133 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Key Exchange API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/key/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-paths:
-  "/query/{serverName}/{keyId}":
-    get:
-      summary: Query for another server's keys
-      description: |-
-        Query for another server's keys. The receiving (notary) server must
-        sign the keys returned by the queried server.
-      operationId: perspectivesKeyQuery
-      parameters:
-        - in: path
-          name: serverName
-          type: string
-          description: The server's DNS name to query
-          required: true
-          x-example: matrix.org
-        - in: path
-          name: keyId
-          type: string
-          description: |-
-            **Deprecated**. Servers should not use this parameter and instead
-            opt to return all keys, not just the requested one. The key ID to
-            look up.
-
-            When excluded, the trailing slash on this endpoint is optional.
-          required: false
-          x-example: "ed25519:abc123"
-        - in: query
-          name: minimum_valid_until_ts
-          type: integer
-          format: int64
-          description: |-
-            A millisecond POSIX timestamp in milliseconds indicating when the returned
-            certificates will need to be valid until to be useful to the requesting server.
-
-            If not supplied, the current time as determined by the notary server is used.
-          required: false
-          x-example: 1234567890
-      responses:
-        200:
-          description: |-
-            The keys for the server, or an empty array if the server could not be reached
-            and no cached keys were available.
-          schema:
-            $ref: "definitions/keys_query_response.yaml"
-  "/query":
-    post:
-      summary: Query for several server's keys
-      description: |-
-        Query for keys from multiple servers in a batch format. The receiving (notary)
-        server must sign the keys returned by the queried servers.
-      operationId: bulkPerspectivesKeyQuery
-      parameters:
-        - in: body
-          name: body
-          schema:
-            type: object
-            example: {
-              "server_keys": {
-                "example.org": {
-                  "ed25519:abc123": {
-                    "minimum_valid_until_ts": 1234567890
-                  }
-                }
-              }
-            }
-            properties:
-              server_keys:
-                type: object
-                description: |-
-                  The query criteria. The outer `string` key on the object is the
-                  server name (eg: `matrix.org`). The inner `string` key is the
-                  Key ID to query for the particular server. If no key IDs are given
-                  to be queried, the notary server should query for all keys. If no
-                  servers are given, the notary server must return an empty `server_keys`
-                  array in the response.
-
-                  The notary server may return multiple keys regardless of the Key IDs
-                  given.
-                additionalProperties:
-                  type: object
-                  name: ServerName
-                  description: The server names to query.
-                  additionalProperties:
-                    type: object
-                    title: Query Criteria
-                    description: The server key IDs to query.
-                    properties:
-                      minimum_valid_until_ts:
-                        type: integer
-                        format: int64
-                        description: |-
-                          A millisecond POSIX timestamp in milliseconds indicating when
-                          the returned certificates will need to be valid until to be
-                          useful to the requesting server.
-
-                          If not supplied, the current time as determined by the notary
-                          server is used.
-                        example: 1234567890
-            required: ['server_keys']
-      responses:
-        200:
-          description: |-
-            The keys for the queried servers, signed by the notary server. Servers which
-            are offline and have no cached keys will not be included in the result. This
-            may result in an empty array.
-          schema:
-            $ref: "definitions/keys_query_response.yaml"
diff --git a/data/api/server-server/keys_server.yaml b/data/api/server-server/keys_server.yaml
deleted file mode 100644
index 81b98b1e..00000000
--- a/data/api/server-server/keys_server.yaml
+++ /dev/null
@@ -1,63 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Key Exchange API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/key/v2
-produces:
-  - application/json
-paths:
-  "/server/{keyId}":
-    get:
-      summary: Get the homeserver's public key(s)
-      description: |-
-        Gets the homeserver's published signing keys.
-        The homeserver may have any number of active keys and may have a
-        number of old keys.
-
-        Intermediate notary servers should cache a response for half of its
-        lifetime to avoid serving a stale response. Originating servers should
-        avoid returning responses that expire in less than an hour to avoid
-        repeated requests for a certificate that is about to expire. Requesting
-        servers should limit how frequently they query for certificates to
-        avoid flooding a server with requests.
-
-        If the server fails to respond to this request, intermediate notary
-        servers should continue to return the last response they received
-        from the server so that the signatures of old events can still be
-        checked.
-      operationId: getServerKey
-      parameters:
-        - in: path
-          name: keyId
-          type: string
-          description: |-
-            **Deprecated**. Servers should not use this parameter and instead
-            opt to return all keys, not just the requested one. The key ID to
-            look up.
-
-            When excluded, the trailing slash on this endpoint is optional.
-          required: false
-          x-example: "ed25519:abc123"
-          deprecated: true
-      responses:
-        200:
-          description: The homeserver's keys
-          schema:
-            $ref: "definitions/keys.yaml"
diff --git a/data/api/server-server/knocks.yaml b/data/api/server-server/knocks.yaml
deleted file mode 100644
index 2ef5ceaa..00000000
--- a/data/api/server-server/knocks.yaml
+++ /dev/null
@@ -1,323 +0,0 @@
-# Copyright 2021 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Knock Room API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/make_knock/{roomId}/{userId}":
-    get:
-      x-addedInMatrixVersion: "1.1"
-      summary: Get information required to make a knock event for a room.
-      description: |-
-        Asks the receiving server to return information that the sending
-        server will need to prepare a knock event for the room.
-      operationId: makeKnock
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID that is about to be knocked.
-          required: true
-          x-example: "!abc123:example.org"
-        - in: path
-          name: userId
-          type: string
-          description: The user ID the knock event will be for.
-          required: true
-          x-example: "@someone:example.org"
-        - in: query
-          type: array
-          items:
-            type: string
-          name: ver
-          description: |-
-            The room versions the sending server has support for.
-          required: true  # knocking was supported in v7
-          x-example: ["1", "7"]
-      responses:
-        200:
-          description: |-
-            A template to be used for the rest of the [Knocking Rooms](/server-server-api/#knocking-rooms)
-            handshake. Note that events have a different format depending on room version - check the
-            [room version specification](/rooms) for precise event formats. **The response body
-            here describes the common event fields in more detail and may be missing other
-            required fields for a PDU.**
-          schema:
-            type: object
-            properties:
-              room_version:
-                type: string
-                description: |-
-                  The version of the room where the server is trying to knock.
-                example: "7"
-              event:
-                description: |-
-                  An unsigned template event. Note that events have a different format
-                  depending on the room version - check the [room version specification](/rooms)
-                  for precise event formats.
-                type: object
-                title: Event Template
-                properties:
-                  sender:
-                    type: string
-                    description: The user ID of the knocking member.
-                    example: "@someone:example.org"
-                  origin:
-                    type: string
-                    description: The name of the resident homeserver.
-                    example: "matrix.org"
-                  origin_server_ts:
-                    type: integer
-                    format: int64
-                    description: A timestamp added by the resident homeserver.
-                    example: 1234567890
-                  type:
-                    type: string
-                    description: The value `m.room.member`.
-                    example: "m.room.member"
-                  state_key:
-                    type: string
-                    description: The user ID of the knocking member.
-                    example: "@someone:example.org"
-                  content:
-                    type: object
-                    title: Membership Event Content
-                    description: The content of the event.
-                    example: {"membership": "knock"}
-                    properties:
-                      membership:
-                        type: string
-                        description: The value `knock`.
-                        example: "knock"
-                    required: ['membership']
-                required:
-                  - state_key
-                  - origin
-                  - origin_server_ts
-                  - type
-                  - content
-                  - sender
-            required:
-              - room_version  # knocking was added in v7
-              - event
-          examples:
-            application/json: {
-              "room_version": "7",
-              "event": {
-                "$ref": "examples/minimal_pdu.json",
-                "type": "m.room.member",
-                "state_key": "@someone:example.org",
-                "origin": "example.org",
-                "origin_server_ts": 1549041175876,
-                "sender": "@someone:example.org",
-                "content": {
-                  "membership": "knock"
-                }
-              }
-            }
-        400:
-          description: |-
-            The request is invalid or the room the server is attempting
-            to knock upon has a version that is not listed in the `ver`
-            parameters.
-
-            The error should be passed through to clients so that they
-            may give better feedback to users.
-          schema:
-            allOf:
-              - $ref: "../client-server/definitions/errors/error.yaml"
-              - type: object
-                properties:
-                  room_version:
-                    type: string
-                    description: |-
-                      The version of the room. Required if the `errcode`
-                      is `M_INCOMPATIBLE_ROOM_VERSION`.
-          examples:
-            application/json: {
-              "errcode": "M_INCOMPATIBLE_ROOM_VERSION",
-              "error": "Your homeserver does not support the features required to knock on this room",
-              "room_version": "7"
-            }
-        404:
-          description: |-
-            The room that the knocking server is attempting to knock upon is unknown
-            to the receiving server.
-          schema:
-            allOf:
-              - $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown room",
-            }
-        403:
-          description: |-
-            The knocking server or user is not permitted to knock on the room, such as when the
-            server/user is banned or the room is not set up for receiving knocks.
-          schema:
-            allOf:
-              - $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "You are not permitted to knock on this room",
-            }
-
-  "/send_knock/{roomId}/{eventId}":
-    put:
-      x-addedInMatrixVersion: "1.1"
-      summary: Submit a signed knock event to a resident server.
-      description: |-
-        Submits a signed knock event to the resident server for it to
-        accept into the room's graph. Note that events have
-        a different format depending on the room version - check
-        the [room version specification](/rooms) for precise event formats.
-        **The request and response body here describe the common
-        event fields in more detail and may be missing other required
-        fields for a PDU.**
-      operationId: sendKnock
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID that is about to be knocked upon.
-          required: true
-          x-example: "!abc123:example.org"
-        - in: path
-          name: eventId
-          type: string
-          description: The event ID for the knock event.
-          required: true
-          x-example: "$abc123:example.org"
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            type: object
-            properties:
-              sender:
-                type: string
-                description: The user ID of the knocking member.
-                example: "@someone:example.org"
-              origin:
-                type: string
-                description: The name of the knocking homeserver.
-                example: "matrix.org"
-              origin_server_ts:
-                type: integer
-                format: int64
-                description: A timestamp added by the knocking homeserver.
-                example: 1234567890
-              type:
-                type: string
-                description: The value `m.room.member`.
-                example: "m.room.member"
-              state_key:
-                type: string
-                description: The user ID of the knocking member.
-                example: "@someone:example.org"
-              content:
-                type: object
-                title: Membership Event Content
-                description: The content of the event.
-                example: {"membership": "knock"}
-                properties:
-                  membership:
-                    type: string
-                    description: The value `knock`.
-                    example: "knock"
-                required: ['membership']
-            required:
-              - state_key
-              - sender
-              - origin
-              - origin_server_ts
-              - type
-              - content
-          example: {
-            "$ref": "examples/minimal_pdu.json",
-            "type": "m.room.member",
-            "state_key": "@someone:example.org",
-            "origin": "example.org",
-            "origin_server_ts": 1549041175876,
-            "sender": "@someone:example.org",
-            "content": {
-                "membership": "knock"
-            }
-          }
-      responses:
-        200:
-          description: |-
-            Information about the room to pass along to clients regarding the
-            knock.
-          schema:
-            type: object
-            properties:
-              knock_room_state:
-                type: array
-                items:
-                  $ref: "../../event-schemas/schema/core-event-schema/stripped_state.yaml"
-                description: |-
-                  An optional list of [stripped state events](/client-server-api/#stripped-state)
-                  to help the initiator of the knock identify the room.
-                example:
-                  $ref: "../../event-schemas/examples/knock_room_state.json"
-            required: ['knock_room_state']
-          examples:
-            application/json: {
-              "knock_room_state": {"$ref": "../../event-schemas/examples/knock_room_state.json"}
-            }
-        404:
-          description: |-
-            The room that the knocking server is attempting to knock upon is unknown
-            to the receiving server.
-          schema:
-            allOf:
-              - $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Unknown room",
-            }
-        403:
-          description: |-
-            The knocking server or user is not permitted to knock on the room, such as when the
-            server/user is banned or the room is not set up for receiving knocks.
-          schema:
-            allOf:
-              - $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "You are not permitted to knock on this room",
-            }
-
diff --git a/data/api/server-server/leaving-v1.yaml b/data/api/server-server/leaving-v1.yaml
deleted file mode 100644
index df314d5a..00000000
--- a/data/api/server-server/leaving-v1.yaml
+++ /dev/null
@@ -1,251 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2020 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Leave Room API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/make_leave/{roomId}/{userId}":
-    get:
-      summary: Get information required to make a leave event for a room
-      description: |-
-        Asks the receiving server to return information that the sending
-        server will need to prepare a leave event to get out of the room.
-      operationId: makeLeave
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID that is about to be left.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: path
-          name: userId
-          type: string
-          description: The user ID the leave event will be for.
-          required: true
-          x-example: "@someone:example.org"
-      responses:
-        200:
-          description: |-
-            A template to be used to call `/send_leave`. Note that
-            events have a different format depending on the room version - check the
-            [room version specification](/rooms) for precise event formats. **The response body
-            here describes the common event fields in more detail and may be missing other
-            required fields for a PDU.**
-          schema:
-            type: object
-            properties:
-              room_version:
-                type: string
-                description: |-
-                  The version of the room where the server is trying to leave. If not provided,
-                  the room version is assumed to be either "1" or "2".
-                example: "2"
-              event:
-                description: |-
-                  An unsigned template event. Note that events have a different format
-                  depending on the room version - check the [room version specification](/rooms)
-                  for precise event formats.
-                type: object
-                title: Event Template
-                properties:
-                  sender:
-                    type: string
-                    description: The user ID of the leaving member.
-                    example: "@someone:example.org"
-                  origin:
-                    type: string
-                    description: The name of the resident homeserver.
-                    example: "matrix.org"
-                  origin_server_ts:
-                    type: integer
-                    format: int64
-                    description: A timestamp added by the resident homeserver.
-                    example: 1234567890
-                  type:
-                    type: string
-                    description: The value `m.room.member`.
-                    example: "m.room.member"
-                  state_key:
-                    type: string
-                    description: The user ID of the leaving member.
-                    example: "@someone:example.org"
-                  content:
-                    type: object
-                    title: Membership Event Content
-                    description: The content of the event.
-                    example: {"membership": "leave"}
-                    properties:
-                      membership:
-                        type: string
-                        description: The value `leave`.
-                        example: "leave"
-                    required: ['membership']
-                required:
-                  - state_key
-                  - sender
-                  - origin
-                  - origin_server_ts
-                  - type
-                  - content
-          examples:
-            application/json: {
-              "room_version": "2",
-              "event": {
-                "$ref": "examples/minimal_pdu.json",
-                "type": "m.room.member",
-                "state_key": "@someone:example.org",
-                "origin": "example.org",
-                "origin_server_ts": 1549041175876,
-                "sender": "@someone:example.org",
-                "content": {
-                  "membership": "leave"
-                }
-              }
-            }
-        403:
-          description: |-
-            The request is not authorized. This could mean that the user is not in the room.
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_FORBIDDEN",
-              "error": "User is not in the room."
-            }
-  "/send_leave/{roomId}/{eventId}":
-    put:
-      summary: Submit a signed leave event to a resident server
-      description: |-
-        **Note:**
-        Servers should instead prefer to use the v2 `/send_leave` endpoint.
-
-        Submits a signed leave event to the resident server for it
-        to accept it into the room's graph. Note that events have
-        a different format depending on the room version - check
-        the [room version specification](/rooms) for precise event formats.
-        **The request and response body here describe the common
-        event fields in more detail and may be missing other required
-        fields for a PDU.**
-      operationId: sendLeaveV1
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID that is about to be left.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: path
-          name: eventId
-          type: string
-          description: The event ID for the leave event.
-          required: true
-          x-example: "$abc123:example.org"
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            type: object
-            properties:
-              sender:
-                type: string
-                description: The user ID of the leaving member.
-                example: "@someone:example.org"
-              origin:
-                type: string
-                description: The name of the leaving homeserver.
-                example: "matrix.org"
-              origin_server_ts:
-                type: integer
-                format: int64
-                description: A timestamp added by the leaving homeserver.
-                example: 1234567890
-              type:
-                type: string
-                description: The value `m.room.member`.
-                example: "m.room.member"
-              state_key:
-                type: string
-                description: The user ID of the leaving member.
-                example: "@someone:example.org"
-              content:
-                type: object
-                title: Membership Event Content
-                description: The content of the event.
-                example: {"membership": "leave"}
-                properties:
-                  membership:
-                    type: string
-                    description: The value `leave`.
-                    example: "leave"
-                required: ['membership']
-              depth:
-                type: integer
-                description: This field must be present but is ignored; it may be 0.
-                example: 12
-            required:
-              - state_key
-              - sender
-              - origin
-              - origin_server_ts
-              - type
-              - depth
-              - content
-          example: {
-            "$ref": "examples/minimal_pdu.json",
-            "type": "m.room.member",
-            "state_key": "@someone:example.org",
-            "origin": "example.org",
-            "origin_server_ts": 1549041175876,
-            "sender": "@someone:example.org",
-            "content": {
-                "membership": "leave"
-            }
-          }
-      responses:
-        200:
-          description: |-
-            An empty response to indicate the event was accepted into the graph by
-            the receiving homeserver.
-          schema:
-            type: array
-            minItems: 2
-            maxItems: 2
-            items:
-              - type: integer
-                description: The value `200`.
-                example: 200
-              - type: object
-                title: Empty Object
-                description: An empty object.
-          examples:
-            application/json: [200, {}]
diff --git a/data/api/server-server/leaving-v2.yaml b/data/api/server-server/leaving-v2.yaml
deleted file mode 100644
index e3b8f089..00000000
--- a/data/api/server-server/leaving-v2.yaml
+++ /dev/null
@@ -1,140 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2020 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Leave Room API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v2
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  # Note: there is no v2 of make_leave (yet)
-  "/send_leave/{roomId}/{eventId}":
-    put:
-      summary: Submit a signed leave event to a resident server
-      description: |-
-        **Note:**
-        This API is nearly identical to the v1 API with the
-        exception of the response format being fixed.
-
-        This endpoint is preferred over the v1 API as it provides
-        a more standarised response format. Senders which receive
-        a 400, 404, or other status code which indicates this endpoint
-        is not available should retry using the v1 API instead.
-
-        Submits a signed leave event to the resident server for it
-        to accept it into the room's graph. Note that events have
-        a different format depending on the room version - check
-        the [room version specification](/rooms) for precise event formats.
-        **The request and response body here describe the common
-        event fields in more detail and may be missing other required
-        fields for a PDU.**
-      operationId: sendLeaveV2
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID that is about to be left.
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: path
-          name: eventId
-          type: string
-          description: The event ID for the leave event.
-          required: true
-          x-example: "$abc123:example.org"
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            type: object
-            properties:
-              sender:
-                type: string
-                description: The user ID of the leaving member.
-                example: "@someone:example.org"
-              origin:
-                type: string
-                description: The name of the leaving homeserver.
-                example: "matrix.org"
-              origin_server_ts:
-                type: integer
-                format: int64
-                description: A timestamp added by the leaving homeserver.
-                example: 1234567890
-              type:
-                type: string
-                description: The value `m.room.member`.
-                example: "m.room.member"
-              state_key:
-                type: string
-                description: The user ID of the leaving member.
-                example: "@someone:example.org"
-              content:
-                type: object
-                title: Membership Event Content
-                description: The content of the event.
-                example: {"membership": "leave"}
-                properties:
-                  membership:
-                    type: string
-                    description: The value `leave`.
-                    example: "leave"
-                required: ['membership']
-              depth:
-                type: integer
-                description: This field must be present but is ignored; it may be 0.
-                example: 12
-            required:
-              - state_key
-              - sender
-              - origin
-              - origin_server_ts
-              - type
-              - depth
-              - content
-          example: {
-            "$ref": "examples/minimal_pdu.json",
-            "type": "m.room.member",
-            "state_key": "@someone:example.org",
-            "origin": "example.org",
-            "origin_server_ts": 1549041175876,
-            "sender": "@someone:example.org",
-            "content": {
-                "membership": "leave"
-            }
-          }
-      responses:
-        200:
-          description: |-
-            An empty response to indicate the event was accepted into the graph by
-            the receiving homeserver.
-          schema:
-            type: object
-            title: Empty Object
-            description: An empty object.
-          examples:
-            application/json: {}
diff --git a/data/api/server-server/openid.yaml b/data/api/server-server/openid.yaml
deleted file mode 100644
index 0761618d..00000000
--- a/data/api/server-server/openid.yaml
+++ /dev/null
@@ -1,63 +0,0 @@
-# Copyright 2017 Kamax.io
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation OpenID API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-produces:
-  - application/json
-paths:
-  "/openid/userinfo":
-    get:
-      summary: Exchange an OpenID token for user information
-      description: |-
-        Exchanges an OpenID access token for information about the user
-        who generated the token. Currently this only exposes the Matrix
-        User ID of the owner.
-      operationId: exchangeOpenIdToken
-      parameters:
-        - in: query
-          name: access_token
-          type: string
-          description: |-
-            The OpenID access token to get information about the owner for.
-          required: true
-          x-example: SomeT0kenHere
-      responses:
-        200:
-          description: |-
-            Information about the user who generated the OpenID access token.
-          schema:
-            type: object
-            properties:
-              sub:
-                type: string
-                description: The Matrix User ID who generated the token.
-                example: "@alice:example.com"
-            required: ['sub']
-        401:
-          description: The token was not recognized or has expired.
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_UNKNOWN_TOKEN",
-              "error": "Access token unknown or expired"
-            }
diff --git a/data/api/server-server/public_rooms.yaml b/data/api/server-server/public_rooms.yaml
deleted file mode 100644
index ba949bcc..00000000
--- a/data/api/server-server/public_rooms.yaml
+++ /dev/null
@@ -1,194 +0,0 @@
-# Copyright 2018, 2021 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Public Rooms API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/publicRooms":
-    get:
-      summary: Get all the public rooms for a homeserver
-      description: |-
-        Gets all the public rooms for the homeserver. This should not return
-        rooms that are listed on another homeserver's directory, just those
-        listed on the receiving homeserver's directory.
-      operationId: getPublicRooms
-      security:
-        - signedRequest: []
-      parameters:
-        - in: query
-          name: limit
-          type: integer
-          description: |-
-            The maximum number of rooms to return. Defaults to 0 (no limit).
-          x-example: 10
-        - in: query
-          name: since
-          type: string
-          description: |-
-            A pagination token from a previous call to this endpoint to fetch more
-            rooms.
-          x-example: "GetMoreRoomsTokenHere"
-        - in: query
-          name: include_all_networks
-          type: boolean
-          description: |-
-            Whether or not to include all networks/protocols defined by application
-            services on the homeserver. Defaults to false.
-          x-example: false
-        - in: query
-          name: third_party_instance_id
-          type: string
-          description: |-
-            The specific third party network/protocol to request from the homeserver.
-            Can only be used if `include_all_networks` is false.
-          x-example: "irc"
-      responses:
-        200:
-          description: The public room list for the homeserver.
-          schema:
-            $ref: "../client-server/definitions/public_rooms_response.yaml"
-    post:
-      summary: Gets the public rooms on the server with optional filter.
-      description: |-
-        Lists the public rooms on the server, with optional filter.
-
-        This API returns paginated responses. The rooms are ordered by the number
-        of joined members, with the largest rooms first.
-
-        Note that this endpoint receives and returns the same format that is seen
-        in the Client-Server API's `POST /publicRooms` endpoint.
-      operationId: queryPublicRooms
-      security:
-        - signedRequest: []
-      parameters:
-        - in: body
-          name: body
-          required: true
-          description: |-
-            Options for which rooms to return, or empty object to use defaults.
-          schema:
-            type: object
-            properties:
-              limit:
-                type: integer
-                description: |-
-                  Limit the number of results returned.
-              since:
-                type: string
-                description: |-
-                  A pagination token from a previous request, allowing servers
-                  to get the next (or previous) batch of rooms.  The direction
-                  of pagination is specified solely by which token is supplied,
-                  rather than via an explicit flag.
-              filter:
-                type: object
-                title: "Filter"
-                description: |-
-                  Filter to apply to the results.
-                properties:
-                    generic_search_term:
-                      type: string
-                      description: |-
-                        A string to search for in the room metadata, e.g. name,
-                        topic, canonical alias etc. (Optional).
-              include_all_networks:
-                type: boolean
-                description: |-
-                  Whether or not to include all known networks/protocols from
-                  application services on the homeserver. Defaults to false.
-                example: false
-              third_party_instance_id:
-                type: string
-                description: |-
-                  The specific third party network/protocol to request from the
-                  homeserver. Can only be used if `include_all_networks` is false.
-                example: "irc"
-            example: {
-              "limit": 10,
-              "filter": {
-                "generic_search_term": "foo"
-              },
-              "include_all_networks": false,
-              "third_party_instance_id": "irc"
-            }
-      responses:
-        200:
-          description: A list of the rooms on the server.
-          schema:
-            type: object
-            description: A list of the rooms on the server.
-            required: ["chunk"]
-            properties:
-              chunk:
-                title: "PublicRoomsChunks"
-                type: array
-                description: A paginated chunk of public rooms.
-                items:
-                  allOf:
-                    - $ref: "../client-server/definitions/public_rooms_chunk.yaml"
-                    - type: object
-                      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.
-              next_batch:
-                type: string
-                description: |-
-                  A pagination token for the response. The absence of this token
-                  means there are no more results to fetch and the client should
-                  stop paginating.
-              prev_batch:
-                type: string
-                description: |-
-                  A pagination token that allows fetching previous results. The
-                  absence of this token means there are no results before this
-                  batch, i.e. this is the first batch.
-              total_room_count_estimate:
-                type: integer
-                description: |-
-                   An estimate on the total number of public rooms, if the
-                   server has an estimate.
-          examples:
-            application/json: {
-              "chunk": [
-                {
-                  "avatar_url": "mxc://bleecker.street/CHEDDARandBRIE",
-                  "guest_can_join": false,
-                  "name": "CHEESE",
-                  "num_joined_members": 37,
-                  "room_id": "!ol19s:bleecker.street",
-                  "topic": "Tasty tasty cheese",
-                  "world_readable": true,
-                  "join_rule": "public"
-                }
-              ],
-              "next_batch": "p190q",
-              "prev_batch": "p1902",
-              "total_room_count_estimate": 115
-            }
diff --git a/data/api/server-server/query.yaml b/data/api/server-server/query.yaml
deleted file mode 100644
index 42b64ea8..00000000
--- a/data/api/server-server/query.yaml
+++ /dev/null
@@ -1,175 +0,0 @@
-# Copyright 2017 Kamax.io
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Query API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/query/{queryType}":
-    get:
-      summary: Query for information
-      description: |-
-        Performs a single query request on the receiving homeserver. The query string
-        arguments are dependent on which type of query is being made. Known query types
-        are specified as their own endpoints as an extension to this definition.
-      operationId: queryInfo
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: queryType
-          type: string
-          description: The type of query to make
-          required: true
-          x-example: profile
-      responses:
-        200:
-          description: |-
-            The query response. The schema varies depending on the query being made.
-  "/query/directory":
-    get:
-      summary: Query for the room ID and resident homeservers for a room alias
-      description: |-
-        Performs a query to get the mapped room ID and list of resident homeservers in
-        the room for a given room alias. Homeservers should only query room aliases
-        that belong to the target server (identified by the DNS Name in the alias).
-
-        Servers may wish to cache the response to this query to avoid requesting the
-        information too often.
-      operationId: queryRoomDirectory
-      security:
-        - signedRequest: []
-      parameters:
-        - in: query
-          name: room_alias
-          type: string
-          description: The room alias to query.
-          required: true
-          x-example: "#room_alias:example.org"
-      responses:
-        200:
-          description: |-
-            The corresponding room ID and list of known resident homeservers for the room.
-          schema:
-            type: object
-            properties:
-              room_id:
-                type: string
-                description: The room ID mapped to the queried room alias.
-                x-example: "!roomid1234:example.org"
-              servers:
-                type: array
-                description: |-
-                  An array of server names that are likely to hold the given room. This
-                  list may or may not include the server answering the query.
-                items:
-                  type: string
-            required:
-              - "room_id"
-              - "servers"
-          examples:
-            application/json: {
-              "room_id": "!roomid1234:example.org",
-              "servers": [
-                "example.org",
-                "example.com",
-                "another.example.com:8449",
-              ]
-            }
-        404:
-          description: The room alias was not found.
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Room alias not found."
-            }
-  "/query/profile":
-    get:
-      summary: Query for profile information about a given user
-      description: |-
-        Performs a query to get profile information, such as a display name or avatar,
-        for a given user. Homeservers should only query profiles for users that belong
-        to the target server (identified by the DNS Name in the user ID).
-
-        Servers may wish to cache the response to this query to avoid requesting the
-        information too often.
-      operationId: queryProfile
-      security:
-        - signedRequest: []
-      parameters:
-        - in: query
-          name: user_id
-          type: string
-          description: The user ID to query.
-          required: true
-          x-example: "@someone:example.org"
-        - in: query
-          name: field
-          type: string
-          enum: ['displayname', 'avatar_url']
-          description: |-
-            The field to query. If specified, the server will only return the given field
-            in the response. If not specified, the server will return the full profile for
-            the user.
-      responses:
-        200:
-          description: |-
-            The profile for the user. If a `field` is specified in the request, only the
-            matching field should be included in the response. If no `field` was specified,
-            the response should include the fields of the user's profile that can be made
-            public, such as the display name and avatar.
-
-            If the user does not have a particular field set on their profile, the server
-            should exclude it from the response body or give it the value `null`.
-          schema:
-            type: object
-            properties:
-              displayname:
-                type: string
-                description: |-
-                  The display name of the user. May be omitted if the user does not have a
-                  display name set.
-                x-example: "John Doe"
-              avatar_url:
-                type: string
-                description: |-
-                  The avatar URL for the user's avatar. May be omitted if the user does not
-                  have an avatar set.
-                x-example: "mxc://matrix.org/MyC00lAvatar"
-          examples:
-            application/json: {
-              "displayname": "John Doe",
-              "avatar_url": "mxc://matrix.org/MyC00lAvatar"
-            }
-        404:
-          description: The user does not exist or does not have a profile.
-          schema:
-            $ref: "../client-server/definitions/errors/error.yaml"
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "User does not exist."
-            }
diff --git a/data/api/server-server/space_hierarchy.yaml b/data/api/server-server/space_hierarchy.yaml
deleted file mode 100644
index cb30fa0f..00000000
--- a/data/api/server-server/space_hierarchy.yaml
+++ /dev/null
@@ -1,207 +0,0 @@
-# Copyright 2021 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.
-swagger: '2.0'
-info:
-  title: "Matrix Federation Space Hierarchy API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/hierarchy/{roomId}":
-    get:
-      x-addedInMatrixVersion: "1.2"
-      summary: Retrieve a portion of a space tree.
-      description: |-
-        Federation version of the Client-Server [`GET /hierarchy`](/client-server-api/#get_matrixclientv1roomsroomidhierarchy)
-        endpoint. Unlike the Client-Server API version, this endpoint does not paginate. Instead, all
-        the space-room's children the requesting server could feasibly peek/join are returned. The
-        requesting server is responsible for filtering the results further down for the user's request.
-
-        Only [`m.space.child`](#mspacechild) state events of the room are considered. Invalid child
-        rooms and parent events are not covered by this endpoint.
-
-        Responses to this endpoint should be cached for a period of time.
-      operationId: getSpaceHierarchy
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          type: string
-          name: roomId
-          description: The room ID of the space to get a hierarchy for.
-          required: true
-          x-example: "!space:example.org"
-        - in: query
-          type: boolean
-          name: suggested_only
-          description: |-
-            Optional (default `false`) flag to indicate whether or not the server should only consider
-            suggested rooms. Suggested rooms are annotated in their [`m.space.child`](#mspacechild) event
-            contents.
-          x-example: true
-      responses:
-        200:
-          description: |-
-            The space room and its children.
-          examples:
-            application/json: {
-              "room": {
-                "room_id": "!space:example.org",
-                "avatar_url": "mxc://example.org/abcdef",
-                "guest_can_join": false,
-                "name": "The First Space",
-                "topic": "No other spaces were created first, ever",
-                "world_readable": true,
-                "join_rule": "public",
-                "room_type": "m.space",
-                "num_joined_members": 42,
-                "canonical_alias": "#general:example.org",
-                "allowed_room_ids": [],
-                "children_state": [
-                  {
-                    "type": "m.space.child",
-                    "state_key": "!a:example.org",
-                    "content": {
-                      "via": ["remote.example.org"]
-                    },
-                    "sender": "@alice:example.org",
-                    "origin_server_ts": 1629413349153
-                  }
-                ]
-              },
-              "inaccessible_children": [
-                "!secret:example.org"
-              ],
-              "children": [
-                {
-                  "room_id": "!second_room:example.org",
-                  "avatar_url": "mxc://example.org/abcdef2",
-                  "guest_can_join": false,
-                  "name": "The ~~First~~ Second Space",
-                  "topic": "Hello world",
-                  "world_readable": true,
-                  "join_rule": "restricted",
-                  "room_type": "m.space",
-                  "num_joined_members": 42,
-                  "canonical_alias": "#general:example.org",
-                  "allowed_room_ids": [
-                    "!upstream:example.org"
-                  ],
-                  "children_state": [
-                    {
-                      "type": "m.space.child",
-                      "state_key": "!b:example.org",
-                      "content": {
-                        "via": ["remote.example.org"]
-                      },
-                      "sender": "@alice:example.org",
-                      "origin_server_ts": 1629422222222
-                    }
-                  ]
-                }
-              ]
-            }
-          schema:
-            type: object
-            properties:
-              room:
-                description: A summary of the room requested.
-                allOf:
-                  - $ref: "../client-server/definitions/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
-                        description: |-
-                          If the room is a [restricted room](#restricted-rooms), these are the room IDs which
-                          are specified by the join rules. Empty or omitted otherwise.
-                      children_state:
-                        type: array
-                        description: |-
-                          The [`m.space.child`](/client-server-api/#mspacechild) events of the space-room, represented
-                          as [Stripped State Events](/client-server-api/#stripped-state) with an added
-                          `origin_server_ts` key.
-
-                          If the room is not a space-room, this should be empty.
-                        items:
-                          allOf:
-                            - $ref: "../../event-schemas/schema/core-event-schema/stripped_state.yaml"
-                            - type: object
-                              properties:
-                                origin_server_ts:
-                                  type: number
-                                  format: int64
-                                  description: The `origin_server_ts` for the event.
-                              required: [origin_server_ts]
-                    required: [room_type, allowed_room_ids, children_state]
-              children:
-                type: array
-                description: |-
-                  A summary of the space's children. Rooms which the requesting server cannot peek/join will
-                  be excluded.
-                items:
-                  allOf:
-                    - $ref: "../client-server/definitions/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
-                          description: |-
-                            If the room is a [restricted room](#restricted-rooms), these are the room IDs which
-                            are specified by the join rules. Empty or omitted otherwise.
-                      required: [room_type, allowed_room_ids, children_state]
-              inaccessible_children:
-                type: array
-                items:
-                  type: string
-                description: |-
-                  The list of room IDs the requesting server doesn't have a viable way to peek/join. Rooms which
-                  the responding server cannot provide details on will be outright excluded from the response instead.
-
-                  Assuming both the requesting and responding server are well behaved, the requesting server should
-                  consider these room IDs as not accessible from anywhere. They should not be re-requested.
-            required: [room, children, inaccessible_children]
-        404:
-          description: |-
-            The room is not known to the server or the requesting server is unable to peek/join
-            it (if it were to attempt this).
-          examples:
-            application/json: {
-              "errcode": "M_NOT_FOUND",
-              "error": "Room does not exist."
-            }
-          schema:
-            "$ref": "../client-server/definitions/errors/error.yaml"
-      tags:
-        - Spaces
diff --git a/data/api/server-server/third_party_invite.yaml b/data/api/server-server/third_party_invite.yaml
deleted file mode 100644
index 9a636aa9..00000000
--- a/data/api/server-server/third_party_invite.yaml
+++ /dev/null
@@ -1,325 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Third Party Invites API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/exchange_third_party_invite/{roomId}":
-    put:
-      summary: Request a server to auth a third party invite event
-      description: |-
-        The receiving server will verify the partial `m.room.member` event
-        given in the request body. If valid, the receiving server will issue
-        an invite as per the [Inviting to a room](/server-server-api/#inviting-to-a-room) section before returning a
-        response to this request.
-      operationId: exchangeThirdPartyInvite
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: roomId
-          type: string
-          description: The room ID to exchange a third party invite in
-          required: true
-          x-example: "!abc123:matrix.org"
-        - in: body
-          name: body
-          type: object
-          description: A partial `m.room.member` event
-          required: true
-          schema:
-            type: object
-            properties:
-              type:
-                type: string
-                description: The event type. Must be `m.room.member`
-                example: "m.room.member"
-              room_id:
-                type: string
-                description: |-
-                  The room ID the event is for. Must match the ID given in
-                  the path.
-                example: "!abc123:matrix.org"
-              sender:
-                type: string
-                description: |-
-                  The user ID of the user who sent the original `m.room.third_party_invite`
-                  event.
-                example: "@joe:matrix.org"
-              state_key:
-                type: string
-                description: The user ID of the invited user
-                example: "@someone:example.org"
-              content:
-                type: object
-                description: The event content
-                title: Event Content
-                properties:
-                  membership:
-                    type: string
-                    description: The membership state. Must be `invite`
-                    example: invite
-                  third_party_invite:
-                    type: object
-                    description: The third party invite
-                    title: Third Party Invite
-                    properties:
-                      display_name:
-                        type: string
-                        description: |-
-                          A name which can be displayed to represent the user instead of their
-                          third party identifier.
-                        example: "alice"
-                      signed:
-                        type: object
-                        description: |-
-                          A block of content which has been signed, which servers can use to
-                          verify the event.
-                        title: Invite Signatures
-                        properties:
-                          signatures:
-                            type: object
-                            title: Signatures
-                            additionalProperties:
-                              type: object
-                              additionalProperties:
-                                type: string
-                            description: |-
-                              The server signatures for this event.
-
-                              The signature is calculated using the process
-                              described at [Signing JSON](/appendices/#signing-json).
-                            example: {
-                              "magic.forest": {
-                                "ed25519:3": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"
-                              }
-                            }
-                          mxid:
-                            type: string
-                            description: The invited matrix user ID
-                            example: "@alice:localhost"
-                          token:
-                            type: string
-                            description: The token used to verify the event
-                            example: abc123
-                        required: ['signatures', 'mxid', 'token']
-                        example: {
-                          "mxid": "@alice:localhost",
-                          "token": "abc123",
-                          "signatures": {
-                            "magic.forest": {
-                              "ed25519:3": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"
-                            }
-                          }
-                        }
-                    required: ['display_name', 'signed']
-                    example: {
-                      "display_name": "alice",
-                      "signed": {
-                        "mxid": "@alice:localhost",
-                        "token": "abc123",
-                        "signatures": {
-                          "magic.forest": {
-                            "ed25519:3": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"
-                          }
-                        }
-                      }
-                    }
-                required: ['membership', 'third_party_invite']
-                example: {
-                  "membership": "invite",
-                  "third_party_invite": {
-                    "display_name": "alice",
-                    "signed": {
-                      "mxid": "@alice:localhost",
-                      "token": "abc123",
-                      "signatures": {
-                        "magic.forest": {
-                          "ed25519:3": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"
-                        }
-                      }
-                    }
-                  }
-                }
-            required:
-              - type
-              - room_id
-              - sender
-              - state_key
-              - content
-          example: {
-            "type": "m.room.member",
-            "room_id": "!abc123:matrix.org",
-            "sender": "@joe:matrix.org",
-            "state_key": "@someone:example.org",
-            "content": {
-              "membership": "invite",
-              "third_party_invite": {
-                "display_name": "alice",
-                "signed": {
-                  "mxid": "@alice:localhost",
-                  "token": "abc123",
-                  "signatures": {
-                    "magic.forest": {
-                      "ed25519:3": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"
-                    }
-                  }
-                }
-              }
-            }
-          }
-      responses:
-        200:
-          description: The invite has been issued successfully.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-            description: An empty object
-            example: {}
-  "/3pid/onbind":
-    put:
-      summary: |-
-        Notifies the server that a third party identifier has been bound to one
-        of its users.
-      description: |-
-        Used by identity servers to notify the homeserver that one of its users
-        has bound a third party identifier successfully, including any pending
-        room invites the identity server has been made aware of.
-      operationId: onBindThirdPartyIdentifier
-      parameters:
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            type: object
-            properties:
-              medium:
-                type: string
-                description: |-
-                  The type of third party identifier. Currently only "email" is
-                  a possible value.
-                example: "email"
-              address:
-                type: string
-                description: |-
-                  The third party identifier itself. For example, an email address.
-                example: "alice@example.com"
-              mxid:
-                type: string
-                description: The user that is now bound to the third party identifier.
-                example: "@alice:matrix.org"
-              invites:
-                type: array
-                description: |-
-                  A list of pending invites that the third party identifier has received.
-                items:
-                  type: object
-                  title: Third Party Invite
-                  properties:
-                    medium:
-                      type: string
-                      description: |-
-                        The type of third party invite issues. Currently only
-                        "email" is used.
-                      example: "email"
-                    address:
-                      type: string
-                      description: |-
-                        The third party identifier that received the invite.
-                      example: "alice@example.com"
-                    mxid:
-                      type: string
-                      description: The now-bound user ID that received the invite.
-                      example: "@alice:matrix.org"
-                    room_id:
-                      type: string
-                      description: The room ID the invite is valid for.
-                      example: "!somewhere:example.org"
-                    sender:
-                      type: string
-                      description: The user ID that sent the invite.
-                      example: "@bob:matrix.org"
-                    # TODO (TravisR): Make this reusable when doing IS spec changes
-                    #   also make sure it isn't lying about anything, like the key version
-                    signed:
-                      type: object
-                      title: Identity Server Signatures
-                      description: |-
-                        Signature from the identity server using a long-term private
-                        key.
-                      properties:
-                        mxid:
-                          type: string
-                          description: |-
-                            The user ID that has been bound to the third party
-                            identifier.
-                          example: "@alice:matrix.org"
-                        token:
-                          type: string
-                          # TODO: What is this actually?
-                          description: A token.
-                          example: "Hello World"
-                        signatures:
-                          type: object
-                          title: Identity Server Signature
-                          description: |-
-                            The signature from the identity server. The `string` key
-                            is the identity server's domain name, such as vector.im
-                          additionalProperties:
-                            type: object
-                            title: Identity Server Domain Signature
-                            description: The signature for the identity server.
-                            properties:
-                              "ed25519:0":
-                                type: string
-                                description: The signature.
-                                example: "SomeSignatureGoesHere"
-                            required: ['ed25519:0']
-                          example: {
-                            "vector.im": {
-                              "ed25519:0": "SomeSignatureGoesHere"
-                            }
-                          }
-                      required: ['mxid', 'token', 'signatures']
-                  required:
-                    - medium
-                    - address
-                    - mxid
-                    - room_id
-                    - sender
-                    - signed
-            required: ['medium', 'address', 'mxid', 'invites']
-      responses:
-        200:
-          description: The homeserver has processed the notification.
-          examples:
-            application/json: {}
-          schema:
-            type: object
-            description: An empty object
-            example: {}
diff --git a/data/api/server-server/transactions.yaml b/data/api/server-server/transactions.yaml
deleted file mode 100644
index cb801ee8..00000000
--- a/data/api/server-server/transactions.yaml
+++ /dev/null
@@ -1,109 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Transaction API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/send/{txnId}":
-    put:
-      summary: Send a transaction
-      description: |-
-        Push messages representing live activity to another server. The destination name
-        will be set to that of the receiving server itself. Each embedded PDU in the
-        transaction body will be processed.
-
-        The sending server must wait and retry for a 200 OK response before sending a
-        transaction with a different `txnId` to the receiving server.
-
-        Note that events have a different format depending on the room version - check
-        the [room version specification](/rooms) for precise event formats.
-      operationId: sendTransaction
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: txnId
-          type: string
-          description: |-
-            The transaction ID.
-          required: true
-          x-example: S0meTransacti0nId
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            allOf:
-              - $ref: "definitions/transaction.yaml"
-              - type: object
-                properties:
-                  edus:
-                    type: array
-                    description: |-
-                      List of ephemeral messages. May be omitted if there are no ephemeral
-                      messages to be sent. Must not include more than 100 EDUs.
-                    items:
-                      $ref: "definitions/edu.yaml"
-          example: {
-            "$ref": "examples/transaction.json",
-            "edus": [{"$ref": "examples/edu.json"}]
-          }
-      responses:
-        200:
-          description: |-
-            The result of processing the transaction. The server is to use this response even in
-            the event of one or more PDUs failing to be processed.
-          schema:
-            type: object
-            title: PDU Processing Results
-            description: The results for the processing of each PDU in the transaction.
-            properties:
-              pdus:
-                type: object
-                description: |-
-                  The PDUs from the original transaction. The string key represents the ID of the
-                  PDU (event) that was processed.
-                additionalProperties:
-                  type: object
-                  title: PDU Processing Result
-                  description: Information about how the PDU was handled.
-                  properties:
-                    error:
-                      type: string
-                      description: |-
-                        A human readable description about what went wrong in processing this PDU.
-                        If no error is present, the PDU can be considered successfully handled.
-                      example: "You are not allowed to send a message to this room."
-            required: ['pdus']
-          examples:
-            application/json: {
-              "pdus": {
-                "$successful_event:example.org": {},
-                "$failed_event:example.org": {
-                  "error": "You are not allowed to send a message to this room."
-                }
-              }
-            }
diff --git a/data/api/server-server/user_devices.yaml b/data/api/server-server/user_devices.yaml
deleted file mode 100644
index 9fb15777..00000000
--- a/data/api/server-server/user_devices.yaml
+++ /dev/null
@@ -1,118 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2020 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation User Device Management API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/user/devices/{userId}":
-    get:
-      summary: Gets all of the user's devices
-      description: Gets information on all of the user's devices
-      operationId: getUserDevices
-      security:
-        - signedRequest: []
-      parameters:
-        - in: path
-          name: userId
-          type: string
-          required: true
-          description: |-
-            The user ID to retrieve devices for. Must be a user local to the
-            receiving homeserver.
-          x-example: "@alice:example.org"
-      responses:
-        200:
-          description: The user's devices.
-          schema:
-            type: object
-            properties:
-              user_id:
-                type: string
-                description: The user ID devices were requested for.
-                example: "@alice:example.org"
-              stream_id:
-                type: integer
-                description: |-
-                  A unique ID for a given user_id which describes the version of
-                  the returned device list.  This is matched with the `stream_id`
-                  field in `m.device_list_update` EDUs in order to incrementally
-                  update the returned device_list.
-                example: 5
-              devices:
-                type: array
-                description: The user's devices. May be empty.
-                items:
-                  type: object
-                  title: User Device
-                  properties:
-                    device_id:
-                      type: string
-                      description: The device ID.
-                      example: "JLAFKJWSCS"
-                    keys:
-                      type: object
-                      description: Identity keys for the device.
-                      $ref: "../client-server/definitions/device_keys.yaml"
-                    device_display_name:
-                      type: string
-                      description: Optional display name for the device.
-                      example: "Alice's Mobile Phone"
-                  required: ['device_id', 'keys']
-              master_key:
-                type: object
-                description: |-
-                  The user\'s master cross-signing key.
-                allOf:
-                  - $ref: ../client-server/definitions/cross_signing_key.yaml
-                  # FIXME: why isn't the doc generator picking up this example?
-                  - example: {
-                      "user_id": "@alice:example.com",
-                      "usage": ["master"],
-                      "keys": {
-                        "ed25519:base64+master+public+key": "base64+master+public+key",
-                      }
-                    }
-              self_signing_key:
-                type: object
-                description: |-
-                  The user\'s self-signing key.
-                allOf:
-                  - $ref: ../client-server/definitions/cross_signing_key.yaml
-                  # FIXME: why isn't the doc generator picking up this example?
-                  - example: {
-                      "user_id": "@alice:example.com",
-                      "usage": ["self_signing"],
-                      "keys": {
-                        "ed25519:base64+self+signing+public+key": "base64+self+signing+master+public+key",
-                      },
-                      "signatures": {
-                        "@alice:example.com": {
-                          "ed25519:base64+master+public+key": "signature+of+self+signing+key"
-                        }
-                      }
-                    }
-            required: ['user_id', 'stream_id', 'devices']
diff --git a/data/api/server-server/user_keys.yaml b/data/api/server-server/user_keys.yaml
deleted file mode 100644
index efad0056..00000000
--- a/data/api/server-server/user_keys.yaml
+++ /dev/null
@@ -1,254 +0,0 @@
-# Copyright 2018 New Vector Ltd
-# Copyright 2020 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation User Key Management API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-consumes:
-  - application/json
-produces:
-  - application/json
-securityDefinitions:
-  $ref: definitions/security.yaml
-paths:
-  "/user/keys/claim":
-    post:
-      summary: Claims one-time encryption keys for a user.
-      description: |-
-        Claims one-time keys for use in pre-key messages.
-      operationId: claimUserEncryptionKeys
-      security:
-        - signedRequest: []
-      parameters:
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            type: object
-            properties:
-              one_time_keys:
-                type: object
-                description: |-
-                  The keys to be claimed. A map from user ID, to a map from
-                  device ID to algorithm name.
-                additionalProperties:
-                  type: object
-                  additionalProperties:
-                    type: string
-                    description: algorithm
-                    example: "signed_curve25519"
-                example: {
-                  "@alice:example.com": {
-                    "JLAFKJWSCS": "signed_curve25519"
-                  }
-                }
-            required:
-              - one_time_keys
-      responses:
-        200:
-          description: The claimed keys.
-          schema:
-            type: object
-            properties:
-              one_time_keys:
-                type: object
-                description: |-
-                  One-time keys for the queried devices. A map from user ID, to a
-                  map from devices to a map from `<algorithm>:<key_id>` to the key object.
-
-                  See the [Client-Server Key Algorithms](/client-server-api/#key-algorithms) section for more information on
-                  the Key Object format.
-                additionalProperties:
-                  type: object
-                  additionalProperties:
-                    type:
-                      - string
-                      - type: object
-                        title: KeyObject
-                        properties:
-                          key:
-                            type: string
-                            description: The key, encoded using unpadded base64.
-                          signatures:
-                            type: object
-                            title: Signatures
-                            additionalProperties:
-                              type: object
-                              additionalProperties:
-                                type: string
-                            description: |-
-                              Signature of the key object.
-
-                              The signature is calculated using the process described at [Signing JSON](/appendices/#signing-json).
-                        required: ['key', 'signatures']
-                example: {
-                  "@alice:example.com": {
-                    "JLAFKJWSCS": {
-                      "signed_curve25519:AAAAHg": {
-                        "key": "zKbLg+NrIjpnagy+pIY6uPL4ZwEG2v+8F9lmgsnlZzs",
-                        "signatures": {
-                          "@alice:example.com": {
-                            "ed25519:JLAFKJWSCS": "FLWxXqGbwrb8SM3Y795eB6OA8bwBcoMZFXBqnTn58AYWZSqiD45tlBVcDa2L7RwdKXebW/VzDlnfVJ+9jok1Bw"
-                          }
-                        }
-                      }
-                    }
-                  }
-                }
-            required: ['one_time_keys']
-  "/user/keys/query":
-    post:
-      summary: Download device identity keys.
-      description: |-
-        Returns the current devices and identity keys for the given users.
-      operationId: queryUserEncryptionKeys
-      security:
-        - signedRequest: []
-      parameters:
-        - in: body
-          name: body
-          type: object
-          required: true
-          schema:
-            type: object
-            properties:
-              device_keys:
-                type: object
-                description: |-
-                  The keys to be downloaded. A map from user ID, to a list of
-                  device IDs, or to an empty list to indicate all devices for the
-                  corresponding user.
-                additionalProperties:
-                  type: array
-                  items:
-                    type: string
-                    description: "Device ID"
-                example: {
-                  "@alice:example.com": []
-                }
-            required: ['device_keys']
-      responses:
-        200:
-          description: The device information.
-          schema:
-            type: object
-            properties:
-              device_keys:
-                type: object
-                description: |-
-                  Information on the queried devices. A map from user ID, to a
-                  map from device ID to device information.  For each device,
-                  the information returned will be the same as uploaded via
-                  `/keys/upload`, with the addition of an `unsigned`
-                  property.
-                additionalProperties:
-                  type: object
-                  additionalProperties:
-                    allOf:
-                      - $ref: ../client-server/definitions/device_keys.yaml
-                    properties:
-                      unsigned:
-                        title: UnsignedDeviceInfo
-                        type: object
-                        description: |-
-                          Additional data added to the device key information
-                          by intermediate servers, and not covered by the
-                          signatures.
-                        properties:
-                          device_display_name:
-                            type: string
-                            description:
-                              The display name which the user set on the device.
-              master_keys:
-                x-addedInMatrixVersion: "1.1"
-                type: object
-                description: |-
-                  Information on the master cross-signing keys of the queried users.
-                  A map from user ID, to master key information.  For each key, the
-                  information returned will be the same as uploaded via
-                  `/keys/device_signing/upload`, along with the signatures
-                  uploaded via `/keys/signatures/upload` that the user is
-                  allowed to see.
-                additionalProperties:
-                  allOf:
-                    - $ref: ../client-server/definitions/cross_signing_key.yaml
-                example: {
-                  "@alice:example.com": {
-                    "user_id": "@alice:example.com",
-                    "usage": ["master"],
-                    "keys": {
-                      "ed25519:base64+master+public+key": "base64+master+public+key",
-                    }
-                  }
-                }
-              self_signing_keys:
-                x-addedInMatrixVersion: "1.1"
-                type: object
-                description: |-
-                  Information on the self-signing keys of the queried users. A map
-                  from user ID, to self-signing key information.  For each key, the
-                  information returned will be the same as uploaded via
-                  `/keys/device_signing/upload`.
-                additionalProperties:
-                  allOf:
-                    - $ref: ../client-server/definitions/cross_signing_key.yaml
-                example: {
-                  "@alice:example.com": {
-                    "user_id": "@alice:example.com",
-                    "usage": ["self_signing"],
-                    "keys": {
-                      "ed25519:base64+self+signing+public+key": "base64+self+signing+master+public+key",
-                    },
-                    "signatures": {
-                      "@alice:example.com": {
-                        "ed25519:base64+master+public+key": "signature+of+self+signing+key"
-                      }
-                    }
-                  }
-                }
-            required: ['device_keys']
-          examples:
-            application/json: {
-              "device_keys": {
-                "@alice:example.com": {
-                  "JLAFKJWSCS": {
-                    "user_id": "@alice:example.com",
-                    "device_id": "JLAFKJWSCS",
-                    "algorithms": [
-                      "m.olm.v1.curve25519-aes-sha2",
-                      "m.megolm.v1.aes-sha2"
-                    ],
-                    "keys": {
-                      "curve25519:JLAFKJWSCS": "3C5BFWi2Y8MaVvjM8M22DBmh24PmgR0nPvJOIArzgyI",
-                      "ed25519:JLAFKJWSCS": "lEuiRJBit0IG6nUf5pUzWTUEsRVVe/HJkoKuEww9ULI"
-                    },
-                    "signatures": {
-                      "@alice:example.com": {
-                        "ed25519:JLAFKJWSCS": "dSO80A01XiigH3uBiDVx/EjzaoycHcjq9lfQX0uWsqxl2giMIiSPR8a4d291W1ihKJL/a+myXS367WT6NAIcBA"
-                      }
-                    },
-                    "unsigned": {
-                      "device_display_name": "Alice's mobile phone"
-                    }
-                  }
-                }
-              }
-            }
diff --git a/data/api/server-server/version.yaml b/data/api/server-server/version.yaml
deleted file mode 100644
index 929f7b91..00000000
--- a/data/api/server-server/version.yaml
+++ /dev/null
@@ -1,54 +0,0 @@
-# Copyright 2017 Kamax.io
-#
-# 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.
-
-swagger: '2.0'
-info:
-  title: "Matrix Federation Version API"
-  version: "1.0.0"
-host: localhost:8448
-schemes:
-  - https
-basePath: /_matrix/federation/v1
-produces:
-  - application/json
-paths:
-  "/version":
-    get:
-      summary: Get the implementation name and version of this homeserver.
-      description: Get the implementation name and version of this homeserver.
-      operationId: getVersion
-      responses:
-        200:
-          description:
-            The implementation name and version of this homeserver.
-          examples:
-            application/json: {
-                "server": {
-                  "name": "My_Homeserver_Implementation",
-                  "version": "ArbitraryVersionNumber"
-                }
-              }
-          schema:
-            type: object
-            properties:
-              server:
-                title: Server
-                type: object
-                properties:
-                  name:
-                    type: string
-                    description: Arbitrary name that identify this implementation.
-                  version:
-                    type: string
-                    description: Version of this implementation. The version format depends on the implementation.
diff --git a/data/api/server-server/wellknown.yaml b/data/api/server-server/wellknown.yaml
deleted file mode 100644
index c1a060d9..00000000
--- a/data/api/server-server/wellknown.yaml
+++ /dev/null
@@ -1,53 +0,0 @@
-# Copyright 2019 New Vector Ltd
-#
-# 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.
-swagger: '2.0'
-info:
-  title: "Matrix Federation Server Discovery API"
-  version: "1.0.0"
-host: localhost:443
-schemes:
-  - https
-basePath: /.well-known
-produces:
-  - application/json
-paths:
-  "/matrix/server":
-    get:
-      summary: Gets information about the delegated server for server-server communication.
-      description: |-
-        Gets information about the delegated server for server-server communication
-        between Matrix homeservers. Servers should follow 30x redirects, carefully
-        avoiding redirect loops, and use normal X.509 certificate validation.
-      operationId: getWellKnown
-      responses:
-        200:
-          description:
-            The delegated server information. The `Content-Type` for this response SHOULD
-            be `application/json`, however servers parsing the response should assume that
-            the body is JSON regardless of type. Failures parsing the JSON or invalid data
-            provided in the resulting parsed JSON should not result in discovery failure -
-            consult the server discovery process for information on how to continue.
-          examples:
-            application/json: {
-              "m.server": "delegated.example.com:1234"
-            }
-          schema:
-            type: object
-            properties:
-              "m.server":
-                type: string
-                description: |-
-                  The server name to delegate server-server communications to, with optional
-                  port. The delegated server name uses the same grammar as
-                  [server names in the appendices](/appendices/#server-name).
diff --git a/data/event-schemas/examples/core/event.json b/data/event-schemas/examples/core/event.json
deleted file mode 100644
index 8a469a5c..00000000
--- a/data/event-schemas/examples/core/event.json
+++ /dev/null
@@ -1,6 +0,0 @@
-{
-    "content": {
-        "key": "value"
-    },
-    "type": "org.example.custom.event"
-}
diff --git a/data/event-schemas/examples/core/room_edu.json b/data/event-schemas/examples/core/room_edu.json
deleted file mode 100644
index dc57b506..00000000
--- a/data/event-schemas/examples/core/room_edu.json
+++ /dev/null
@@ -1,3 +0,0 @@
-{
-    "$ref": "event.json"
-}
diff --git a/data/event-schemas/examples/core/room_event.json b/data/event-schemas/examples/core/room_event.json
deleted file mode 100644
index 521225cc..00000000
--- a/data/event-schemas/examples/core/room_event.json
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-    "$ref": "event.json",
-    "event_id": "$143273582443PhrSn:example.org",
-    "room_id": "!jEsUZKDJdhlrceRyVU:example.org",
-    "sender": "@example:example.org",
-    "origin_server_ts": 1432735824653,
-    "unsigned": {
-      "age": 1234
-    }
-}
diff --git a/data/event-schemas/examples/core/state_event.json b/data/event-schemas/examples/core/state_event.json
deleted file mode 100644
index 910747ee..00000000
--- a/data/event-schemas/examples/core/state_event.json
+++ /dev/null
@@ -1,4 +0,0 @@
-{
-    "$ref": "room_event.json",
-    "state_key": "ArbitraryString"
-}
diff --git a/data/event-schemas/examples/invite_room_state.json b/data/event-schemas/examples/invite_room_state.json
deleted file mode 100644
index 9d8c1b2b..00000000
--- a/data/event-schemas/examples/invite_room_state.json
+++ /dev/null
@@ -1,18 +0,0 @@
-[
-    {
-        "type": "m.room.name",
-        "sender": "@bob:example.org",
-        "state_key": "",
-        "content": {
-            "name": "Example Room"
-        }
-    },
-    {
-        "type": "m.room.join_rules",
-        "sender": "@bob:example.org",
-        "state_key": "",
-        "content": {
-            "join_rule": "invite"
-        }
-    }
-]
diff --git a/data/event-schemas/examples/knock_room_state.json b/data/event-schemas/examples/knock_room_state.json
deleted file mode 100644
index 9692bb31..00000000
--- a/data/event-schemas/examples/knock_room_state.json
+++ /dev/null
@@ -1,18 +0,0 @@
-[
-    {
-        "type": "m.room.name",
-        "sender": "@bob:example.org",
-        "state_key": "",
-        "content": {
-            "name": "Example Room"
-        }
-    },
-    {
-        "type": "m.room.join_rules",
-        "sender": "@bob:example.org",
-        "state_key": "",
-        "content": {
-            "join_rule": "knock"
-        }
-    }
-]
diff --git a/data/event-schemas/examples/m.accepted_terms.yaml b/data/event-schemas/examples/m.accepted_terms.yaml
deleted file mode 100644
index 5e8dad16..00000000
--- a/data/event-schemas/examples/m.accepted_terms.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/event.json",
-  "type": "m.accepted_terms",
-  "content": {
-    "accepted": [
-      "https://example.org/somewhere/terms-1.2-en.html",
-      "https://example.org/somewhere/privacy-1.2-en.html"
-    ]
-  }
-}
diff --git a/data/event-schemas/examples/m.call.answer.yaml b/data/event-schemas/examples/m.call.answer.yaml
deleted file mode 100644
index a4cfc1e1..00000000
--- a/data/event-schemas/examples/m.call.answer.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.call.answer",
-  "content": {
-    "version" : 0,
-    "call_id": "12345",
-    "lifetime": 60000,
-    "answer": {
-      "type" : "answer",
-      "sdp" : "v=0\r\no=- 6584580628695956864 2 IN IP4 127.0.0.1[...]"
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.call.candidates.yaml b/data/event-schemas/examples/m.call.candidates.yaml
deleted file mode 100644
index 8f1f807a..00000000
--- a/data/event-schemas/examples/m.call.candidates.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.call.candidates",
-  "content": {
-    "version" : 0,
-    "call_id": "12345",
-    "candidates": [
-      {
-        "sdpMid": "audio",
-        "sdpMLineIndex": 0,
-        "candidate": "candidate:863018703 1 udp 2122260223 10.9.64.156 43670 typ host generation 0"
-      }
-    ]
-  }
-}
diff --git a/data/event-schemas/examples/m.call.hangup.yaml b/data/event-schemas/examples/m.call.hangup.yaml
deleted file mode 100644
index 295f16e4..00000000
--- a/data/event-schemas/examples/m.call.hangup.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.call.hangup",
-  "content": {
-    "version" : 0,
-    "call_id": "12345"
-  }
-}
diff --git a/data/event-schemas/examples/m.call.invite.yaml b/data/event-schemas/examples/m.call.invite.yaml
deleted file mode 100644
index fa482bd9..00000000
--- a/data/event-schemas/examples/m.call.invite.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.call.invite",
-  "content": {
-    "version" : 0,
-    "call_id": "12345",
-    "lifetime": 60000,
-    "offer": {
-      "type" : "offer",
-      "sdp" : "v=0\r\no=- 6584580628695956864 2 IN IP4 127.0.0.1[...]"
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.direct.yaml b/data/event-schemas/examples/m.direct.yaml
deleted file mode 100644
index e453dd59..00000000
--- a/data/event-schemas/examples/m.direct.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/event.json",
-  "type": "m.direct",
-  "content": {
-    "@bob:example.com": [
-      "!abcdefgh:example.com",
-      "!hgfedcba:example.com"
-    ]
-  }
-}
diff --git a/data/event-schemas/examples/m.dummy.yaml b/data/event-schemas/examples/m.dummy.yaml
deleted file mode 100644
index 0cd39166..00000000
--- a/data/event-schemas/examples/m.dummy.yaml
+++ /dev/null
@@ -1,4 +0,0 @@
-{
-  "content": {},
-  "type": "m.dummy"
-}
diff --git a/data/event-schemas/examples/m.forwarded_room_key.yaml b/data/event-schemas/examples/m.forwarded_room_key.yaml
deleted file mode 100644
index ef1d6180..00000000
--- a/data/event-schemas/examples/m.forwarded_room_key.yaml
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "content": {
-    "algorithm": "m.megolm.v1.aes-sha2",
-    "room_id": "!Cuyf34gef24t:localhost",
-    "session_id": "X3lUlvLELLYxeTx4yOVu6UDpasGEVO0Jbu+QFnm0cKQ",
-    "session_key": "AgAAAADxKHa9uFxcXzwYoNueL5Xqi69IkD4sni8Llf...",
-    "sender_key": "RF3s+E7RkTQTGF2d8Deol0FkQvgII2aJDf3/Jp5mxVU",
-    "sender_claimed_ed25519_key": "aj40p+aw64yPIdsxoog8jhPu9i7l7NcFRecuOQblE3Y",
-    "forwarding_curve25519_key_chain": [
-      "hPQNcabIABgGnx3/ACv/jmMmiQHoeFfuLB17tzWp6Hw"
-    ]
-  },
-  "type": "m.forwarded_room_key"
-}
diff --git a/data/event-schemas/examples/m.fully_read.yaml b/data/event-schemas/examples/m.fully_read.yaml
deleted file mode 100644
index f314c803..00000000
--- a/data/event-schemas/examples/m.fully_read.yaml
+++ /dev/null
@@ -1,7 +0,0 @@
-{
-  "$ref": "core/event.json",
-  "type": "m.fully_read",
-  "content": {
-    "event_id": "$someplace:example.org"
-  }
-}
diff --git a/data/event-schemas/examples/m.identity_server.yaml b/data/event-schemas/examples/m.identity_server.yaml
deleted file mode 100644
index 32855e9c..00000000
--- a/data/event-schemas/examples/m.identity_server.yaml
+++ /dev/null
@@ -1,7 +0,0 @@
-{
-  "$ref": "core/event.json",
-  "type": "m.identity_server",
-  "content": {
-    "base_url": "https://example.org"
-  }
-}
diff --git a/data/event-schemas/examples/m.ignored_user_list.yaml b/data/event-schemas/examples/m.ignored_user_list.yaml
deleted file mode 100644
index 83def6e4..00000000
--- a/data/event-schemas/examples/m.ignored_user_list.yaml
+++ /dev/null
@@ -1,9 +0,0 @@
-{
-  "$ref": "core/event.json",
-  "type": "m.ignored_user_list",
-  "content": {
-    "ignored_users": {
-      "@someone:example.org": {}
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.key.verification.accept.yaml b/data/event-schemas/examples/m.key.verification.accept.yaml
deleted file mode 100644
index 98e89c06..00000000
--- a/data/event-schemas/examples/m.key.verification.accept.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-{
-    "type": "m.key.verification.accept",
-    "content": {
-        "transaction_id": "S0meUniqueAndOpaqueString",
-        "method": "m.sas.v1",
-        "key_agreement_protocol": "curve25519",
-        "hash": "sha256",
-        "message_authentication_code": "hkdf-hmac-sha256",
-        "short_authentication_string": ["decimal", "emoji"],
-        "commitment": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"
-    }
-}
diff --git a/data/event-schemas/examples/m.key.verification.cancel.yaml b/data/event-schemas/examples/m.key.verification.cancel.yaml
deleted file mode 100644
index 9d78f67c..00000000
--- a/data/event-schemas/examples/m.key.verification.cancel.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-    "type": "m.key.verification.cancel",
-    "content": {
-        "transaction_id": "S0meUniqueAndOpaqueString",
-        "code": "m.user",
-        "reason": "User rejected the key verification request"
-    }
-}
diff --git a/data/event-schemas/examples/m.key.verification.done.yaml b/data/event-schemas/examples/m.key.verification.done.yaml
deleted file mode 100644
index 0e883cf1..00000000
--- a/data/event-schemas/examples/m.key.verification.done.yaml
+++ /dev/null
@@ -1,6 +0,0 @@
-{
-    "type": "m.key.verification.done",
-    "content": {
-        "transaction_id": "S0meUniqueAndOpaqueString"
-    }
-}
diff --git a/data/event-schemas/examples/m.key.verification.key.yaml b/data/event-schemas/examples/m.key.verification.key.yaml
deleted file mode 100644
index 608a2ebd..00000000
--- a/data/event-schemas/examples/m.key.verification.key.yaml
+++ /dev/null
@@ -1,7 +0,0 @@
-{
-    "type": "m.key.verification.key",
-    "content": {
-        "transaction_id": "S0meUniqueAndOpaqueString",
-        "key": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"
-    }
-}
diff --git a/data/event-schemas/examples/m.key.verification.mac.yaml b/data/event-schemas/examples/m.key.verification.mac.yaml
deleted file mode 100644
index c77c3a8d..00000000
--- a/data/event-schemas/examples/m.key.verification.mac.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-    "type": "m.key.verification.mac",
-    "content": {
-        "transaction_id": "S0meUniqueAndOpaqueString",
-        "keys": "2Wptgo4CwmLo/Y8B8qinxApKaCkBG2fjTWB7AbP5Uy+aIbygsSdLOFzvdDjww8zUVKCmI02eP9xtyJxc/cLiBA",
-        "mac": {
-            "ed25519:ABCDEF": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"
-        }
-    }
-}
diff --git a/data/event-schemas/examples/m.key.verification.ready.yaml b/data/event-schemas/examples/m.key.verification.ready.yaml
deleted file mode 100644
index 0397a566..00000000
--- a/data/event-schemas/examples/m.key.verification.ready.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-    "type": "m.key.verification.ready",
-    "content": {
-        "from_device": "BobDevice1",
-        "transaction_id": "S0meUniqueAndOpaqueString",
-        "methods": [
-            "m.sas.v1"
-        ]
-    }
-}
diff --git a/data/event-schemas/examples/m.key.verification.request.yaml b/data/event-schemas/examples/m.key.verification.request.yaml
deleted file mode 100644
index 258471d2..00000000
--- a/data/event-schemas/examples/m.key.verification.request.yaml
+++ /dev/null
@@ -1,11 +0,0 @@
-{
-    "type": "m.key.verification.request",
-    "content": {
-        "from_device": "AliceDevice2",
-        "transaction_id": "S0meUniqueAndOpaqueString",
-        "methods": [
-            "m.sas.v1"
-        ],
-        "timestamp": 1559598944869
-    }
-}
diff --git a/data/event-schemas/examples/m.key.verification.start$m.sas.v1.yaml b/data/event-schemas/examples/m.key.verification.start$m.sas.v1.yaml
deleted file mode 100644
index dae1d405..00000000
--- a/data/event-schemas/examples/m.key.verification.start$m.sas.v1.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-{
-    "type": "m.key.verification.start",
-    "content": {
-        "from_device": "BobDevice1",
-        "transaction_id": "S0meUniqueAndOpaqueString",
-        "method": "m.sas.v1",
-        "key_agreement_protocols": ["curve25519"],
-        "hashes": ["sha256"],
-        "message_authentication_codes": ["hkdf-hmac-sha256"],
-        "short_authentication_string": ["decimal", "emoji"]
-    }
-}
diff --git a/data/event-schemas/examples/m.key.verification.start.yaml b/data/event-schemas/examples/m.key.verification.start.yaml
deleted file mode 100644
index 52f16150..00000000
--- a/data/event-schemas/examples/m.key.verification.start.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-    "type": "m.key.verification.start",
-    "content": {
-        "from_device": "BobDevice1",
-        "transaction_id": "S0meUniqueAndOpaqueString",
-        "method": "m.sas.v1"
-    }
-}
diff --git a/data/event-schemas/examples/m.policy.rule.room.yaml b/data/event-schemas/examples/m.policy.rule.room.yaml
deleted file mode 100644
index 5a532cb5..00000000
--- a/data/event-schemas/examples/m.policy.rule.room.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.policy.rule.room",
-  "state_key": "rule:#*:example.org",
-  "content": {
-    "entity": "#*:example.org",
-    "recommendation": "m.ban",
-    "reason": "undesirable content"
-  }
-}
diff --git a/data/event-schemas/examples/m.policy.rule.server.yaml b/data/event-schemas/examples/m.policy.rule.server.yaml
deleted file mode 100644
index 3d740a28..00000000
--- a/data/event-schemas/examples/m.policy.rule.server.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.policy.rule.server",
-  "state_key": "rule:*.example.org",
-  "content": {
-    "entity": "*.example.org",
-    "recommendation": "m.ban",
-    "reason": "undesirable engagement"
-  }
-}
diff --git a/data/event-schemas/examples/m.policy.rule.user.yaml b/data/event-schemas/examples/m.policy.rule.user.yaml
deleted file mode 100644
index eb3832da..00000000
--- a/data/event-schemas/examples/m.policy.rule.user.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.policy.rule.user",
-  "state_key": "rule:@alice*:example.org",
-  "content": {
-    "entity": "@alice*:example.org",
-    "recommendation": "m.ban",
-    "reason": "undesirable behaviour"
-  }
-}
diff --git a/data/event-schemas/examples/m.presence.yaml b/data/event-schemas/examples/m.presence.yaml
deleted file mode 100644
index 4d9cd5a5..00000000
--- a/data/event-schemas/examples/m.presence.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-{
-  "$ref": "core/event.json",
-  "sender": "@example:localhost",
-  "type": "m.presence",
-  "content": {
-    "avatar_url": "mxc://localhost/wefuiwegh8742w",
-    "last_active_ago": 2478593,
-    "presence": "online",
-    "currently_active": false,
-    "status_msg": "Making cupcakes"
-  }
-}
diff --git a/data/event-schemas/examples/m.push_rules.yaml b/data/event-schemas/examples/m.push_rules.yaml
deleted file mode 100644
index 34bc2fe6..00000000
--- a/data/event-schemas/examples/m.push_rules.yaml
+++ /dev/null
@@ -1,197 +0,0 @@
-{
-  "$ref": "core/event.json",
-  "type": "m.push_rules",
-  "content": {
-    "global": {
-      "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": [
-            "dont_notify"
-          ],
-          "conditions": [],
-          "default": true,
-          "enabled": false,
-          "rule_id": ".m.rule.master"
-        },
-        {
-          "actions": [
-            "dont_notify"
-          ],
-          "conditions": [
-            {
-              "key": "content.msgtype",
-              "kind": "event_match",
-              "pattern": "m.notice"
-            }
-          ],
-          "default": true,
-          "enabled": true,
-          "rule_id": ".m.rule.suppress_notices"
-        }
-      ],
-      "room": [],
-      "sender": [],
-      "underride": [
-        {
-          "actions": [
-            "notify",
-            {
-              "set_tweak": "sound",
-              "value": "ring"
-            },
-            {
-              "set_tweak": "highlight",
-              "value": false
-            }
-          ],
-          "conditions": [
-            {
-              "key": "type",
-              "kind": "event_match",
-              "pattern": "m.call.invite"
-            }
-          ],
-          "default": true,
-          "enabled": true,
-          "rule_id": ".m.rule.call"
-        },
-        {
-          "actions": [
-            "notify",
-            {
-              "set_tweak": "sound",
-              "value": "default"
-            },
-            {
-              "set_tweak": "highlight"
-            }
-          ],
-          "conditions": [
-            {
-              "kind": "contains_display_name"
-            }
-          ],
-          "default": true,
-          "enabled": true,
-          "rule_id": ".m.rule.contains_display_name"
-        },
-        {
-          "actions": [
-            "notify",
-            {
-              "set_tweak": "sound",
-              "value": "default"
-            },
-            {
-              "set_tweak": "highlight",
-              "value": false
-            }
-          ],
-          "conditions": [
-            {
-              "kind": "room_member_count",
-              "is": "2"
-            },
-            {
-              "kind": "event_match",
-              "key": "type",
-              "pattern": "m.room.message"
-            }
-          ],
-          "default": true,
-          "enabled": true,
-          "rule_id": ".m.rule.room_one_to_one"
-        },
-        {
-          "actions": [
-            "notify",
-            {
-              "set_tweak": "sound",
-              "value": "default"
-            },
-            {
-              "set_tweak": "highlight",
-              "value": false
-            }
-          ],
-          "conditions": [
-            {
-              "key": "type",
-              "kind": "event_match",
-              "pattern": "m.room.member"
-            },
-            {
-              "key": "content.membership",
-              "kind": "event_match",
-              "pattern": "invite"
-            },
-            {
-              "key": "state_key",
-              "kind": "event_match",
-              "pattern": "@alice:example.com"
-            }
-          ],
-          "default": true,
-          "enabled": true,
-          "rule_id": ".m.rule.invite_for_me"
-        },
-        {
-          "actions": [
-            "notify",
-            {
-              "set_tweak": "highlight",
-              "value": false
-            }
-          ],
-          "conditions": [
-            {
-              "key": "type",
-              "kind": "event_match",
-              "pattern": "m.room.member"
-            }
-          ],
-          "default": true,
-          "enabled": true,
-          "rule_id": ".m.rule.member_event"
-        },
-        {
-          "actions": [
-            "notify",
-            {
-              "set_tweak": "highlight",
-              "value": false
-            }
-          ],
-          "conditions": [
-            {
-              "key": "type",
-              "kind": "event_match",
-              "pattern": "m.room.message"
-            }
-          ],
-          "default": true,
-          "enabled": true,
-          "rule_id": ".m.rule.message"
-        }
-      ]
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.receipt.yaml b/data/event-schemas/examples/m.receipt.yaml
deleted file mode 100644
index c52d8540..00000000
--- a/data/event-schemas/examples/m.receipt.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-{
-  "$ref": "core/room_edu.json",
-  "type": "m.receipt",
-  "content": {
-    "$1435641916114394fHBLK:matrix.org": {
-      "m.read": {
-        "@rikj:jki.re": {
-          "ts": 1436451550453
-        }
-      }
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.room.avatar.yaml b/data/event-schemas/examples/m.room.avatar.yaml
deleted file mode 100644
index cf0d17f3..00000000
--- a/data/event-schemas/examples/m.room.avatar.yaml
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.avatar",
-  "state_key": "",
-  "content": {
-    "info": {
-        "h": 398,
-        "w": 394,
-        "mimetype": "image/jpeg",
-        "size": 31037
-    },
-    "url": "mxc://example.org/JWEIFJgwEIhweiWJE"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.canonical_alias.yaml b/data/event-schemas/examples/m.room.canonical_alias.yaml
deleted file mode 100644
index 698c11b8..00000000
--- a/data/event-schemas/examples/m.room.canonical_alias.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.canonical_alias",
-  "state_key": "",
-  "content": {
-    "alias": "#somewhere:localhost",
-    "alt_aliases": [
-      "#somewhere:example.org",
-      "#myroom:example.com"
-    ]
-  }
-}
diff --git a/data/event-schemas/examples/m.room.create.yaml b/data/event-schemas/examples/m.room.create.yaml
deleted file mode 100644
index e33dbc3b..00000000
--- a/data/event-schemas/examples/m.room.create.yaml
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.create",
-  "state_key": "",
-  "content": {
-    "creator": "@example:example.org",
-    "room_version": "1",
-    "m.federate": true,
-    "predecessor": {
-      "event_id": "$something:example.org",
-      "room_id": "!oldroom:example.org"
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.room.encrypted$megolm.yaml b/data/event-schemas/examples/m.room.encrypted$megolm.yaml
deleted file mode 100644
index ac542e25..00000000
--- a/data/event-schemas/examples/m.room.encrypted$megolm.yaml
+++ /dev/null
@@ -1,11 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.encrypted",
-  "content": {
-    "algorithm": "m.megolm.v1.aes-sha2",
-    "ciphertext": "AwgAEnACgAkLmt6qF84IK++J7UDH2Za1YVchHyprqTqsg...",
-    "device_id": "RJYKSTBOIE",
-    "sender_key": "IlRMeOPX2e0MurIyfWEucYBRVOEEUMrOHqn/8mLqMjA",
-    "session_id": "X3lUlvLELLYxeTx4yOVu6UDpasGEVO0Jbu+QFnm0cKQ"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.encrypted$olm.yaml b/data/event-schemas/examples/m.room.encrypted$olm.yaml
deleted file mode 100644
index 381651d9..00000000
--- a/data/event-schemas/examples/m.room.encrypted$olm.yaml
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.encrypted",
-  "content": {
-    "algorithm": "m.olm.v1.curve25519-aes-sha2",
-    "sender_key": "Szl29ksW/L8yZGWAX+8dY1XyFi+i5wm+DRhTGkbMiwU",
-    "ciphertext": {
-      "7qZcfnBmbEGzxxaWfBjElJuvn7BZx+lSz/SvFrDF/z8": {
-        "type": 0,
-        "body": "AwogGJJzMhf/S3GQFXAOrCZ3iKyGU5ZScVtjI0KypTYrW..."
-      }
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.room.encryption.yaml b/data/event-schemas/examples/m.room.encryption.yaml
deleted file mode 100644
index 6158b937..00000000
--- a/data/event-schemas/examples/m.room.encryption.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.encryption",
-  "state_key": "",
-  "content": {
-    "algorithm": "m.megolm.v1.aes-sha2",
-    "rotation_period_ms": 604800000,
-    "rotation_period_msgs": 100
-  }
-}
diff --git a/data/event-schemas/examples/m.room.guest_access.yaml b/data/event-schemas/examples/m.room.guest_access.yaml
deleted file mode 100644
index a6deff8c..00000000
--- a/data/event-schemas/examples/m.room.guest_access.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.guest_access",
-  "state_key": "",
-  "content": {
-    "guest_access": "can_join"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.history_visibility.yaml b/data/event-schemas/examples/m.room.history_visibility.yaml
deleted file mode 100644
index 27c4fec3..00000000
--- a/data/event-schemas/examples/m.room.history_visibility.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.history_visibility",
-  "state_key": "",
-  "content": {
-    "history_visibility": "shared"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.join_rules$restricted.yaml b/data/event-schemas/examples/m.room.join_rules$restricted.yaml
deleted file mode 100644
index bf807e54..00000000
--- a/data/event-schemas/examples/m.room.join_rules$restricted.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.join_rules",
-  "state_key": "",
-  "content": {
-    "join_rule": "restricted",
-    "allow": [
-      {
-        "type": "m.room_membership",
-        "room_id": "!other:example.org"
-      },
-      {
-        "type": "m.room_membership",
-        "room_id": "!elsewhere:example.org"
-      }
-    ]
-  }
-}
diff --git a/data/event-schemas/examples/m.room.join_rules.yaml b/data/event-schemas/examples/m.room.join_rules.yaml
deleted file mode 100644
index 2873be78..00000000
--- a/data/event-schemas/examples/m.room.join_rules.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.join_rules",
-  "state_key": "",
-  "content": {
-    "join_rule": "public"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.member$invite_room_state.yaml b/data/event-schemas/examples/m.room.member$invite_room_state.yaml
deleted file mode 100644
index 38a4951c..00000000
--- a/data/event-schemas/examples/m.room.member$invite_room_state.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
-{
-  "$ref": "m.room.member.yaml",
-  "content": {
-    "membership": "invite",
-    "avatar_url": "mxc://example.org/SEsfnsuifSDFSSEF",
-    "displayname": "Alice Margatroid",
-    "reason": "Looking for support"
-  },
-  "unsigned": {
-    "age": 1234,
-    "invite_room_state": {
-      "$ref": "invite_room_state.json"
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.room.member$join_authorised_via_users_server.yaml b/data/event-schemas/examples/m.room.member$join_authorised_via_users_server.yaml
deleted file mode 100644
index eb8c84bc..00000000
--- a/data/event-schemas/examples/m.room.member$join_authorised_via_users_server.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-{
-  "$ref": "m.room.member.yaml",
-  "content": {
-    "membership": "join",
-    "avatar_url": "mxc://example.org/SEsfnsuifSDFSSEF",
-    "displayname": "Alice Margatroid",
-    "join_authorised_via_users_server": "@bob:other.example.org"
-  },
-  "unsigned": {
-    "age": 1234
-  }
-}
diff --git a/data/event-schemas/examples/m.room.member$knock_room_state.yaml b/data/event-schemas/examples/m.room.member$knock_room_state.yaml
deleted file mode 100644
index c1ec3a32..00000000
--- a/data/event-schemas/examples/m.room.member$knock_room_state.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
-{
-  "$ref": "m.room.member.yaml",
-  "content": {
-    "membership": "knock",
-    "avatar_url": "mxc://example.org/SEsfnsuifSDFSSEF",
-    "displayname": "Alice Margatroid",
-    "reason": "Looking for support"
-  },
-  "unsigned": {
-    "age": 1234,
-    "knock_room_state": {
-      "$ref": "knock_room_state.json"
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.room.member$third_party_invite.yaml b/data/event-schemas/examples/m.room.member$third_party_invite.yaml
deleted file mode 100644
index ead4cbee..00000000
--- a/data/event-schemas/examples/m.room.member$third_party_invite.yaml
+++ /dev/null
@@ -1,20 +0,0 @@
-{
-  "$ref": "m.room.member.yaml",
-  "content": {
-    "membership": "invite",
-    "avatar_url": "mxc://example.org/SEsfnsuifSDFSSEF",
-    "displayname": "Alice Margatroid",
-    "third_party_invite": {
-      "display_name": "alice",
-      "signed": {
-        "mxid": "@alice:example.org",
-        "signatures": {
-          "magic.forest": {
-            "ed25519:3": "fQpGIW1Snz+pwLZu6sTy2aHy/DYWWTspTJRPyNp0PKkymfIsNffysMl6ObMMFdIJhk6g6pwlIqZ54rxo8SLmAg"
-          }
-        },
-        "token": "abc123"
-      }
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.room.member.yaml b/data/event-schemas/examples/m.room.member.yaml
deleted file mode 100644
index 5147b258..00000000
--- a/data/event-schemas/examples/m.room.member.yaml
+++ /dev/null
@@ -1,11 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "state_key": "@alice:example.org",
-  "type": "m.room.member",
-  "content": {
-    "membership": "join",
-    "avatar_url": "mxc://example.org/SEsfnsuifSDFSSEF",
-    "displayname": "Alice Margatroid",
-    "reason": "Looking for support"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.message$m.audio.yaml b/data/event-schemas/examples/m.room.message$m.audio.yaml
deleted file mode 100644
index 58e874e0..00000000
--- a/data/event-schemas/examples/m.room.message$m.audio.yaml
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.message",
-  "content": {
-    "body": "Bee Gees - Stayin' Alive",
-    "url": "mxc://example.org/ffed755USFFxlgbQYZGtryd",
-    "info": {
-      "duration": 2140786,
-      "size": 1563685,
-      "mimetype": "audio/mpeg"
-    },
-    "msgtype": "m.audio"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.message$m.emote.yaml b/data/event-schemas/examples/m.room.message$m.emote.yaml
deleted file mode 100644
index 5fecb9a3..00000000
--- a/data/event-schemas/examples/m.room.message$m.emote.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.message",
-  "content": {
-    "body": "thinks this is an example emote",
-    "msgtype": "m.emote",
-    "format": "org.matrix.custom.html",
-    "formatted_body": "thinks <b>this</b> is an example emote"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.message$m.file.yaml b/data/event-schemas/examples/m.room.message$m.file.yaml
deleted file mode 100644
index c375861b..00000000
--- a/data/event-schemas/examples/m.room.message$m.file.yaml
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.message",
-  "content": {
-    "body": "something-important.doc",
-    "filename": "something-important.doc",
-    "info": {
-      "mimetype": "application/msword",
-      "size": 46144
-    },
-    "msgtype": "m.file",
-    "url": "mxc://example.org/FHyPlCeYUSFFxlgbQYZmoEoe"
-  }
-} 
diff --git a/data/event-schemas/examples/m.room.message$m.image.yaml b/data/event-schemas/examples/m.room.message$m.image.yaml
deleted file mode 100644
index a0e38c82..00000000
--- a/data/event-schemas/examples/m.room.message$m.image.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.message",
-  "content": {
-    "body": "filename.jpg",
-    "info": {
-        "h": 398,
-        "w": 394,
-        "mimetype": "image/jpeg",
-        "size": 31037
-    },
-    "url": "mxc://example.org/JWEIFJgwEIhweiWJE",
-    "msgtype": "m.image"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.message$m.location.yaml b/data/event-schemas/examples/m.room.message$m.location.yaml
deleted file mode 100644
index 49820419..00000000
--- a/data/event-schemas/examples/m.room.message$m.location.yaml
+++ /dev/null
@@ -1,18 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.message",
-  "content": {
-    "body": "Big Ben, London, UK",
-    "geo_uri": "geo:51.5008,0.1247",
-    "info": {
-      "thumbnail_url": "mxc://example.org/FHyPlCeYUSFFxlgbQYZmoEoe",
-      "thumbnail_info": {
-        "mimetype": "image/jpeg",
-        "size": 46144,
-        "w": 300,
-        "h": 300
-      }
-    },
-    "msgtype": "m.location"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.message$m.notice.yaml b/data/event-schemas/examples/m.room.message$m.notice.yaml
deleted file mode 100644
index d33751da..00000000
--- a/data/event-schemas/examples/m.room.message$m.notice.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.message",
-  "content": {
-    "body": "This is an example notice",
-    "msgtype": "m.notice",
-    "format": "org.matrix.custom.html",
-    "formatted_body": "This is an <strong>example</strong> notice"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.message$m.server_notice.yaml b/data/event-schemas/examples/m.room.message$m.server_notice.yaml
deleted file mode 100644
index 0eb44ea7..00000000
--- a/data/event-schemas/examples/m.room.message$m.server_notice.yaml
+++ /dev/null
@@ -1,11 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.message",
-  "content": {
-    "body": "Human-readable message to explain the notice",
-    "msgtype": "m.server_notice",
-    "server_notice_type": "m.server_notice.usage_limit_reached",
-    "admin_contact": "mailto:server.admin@example.org",
-    "limit_type": "monthly_active_user"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.message$m.text.yaml b/data/event-schemas/examples/m.room.message$m.text.yaml
deleted file mode 100644
index ba1fb769..00000000
--- a/data/event-schemas/examples/m.room.message$m.text.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.message",
-  "content": {
-    "body": "This is an example text message",
-    "msgtype": "m.text",
-    "format": "org.matrix.custom.html",
-    "formatted_body": "<b>This is an example text message</b>"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.message$m.video.yaml b/data/event-schemas/examples/m.room.message$m.video.yaml
deleted file mode 100644
index 71f19a66..00000000
--- a/data/event-schemas/examples/m.room.message$m.video.yaml
+++ /dev/null
@@ -1,23 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.message",
-  "content": {
-    "body": "Gangnam Style",
-    "url": "mxc://example.org/a526eYUSFFxlgbQYZmo442",
-    "info": {
-      "thumbnail_url": "mxc://example.org/FHyPlCeYUSFFxlgbQYZmoEoe",
-      "thumbnail_info": {
-        "mimetype": "image/jpeg",
-        "size": 46144,
-        "w": 300,
-        "h": 300
-      },
-      "w": 480,
-      "h": 320,
-      "duration": 2140786,
-      "size": 1563685,
-      "mimetype": "video/mp4"
-    },
-    "msgtype": "m.video"
-  }
-} 
diff --git a/data/event-schemas/examples/m.room.message.feedback.yaml b/data/event-schemas/examples/m.room.message.feedback.yaml
deleted file mode 100644
index e146e874..00000000
--- a/data/event-schemas/examples/m.room.message.feedback.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.message.feedback",
-  "content": {
-    "type": "delivered",
-    "target_event_id": "$WEIGFHFW:localhost"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.name.yaml b/data/event-schemas/examples/m.room.name.yaml
deleted file mode 100644
index e77e2b53..00000000
--- a/data/event-schemas/examples/m.room.name.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.name",
-  "state_key": "",
-  "content": {
-    "name": "The room name"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.pinned_events.yaml b/data/event-schemas/examples/m.room.pinned_events.yaml
deleted file mode 100644
index 5bf31f05..00000000
--- a/data/event-schemas/examples/m.room.pinned_events.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.pinned_events",
-  "state_key": "",
-  "content": {
-    "pinned": ["$someevent:example.org"]
-  }
-}
diff --git a/data/event-schemas/examples/m.room.power_levels.yaml b/data/event-schemas/examples/m.room.power_levels.yaml
deleted file mode 100644
index ad741e88..00000000
--- a/data/event-schemas/examples/m.room.power_levels.yaml
+++ /dev/null
@@ -1,24 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.power_levels",
-  "state_key": "",
-  "content": {
-    "ban": 50,
-    "events": {
-      "m.room.name": 100,
-      "m.room.power_levels": 100
-    },
-    "events_default": 0,
-    "invite": 50,
-    "kick": 50,
-    "redact": 50,
-    "state_default": 50,
-    "users": {
-      "@example:localhost": 100
-    },
-    "users_default": 0,
-    "notifications": {
-      "room": 20
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.room.redaction.yaml b/data/event-schemas/examples/m.room.redaction.yaml
deleted file mode 100644
index 42bc8411..00000000
--- a/data/event-schemas/examples/m.room.redaction.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.room.redaction",
-  "redacts": "$fukweghifu23:localhost",
-  "content": {
-    "reason": "Spamming"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.server_acl.yaml b/data/event-schemas/examples/m.room.server_acl.yaml
deleted file mode 100644
index 06586f79..00000000
--- a/data/event-schemas/examples/m.room.server_acl.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.server_acl",
-  "state_key": "",
-  "content": {
-    "allow_ip_literals": false,
-    "allow": ["*"],
-    "deny": ["*.evil.com", "evil.com"]
-  }
-}
diff --git a/data/event-schemas/examples/m.room.third_party_invite.yaml b/data/event-schemas/examples/m.room.third_party_invite.yaml
deleted file mode 100644
index 03f35375..00000000
--- a/data/event-schemas/examples/m.room.third_party_invite.yaml
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.third_party_invite",
-  "state_key": "pc98",
-  "content": {
-    "display_name": "Alice Margatroid",
-    "key_validity_url": "https://magic.forest/verifykey",
-    "public_key": "abc123",
-    "public_keys": [{
-      "public_key": "def456",
-      "key_validity_url": "https://magic.forest/verifykey"
-    }]
-  }
-}
diff --git a/data/event-schemas/examples/m.room.tombstone.yaml b/data/event-schemas/examples/m.room.tombstone.yaml
deleted file mode 100644
index b6224476..00000000
--- a/data/event-schemas/examples/m.room.tombstone.yaml
+++ /dev/null
@@ -1,9 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.tombstone",
-  "state_key": "",
-  "content": {
-    "body": "This room has been replaced",
-    "replacement_room": "!newroom:example.org"
-  }
-}
diff --git a/data/event-schemas/examples/m.room.topic.yaml b/data/event-schemas/examples/m.room.topic.yaml
deleted file mode 100644
index 69e5d4f1..00000000
--- a/data/event-schemas/examples/m.room.topic.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.room.topic",
-  "state_key": "",
-  "content": {
-    "topic": "A room topic"
-  }
-}
diff --git a/data/event-schemas/examples/m.room_key.withheld.yaml b/data/event-schemas/examples/m.room_key.withheld.yaml
deleted file mode 100644
index fa8f135f..00000000
--- a/data/event-schemas/examples/m.room_key.withheld.yaml
+++ /dev/null
@@ -1,12 +0,0 @@
-{
-  "$ref": "core/event.json",
-  "type": "m.room_key.withheld",
-  "content": {
-    "algorithm": "m.megolm.v1.aes-sha2",
-    "room_id": "!Cuyf34gef24t:localhost",
-    "session_id": "X3lUlvLELLYxeTx4yOVu6UDpasGEVO0Jbu+QFnm0cKQ",
-    "sender_key": "RF3s+E7RkTQTGF2d8Deol0FkQvgII2aJDf3/Jp5mxVU",
-    "code": "m.unverified",
-    "reason": "Device not verified"
-  }
-}
diff --git a/data/event-schemas/examples/m.room_key.yaml b/data/event-schemas/examples/m.room_key.yaml
deleted file mode 100644
index dba497b4..00000000
--- a/data/event-schemas/examples/m.room_key.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/event.json",
-  "type": "m.room_key",
-  "content": {
-    "algorithm": "m.megolm.v1.aes-sha2",
-    "room_id": "!Cuyf34gef24t:localhost",
-    "session_id": "X3lUlvLELLYxeTx4yOVu6UDpasGEVO0Jbu+QFnm0cKQ",
-    "session_key": "AgAAAADxKHa9uFxcXzwYoNueL5Xqi69IkD4sni8LlfJL7qNBEY..."
-  }
-}
diff --git a/data/event-schemas/examples/m.room_key_request$cancel_request.yaml b/data/event-schemas/examples/m.room_key_request$cancel_request.yaml
deleted file mode 100644
index afc1c350..00000000
--- a/data/event-schemas/examples/m.room_key_request$cancel_request.yaml
+++ /dev/null
@@ -1,8 +0,0 @@
-{
-  "content": {
-    "action": "request_cancellation",
-    "requesting_device_id": "RJYKSTBOIE",
-    "request_id": "1495474790150.19"
-  },
-  "type": "m.room_key_request"
-}
diff --git a/data/event-schemas/examples/m.room_key_request$request.yaml b/data/event-schemas/examples/m.room_key_request$request.yaml
deleted file mode 100644
index 8557f08e..00000000
--- a/data/event-schemas/examples/m.room_key_request$request.yaml
+++ /dev/null
@@ -1,14 +0,0 @@
-{
-  "content": {
-    "body": {
-      "algorithm": "m.megolm.v1.aes-sha2",
-      "room_id": "!Cuyf34gef24t:localhost",
-      "session_id": "X3lUlvLELLYxeTx4yOVu6UDpasGEVO0Jbu+QFnm0cKQ",
-      "sender_key": "RF3s+E7RkTQTGF2d8Deol0FkQvgII2aJDf3/Jp5mxVU"
-    },
-    "action": "request",
-    "requesting_device_id": "RJYKSTBOIE",
-    "request_id": "1495474790150.19"
-  },
-  "type": "m.room_key_request"
-}
diff --git a/data/event-schemas/examples/m.space.child.yaml b/data/event-schemas/examples/m.space.child.yaml
deleted file mode 100644
index 1f7692c7..00000000
--- a/data/event-schemas/examples/m.space.child.yaml
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.space.child",
-  "state_key": "!roomid:example.org",
-  "content": {
-    "suggested": true,
-    "via": ["example.org", "other.example.org"],
-    "order": "lexicographically_compare_me"
-  }
-}
diff --git a/data/event-schemas/examples/m.space.parent.yaml b/data/event-schemas/examples/m.space.parent.yaml
deleted file mode 100644
index 81a2b270..00000000
--- a/data/event-schemas/examples/m.space.parent.yaml
+++ /dev/null
@@ -1,9 +0,0 @@
-{
-  "$ref": "core/state_event.json",
-  "type": "m.space.parent",
-  "state_key": "!parent_roomid:example.org",
-  "content": {
-    "canonical": true,
-    "via": ["example.org", "other.example.org"]
-  }
-}
diff --git a/data/event-schemas/examples/m.sticker.yaml b/data/event-schemas/examples/m.sticker.yaml
deleted file mode 100644
index 971cdc90..00000000
--- a/data/event-schemas/examples/m.sticker.yaml
+++ /dev/null
@@ -1,21 +0,0 @@
-{
-  "$ref": "core/room_event.json",
-  "type": "m.sticker",
-  "content": {
-    "body": "Landing",
-    "info": {
-      "mimetype": "image/png",
-      "thumbnail_info": {
-        "mimetype": "image/png",
-        "h": 200,
-        "w": 140,
-        "size": 73602
-      },
-      "h": 200,
-      "thumbnail_url": "mxc://matrix.org/sHhqkFCvSkFwtmvtETOtKnLP",
-      "w": 140,
-      "size": 73602
-    },
-    "url": "mxc://matrix.org/sHhqkFCvSkFwtmvtETOtKnLP"
-  }
-}
diff --git a/data/event-schemas/examples/m.tag.yaml b/data/event-schemas/examples/m.tag.yaml
deleted file mode 100644
index 7e56b1ea..00000000
--- a/data/event-schemas/examples/m.tag.yaml
+++ /dev/null
@@ -1,9 +0,0 @@
-{
-  "$ref": "core/event.json",
-  "type": "m.tag",
-  "content": {
-    "tags": {
-      "u.work": {"order": 0.9}
-    }
-  }
-}
diff --git a/data/event-schemas/examples/m.typing.yaml b/data/event-schemas/examples/m.typing.yaml
deleted file mode 100644
index 416b9968..00000000
--- a/data/event-schemas/examples/m.typing.yaml
+++ /dev/null
@@ -1,7 +0,0 @@
-{
-  "$ref": "core/room_edu.json",
-  "type": "m.typing",
-  "content": {
-    "user_ids": ["@alice:matrix.org", "@bob:example.com"]
-  }
-}
diff --git a/data/event-schemas/moderation_policy_rule.yaml b/data/event-schemas/moderation_policy_rule.yaml
deleted file mode 100644
index a57a1ffe..00000000
--- a/data/event-schemas/moderation_policy_rule.yaml
+++ /dev/null
@@ -1,30 +0,0 @@
-# Copyright 2020 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.
-properties:
-  entity:
-    description: |-
-      The entity affected by this rule. Glob characters `*` and `?` can be used
-      to match zero or more and one or more characters respectively.
-    type: string
-  recommendation:
-    description: The suggested action to take. Currently only `m.ban` is specified.
-    type: string
-  reason:
-    description: The human-readable description for the `recommendation`.
-    type: string
-type: object
-required:
-  - entity
-  - recommendation
-  - reason
diff --git a/data/event-schemas/schema/core-event-schema/event.yaml b/data/event-schemas/schema/core-event-schema/event.yaml
deleted file mode 100644
index 0fe5ac6c..00000000
--- a/data/event-schemas/schema/core-event-schema/event.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
-description: The basic set of fields all events must have.
-properties:
-  content:
-    description: The fields in this object will vary depending on the type of event.
-      When interacting with the REST API, this is the HTTP body.
-    type: object
-  type:
-    description: The type of event. This SHOULD be namespaced similar to Java package
-      naming conventions e.g. 'com.example.subdomain.event.type'
-    type: string
-required:
-  - type
-  - content
-title: Event
-type: object
diff --git a/data/event-schemas/schema/core-event-schema/msgtype_infos/image_info.yaml b/data/event-schemas/schema/core-event-schema/msgtype_infos/image_info.yaml
deleted file mode 100644
index b83bf6c1..00000000
--- a/data/event-schemas/schema/core-event-schema/msgtype_infos/image_info.yaml
+++ /dev/null
@@ -1,37 +0,0 @@
-$schema: http://json-schema.org/draft-04/schema#
-description: Metadata about an image.
-properties:
-  h:
-    description: |-
-      The intended display height of the image in pixels. This may
-      differ from the intrinsic dimensions of the image file.
-    type: integer
-  w:
-    description: |-
-      The intended display width of the image in pixels. This may
-      differ from the intrinsic dimensions of the image file.
-    type: integer
-  mimetype:
-    description: The mimetype of the image, e.g. `image/jpeg`.
-    type: string
-  size:
-    description: Size of the image in bytes.
-    type: integer
-  thumbnail_url:
-    description: |-
-      The URL (typically [MXC URI](/client-server-api/#matrix-content-mxc-uris)) to a thumbnail of the image.
-      Only present if the thumbnail is unencrypted.
-    type: string
-  thumbnail_file:
-    description: |-
-      Information on the encrypted thumbnail file, as specified in
-      [End-to-end encryption](/client-server-api/#sending-encrypted-attachments).
-      Only present if the thumbnail is encrypted.
-    title: EncryptedFile
-    type: object
-  thumbnail_info:
-    allOf:
-      - $ref: thumbnail_info.yaml
-    description: Metadata about the image referred to in `thumbnail_url`.
-title: ImageInfo
-type: object
diff --git a/data/event-schemas/schema/core-event-schema/msgtype_infos/thumbnail_info.yaml b/data/event-schemas/schema/core-event-schema/msgtype_infos/thumbnail_info.yaml
deleted file mode 100644
index 79f7c253..00000000
--- a/data/event-schemas/schema/core-event-schema/msgtype_infos/thumbnail_info.yaml
+++ /dev/null
@@ -1,21 +0,0 @@
-$schema: http://json-schema.org/draft-04/schema#
-description: Metadata about a thumbnail image.
-properties:
-  h:
-    description: |-
-      The intended display height of the image in pixels. This may
-      differ from the intrinsic dimensions of the image file.
-    type: integer
-  w:
-    description: |-
-      The intended display width of the image in pixels. This may
-      differ from the intrinsic dimensions of the image file.
-    type: integer
-  mimetype:
-    description: The mimetype of the image, e.g. `image/jpeg`.
-    type: string
-  size:
-    description: Size of the image in bytes.
-    type: integer
-title: ThumbnailInfo
-type: object
diff --git a/data/event-schemas/schema/core-event-schema/room_event.yaml b/data/event-schemas/schema/core-event-schema/room_event.yaml
deleted file mode 100644
index 7eaae223..00000000
--- a/data/event-schemas/schema/core-event-schema/room_event.yaml
+++ /dev/null
@@ -1,13 +0,0 @@
-allOf:
-- $ref: sync_room_event.yaml
-description: Room Events have the following fields.
-properties:
-  room_id:
-    description: |-
-      The ID of the room associated with this event. Will not be present on events
-      that arrive through `/sync`, despite being required everywhere else.
-    type: string
-required:
-- room_id
-title: RoomEvent
-type: object
diff --git a/data/event-schemas/schema/core-event-schema/state_event.yaml b/data/event-schemas/schema/core-event-schema/state_event.yaml
deleted file mode 100644
index d2ff5243..00000000
--- a/data/event-schemas/schema/core-event-schema/state_event.yaml
+++ /dev/null
@@ -1,6 +0,0 @@
-allOf:
-- $ref: room_event.yaml
-- $ref: sync_state_event.yaml
-description: State Events have the following fields.
-title: StateEvent
-type: object
diff --git a/data/event-schemas/schema/core-event-schema/stripped_state.yaml b/data/event-schemas/schema/core-event-schema/stripped_state.yaml
deleted file mode 100644
index c98d8878..00000000
--- a/data/event-schemas/schema/core-event-schema/stripped_state.yaml
+++ /dev/null
@@ -1,44 +0,0 @@
-# Copyright 2019 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.
-
-# Note: this, and the example, are in the `event-schemas` directory because
-# the CS API uses a symlink. In order for the `m.room.member` event to
-# reference this, we'd need to use relative pathing. The symlink makes this
-# difficult because the schema would be at two different locations, with
-# different relative pathing.
-
-title: StrippedStateEvent
-type: object
-description: |-
-  A stripped down state event, with only the `type`, `state_key`,
-  `sender`, and `content` keys.
-properties:
-  content:
-    description: The `content` for the event.
-    title: EventContent
-    type: object
-  state_key:
-    description: The `state_key` for the event.
-    type: string
-  type:
-    description: The `type` for the event.
-    type: string
-  sender:
-    description: The `sender` for the event.
-    type: string
-required:
-  - type
-  - state_key
-  - content
-  - sender
diff --git a/data/event-schemas/schema/core-event-schema/sync_room_event.yaml b/data/event-schemas/schema/core-event-schema/sync_room_event.yaml
deleted file mode 100644
index 7ad7191b..00000000
--- a/data/event-schemas/schema/core-event-schema/sync_room_event.yaml
+++ /dev/null
@@ -1,43 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-# Note: this is technically not a core event schema, however it is included here
-# to keep things sane. The short story is that /sync doesn't require a room_id to
-# be on events, so we give it a whole event structure as a base for room_event.
-# This base doesn't declare a room_id, which instead appears in the room_event.
-
-allOf:
-- $ref: event.yaml
-description: In addition to the Event fields, Room Events have the following additional
-  fields.
-properties:
-  event_id:
-    description: The globally unique event identifier.
-    type: string
-  sender:
-    description: Contains the fully-qualified ID of the user who sent this event.
-    type: string
-  origin_server_ts:
-    description: Timestamp in milliseconds on originating homeserver
-      when this event was sent.
-    type: integer
-    format: int64
-  unsigned:
-    $ref: unsigned_prop.yaml
-required:
-- event_id
-- sender
-- origin_server_ts
-title: SyncRoomEvent
-type: object
diff --git a/data/event-schemas/schema/core-event-schema/sync_state_event.yaml b/data/event-schemas/schema/core-event-schema/sync_state_event.yaml
deleted file mode 100644
index 7033a5e6..00000000
--- a/data/event-schemas/schema/core-event-schema/sync_state_event.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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.
-
-# See sync_room_event.yaml for why this file is here.
-
-allOf:
-- $ref: sync_room_event.yaml
-description: In addition to the Room Event fields, State Events have the following
-  additional fields.
-properties:
-  state_key:
-    description: A unique key which defines the overwriting semantics for this piece
-      of room state. This value is often a zero-length string. The presence of this
-      key makes this event a State Event.
-
-      State keys starting with an `@` are reserved for referencing user IDs, such
-      as room members. With the exception of a few events, state events set with a
-      given user's ID as the state key MUST only be set by that user.
-    type: string
-required:
-- state_key
-title: SyncStateEvent
-type: object
diff --git a/data/event-schemas/schema/core-event-schema/unsigned_prop.yaml b/data/event-schemas/schema/core-event-schema/unsigned_prop.yaml
deleted file mode 100644
index 3ca19c41..00000000
--- a/data/event-schemas/schema/core-event-schema/unsigned_prop.yaml
+++ /dev/null
@@ -1,22 +0,0 @@
-# Copyright 2020 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.
-
-title: UnsignedData
-type: object
-description: Contains optional extra information about the event.
-properties:
-  age:
-    description: The time in milliseconds that has elapsed since the event was
-      sent.
-    type: integer
diff --git a/data/event-schemas/schema/m.accepted_terms.yaml b/data/event-schemas/schema/m.accepted_terms.yaml
deleted file mode 100644
index 510e741d..00000000
--- a/data/event-schemas/schema/m.accepted_terms.yaml
+++ /dev/null
@@ -1,23 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-description: |-
-  A list of terms URLs the user has previously accepted. Clients SHOULD use this
-  to avoid presenting the user with terms they have already agreed to.
-properties:
-  content:
-    type: object
-    properties:
-      accepted:
-        type: array
-        items:
-          type: string
-        description: |-
-          The list of URLs the user has previously accepted. Should be appended to
-          when the user agrees to new terms.
-  type:
-    enum:
-      - m.accepted_terms
-    type: string
-title: Accepted Terms of Service URLs
-type: object
diff --git a/data/event-schemas/schema/m.call.answer.yaml b/data/event-schemas/schema/m.call.answer.yaml
deleted file mode 100644
index 9d98dd7d..00000000
--- a/data/event-schemas/schema/m.call.answer.yaml
+++ /dev/null
@@ -1,44 +0,0 @@
-{
-    "type": "object",
-    "description": "This event is sent by the callee when they wish to answer the call.",
-    "allOf": [{
-        "$ref": "core-event-schema/room_event.yaml"
-    }],
-    "properties": {
-        "content": {
-            "type": "object",
-            "properties": {
-                "call_id": {
-                    "type": "string",
-                    "description": "The ID of the call this event relates to."
-                },
-                "answer": {
-                    "type": "object",
-                    "title": "Answer",
-                    "description": "The session description object",
-                    "properties": {
-                        "type": {
-                            "type": "string",
-                            "enum": ["answer"],
-                            "description": "The type of session description."
-                        },
-                        "sdp": {
-                            "type": "string",
-                            "description": "The SDP text of the session description."
-                        }
-                    },
-                    "required": ["type", "sdp"]
-                },
-                "version": {
-                    "type": "number",
-                    "description": ""
-                }
-            },
-            "required": ["call_id", "answer", "version"]
-        },
-        "type": {
-            "type": "string",
-            "enum": ["m.call.answer"]
-        }
-    }
-}
diff --git a/data/event-schemas/schema/m.call.candidates.yaml b/data/event-schemas/schema/m.call.candidates.yaml
deleted file mode 100644
index 7426717c..00000000
--- a/data/event-schemas/schema/m.call.candidates.yaml
+++ /dev/null
@@ -1,50 +0,0 @@
-{
-    "type": "object",
-    "description": "This event is sent by callers after sending an invite and by the callee after answering. Its purpose is to give the other party additional ICE candidates to try using to communicate.",
-    "allOf": [{
-        "$ref": "core-event-schema/room_event.yaml"
-    }],
-    "properties": {
-        "content": {
-            "type": "object",
-            "properties": {
-                "call_id": {
-                    "type": "string",
-                    "description": "The ID of the call this event relates to."
-                },
-                "candidates": {
-                    "type": "array",
-                    "description": "Array of objects describing the candidates.",
-                    "items": {
-                        "type": "object",
-                        "title": "Candidate",
-                        "properties": {
-                            "sdpMid": {
-                                "type": "string",
-                                "description": "The SDP media type this candidate is intended for."
-                            },
-                            "sdpMLineIndex": {
-                                "type": "number",
-                                "description": "The index of the SDP 'm' line this candidate is intended for."
-                            },
-                            "candidate": {
-                                "type": "string",
-                                "description": "The SDP 'a' line of the candidate."
-                            }
-                        },
-                        "required": ["candidate", "sdpMLineIndex", "sdpMid"]
-                    }
-                },
-                "version": {
-                    "type": "integer",
-                    "description": "The version of the VoIP specification this messages adheres to. This specification is version 0."
-                }
-            },
-            "required": ["call_id", "candidates", "version"]
-        },
-        "type": {
-            "type": "string",
-            "enum": ["m.call.candidates"]
-        }
-    }
-}
diff --git a/data/event-schemas/schema/m.call.hangup.yaml b/data/event-schemas/schema/m.call.hangup.yaml
deleted file mode 100644
index 116d5af7..00000000
--- a/data/event-schemas/schema/m.call.hangup.yaml
+++ /dev/null
@@ -1,35 +0,0 @@
-{
-    "type": "object",
-    "description": "Sent by either party to signal their termination of the call. This can be sent either once the call has has been established or before to abort the call.",
-    "allOf": [{
-        "$ref": "core-event-schema/room_event.yaml"
-    }],
-    "properties": {
-        "content": {
-            "type": "object",
-            "properties": {
-                "call_id": {
-                    "type": "string",
-                    "description": "The ID of the call this event relates to."
-                },
-                "version": {
-                    "type": "integer",
-                    "description": "The version of the VoIP specification this message adheres to. This specification is version 0."
-                },
-                "reason": {
-                    "type": "string",
-                    "description": "Optional error reason for the hangup. This should not be provided when the user naturally ends or rejects the call. When there was an error in the call negotiation, this should be `ice_failed` for when ICE negotiation fails or `invite_timeout` for when the other party did not answer in time.",
-                    "enum": [
-                        "ice_failed",
-                        "invite_timeout"
-                    ]
-                }
-            },
-            "required": ["call_id", "version"]
-        },
-        "type": {
-            "type": "string",
-            "enum": ["m.call.hangup"]
-        }
-    }
-}
diff --git a/data/event-schemas/schema/m.call.invite.yaml b/data/event-schemas/schema/m.call.invite.yaml
deleted file mode 100644
index 65796e1e..00000000
--- a/data/event-schemas/schema/m.call.invite.yaml
+++ /dev/null
@@ -1,48 +0,0 @@
-{
-    "type": "object",
-    "description": "This event is sent by the caller when they wish to establish a call.",
-    "allOf": [{
-        "$ref": "core-event-schema/room_event.yaml"
-    }],
-    "properties": {
-        "content": {
-            "type": "object",
-            "properties": {
-                "call_id": {
-                    "type": "string",
-                    "description": "A unique identifier for the call."
-                },
-                "offer": {
-                    "type": "object",
-                    "title": "Offer",
-                    "description": "The session description object",
-                    "properties": {
-                        "type": {
-                            "type": "string",
-                            "enum": ["offer"],
-                            "description": "The type of session description."
-                        },
-                        "sdp": {
-                            "type": "string",
-                            "description": "The SDP text of the session description."
-                        }
-                    },
-                    "required": ["type", "sdp"]
-                },
-                "version": {
-                    "type": "integer",
-                    "description": "The version of the VoIP specification this message adheres to. This specification is version 0."
-                },
-                "lifetime": {
-                    "type": "integer",
-                    "description": "The time in milliseconds that the invite is valid for. Once the invite age exceeds this value, clients should discard it. They should also no longer show the call as awaiting an answer in the UI."
-                }
-            },
-            "required": ["call_id", "offer", "version", "lifetime"]
-        },
-        "type": {
-            "type": "string",
-            "enum": ["m.call.invite"]
-        }
-    }
-}
diff --git a/data/event-schemas/schema/m.direct.yaml b/data/event-schemas/schema/m.direct.yaml
deleted file mode 100644
index f00b83bc..00000000
--- a/data/event-schemas/schema/m.direct.yaml
+++ /dev/null
@@ -1,23 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-description: |-
-  A map of which rooms are considered 'direct' rooms for specific users
-  is kept in  `account_data` in an event of type `m.direct`. The
-  content of this event is an object where the keys are the user IDs
-  and values are lists of room ID strings of the 'direct' rooms for
-  that user ID.
-properties:
-  content:
-    additionalProperties:
-      type: array
-      title: User ID
-      items:
-        type: string
-    type: object
-  type:
-    enum:
-      - m.direct
-    type: string
-title: Direct Chat Mapping
-type: object
diff --git a/data/event-schemas/schema/m.dummy.yaml b/data/event-schemas/schema/m.dummy.yaml
deleted file mode 100644
index 4699dd86..00000000
--- a/data/event-schemas/schema/m.dummy.yaml
+++ /dev/null
@@ -1,23 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  This event type is used to indicate new Olm sessions for end-to-end encryption.
-  Typically it is encrypted as an `m.room.encrypted` event, then sent as a [to-device](/client-server-api/#send-to-device-messaging)
-  event.
-
-  The event does not have any content associated with it. The sending client is expected
-  to send a key share request shortly after this message, causing the receiving client to
-  process this `m.dummy` event as the most recent event and using the keyshare request
-  to set up the session. The keyshare request and `m.dummy` combination should result
-  in the original sending client receiving keys over the newly established session.
-properties:
-  content:
-    properties: {}
-    type: object
-  type:
-    enum:
-      - m.dummy
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.forwarded_room_key.yaml b/data/event-schemas/schema/m.forwarded_room_key.yaml
deleted file mode 100644
index 71ea6690..00000000
--- a/data/event-schemas/schema/m.forwarded_room_key.yaml
+++ /dev/null
@@ -1,68 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  This event type is used to forward keys for end-to-end encryption. Typically
-  it is encrypted as an `m.room.encrypted` event, then sent as a [to-device](/client-server-api/#send-to-device-messaging)
-  event.
-properties:
-  content:
-    properties:
-      algorithm:
-        type: string
-        description: |-
-          The encryption algorithm the key in this event is to be used with.
-      room_id:
-        type: string
-        description: The room where the key is used.
-      sender_key:
-        type: string
-        description: |-
-          The Curve25519 key of the device which initiated the session originally.
-      session_id:
-        type: string
-        description: The ID of the session that the key is for.
-      session_key:
-        type: string
-        description: The key to be exchanged.
-      sender_claimed_ed25519_key:
-        type: string
-        description: |-
-          The Ed25519 key of the device which initiated the session originally.
-          It is 'claimed' because the receiving device has no way to tell that the
-          original room_key actually came from a device which owns the private part of
-          this key unless they have done device verification.
-      forwarding_curve25519_key_chain:
-        type: array
-        items:
-          type: string
-        description: |-
-          Chain of Curve25519 keys. It starts out empty, but each time the
-          key is forwarded to another device, the previous sender in the chain is added
-          to the end of the list. For example, if the key is forwarded from A to B to
-          C, this field is empty between A and B, and contains A's Curve25519 key between
-          B and C.
-      withheld:
-        type: object
-        description: |-
-          Indicates that the key cannot be used to decrypt all the messages
-          from the session because a portion of the session was withheld as
-          described in [Reporting that decryption keys are withheld](/client-server-api/#reporting-that-decryption-keys-are-withheld). This
-          object must include the `code` and `reason` properties from the
-          `m.room_key.withheld` message that was received by the sender of
-          this message.
-    required:
-      - algorithm
-      - room_id
-      - session_id
-      - session_key
-      - sender_claimed_ed25519_key
-      - forwarding_curve25519_key_chain
-      - sender_key
-    type: object
-  type:
-    enum:
-      - m.forwarded_room_key
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.fully_read.yaml b/data/event-schemas/schema/m.fully_read.yaml
deleted file mode 100644
index 6f8c832d..00000000
--- a/data/event-schemas/schema/m.fully_read.yaml
+++ /dev/null
@@ -1,25 +0,0 @@
-{
-    "type": "object",
-    "title": "Read Marker Location Event",
-    "description": "The current location of the user's read marker in a room. This event appears in the user's room account data for the room the marker is applicable for.",
-    "allOf": [{
-        "$ref": "core-event-schema/event.yaml"
-    }],
-    "properties": {
-        "content": {
-            "type": "object",
-            "properties": {
-                "event_id": {
-                    "type": "string",
-                    "description": "The event the user's read marker is located at in the room."
-                }
-            },
-            "required": ["event_id"]
-        },
-        "type": {
-            "type": "string",
-            "enum": ["m.fully_read"]
-        }
-    },
-    "required": ["type", "content"]
-}
diff --git a/data/event-schemas/schema/m.identity_server.yaml b/data/event-schemas/schema/m.identity_server.yaml
deleted file mode 100644
index acd0eb92..00000000
--- a/data/event-schemas/schema/m.identity_server.yaml
+++ /dev/null
@@ -1,23 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-description: |-
-  Persists the user's preferred identity server, or preference to not use
-  an identity server at all, in the user's account data.
-properties:
-  content:
-    type: object
-    properties:
-      base_url:
-        type: string
-        description: |-
-          The URL of the identity server the user prefers to use, or `null`
-          if the user does not want to use an identity server. This value is
-          similar in structure to the `base_url` for identity servers in the
-          `.well-known/matrix/client` schema.
-  type:
-    enum:
-      - m.identity_server
-    type: string
-title: Identity Server Preference
-type: object
diff --git a/data/event-schemas/schema/m.ignored_user_list.yaml b/data/event-schemas/schema/m.ignored_user_list.yaml
deleted file mode 100644
index 0f0b2f85..00000000
--- a/data/event-schemas/schema/m.ignored_user_list.yaml
+++ /dev/null
@@ -1,28 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-description: |-
-  A map of users which are considered ignored is kept in `account_data`
-  in an event type of `m.ignored_user_list`.
-properties:
-  content:
-    type: object
-    properties:
-      ignored_users:
-        type: object
-        title: "Ignored users"
-        description: "The map of users to ignore"
-        patternProperties:
-          "^@":
-            type: "object"
-            title: "Ignored User"
-            description: "An empty object for future enhancement"
-            x-pattern: "$USER_ID"
-    required:
-      - ignored_users
-  type:
-    enum:
-      - m.ignored_user_list
-    type: string
-title: Ignored User List
-type: object
diff --git a/data/event-schemas/schema/m.key.verification.accept.yaml b/data/event-schemas/schema/m.key.verification.accept.yaml
deleted file mode 100644
index ae63995b..00000000
--- a/data/event-schemas/schema/m.key.verification.accept.yaml
+++ /dev/null
@@ -1,61 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  Accepts a previously sent `m.key.verification.start` message.
-properties:
-  content:
-    properties:
-      transaction_id:
-        type: string
-        description: |-
-          Required when sent as a to-device message. An opaque identifier for
-          the verification process. Must be the same as the one used for the
-          `m.key.verification.start` message.
-      key_agreement_protocol:
-        type: string
-        description: |-
-          The key agreement protocol the device is choosing to use, out of the
-          options in the `m.key.verification.start` message.
-      hash:
-        type: string
-        description: |-
-          The hash method the device is choosing to use, out of the options in
-          the `m.key.verification.start` message.
-      message_authentication_code:
-        type: string
-        description: |-
-          The message authentication code the device is choosing to use, out of
-          the options in the `m.key.verification.start` message.
-      short_authentication_string:
-        type: array
-        description: |-
-          The SAS methods both devices involved in the verification process
-          understand. Must be a subset of the options in the `m.key.verification.start`
-          message.
-        items:
-          type: string
-          enum: ["decimal", "emoji"]
-      commitment:
-        type: string
-        description: |-
-          The hash (encoded as unpadded base64) of the concatenation of the device's
-          ephemeral public key (encoded as unpadded base64) and the canonical JSON
-          representation of the `m.key.verification.start` message.
-      m.relates_to:
-        allOf:
-          - $ref: m.key.verification.m.relates_to.yaml
-    required:
-      - method
-      - key_agreement_protocol
-      - hash
-      - message_authentication_code
-      - short_authentication_string
-      - commitment
-    type: object
-  type:
-    enum:
-      - m.key.verification.accept
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.key.verification.cancel.yaml b/data/event-schemas/schema/m.key.verification.cancel.yaml
deleted file mode 100644
index 6474b763..00000000
--- a/data/event-schemas/schema/m.key.verification.cancel.yaml
+++ /dev/null
@@ -1,71 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  Cancels a key verification process/request.
-properties:
-  content:
-    properties:
-      transaction_id:
-        type: string
-        description: |-
-          Required when sent as a to-device message. The opaque identifier for
-          the verification process/request.
-      reason:
-        type: string
-        description: |-
-          A human readable description of the `code`. The client should only rely on this
-          string if it does not understand the `code`.
-      code:
-        type: string
-        # Note: this is not an enum because we go into detail about the different
-        # error codes. If we made this an enum, we'd be repeating information.
-        # Also, we can't put a real bulleted list in here because the HTML2RST parser
-        # cuts the text at weird points, breaking the list completely.
-        description: |-
-          The error code for why the process/request was cancelled by the user. Error
-          codes should use the Java package naming convention if not in the following
-          list:
-
-          * `m.user`: The user cancelled the verification.
-
-          * `m.timeout`: The verification process timed out. Verification processes
-          can define their own timeout parameters.
-
-          * `m.unknown_transaction`: The device does not know about the given transaction
-          ID.
-
-          * `m.unknown_method`: The device does not know how to handle the requested
-          method. This should be sent for `m.key.verification.start` messages and
-          messages defined by individual verification processes.
-
-          * `m.unexpected_message`: The device received an unexpected message. Typically
-          raised when one of the parties is handling the verification out of order.
-
-          * `m.key_mismatch`: The key was not verified.
-
-          * `m.user_mismatch`: The expected user did not match the user verified.
-
-          * `m.invalid_message`: The message received was invalid.
-
-          * `m.accepted`: A `m.key.verification.request` was accepted by a different
-            device. The device receiving this error can ignore the verification request.
-
-          Clients should be careful to avoid error loops. For example, if a device sends
-          an incorrect message and the client returns `m.invalid_message` to which it
-          gets an unexpected response with `m.unexpected_message`, the client should not
-          respond again with `m.unexpected_message` to avoid the other device potentially
-          sending another error response.
-      m.relates_to:
-        allOf:
-          - $ref: m.key.verification.m.relates_to.yaml
-    required:
-      - code
-      - reason
-    type: object
-  type:
-    enum:
-      - m.key.verification.cancel
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.key.verification.done.yaml b/data/event-schemas/schema/m.key.verification.done.yaml
deleted file mode 100644
index bfdc540b..00000000
--- a/data/event-schemas/schema/m.key.verification.done.yaml
+++ /dev/null
@@ -1,23 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  Indicates that a verification process/request has completed successfully.
-properties:
-  content:
-    properties:
-      transaction_id:
-        type: string
-        description: |-
-          Required when sent as a to-device message. The opaque identifier for
-          the verification process/request.
-      m.relates_to:
-        allOf:
-          - $ref: m.key.verification.m.relates_to.yaml
-    type: object
-  type:
-    enum:
-      - m.key.verification.done
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.key.verification.key.yaml b/data/event-schemas/schema/m.key.verification.key.yaml
deleted file mode 100644
index 62704ea7..00000000
--- a/data/event-schemas/schema/m.key.verification.key.yaml
+++ /dev/null
@@ -1,30 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  Sends the ephemeral public key for a device to the partner device.
-properties:
-  content:
-    properties:
-      transaction_id:
-        type: string
-        description: |-
-          Required when sent as a to-device message. An opaque identifier for
-          the verification process. Must be the same as the one used for the
-          `m.key.verification.start` message.
-      key:
-        type: string
-        description: |-
-          The device's ephemeral public key, encoded as unpadded base64.
-      m.relates_to:
-        allOf:
-          - $ref: m.key.verification.m.relates_to.yaml
-    required:
-      - key
-    type: object
-  type:
-    enum:
-      - m.key.verification.key
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.key.verification.m.relates_to.yaml b/data/event-schemas/schema/m.key.verification.m.relates_to.yaml
deleted file mode 100644
index 670fd606..00000000
--- a/data/event-schemas/schema/m.key.verification.m.relates_to.yaml
+++ /dev/null
@@ -1,20 +0,0 @@
----
-description: |-
-  Required when sent as an in-room message. Indicates the
-  `m.key.verification.request` that this message is related to. Note that for
-  encrypted messages, this property should be in the unencrypted portion of the
-  event.
-properties:
-  rel_type:
-    type: string
-    enum:
-      - m.reference
-    description: |-
-      The relationship type.
-  event_id:
-    type: string
-    description: |-
-      The event ID of the `m.key.verification.request` that this message is
-      related to.
-type: object
-title: VerificationRelatesTo
diff --git a/data/event-schemas/schema/m.key.verification.mac.yaml b/data/event-schemas/schema/m.key.verification.mac.yaml
deleted file mode 100644
index 9f7f5f4f..00000000
--- a/data/event-schemas/schema/m.key.verification.mac.yaml
+++ /dev/null
@@ -1,40 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  Sends the MAC of a device's key to the partner device.
-properties:
-  content:
-    properties:
-      transaction_id:
-        type: string
-        description: |-
-          Required when sent as a to-device message. An opaque identifier for
-          the verification process. Must be the same as the one used for the
-          `m.key.verification.start` message.
-      mac:
-        type: object
-        description: |-
-          A map of the key ID to the MAC of the key, using the algorithm in the
-          verification process. The MAC is encoded as unpadded base64.
-        additionalProperties:
-          type: string
-          description: The key's MAC, encoded as unpadded base64.
-      keys:
-        type: string
-        description: |-
-          The MAC of the comma-separated, sorted, list of key IDs given in the `mac`
-          property, encoded as unpadded base64.
-      m.relates_to:
-        allOf:
-          - $ref: m.key.verification.m.relates_to.yaml
-    required:
-      - mac
-      - keys
-    type: object
-  type:
-    enum:
-      - m.key.verification.mac
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.key.verification.ready.yaml b/data/event-schemas/schema/m.key.verification.ready.yaml
deleted file mode 100644
index bf9d975b..00000000
--- a/data/event-schemas/schema/m.key.verification.ready.yaml
+++ /dev/null
@@ -1,40 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  Accepts a key verification request. Sent in response to an
-  `m.key.verification.request` event.
-properties:
-  content:
-    properties:
-      from_device:
-        type: string
-        description: |-
-          The device ID which is accepting the request.
-      transaction_id:
-        type: string
-        description: |-
-          Required when sent as a to-device message. The transaction ID of the
-          verification request, as given in the `m.key.verification.request`
-          message.
-      methods:
-        type: array
-        description: |-
-          The verification methods supported by the sender, corresponding to
-          the verification methods indicated in the
-          `m.key.verification.request` message.
-        items:
-          type: string
-      m.relates_to:
-        allOf:
-          - $ref: m.key.verification.m.relates_to.yaml
-    required:
-      - from_device
-      - methods
-    type: object
-  type:
-    enum:
-      - m.key.verification.ready
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.key.verification.request.yaml b/data/event-schemas/schema/m.key.verification.request.yaml
deleted file mode 100644
index 7732cf38..00000000
--- a/data/event-schemas/schema/m.key.verification.request.yaml
+++ /dev/null
@@ -1,42 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  Requests a key verification with another user's devices.
-properties:
-  content:
-    properties:
-      from_device:
-        type: string
-        description: |-
-          The device ID which is initiating the request.
-      transaction_id:
-        type: string
-        description: |-
-          Required when sent as a to-device message. An opaque identifier for
-          the verification request. Must be unique with respect to the devices
-          involved.
-      methods:
-        type: array
-        description: |-
-          The verification methods supported by the sender.
-        items:
-          type: string
-      timestamp:
-        type: integer
-        format: int64
-        description: |-
-          Required when sent as a to-device message. The POSIX timestamp in
-          milliseconds for when the request was made. If the request is in the
-          future by more than 5 minutes or more than 10 minutes in the past,
-          the message should be ignored by the receiver.
-    required:
-      - from_device
-      - methods
-    type: object
-  type:
-    enum:
-      - m.key.verification.request
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.key.verification.start$m.reciprocate.v1.yaml b/data/event-schemas/schema/m.key.verification.start$m.reciprocate.v1.yaml
deleted file mode 100644
index a60711b3..00000000
--- a/data/event-schemas/schema/m.key.verification.start$m.reciprocate.v1.yaml
+++ /dev/null
@@ -1,44 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  Begins a key verification process using the `m.reciprocate.v1` method, after
-  scanning a QR code.
-properties:
-  content:
-    properties:
-      from_device:
-        type: string
-        description: |-
-          The device ID which is initiating the process.
-      transaction_id:
-        type: string
-        description: |-
-          Required when sent as a to-device message. An opaque identifier for
-          the verification process. Must be unique with respect to the devices
-          involved. Must be the same as the `transaction_id` given in the
-          `m.key.verification.request` if this process is originating from a
-          request.
-      method:
-        type: string
-        enum: ["m.reciprocate.v1"]
-        description: |-
-          The verification method to use.
-      secret:
-        type: string
-        description: |-
-          The shared secret from the QR code, encoded using unpadded base64.
-      m.relates_to:
-        allOf:
-          - $ref: m.key.verification.m.relates_to.yaml
-    required:
-      - from_device
-      - method
-      - secret
-    type: object
-  type:
-    enum:
-      - m.key.verification.start
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.key.verification.start$m.sas.v1.yaml b/data/event-schemas/schema/m.key.verification.start$m.sas.v1.yaml
deleted file mode 100644
index 515a72a1..00000000
--- a/data/event-schemas/schema/m.key.verification.start$m.sas.v1.yaml
+++ /dev/null
@@ -1,72 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  Begins a SAS key verification process using the `m.sas.v1` method.
-properties:
-  content:
-    properties:
-      from_device:
-        type: string
-        description: |-
-          The device ID which is initiating the process.
-      transaction_id:
-        type: string
-        description: |-
-          Required when sent as a to-device message. An opaque identifier for
-          the verification process. Must be unique with respect to the devices
-          involved. Must be the same as the `transaction_id` given in the
-          `m.key.verification.request` if this process is originating from a
-          request.
-      method:
-        type: string
-        enum: ["m.sas.v1"]
-        description: |-
-          The verification method to use.
-      key_agreement_protocols:
-        type: array
-        description: |-
-          The key agreement protocols the sending device understands. Should
-          include at least `curve25519-hkdf-sha256`.
-        items:
-          type: string
-      hashes:
-        type: array
-        description: |-
-          The hash methods the sending device understands. Must include at least
-          `sha256`.
-        items:
-          type: string
-      message_authentication_codes:
-        type: array
-        description: |-
-          The message authentication codes that the sending device understands.
-          Must include at least `hkdf-hmac-sha256`.
-        items:
-          type: string
-      short_authentication_string:
-        type: array
-        description: |-
-          The SAS methods the sending device (and the sending device's user)
-          understands. Must include at least `decimal`. Optionally can include
-          `emoji`.
-        items:
-          type: string
-          enum: ["decimal", "emoji"]
-      m.relates_to:
-        allOf:
-          - $ref: m.key.verification.m.relates_to.yaml
-    required:
-      - from_device
-      - method
-      - key_agreement_protocols
-      - hashes
-      - message_authentication_codes
-      - short_authentication_string
-    type: object
-  type:
-    enum:
-      - m.key.verification.start
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.key.verification.start.yaml b/data/event-schemas/schema/m.key.verification.start.yaml
deleted file mode 100644
index a36a72f8..00000000
--- a/data/event-schemas/schema/m.key.verification.start.yaml
+++ /dev/null
@@ -1,45 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  Begins a key verification process. Typically sent as a [to-device](/client-server-api/#send-to-device-messaging) event. The `method`
-  field determines the type of verification. The fields in the event will differ depending
-  on the `method`. This definition includes fields that are in common among all variants.
-properties:
-  content:
-    properties:
-      from_device:
-        type: string
-        description: |-
-          The device ID which is initiating the process.
-      transaction_id:
-        type: string
-        description: |-
-          Required when sent as a to-device message. An opaque identifier for
-          the verification process. Must be unique with respect to the devices
-          involved. Must be the same as the `transaction_id` given in the
-          `m.key.verification.request` if this process is originating from a
-          request.
-      method:
-        type: string
-        description: |-
-          The verification method to use.
-      next_method:
-        type: string
-        description: |-
-          Optional method to use to verify the other user's key with. Applicable
-          when the `method` chosen only verifies one user's key. This field will
-          never be present if the `method` verifies keys both ways.
-      m.relates_to:
-        allOf:
-          - $ref: m.key.verification.m.relates_to.yaml
-    required:
-      - from_device
-      - method
-    type: object
-  type:
-    enum:
-      - m.key.verification.start
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.policy.rule.room.yaml b/data/event-schemas/schema/m.policy.rule.room.yaml
deleted file mode 100644
index ff81543e..00000000
--- a/data/event-schemas/schema/m.policy.rule.room.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: A moderation policy rule which affects room IDs and room aliases.
-properties:
-  content:
-    $ref: "../moderation_policy_rule.yaml"
-  state_key:
-    description: An arbitrary string decided upon by the sender.
-    type: string
-  type:
-    enum:
-      - m.policy.rule.room
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.policy.rule.server.yaml b/data/event-schemas/schema/m.policy.rule.server.yaml
deleted file mode 100644
index ca37e8ff..00000000
--- a/data/event-schemas/schema/m.policy.rule.server.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: A moderation policy rule which affects servers.
-properties:
-  content:
-    $ref: "../moderation_policy_rule.yaml"
-  state_key:
-    description: An arbitrary string decided upon by the sender.
-    type: string
-  type:
-    enum:
-      - m.policy.rule.server
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.policy.rule.user.yaml b/data/event-schemas/schema/m.policy.rule.user.yaml
deleted file mode 100644
index 4fa65ad8..00000000
--- a/data/event-schemas/schema/m.policy.rule.user.yaml
+++ /dev/null
@@ -1,15 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: A moderation policy rule which affects users.
-properties:
-  content:
-    $ref: "../moderation_policy_rule.yaml"
-  state_key:
-    description: An arbitrary string decided upon by the sender.
-    type: string
-  type:
-    enum:
-      - m.policy.rule.user
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.presence.yaml b/data/event-schemas/schema/m.presence.yaml
deleted file mode 100644
index 540fc7a0..00000000
--- a/data/event-schemas/schema/m.presence.yaml
+++ /dev/null
@@ -1,49 +0,0 @@
-{
-    "type": "object",
-    "title": "Presence Event",
-    "description": "Informs the client of a user's presence state change.",
-    "allOf": [{
-        "$ref": "core-event-schema/event.yaml"
-    }],
-    "properties": {
-        "content": {
-            "type": "object",
-            "properties": {
-                "avatar_url": {
-                    "type": "string",
-                    "description": "The current avatar URL for this user, if any."
-                },
-                "displayname": {
-                    "type": "string",
-                    "description": "The current display name for this user, if any."
-                },
-                "last_active_ago": {
-                    "type": "number",
-                    "description": "The last time since this used performed some action, in milliseconds."
-                },
-                "presence": {
-                    "type": "string",
-                    "description": "The presence state for this user.",
-                    "enum": ["online", "offline", "unavailable"]
-                },
-                "currently_active": {
-                    "type": boolean,
-                    "description": "Whether the user is currently active"
-                },
-                "status_msg": {
-                    "type": "string",
-                    "description": "An optional description to accompany the presence."
-                }
-            },
-            "required": ["presence"]
-        },
-        "type": {
-            "type": "string",
-            "enum": ["m.presence"]
-        },
-        "sender": {
-            "type": "string"
-        }
-    },
-    "required": ["sender", "type", "content"]
-}
diff --git a/data/event-schemas/schema/m.push_rules.yaml b/data/event-schemas/schema/m.push_rules.yaml
deleted file mode 100644
index 6fde9e14..00000000
--- a/data/event-schemas/schema/m.push_rules.yaml
+++ /dev/null
@@ -1,21 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-description: Describes all push rules for this user.
-properties:
-  content:
-    properties:
-      global:
-        type: object
-        title: Ruleset
-        description: The global ruleset
-        allOf:
-          - $ref: ../../api/client-server/definitions/push_ruleset.yaml
-    type: object
-  type:
-    enum:
-      - m.push_rules
-    type: string
-title: Push rules
-type: object
-
diff --git a/data/event-schemas/schema/m.receipt.yaml b/data/event-schemas/schema/m.receipt.yaml
deleted file mode 100644
index 56d4b341..00000000
--- a/data/event-schemas/schema/m.receipt.yaml
+++ /dev/null
@@ -1,48 +0,0 @@
-{
-    "type": "object",
-    "title": "Receipt Event",
-    "description": "Informs the client of new receipts.",
-    "allOf": [{
-        "$ref": "core-event-schema/event.yaml"
-    }],
-    "properties": {
-        "content": {
-            "type": "object",
-            "patternProperties": {
-                "^\\$": {
-                    "type": "object",
-                    "x-pattern": "$EVENT_ID",
-                    "title": "Receipts",
-                    "description": "The mapping of event ID to a collection of receipts for this event ID. The event ID is the ID of the event being acknowledged and *not* an ID for the receipt itself.",
-                    "properties": {
-                        "m.read": {
-                            "type": "object",
-                            "title": "Users",
-                            "description": "A collection of users who have sent `m.read` receipts for this event.",
-                            "patternProperties": {
-                                "^@": {
-                                    "type": "object",
-                                    "title": "Receipt",
-                                    "description": "The mapping of user ID to receipt. The user ID is the entity who sent this receipt.",
-                                    "x-pattern": "$USER_ID",
-                                    "properties": {
-                                        "ts": {
-                                            "type": "number",
-                                            "description": "The timestamp the receipt was sent at."
-                                        }
-                                    }
-                                }
-                            }
-                        }
-                    }
-                }
-            },
-            "additionalProperties": false
-        },
-        "type": {
-            "type": "string",
-            "enum": ["m.receipt"]
-        }
-    },
-    "required": ["type", "content"]
-}
diff --git a/data/event-schemas/schema/m.room.avatar.yaml b/data/event-schemas/schema/m.room.avatar.yaml
deleted file mode 100644
index 7d4b90b1..00000000
--- a/data/event-schemas/schema/m.room.avatar.yaml
+++ /dev/null
@@ -1,27 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: A picture that is associated with the room. This can be displayed alongside the room information.
-properties:
-  content:
-    properties:
-      info:
-        allOf:
-          - $ref: core-event-schema/msgtype_infos/image_info.yaml
-        description: Metadata about the image referred to in `url`.
-      url:
-        description: The URL to the image.
-        type: string
-    required:
-      - url
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.avatar
-    type: string
-title: RoomAvatar
-type: object
diff --git a/data/event-schemas/schema/m.room.canonical_alias.yaml b/data/event-schemas/schema/m.room.canonical_alias.yaml
deleted file mode 100644
index 7547bd3a..00000000
--- a/data/event-schemas/schema/m.room.canonical_alias.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: |-
-    This event is used to inform the room about which alias should be
-    considered the canonical one, and which other aliases point to the room.
-    This could be for display purposes or as suggestion to users which alias
-    to use to advertise and access the room.
-properties:
-  content:
-    properties:
-      alias:
-        description: |
-          The canonical alias for the room. If not present, null, or empty the
-          room should be considered to have no canonical alias.
-        type: string
-      alt_aliases:
-        description: |
-          Alternative aliases the room advertises. This list can have aliases
-          despite the `alias` field being null, empty, or otherwise not present.
-        type: array
-        items:
-          type: string
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.canonical_alias
-    type: string
-title: Informs the room as to which alias is the canonical one.
-type: object
diff --git a/data/event-schemas/schema/m.room.create.yaml b/data/event-schemas/schema/m.room.create.yaml
deleted file mode 100644
index 44c9c84e..00000000
--- a/data/event-schemas/schema/m.room.create.yaml
+++ /dev/null
@@ -1,47 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: This is the first event in a room and cannot be changed. It acts as the root of all other events.
-properties:
-  content:
-    properties:
-      creator:
-        description: The `user_id` of the room creator. This is set by the homeserver.
-        type: string
-      m.federate:
-        description: Whether users on other servers can join this room. Defaults to `true` if key does not exist.
-        type: boolean
-      room_version:
-        description: The version of the room. Defaults to `"1"` if the key does not exist.
-        type: string
-      type:
-        description: |-
-          Optional [room type](#types) to denote a room's intended function outside of traditional conversation.
-
-          Unspecified room types are possible using [Namespaced Identifiers](/appendices/#common-namespaced-identifier-grammar).
-        type: string
-      predecessor:
-        description: A reference to the room this room replaces, if the previous room was upgraded.
-        type: object
-        title: Previous Room
-        properties:
-          room_id:
-            type: string
-            description: The ID of the old room.
-          event_id:
-            type: string
-            description: The event ID of the last known event in the old room.
-        required: [room_id, event_id]
-    required:
-      - creator
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.create
-    type: string
-title: The first event in the room.
-type: object
diff --git a/data/event-schemas/schema/m.room.encrypted.yaml b/data/event-schemas/schema/m.room.encrypted.yaml
deleted file mode 100644
index 32e86902..00000000
--- a/data/event-schemas/schema/m.room.encrypted.yaml
+++ /dev/null
@@ -1,61 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  This event type is used when sending encrypted events. It can be used either
-  within a room (in which case it will have all of the [Room Event fields](/client-server-api/#room-event-fields)), or
-  as a [to-device](/client-server-api/#send-to-device-messaging) event.
-
-properties:
-  content:
-    properties:
-      algorithm:
-        type: string
-        enum:
-          - m.olm.v1.curve25519-aes-sha2
-          - m.megolm.v1.aes-sha2
-        description: |-
-          The encryption algorithm used to encrypt this event. The
-          value of this field determines which other properties will be
-          present.
-      ciphertext:
-        oneOf:
-          - type: string
-          - type: object
-            additionalProperties:
-              type: object
-              title: CiphertextInfo
-              properties:
-                body:
-                  type: string
-                  description: The encrypted payload.
-                type:
-                  type: integer
-                  description: The Olm message type.
-        description: |-
-          The encrypted content of the event. Either the encrypted payload
-          itself, in the case of a Megolm event, or a map from the recipient
-          Curve25519 identity key to ciphertext information, in the case of an
-          Olm event. For more details, see [Messaging Algorithms](/client-server-api/#messaging-algorithms).
-      sender_key:
-        type: string
-        description: The Curve25519 key of the sender.
-      device_id:
-        type: string
-        description: The ID of the sending device. Required with Megolm.
-      session_id:
-        type: string
-        description: |-
-          The ID of the session used to encrypt the message. Required with
-          Megolm.
-    required:
-      - algorithm
-      - sender_key
-      - ciphertext
-    type: object
-  type:
-    enum:
-      - m.room.encrypted
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.room.encryption.yaml b/data/event-schemas/schema/m.room.encryption.yaml
deleted file mode 100644
index 9f443b5e..00000000
--- a/data/event-schemas/schema/m.room.encryption.yaml
+++ /dev/null
@@ -1,36 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: Defines how messages sent in this room should be encrypted.
-properties:
-  content:
-    properties:
-      algorithm:
-        type: string
-        enum:
-          - "m.megolm.v1.aes-sha2"
-        description: |-
-          The encryption algorithm to be used to encrypt messages sent in this
-          room.
-      rotation_period_ms:
-        type: integer
-        description: |-
-          How long the session should be used before changing it. `604800000`
-          (a week) is the recommended default.
-      rotation_period_msgs:
-        type: integer
-        description: |-
-          How many messages should be sent before changing the session. `100` is the
-          recommended default.
-    required:
-      - algorithm
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.encryption
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.room.guest_access.yaml b/data/event-schemas/schema/m.room.guest_access.yaml
deleted file mode 100644
index f886dfe5..00000000
--- a/data/event-schemas/schema/m.room.guest_access.yaml
+++ /dev/null
@@ -1,26 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: 'This event controls whether guest users are allowed to join rooms. If this event is absent, servers should act as if it is present and has the guest_access value "forbidden".'
-properties:
-  content:
-    properties:
-      guest_access:
-        description: Whether guests can join the room.
-        enum:
-          - can_join
-          - forbidden
-        type: string
-    required:
-      - guest_access
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.guest_access
-    type: string
-title: Controls whether guest users are allowed to join rooms.
-type: object
diff --git a/data/event-schemas/schema/m.room.history_visibility.yaml b/data/event-schemas/schema/m.room.history_visibility.yaml
deleted file mode 100644
index 27ec67c7..00000000
--- a/data/event-schemas/schema/m.room.history_visibility.yaml
+++ /dev/null
@@ -1,28 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: This event controls whether a user can see the events that happened in a room from before they joined.
-properties:
-  content:
-    properties:
-      history_visibility:
-        description: Who can see the room history.
-        enum:
-          - invited
-          - joined
-          - shared
-          - world_readable
-        type: string
-    required:
-      - history_visibility
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.history_visibility
-    type: string
-title: Controls visibility of history.
-type: object
diff --git a/data/event-schemas/schema/m.room.join_rules.yaml b/data/event-schemas/schema/m.room.join_rules.yaml
deleted file mode 100644
index dbac60d5..00000000
--- a/data/event-schemas/schema/m.room.join_rules.yaml
+++ /dev/null
@@ -1,69 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: |
-  A room may have one of the following designations:
-  * `public` - anyone can join the room without any prior action.
-  * `invite` - a user must first receive an invite from someone already in the room
-    in order to join.
-  * `knock` - a user can request an invite to the room. They can be allowed (invited)
-    or denied (kicked/banned) access. Otherwise, users need to be invited in. Only
-    available in rooms [which support knocking](/rooms/#feature-matrix).
-  * `restricted` - anyone able to satisfy at least one of the allow conditions is
-    able to join the room without prior action. Otherwise, an invite is required.
-    Only available in rooms [which support the join rule](/rooms/#feature-matrix).
-  * `private` - reserved without implementation. No significant meaning.
-properties:
-  content:
-    properties:
-      join_rule:
-        description: The type of rules used for users wishing to join this room.
-        enum:
-          - public
-          - knock
-          - invite
-          - private
-          - restricted
-        type: string
-      allow:
-        x-addedInMatrixVersion: "1.2"
-        description: |-
-          For `restricted` rooms, the conditions the user will be tested against. The
-          user needs only to satisfy one of the conditions to join the `restricted`
-          room. If the user fails to meet any condition, or the condition is unable
-          to be confirmed as satisfied, then the user requires an invite to join the
-          room. Improper or no `allow` conditions on a `restricted` join rule imply
-          the room is effectively invite-only (no conditions can be satisfied).
-        type: array
-        items:
-          type: object
-          title: AllowCondition
-          properties:
-            type:
-              type: string
-              description: |-
-                The type of condition:
-                * `m.room_membership` - the user satisfies the condition if they are
-                  joined to the referenced room.
-              enum: ['m.room_membership']
-            room_id:
-              type: string
-              description: |-
-                Required if `type` is `m.room_membership`. The room ID to check the
-                user's membership against. If the user is joined to this room, they
-                satisfy the condition and thus are permitted to join the `restricted`
-                room.
-          required: ['type']
-    required:
-      - join_rule
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.join_rules
-    type: string
-title: Describes how users are allowed to join the room.
-type: object
diff --git a/data/event-schemas/schema/m.room.member.yaml b/data/event-schemas/schema/m.room.member.yaml
deleted file mode 100644
index bf2f7145..00000000
--- a/data/event-schemas/schema/m.room.member.yaml
+++ /dev/null
@@ -1,163 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: |-
-  Adjusts the membership state for a user in a room. It is preferable to use the membership APIs (`/rooms/<room id>/invite` etc) when performing membership actions rather than adjusting the state directly as there are a restricted set of valid transformations. For example, user A cannot force user B to join a room, and trying to force this state change directly will fail.
-
-  The following membership states are specified:
-
-  - `invite` - The user has been invited to join a room, but has not yet joined it. They may not participate in the room until they join.
-
-  - `join` - The user has joined the room (possibly after accepting an invite), and may participate in it.
-
-  - `leave` - The user was once joined to the room, but has since left (possibly by choice, or possibly by being kicked).
-
-  - `ban` - The user has been banned from the room, and is no longer allowed to join it until they are un-banned from the room (by having their membership state set to a value other than `ban`).
-
-  - `knock` - The user has knocked on the room, requesting permission to participate. They may not participate in the room until they join.
-
-  The `third_party_invite` property will be set if this invite is an `invite` event and is the successor of an `m.room.third_party_invite` event, and absent otherwise.
-
-  This event may also include an `invite_room_state` key inside the event's `unsigned` data.
-  If present, this contains an array of [stripped state events](/client-server-api/#stripped-state)
-  to assist the receiver in identifying the room.
-
-  The user for which a membership applies is represented by the `state_key`. Under some conditions,
-  the `sender` and `state_key` may not match - this may be interpreted as the `sender` affecting
-  the membership state of the `state_key` user.
-
-  The `membership` for a given user can change over time. The table below represents the various changes
-  over time and how clients and servers must interpret those changes. Previous membership can be retrieved
-  from the `prev_content` object on an event. If not present, the user's previous membership must be assumed
-  as `leave`.
-
-  |                   | to `invite`          | to `join`                              | to `leave`                                                                                                                              | to `ban`                    | to `knock`           |
-  |-------------------|----------------------|----------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------|-----------------------------|----------------------|
-  | **from `invite`** | No change.           | User joined the room.                  | If the `state_key` is the same as the `sender`, the user rejected the invite. Otherwise, the `state_key` user had their invite revoked. | User was banned.            | User is re-knocking. |
-  | **from `join`**   | Must never happen.   | `displayname` or `avatar_url` changed. | If the `state_key` is the same as the `sender`, the user left. Otherwise, the `state_key` user was kicked.                              | User was kicked and banned. | Must never happen.   |
-  | **from `leave`**  | New invitation sent. | User joined.                           | No change.                                                                                                                              | User was banned.            | User is knocking.    |
-  | **from `ban`**    | Must never happen.   | Must never happen.                     | User was unbanned.                                                                                                                      | No change.                  | Must never happen.   |
-  | **from `knock`**  | Knock accepted.      | Must never happen.                     | If the `state_key` is the same as the `sender`, the user retracted the knock. Otherwise, the `state_key` user had their knock denied.   | User was banned.            | No change.           |
-
-properties:
-  content:
-    properties:
-      avatar_url:
-        description: 'The avatar URL for this user, if any.'
-        type: string
-        format: uri
-      displayname:
-        description: 'The display name for this user, if any.'
-        type:
-          - "string"
-          - "null"
-      membership:
-        description: The membership state of the user.
-        enum:
-          - invite
-          - join
-          - knock
-          - leave
-          - ban
-        type: string
-      is_direct:
-        description: Flag indicating if the room containing this event was created with the intention of being a direct chat. See [Direct Messaging](/client-server-api/#direct-messaging).
-        type: boolean
-      join_authorised_via_users_server:
-        x-addedInMatrixVersion: "1.2"
-        type: string
-        description: |-
-          Usually found on `join` events, this field is used to denote which homeserver (through representation of a user with sufficient power level)
-          authorised the user's join. More information about this field can be found in the [Restricted Rooms Specification](#restricted-rooms).
-
-          Client and server implementations should be aware of the [signing implications](/rooms/v8/#authorization-rules) of including this
-          field in further events: in particular, the event must be signed by the server which
-          owns the user ID in the field. When copying the membership event's `content`
-          (for profile updates and similar) it is therefore encouraged to exclude this
-          field in the copy, as otherwise the event might fail event authorization.
-      reason:
-        x-addedInMatrixVersion: "1.1"
-        type: string
-        description: |-
-          Optional user-supplied text for why their membership has changed. For kicks and bans, this is typically the reason for the kick or ban.
-          For other membership changes, this is a way for the user to communicate their intent without having to send a message to the room, such
-          as in a case where Bob rejects an invite from Alice about an upcoming concert, but can't make it that day.
-
-          Clients are not recommended to show this reason to users when receiving an invite due to the potential for spam and abuse. Hiding the
-          reason behind a button or other component is recommended.
-      third_party_invite:
-        properties:
-          display_name:
-            description: A name which can be displayed to represent the user instead of their third party identifier
-            type: string
-          signed:
-            description: 'A block of content which has been signed, which servers can use to verify the event. Clients should ignore this.'
-            properties:
-              mxid:
-                description: The invited matrix user ID. Must be equal to the user_id property of the event.
-                type: string
-              signatures:
-                description: 'A single signature from the verifying server, in the format specified by the Signing Events section of the server-server API.'
-                title: Signatures
-                type: object
-                additionalProperties:
-                  type: object
-                  additionalProperties:
-                    type: string
-              token:
-                description: The token property of the containing third_party_invite object.
-                type: string
-            required:
-              - mxid
-              - signatures
-              - token
-            title: signed
-            type: object
-        required:
-          - display_name
-          - signed
-        title: Invite
-        type: object
-    required:
-      - membership
-    title: EventContent
-    type: object
-  state_key:
-    description: |-
-      The `user_id` this membership event relates to. In all cases except for when `membership` is
-      `join`, the user ID sending the event does not need to match the user ID in the `state_key`,
-      unlike other events. Regular authorisation rules still apply.
-    type: string
-  type:
-    enum:
-      - m.room.member
-    type: string
-  unsigned:
-    allOf:
-      - $ref: "core-event-schema/unsigned_prop.yaml"
-      - type: object
-        properties:
-          invite_room_state:
-            description: |-
-              A subset of the state of the room at the time of the invite, if `membership` is `invite`.
-              Note that this state is informational, and SHOULD NOT be trusted; once the client has
-              joined the room, it SHOULD fetch the live state from the server and discard the
-              invite_room_state. Also, clients must not rely on any particular state being present here;
-              they SHOULD behave properly (with possibly a degraded but not a broken experience) in
-              the absence of any particular events here. If they are set on the room, at least the
-              state for `m.room.avatar`, `m.room.canonical_alias`, `m.room.join_rules`, and `m.room.name`
-              SHOULD be included.
-            items:
-              $ref: "core-event-schema/stripped_state.yaml"
-            type: array
-          knock_room_state:
-            description: |-
-              A subset of the state of the room at the time of the knock, if `membership` is `knock`.
-              This has the same restrictions as `invite_room_state`. If they are set on the room, at least
-              the state for `m.room.avatar`, `m.room.canonical_alias`, `m.room.join_rules`, `m.room.name`,
-              and `m.room.encryption` SHOULD be included.
-            items:
-              $ref: "core-event-schema/stripped_state.yaml"
-            type: array
-title: The current membership state of a user in the room.
-type: object
diff --git a/data/event-schemas/schema/m.room.message$m.audio.yaml b/data/event-schemas/schema/m.room.message$m.audio.yaml
deleted file mode 100644
index 3faf0c31..00000000
--- a/data/event-schemas/schema/m.room.message$m.audio.yaml
+++ /dev/null
@@ -1,50 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: This message represents a single audio clip.
-properties:
-  content:
-    properties:
-      body:
-        description: "A description of the audio e.g. 'Bee Gees - Stayin' Alive', or some kind of content description for accessibility e.g. 'audio attachment'."
-        type: string
-      info:
-        description: Metadata for the audio clip referred to in `url`.
-        properties:
-          duration:
-            description: The duration of the audio in milliseconds.
-            type: integer
-          mimetype:
-            description: The mimetype of the audio e.g. `audio/aac`.
-            type: string
-          size:
-            description: The size of the audio clip in bytes.
-            type: integer
-        title: AudioInfo
-        type: object
-      msgtype:
-        enum:
-          - m.audio
-        type: string
-      url:
-        description: |-
-          Required if the file is unencrypted. The URL (typically [MXC URI](/client-server-api/#matrix-content-mxc-uris))
-          to the audio clip.
-        type: string
-      file:
-        description: |-
-          Required if the file is encrypted. Information on the encrypted
-          file, as specified in
-          [End-to-end encryption](/client-server-api/#sending-encrypted-attachments).
-        title: EncryptedFile
-        type: object
-    required:
-      - msgtype
-      - body
-    type: object
-  type:
-    enum:
-      - m.room.message
-    type: string
-title: AudioMessage
-type: object
diff --git a/data/event-schemas/schema/m.room.message$m.emote.yaml b/data/event-schemas/schema/m.room.message$m.emote.yaml
deleted file mode 100644
index 43e2639d..00000000
--- a/data/event-schemas/schema/m.room.message$m.emote.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: "This message is similar to `m.text` except that the sender is 'performing' the action contained in the `body` key, similar to `/me` in IRC. This message should be prefixed by the name of the sender. This message could also be represented in a different colour to distinguish it from regular `m.text` messages."
-properties:
-  content:
-    properties:
-      body:
-        description: The emote action to perform.
-        type: string
-      msgtype:
-        enum:
-          - m.emote
-        type: string
-      format:
-        description: |-
-          The format used in the `formatted_body`. Currently only
-          `org.matrix.custom.html` is supported.
-        type: string
-      formatted_body:
-        description: |-
-          The formatted version of the `body`. This is required if `format`
-          is specified.
-        type: string
-    required:
-      - msgtype
-      - body
-    type: object
-  type:
-    enum:
-      - m.room.message
-    type: string
-title: EmoteMessage
-type: object
diff --git a/data/event-schemas/schema/m.room.message$m.file.yaml b/data/event-schemas/schema/m.room.message$m.file.yaml
deleted file mode 100644
index 5958e117..00000000
--- a/data/event-schemas/schema/m.room.message$m.file.yaml
+++ /dev/null
@@ -1,66 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: This message represents a generic file.
-properties:
-  content:
-    properties:
-      body:
-        description: A human-readable description of the file. This is recommended to be the filename of the original upload.
-        type: string
-      filename:
-        description: The original filename of the uploaded file.
-        type: string
-      info:
-        description: Information about the file referred to in `url`.
-        properties:
-          mimetype:
-            description: The mimetype of the file e.g. `application/msword`.
-            type: string
-          size:
-            description: The size of the file in bytes.
-            type: integer
-          thumbnail_url:
-            description: |-
-              The URL to the thumbnail of the file. Only present if the
-              thumbnail is unencrypted.
-            type: string
-          thumbnail_file:
-            description: |-
-              Information on the encrypted thumbnail file, as specified in
-              [End-to-end encryption](/client-server-api/#sending-encrypted-attachments).
-              Only present if the thumbnail is encrypted.
-            title: EncryptedFile
-            type: object
-          thumbnail_info:
-            allOf:
-              - $ref: core-event-schema/msgtype_infos/thumbnail_info.yaml
-            description: Metadata about the image referred to in `thumbnail_url`.
-        title: FileInfo
-        type: object
-      msgtype:
-        enum:
-          - m.file
-        type: string
-      url:
-        description: |-
-          Required if the file is unencrypted. The URL (typically [MXC URI](/client-server-api/#matrix-content-mxc-uris))
-          to the file.
-        type: string
-      file:
-        description: |-
-          Required if the file is encrypted. Information on the encrypted
-          file, as specified in
-          [End-to-end encryption](/client-server-api/#sending-encrypted-attachments).
-        title: EncryptedFile
-        type: object
-    required:
-      - msgtype
-      - body
-    type: object
-  type:
-    enum:
-      - m.room.message
-    type: string
-title: FileMessage
-type: object
diff --git a/data/event-schemas/schema/m.room.message$m.image.yaml b/data/event-schemas/schema/m.room.message$m.image.yaml
deleted file mode 100644
index 5eaa89d4..00000000
--- a/data/event-schemas/schema/m.room.message$m.image.yaml
+++ /dev/null
@@ -1,40 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: This message represents a single image and an optional thumbnail.
-properties:
-  content:
-    properties:
-      body:
-        description: "A textual representation of the image. This could be the alt text of the image, the filename of the image, or some kind of content description for accessibility e.g. 'image attachment'."
-        type: string
-      info:
-        allOf:
-          - $ref: core-event-schema/msgtype_infos/image_info.yaml
-        description: Metadata about the image referred to in `url`.
-      msgtype:
-        enum:
-          - m.image
-        type: string
-      url:
-        description: |-
-          Required if the file is unencrypted. The URL (typically [MXC URI](/client-server-api/#matrix-content-mxc-uris))
-          to the image.
-        type: string
-      file:
-        description: |-
-          Required if the file is encrypted. Information on the encrypted
-          file, as specified in
-          [End-to-end encryption](/client-server-api/#sending-encrypted-attachments).
-        title: EncryptedFile
-        type: object
-    required:
-      - msgtype
-      - body
-    type: object
-  type:
-    enum:
-      - m.room.message
-    type: string
-title: ImageMessage
-type: object
diff --git a/data/event-schemas/schema/m.room.message$m.location.yaml b/data/event-schemas/schema/m.room.message$m.location.yaml
deleted file mode 100644
index 37f723f2..00000000
--- a/data/event-schemas/schema/m.room.message$m.location.yaml
+++ /dev/null
@@ -1,48 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: This message represents a real-world location.
-properties:
-  content:
-    properties:
-      body:
-        description: "A description of the location e.g. 'Big Ben, London, UK', or some kind of content description for accessibility e.g. 'location attachment'."
-        type: string
-      geo_uri:
-        description: A [geo URI (RFC5870)](https://datatracker.ietf.org/doc/html/rfc5870) representing this location.
-        type: string
-      msgtype:
-        enum:
-          - m.location
-        type: string
-      info:
-        type: object
-        properties:
-          thumbnail_url:
-            description: |-
-              The URL to the thumbnail of the file. Only present if the
-              thumbnail is unencrypted.
-            type: string
-          thumbnail_file:
-            description: |-
-              Information on the encrypted thumbnail file, as specified in
-              [End-to-end encryption](/client-server-api/#sending-encrypted-attachments).
-              Only present if the thumbnail is encrypted.
-            title: EncryptedFile
-            type: object
-          thumbnail_info:
-            allOf:
-              - $ref: core-event-schema/msgtype_infos/thumbnail_info.yaml
-            description:  Metadata about the image referred to in `thumbnail_url`.
-        title: LocationInfo
-    required:
-      - msgtype
-      - body
-      - geo_uri
-    type: object
-  type:
-    enum:
-      - m.room.message
-    type: string
-title: LocationMessage
-type: object
diff --git a/data/event-schemas/schema/m.room.message$m.notice.yaml b/data/event-schemas/schema/m.room.message$m.notice.yaml
deleted file mode 100644
index 7b735d60..00000000
--- a/data/event-schemas/schema/m.room.message$m.notice.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: 'The `m.notice` type is primarily intended for responses from automated clients. An `m.notice` message must be treated the same way as a regular `m.text` message with two exceptions. Firstly, clients should present `m.notice` messages to users in a distinct manner, and secondly, `m.notice` messages must never be automatically responded to. This helps to prevent infinite-loop situations where two automated clients continuously exchange messages.'
-properties:
-  content:
-    properties:
-      body:
-        description: The notice text to send.
-        type: string
-      msgtype:
-        enum:
-          - m.notice
-        type: string
-      format:
-        description: |-
-          The format used in the `formatted_body`. Currently only
-          `org.matrix.custom.html` is supported.
-        type: string
-      formatted_body:
-        description: |-
-          The formatted version of the `body`. This is required if `format`
-          is specified.
-        type: string
-    required:
-      - msgtype
-      - body
-    type: object
-  type:
-    enum:
-      - m.room.message
-    type: string
-title: NoticeMessage
-type: object
diff --git a/data/event-schemas/schema/m.room.message$m.server_notice.yaml b/data/event-schemas/schema/m.room.message$m.server_notice.yaml
deleted file mode 100644
index ca7144b0..00000000
--- a/data/event-schemas/schema/m.room.message$m.server_notice.yaml
+++ /dev/null
@@ -1,39 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: Represents a server notice for a user.
-properties:
-  content:
-    properties:
-      body:
-        description: A human-readable description of the notice.
-        type: string
-      msgtype:
-        enum:
-          - m.server_notice
-        type: string
-      server_notice_type:
-        description: |-
-          The type of notice being represented.
-        type: string
-      admin_contact:
-        description: |-
-          A URI giving a contact method for the server administrator. Required if the
-          notice type is `m.server_notice.usage_limit_reached`.
-        type: string
-      limit_type:
-        description: |-
-          The kind of usage limit the server has exceeded. Required if the notice type is
-          `m.server_notice.usage_limit_reached`.
-        type: string
-    required:
-      - msgtype
-      - body
-      - server_notice_type
-    type: object
-  type:
-    enum:
-      - m.room.message
-    type: string
-title: ServerNoticeMessage
-type: object
diff --git a/data/event-schemas/schema/m.room.message$m.text.yaml b/data/event-schemas/schema/m.room.message$m.text.yaml
deleted file mode 100644
index 4cba2bd6..00000000
--- a/data/event-schemas/schema/m.room.message$m.text.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: This message is the most basic message and is used to represent text.
-properties:
-  content:
-    properties:
-      body:
-        description: The body of the message.
-        type: string
-      msgtype:
-        enum:
-          - m.text
-        type: string
-      format:
-        description: |-
-          The format used in the `formatted_body`. Currently only
-          `org.matrix.custom.html` is supported.
-        type: string
-      formatted_body:
-        description: |-
-          The formatted version of the `body`. This is required if `format`
-          is specified.
-        type: string
-    required:
-      - msgtype
-      - body
-    type: object
-  type:
-    enum:
-      - m.room.message
-    type: string
-title: TextMessage
-type: object
diff --git a/data/event-schemas/schema/m.room.message$m.video.yaml b/data/event-schemas/schema/m.room.message$m.video.yaml
deleted file mode 100644
index 1879df65..00000000
--- a/data/event-schemas/schema/m.room.message$m.video.yaml
+++ /dev/null
@@ -1,72 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: This message represents a single video clip.
-properties:
-  content:
-    properties:
-      body:
-        description: "A description of the video e.g. 'Gangnam style', or some kind of content description for accessibility e.g. 'video attachment'."
-        type: string
-      info:
-        description: Metadata about the video clip referred to in `url`.
-        properties:
-          duration:
-            description: The duration of the video in milliseconds.
-            type: integer
-          h:
-            description: The height of the video in pixels.
-            type: integer
-          w:
-            description: The width of the video in pixels.
-            type: integer
-          mimetype:
-            description: The mimetype of the video e.g. `video/mp4`.
-            type: string
-          size:
-            description: The size of the video in bytes.
-            type: integer
-          thumbnail_url:
-            description: |-
-              The URL (typically [MXC URI](/client-server-api/#matrix-content-mxc-uris)) to an image thumbnail of
-              the video clip. Only present if the thumbnail is unencrypted.
-            type: string
-          thumbnail_file:
-            description: |-
-              Information on the encrypted thumbnail file, as specified in
-              [End-to-end encryption](/client-server-api/#sending-encrypted-attachments).
-              Only present if the thumbnail is encrypted.
-            title: EncryptedFile
-            type: object
-          thumbnail_info:
-            allOf:
-              - $ref: core-event-schema/msgtype_infos/thumbnail_info.yaml
-            description: Metadata about the image referred to in `thumbnail_url`.
-        title: VideoInfo
-        type: object
-      msgtype:
-        enum:
-          - m.video
-        type: string
-      url:
-        description: |-
-          Required if the file is unencrypted. The URL (typically [MXC URI](/client-server-api/#matrix-content-mxc-uris))
-          to the video clip.
-        type: string
-      file:
-        description: |-
-          Required if the file is encrypted. Information on the encrypted
-          file, as specified in
-          [End-to-end encryption](/client-server-api/#sending-encrypted-attachments).
-        title: EncryptedFile
-        type: object
-    required:
-      - msgtype
-      - body
-    type: object
-  type:
-    enum:
-      - m.room.message
-    type: string
-title: VideoMessage
-type: object
diff --git a/data/event-schemas/schema/m.room.message.feedback.yaml b/data/event-schemas/schema/m.room.message.feedback.yaml
deleted file mode 100644
index fbb39c0a..00000000
--- a/data/event-schemas/schema/m.room.message.feedback.yaml
+++ /dev/null
@@ -1,26 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: '**NB: Usage of this event is discouraged in favour of the** [receipts module](/client-server-api/#receipts). **Most clients will not recognise this event.** Feedback events are events sent to acknowledge a message in some way. There are two supported acknowledgements: `delivered` (sent when the event has been received) and `read` (sent when the event has been observed by the end-user). The `target_event_id` should reference the `m.room.message` event being acknowledged.'
-properties:
-  content:
-    properties:
-      target_event_id:
-        description: The event that this feedback is related to.
-        type: string
-      type:
-        description: The type of feedback.
-        enum:
-          - delivered
-          - read
-        type: string
-    required:
-      - type
-      - target_event_id
-    type: object
-  type:
-    enum:
-      - m.room.message.feedback
-    type: string
-title: MessageFeedback
-type: object
diff --git a/data/event-schemas/schema/m.room.message.yaml b/data/event-schemas/schema/m.room.message.yaml
deleted file mode 100644
index 546b5e19..00000000
--- a/data/event-schemas/schema/m.room.message.yaml
+++ /dev/null
@@ -1,23 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: 'This event is used when sending messages in a room. Messages are not limited to be text. The `msgtype` key outlines the type of message, e.g. text, audio, image, video, etc. The `body` key is text and MUST be used with every kind of `msgtype` as a fallback mechanism for when a client cannot render a message. This allows clients to display *something* even if it is just plain text.'
-properties:
-  content:
-    properties:
-      body:
-        description: The textual representation of this message.
-        type: string
-      msgtype:
-        description: 'The type of message, e.g. `m.image`, `m.text`'
-        type: string
-    required:
-      - msgtype
-      - body
-    type: object
-  type:
-    enum:
-      - m.room.message
-    type: string
-title: Message
-type: object
diff --git a/data/event-schemas/schema/m.room.name.yaml b/data/event-schemas/schema/m.room.name.yaml
deleted file mode 100644
index c9236de0..00000000
--- a/data/event-schemas/schema/m.room.name.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: |-
-    A room has an opaque room ID which is not human-friendly to read. A room
-    alias is human-friendly, but not all rooms have room aliases. The room name
-    is a human-friendly string designed to be displayed to the end-user. The
-    room name is not unique, as multiple rooms can have the same room name set.
-
-    A room with an `m.room.name` event with an absent, null, or empty
-    `name` field should be treated the same as a room with no `m.room.name`
-    event.
-
-    An event of this type is automatically created when creating a room using
-    `/createRoom` with the `name` key.
-properties:
-  content:
-    properties:
-      name:
-        description: The name of the room.
-        type: string
-    required:
-      - name
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.name
-    type: string
-title: RoomName
-type: object
diff --git a/data/event-schemas/schema/m.room.pinned_events.yaml b/data/event-schemas/schema/m.room.pinned_events.yaml
deleted file mode 100644
index 7b4a0d61..00000000
--- a/data/event-schemas/schema/m.room.pinned_events.yaml
+++ /dev/null
@@ -1,25 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: This event is used to "pin" particular events in a room for other participants to review later. The order of the pinned events is guaranteed and based upon the order supplied in the event. Clients should be aware that the current user may not be able to see some of the events pinned due to visibility settings in the room. Clients are responsible for determining if a particular event in the pinned list is displayable, and have the option to not display it if it cannot be pinned in the client.
-properties:
-  content:
-    properties:
-      pinned:
-        description: An ordered list of event IDs to pin.
-        items:
-          type: string
-        type: array
-    required:
-      - pinned
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.pinned_events
-    type: string
-title: Pinned events in a room
-type: object
diff --git a/data/event-schemas/schema/m.room.power_levels.yaml b/data/event-schemas/schema/m.room.power_levels.yaml
deleted file mode 100644
index 39c1988c..00000000
--- a/data/event-schemas/schema/m.room.power_levels.yaml
+++ /dev/null
@@ -1,110 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: |-
-  This event specifies the minimum level a user must have in order to perform a
-  certain action. It also specifies the levels of each user in the room.
-
-  If a `user_id` is in the `users` list, then that `user_id` has the
-  associated power level. Otherwise they have the default level
-  `users_default`. If `users_default` is not supplied, it is assumed to be
-  0. If the room contains no `m.room.power_levels` event, the room's creator has
-  a power level of 100, and all other users have a power level of 0.
-
-  The level required to send a certain event is governed by `events`,
-  `state_default` and `events_default`. If an event type is specified in
-  `events`, then the user must have at least the level specified in order to
-  send that event. If the event type is not supplied, it defaults to
-  `events_default` for Message Events and `state_default` for State
-  Events.
-
-  If there is no `state_default` in the `m.room.power_levels` event, the
-  `state_default` is 50. If there is no `events_default` in the
-  `m.room.power_levels` event, the `events_default` is 0. If the room
-  contains no `m.room.power_levels` event, *both* the `state_default` and
-  `events_default` are 0.
-
-  The power level required to invite a user to the room, kick a user from the
-  room, ban a user from the room, or redact an event sent by another user, is
-  defined by `invite`, `kick`, `ban`, and `redact`, respectively. Each
-  of these levels defaults to 50 if they are not specified in the
-  `m.room.power_levels` event, or if the room contains no `m.room.power_levels`
-  event.
-
-  **Note:**
-
-  As noted above, in the absence of an `m.room.power_levels` event, the
-  `state_default` is 0, and all users are considered to have power level 0.
-  That means that **any** member of the room can send an
-  `m.room.power_levels` event, changing the permissions in the room.
-
-  Server implementations should therefore ensure that each room has an
-  `m.room.power_levels` event as soon as it is created. See also the
-  documentation of the `/createRoom` API.
-
-properties:
-  content:
-    properties:
-      ban:
-        description: The level required to ban a user. Defaults to 50 if unspecified.
-        type: integer
-      events:
-        additionalProperties:
-          type: integer
-        description: The level required to send specific event types. This is a mapping from event type to power level required.
-        title: Event power levels
-        type: object
-      events_default:
-        description: |-
-            The default level required to send message events. Can be
-            overridden by the `events` key.  Defaults to 0 if unspecified.
-        type: integer
-      invite:
-        description: The level required to invite a user. Defaults to 50 if unspecified.
-        type: integer
-      kick:
-        description: The level required to kick a user. Defaults to 50 if unspecified.
-        type: integer
-      redact:
-        description: The level required to redact an event sent by another user. Defaults to 50 if unspecified.
-        type: integer
-      state_default:
-        description: |-
-            The default level required to send state events. Can be overridden
-            by the `events` key. Defaults to 50 if unspecified.
-        type: integer
-      users:
-        additionalProperties:
-          type: integer
-        description: The power levels for specific users. This is a mapping from `user_id` to power level for that user.
-        title: User power levels
-        type: object
-      users_default:
-        description: |-
-            The default power level for every user in the room, unless their
-            `user_id` is mentioned in the `users` key. Defaults to 0 if
-            unspecified.
-        type: integer
-      notifications:
-        properties:
-          room:
-            type: integer
-            description: The level required to trigger an `@room` notification. Defaults to 50 if unspecified.
-        additionalProperties:
-          type: integer
-        description: |-
-            The power level requirements for specific notification types.
-            This is a mapping from `key` to power level for that notifications key.
-        title: Notifications
-        type: object
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.power_levels
-    type: string
-title: Defines the power levels (privileges) of users in the room.
-type: object
diff --git a/data/event-schemas/schema/m.room.redaction.yaml b/data/event-schemas/schema/m.room.redaction.yaml
deleted file mode 100644
index 143e7eff..00000000
--- a/data/event-schemas/schema/m.room.redaction.yaml
+++ /dev/null
@@ -1,22 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: 'This event is created by the server to describe which event has been redacted, by whom, and optionally why. The event that has been redacted is specified in the `redacts` event level key. Redacting an event means that all keys not required by the protocol are stripped off, allowing messages to be hidden or allowing admins to remove offensive or illegal content.'
-properties:
-  content:
-    properties:
-      reason:
-        description: 'The reason for the redaction, if any.'
-        type: string
-    type: object
-  redacts:
-    description: The event ID that was redacted.
-    type: string
-  type:
-    enum:
-      - m.room.redaction
-    type: string
-required:
-  - redacts
-title: Redaction
-type: object
diff --git a/data/event-schemas/schema/m.room.server_acl.yaml b/data/event-schemas/schema/m.room.server_acl.yaml
deleted file mode 100644
index 744e5231..00000000
--- a/data/event-schemas/schema/m.room.server_acl.yaml
+++ /dev/null
@@ -1,88 +0,0 @@
----
-title: Server ACL
-description: |-
-  An event to indicate which servers are permitted to participate in the
-  room. Server ACLs may allow or deny groups of hosts. All servers participating
-  in the room, including those that are denied, are expected to uphold the
-  server ACL. Servers that do not uphold the ACLs MUST be added to the denied hosts
-  list in order for the ACLs to remain effective.
-
-  The `allow` and `deny` lists are lists of globs supporting `?` and `*`
-  as wildcards. When comparing against the server ACLs, the suspect server's port
-  number must not be considered. Therefore `evil.com`, `evil.com:8448`, and
-  `evil.com:1234` would all match rules that apply to `evil.com`, for example.
-
-  The ACLs are applied to servers when they make requests, and are applied in
-  the following order:
-
-  1. If there is no `m.room.server_acl` event in the room state, allow.
-  2. If the server name is an IP address (v4 or v6) literal, and `allow_ip_literals`
-     is present and `false`, deny.
-  3. If the server name matches an entry in the `deny` list, deny.
-  4. If the server name matches an entry in the `allow` list, allow.
-  5. Otherwise, deny.
-
-  **Note:**
-  Server ACLs do not restrict the events relative to the room DAG via authorisation
-  rules, but instead act purely at the network layer to determine which servers are
-  allowed to connect and interact with a given room.
-
-  **Warning:**
-  Failing to provide an `allow` rule of some kind will prevent **all**
-  servers from participating in the room, including the sender. This renders
-  the room unusable. A common allow rule is `[ "*" ]` which would still
-  permit the use of the `deny` list without losing the room.
-
-  **Warning:**
-  All compliant servers must implement server ACLs.  However, legacy or noncompliant
-  servers exist which do not uphold ACLs, and these MUST be manually appended to
-  the denied hosts list when setting an ACL to prevent them from leaking events from
-  banned servers into a room. Currently, the only way to determine noncompliant hosts is
-  to check the `prev_events` of leaked events, therefore detecting servers which
-  are not upholding the ACLs. Server versions can also be used to try to detect hosts that
-  will not uphold the ACLs, although this is not comprehensive. Server ACLs were added
-  in Synapse v0.32.0, although other server implementations and versions exist in the world.
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-type: object
-properties:
-  content:
-    properties:
-      allow_ip_literals:
-        type: boolean
-        description: |-
-          True to allow server names that are IP address literals. False to
-          deny. Defaults to true if missing or otherwise not a boolean.
-
-          This is strongly recommended to be set to `false` as servers running
-          with IP literal names are strongly discouraged in order to require
-          legitimate homeservers to be backed by a valid registered domain name.
-      allow:
-        type: array
-        description: |-
-          The server names to allow in the room, excluding any port information.
-          Wildcards may be used to cover a wider range of hosts, where `*`
-          matches zero or more characters and `?` matches exactly one character.
-
-          **This defaults to an empty list when not provided, effectively disallowing
-          every server.**
-        items:
-          type: string
-      deny:
-        type: array
-        description: |-
-          The server names to disallow in the room, excluding any port information.
-          Wildcards may be used to cover a wider range of hosts, where `*`
-          matches zero or more characters and `?` matches exactly one character.
-
-          This defaults to an empty list when not provided.
-        items:
-          type: string
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum: ['m.room.server_acl']
-    type: string
diff --git a/data/event-schemas/schema/m.room.third_party_invite.yaml b/data/event-schemas/schema/m.room.third_party_invite.yaml
deleted file mode 100644
index f4188192..00000000
--- a/data/event-schemas/schema/m.room.third_party_invite.yaml
+++ /dev/null
@@ -1,46 +0,0 @@
----
-$schema: http://json-schema.org/draft-04/schema#
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: "Acts as an `m.room.member` invite event, where there isn't a target user_id to invite. This event contains a token and a public key whose private key must be used to sign the token. Any user who can present that signature may use this invitation to join the target room."
-properties:
-  content:
-    properties:
-      display_name:
-        description: "A user-readable string which represents the user who has been invited. This should not contain the user's third party ID, as otherwise when the invite is accepted it would leak the association between the matrix ID and the third party ID."
-        type: string
-      key_validity_url:
-        description: "A URL which can be fetched, with querystring public_key=public_key, to validate whether the key has been revoked. The URL must return a JSON object containing a boolean property named 'valid'."
-        type: string
-      public_key:
-        description: A base64-encoded ed25519 key with which token must be signed (though a signature from any entry in public_keys is also sufficient). This exists for backwards compatibility.
-        type: string
-      public_keys:
-        description: Keys with which the token may be signed.
-        items:
-          properties:
-            key_validity_url:
-              description: "An optional URL which can be fetched, with querystring public_key=public_key, to validate whether the key has been revoked. The URL must return a JSON object containing a boolean property named 'valid'. If this URL is absent, the key must be considered valid indefinitely."
-              type: string
-            public_key:
-              description: A base-64 encoded ed25519 key with which token may be signed.
-              type: string
-          required:
-            - public_key
-          title: PublicKeys
-          type: object
-        type: array
-    required:
-      - display_name
-      - key_validity_url
-      - public_key
-    type: object
-  state_key:
-    description: 'The token, of which a signature must be produced in order to join the room.'
-    type: string
-  type:
-    enum:
-      - m.room.third_party_invite
-    type: string
-title: 'An invitation to a room issued to a third party identifier, rather than a matrix user ID.'
-type: object
diff --git a/data/event-schemas/schema/m.room.tombstone.yaml b/data/event-schemas/schema/m.room.tombstone.yaml
deleted file mode 100644
index 1c590e1f..00000000
--- a/data/event-schemas/schema/m.room.tombstone.yaml
+++ /dev/null
@@ -1,27 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: 'A state event signifying that a room has been upgraded to a different room version, and that clients should go there.'
-properties:
-  content:
-    properties:
-      body:
-        type: string
-        description: A server-defined message.
-      replacement_room:
-        type: string
-        description: The room ID of the new room the client should be visiting.
-    required:
-      - replacement_room
-      - body
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.tombstone
-    type: string
-title: Indication that the room has been upgraded.
-type: object
diff --git a/data/event-schemas/schema/m.room.topic.yaml b/data/event-schemas/schema/m.room.topic.yaml
deleted file mode 100644
index 78a3d878..00000000
--- a/data/event-schemas/schema/m.room.topic.yaml
+++ /dev/null
@@ -1,23 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: 'A topic is a short message detailing what is currently being discussed in the room.  It can also be used as a way to display extra information about the room, which may not be suitable for the room name. The room topic can also be set when creating a room using `/createRoom` with the `topic` key.'
-properties:
-  content:
-    properties:
-      topic:
-        description: The topic text.
-        type: string
-    required:
-      - topic
-    type: object
-  state_key:
-    description: A zero-length string.
-    pattern: '^$'
-    type: string
-  type:
-    enum:
-      - m.room.topic
-    type: string
-title: Topic
-type: object
diff --git a/data/event-schemas/schema/m.room_key.withheld.yaml b/data/event-schemas/schema/m.room_key.withheld.yaml
deleted file mode 100644
index 797b51f9..00000000
--- a/data/event-schemas/schema/m.room_key.withheld.yaml
+++ /dev/null
@@ -1,86 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  This event type is used to indicate that the sender is not sharing room keys
-  with the recipient. It is sent as a to-device event.
-
-  Possible values for `code` include:
-
-  * `m.blacklisted`: the user/device was blacklisted.
-  * `m.unverified`: the user/device was not verified, and the sender is only
-    sharing keys with verified users/devices.
-  * `m.unauthorised`: the user/device is not allowed to have the key. For
-    example, this could be sent in response to a key request if the user/device
-    was not in the room when the original message was sent.
-  * `m.unavailable`: sent in reply to a key request if the device that the
-    key is requested from does not have the requested key.
-  * `m.no_olm`: an olm session could not be established.
-
-  In most cases, this event refers to a specific room key. The one exception to
-  this is when the sender is unable to establish an olm session with the
-  recipient. When this happens, multiple sessions will be affected.  In order
-  to avoid filling the recipient\'s device mailbox, the sender should only send
-  one `m.room_key.withheld` message with no `room_id` nor `session_id`
-  set.  If the sender retries and fails to create an olm session again in the
-  future, it should not send another `m.room_key.withheld` message with a
-  `code` of `m.no_olm`, unless another olm session was previously
-  established successfully.  In response to receiving an
-  `m.room_key.withheld` message with a `code` of `m.no_olm`, the
-  recipient may start an olm session with the sender and send an `m.dummy`
-  message to notify the sender of the new olm session.  The recipient may
-  assume that this `m.room_key.withheld` message applies to all encrypted
-  room messages sent before it receives the message.
-properties:
-  content:
-    properties:
-      algorithm:
-        type: string
-        enum: ["m.megolm.v1.aes-sha2"]
-        description: |-
-          The encryption algorithm for the key that this event is about.
-      room_id:
-        type: string
-        description: |-
-          Required if `code` is not `m.no_olm`.  The room for the key that
-          this event is about.
-      session_id:
-        type: string
-        description: |-
-          Required of `code` is not `m.no_olm`.  The session ID of the key
-          that this event is aboutis for.
-      sender_key:
-        type: string
-        description: |-
-          The unpadded base64-encoded device curve25519 key of the event\'s
-          sender.
-      code:
-        type: string
-        enum:
-          - m.blacklisted
-          - m.unverified
-          - m.unauthorised
-          - m.unavailable
-          - m.no_olm
-        description: |-
-          A machine-readable code for why the key was not sent. Codes beginning
-          with `m.` are reserved for codes defined in the Matrix
-          specification. Custom codes must use the Java package naming
-          convention.
-      reason:
-        type: string
-        description: |-
-          A human-readable reason for why the key was not sent. The receiving
-          client should only use this string if it does not understand the
-          `code`.
-    required:
-      - algorithm
-      - sender_key
-      - code
-    type: object
-  type:
-    enum:
-      - m.room_key.withheld
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.room_key.yaml b/data/event-schemas/schema/m.room_key.yaml
deleted file mode 100644
index 6eebbec5..00000000
--- a/data/event-schemas/schema/m.room_key.yaml
+++ /dev/null
@@ -1,35 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  This event type is used to exchange keys for end-to-end encryption. Typically
-  it is encrypted as an `m.room.encrypted` event, then sent as a [to-device](/client-server-api/#send-to-device-messaging) event.
-properties:
-  content:
-    properties:
-      algorithm:
-        type: string
-        enum: ["m.megolm.v1.aes-sha2"]
-        description: |-
-          The encryption algorithm the key in this event is to be used with.
-      room_id:
-        type: string
-        description: The room where the key is used.
-      session_id:
-        type: string
-        description: The ID of the session that the key is for.
-      session_key:
-        type: string
-        description: The key to be exchanged.
-    required:
-      - algorithm
-      - room_id
-      - session_id
-      - session_key
-    type: object
-  type:
-    enum:
-      - m.room_key
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.room_key_request.yaml b/data/event-schemas/schema/m.room_key_request.yaml
deleted file mode 100644
index 99afdb19..00000000
--- a/data/event-schemas/schema/m.room_key_request.yaml
+++ /dev/null
@@ -1,61 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/event.yaml
-
-description: |-
-  This event type is used to request keys for end-to-end encryption. It is sent as an
-  unencrypted [to-device](/client-server-api/#send-to-device-messaging) event.
-properties:
-  content:
-    properties:
-      body:
-        description: |-
-          Information about the requested key. Required when `action` is
-          `request`.
-        properties:
-          algorithm:
-            type: string
-            description: |-
-              The encryption algorithm the requested key in this event is to be used
-              with.
-          room_id:
-            type: string
-            description: The room where the key is used.
-          sender_key:
-            type: string
-            description: |-
-              The Curve25519 key of the device which initiated the session originally.
-          session_id:
-            type: string
-            description: The ID of the session that the key is for.
-        required:
-          - algorithm
-          - room_id
-          - session_id
-          - sender_key
-        type: object
-        title: RequestedKeyInfo
-      action:
-        enum:
-          - request
-          - request_cancellation
-        type: string
-      requesting_device_id:
-        description: ID of the device requesting the key.
-        type: string
-      request_id:
-        description: |-
-          A random string uniquely identifying the request for a key. If the key is
-          requested multiple times, it should be reused. It should also reused in order
-          to cancel a request.
-        type: string
-    required:
-      - action
-      - requesting_device_id
-      - request_id
-    type: object
-  type:
-    enum:
-      - m.room_key_request
-    type: string
-type: object
diff --git a/data/event-schemas/schema/m.space.child.yaml b/data/event-schemas/schema/m.space.child.yaml
deleted file mode 100644
index afdfefa9..00000000
--- a/data/event-schemas/schema/m.space.child.yaml
+++ /dev/null
@@ -1,46 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: Defines the relationship of a child room to a space-room. Has no effect in rooms which are not [spaces](#spaces).
-properties:
-  content:
-    properties:
-      via:
-        type: array
-        description: |-
-          A list of servers to try and join through. See also: [Routing](/appendices/#routing).
-
-          When not present or invalid, the child room is not considered to be part of the space.
-        items:
-          type: string
-      order:
-        type: string
-        maxLength: 50
-        pattern: '^[\x20-\x7E]+$'
-        description: |-
-          Optional string to define ordering among space children. These are lexicographically
-          compared against other children's `order`, if present.
-
-          Must consist of ASCII characters within the range `\x20` (space) and `\x7E` (`~`),
-          inclusive. Must not exceed 50 characters.
-
-          `order` values with the wrong type, or otherwise invalid contents, are to be treated
-          as though the `order` key was not provided.
-
-          See [Ordering](/client-server-api/#ordering-1) for information on how the ordering works.
-      suggested:
-        type: boolean
-        description: |-
-          Optional (default `false`) flag to denote whether the child is "suggested" or of interest
-          to members of the space. This is primarily intended as a rendering hint for clients to
-          display the room differently, such as eagerly rendering them in the room list.
-    type: object
-  state_key:
-    description: The child room ID being described.
-    type: string
-  type:
-    enum:
-      - m.space.child
-    type: string
-title: Space child room
-type: object
diff --git a/data/event-schemas/schema/m.space.parent.yaml b/data/event-schemas/schema/m.space.parent.yaml
deleted file mode 100644
index ced24d70..00000000
--- a/data/event-schemas/schema/m.space.parent.yaml
+++ /dev/null
@@ -1,32 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/state_event.yaml
-description: Defines the relationship of a room to a parent space-room.
-properties:
-  content:
-    properties:
-      via:
-        type: array
-        description: |-
-          A list of servers to try and join through. See also: [Routing](/appendices/#routing).
-
-          When not present or invalid, the room is not considered to be part of the parent space.
-        items:
-          type: string
-      canonical:
-        type: boolean
-        description: |-
-          Optional (default `false`) flag to denote this parent is the primary parent for the room.
-
-          When multiple `canonical` parents are found, the lowest parent when ordering by room ID
-          lexicographically by Unicode code-points should be used.
-    type: object
-  state_key:
-    description: The parent room ID.
-    type: string
-  type:
-    enum:
-      - m.space.parent
-    type: string
-title: Room space parent
-type: object
diff --git a/data/event-schemas/schema/m.sticker.yaml b/data/event-schemas/schema/m.sticker.yaml
deleted file mode 100644
index 5856cca6..00000000
--- a/data/event-schemas/schema/m.sticker.yaml
+++ /dev/null
@@ -1,34 +0,0 @@
----
-allOf:
-  - $ref: core-event-schema/room_event.yaml
-description: This message represents a single sticker image.
-properties:
-  content:
-    properties:
-      body:
-        description: |-
-          A textual representation or associated description of the sticker
-          image. This could be the alt text of the original image, or a message
-          to accompany and further describe the sticker.
-        type: string
-      info:
-        allOf:
-          - $ref: core-event-schema/msgtype_infos/image_info.yaml
-        description: |-
-          Metadata about the image referred to in `url` including a thumbnail
-          representation.
-      url:
-        description: |-
-          The URL to the sticker image. This must be a valid `mxc://` URI.
-        type: string
-    required:
-      - body
-      - info
-      - url
-    type: object
-  type:
-    enum:
-      - m.sticker
-    type: string
-title: StickerMessage
-type: object
diff --git a/data/event-schemas/schema/m.tag.yaml b/data/event-schemas/schema/m.tag.yaml
deleted file mode 100644
index afa22420..00000000
--- a/data/event-schemas/schema/m.tag.yaml
+++ /dev/null
@@ -1,36 +0,0 @@
-{
-  "type": "object",
-  "title": "Tag Event",
-  "description": "Informs the client of tags on a room.",
-  "allOf": [{
-    "$ref": "core-event-schema/event.yaml"
-  }],
-  "properties": {
-    "type": {
-      "type": "string",
-      "enum": ["m.tag"]
-    },
-    "content": {
-      "type": "object",
-      "properties": {
-        "tags": {
-          "type": "object",
-          "description": "The tags on the room and their contents.",
-          "additionalProperties": {
-            "title": "Tag",
-            "type": "object",
-            "properties": {
-              "order": {
-                "type": "number",
-                "format": "float",
-                "description":
-                  "A number in a range `[0,1]` describing a relative position of the room under the given tag."
-              }
-            }
-          }
-        }
-      }
-    }
-  },
-  "required": ["type", "content"]
-}
diff --git a/data/event-schemas/schema/m.typing.yaml b/data/event-schemas/schema/m.typing.yaml
deleted file mode 100644
index 1613334f..00000000
--- a/data/event-schemas/schema/m.typing.yaml
+++ /dev/null
@@ -1,28 +0,0 @@
-{
-    "type": "object",
-    "title": "Typing Event",
-    "description": "Informs the client of the list of users currently typing.",
-    "allOf": [{
-        "$ref": "core-event-schema/event.yaml"
-    }],
-    "properties": {
-        "content": {
-            "type": "object",
-            "properties": {
-                "user_ids": {
-                    "type": "array",
-                    "items": {
-                        "type": "string"
-                    },
-                    "description": "The list of user IDs typing in this room, if any."
-                }
-            },
-            "required": ["user_ids"]
-        },
-        "type": {
-            "type": "string",
-            "enum": ["m.typing"]
-        }
-    },
-    "required": ["type", "content"]
-}
diff --git a/data/schemas/server-signatures.yaml b/data/schemas/server-signatures.yaml
deleted file mode 100644
index a1855256..00000000
--- a/data/schemas/server-signatures.yaml
+++ /dev/null
@@ -1,24 +0,0 @@
-# Copyright 2018 New Vector Ltd
-#
-# 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
-example: {
-  "example.com": {
-    "ed25519:0": "these86bytesofbase64signaturecoveressentialfieldsincludinghashessocancheckredactedpdus"
-  }
-}
-additionalProperties:
-  type: object
-  title: Server Signatures
-  additionalProperties:
-    type: string
\ No newline at end of file
diff --git a/informal/idp-brands.md b/informal/idp-brands.md
deleted file mode 100644
index 24f91811..00000000
--- a/informal/idp-brands.md
+++ /dev/null
@@ -1,67 +0,0 @@
-# SSO IdP brand registry
-
-This informal document contains specification for common brands that clients might experience
-in the wild as part of `m.login.sso` flows. To add your brand, open a PR against this document
-with the relevant additions (using the existing specification as reference) - an MSC is not
-required. Once opened, mention your PR in [#sct-office:matrix.org](https://matrix.to/#/#sct-office:matrix.org)
-on Matrix so it doesn't end up lost.
-
-Please also take some time to read the [contributing guidelines](https://github.com/matrix-org/matrix-doc/blob/master/CONTRIBUTING.rst)
-for an overview of PR requirements.
-
-<!--
-Author's note: This document intentionally has 2 blank lines between brands for easier distinction
-in the plaintext version. Please maintain them for new & existing brands.
--->
-
-## Brands
-
-For the brands listed here, the `identifier` would be used as the `brand` value in an IdP definition
-under `m.login.sso`'s flow.
-
-Note that each brand may have their own requirements for how they are represented by clients, such as
-Facebook/Twitter wanting their signature blues for button backgrounds whereas GitHub is not as particular
-about the press requirements. Clients should not rely on this document for guidance on press requirements
-and instead refer to the brands individually.
-
-
-### Apple
-
-**Identifier**: `apple`
-
-Suitable for "Sign in with Apple": see https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/buttons/.
-
-
-### Facebook
-
-**Identifier**: `facebook`
-
-"Continue with Facebook": see https://developers.facebook.com/docs/facebook-login/web/login-button/.
-
-
-### GitHub
-
-**Identifier**: `github`
-
-Logos available at https://github.com/logos.
-
-
-### GitLab
-
-**Identifier**: `gitlab`
-
-Logos available at https://about.gitlab.com/press/press-kit/.
-
-
-### Google
-
-**Identifier**: `google`
-
-Suitable for "Google Sign-In": see https://developers.google.com/identity/branding-guidelines.
-
-
-### Twitter
-
-**Identifier**: `twitter`
-
-Suitable for "Log in with Twitter": see https://developer.twitter.com/en/docs/authentication/guides/log-in-with-twitter#tab1.
diff --git a/layouts/404.html b/layouts/404.html
deleted file mode 100644
index 212e20ba..00000000
--- a/layouts/404.html
+++ /dev/null
@@ -1,8 +0,0 @@
-{{ define "main"}}
-    <main id="main">
-      <div>
-       <h1 id="title">Not found</h1>
-          <p>This page doesn't exist. Try going back to the <a href="{{ "/" | relURL }}">main page for the Matrix Specification</a>.</p>
-      </div>
-    </main>
-{{ end }}
diff --git a/layouts/_default/content.html b/layouts/_default/content.html
deleted file mode 100644
index e58073f3..00000000
--- a/layouts/_default/content.html
+++ /dev/null
@@ -1,4 +0,0 @@
-<div class="td-content">
-	<h1>{{ .Title }}</h1>
-	{{ .Content }}
-</div>
diff --git a/layouts/docs/baseof.html b/layouts/docs/baseof.html
deleted file mode 100644
index 3e058fd0..00000000
--- a/layouts/docs/baseof.html
+++ /dev/null
@@ -1,34 +0,0 @@
-{{/*
-
-  A copy of the baseof.html partial in Docsy, modified
-	to remove the right-hand column from the layout.
-
-*/}}
-
-<!doctype html>
-<html lang="{{ .Site.Language.Lang }}" class="no-js">
-  <head>
-    {{ partial "head.html" . }}
-  </head>
-  <body class="td-{{ .Kind }}">
-    <header>
-      {{ partial "navbar.html" . }}
-    </header>
-    <div class="container-fluid td-outer">
-      <div class="td-main">
-        <div class="row flex-xl-nowrap">
-          <div class="col-12 col-md-3 col-xl-3 td-sidebar d-print-none">
-            {{ partial "sidebar.html" . }}
-          </div>
-          <main class="col-12 col-md-9 col-xl-7 pl-md-5" role="main">
-            {{ partial "version-banner.html" . }}
-            {{ partial "breadcrumb.html" . }}
-            {{ block "main" . }}{{ end }}
-          </main>
-        </div>
-      </div>
-      {{ partial "footer.html" . }}
-    </div>
-    {{ partial "scripts.html" . }}
-  </body>
-</html>
diff --git a/layouts/docs/list.html b/layouts/docs/list.html
deleted file mode 100644
index 01145138..00000000
--- a/layouts/docs/list.html
+++ /dev/null
@@ -1,13 +0,0 @@
-{{/*
-
-  A simplified version of the list.html partial in Docsy.
-
-*/}}
-
-{{ define "main" }}
-<div class="td-content">
-	<h1>{{ .Title }}</h1>
-        {{ with .Params.description }}<div class="lead">{{ . | markdownify }}</div>{{ end }}
-	{{ .Content }}
-</div>
-{{ end }}
diff --git a/layouts/partials/added-in.html b/layouts/partials/added-in.html
deleted file mode 100644
index c75c0676..00000000
--- a/layouts/partials/added-in.html
+++ /dev/null
@@ -1,13 +0,0 @@
-{{ $ver := .v }}
-{{ $this := .this }}
-
-{{/*
-    This differs from the shortcode added-in by wanting to be a block instead of inline
-    and by slightly altering the rendered text as a result.
-*/}}
-
-{{ if $this }}
-  **New in this version.**
-{{ else }}
-  **Added in `v{{ $ver }}`**
-{{ end }}
diff --git a/layouts/partials/alert.html b/layouts/partials/alert.html
deleted file mode 100644
index 9096769f..00000000
--- a/layouts/partials/alert.html
+++ /dev/null
@@ -1,20 +0,0 @@
-{{/*
-
-  Display an alert box of the given type, containing the given content.
-
-  Supported types are "warning", "info", and "rationale".
-  The type determines the colors used in the box and, by default,
-  the title for the box: WARNING, INFO, RATIONALE.
-
-  By passing "omit_title", a caller can suppress the title, and just get
-  a box using the colors and styles for the given type.
-
-*/}}
-
-{{ $type := .type}}
-{{ $content := .content}}
-{{ $omit_title := .omit_title }}
-
-<div class="alert {{ $type }} {{ if $omit_title }}omit-title{{end}}" role="alert">
-{{ $content | markdownify }}
-</div>
diff --git a/layouts/partials/breadcrumb.html b/layouts/partials/breadcrumb.html
deleted file mode 100644
index 8e1fb9b2..00000000
--- a/layouts/partials/breadcrumb.html
+++ /dev/null
@@ -1,28 +0,0 @@
-{{/*
-
-  A copy of the breadcrumb.html partial in Docsy, modified
-	to:
-  * omit breadcrumbs when this is the homepage
-  * otherwise, include the homepage in the breadcrumbs
-
-*/}}
-
-{{ if not .IsHome }}
-<nav aria-label="breadcrumb" class="d-none d-md-block d-print-none">
-	<ol class="breadcrumb spb-1">
-{{ template "breadcrumbnav" (dict "p1" . "p2" .) }}
-	</ol>
-</nav	>
-{{ end }}
-
-{{ define "breadcrumbnav" }}
-{{ if .p1.Parent }}
-{{ template "breadcrumbnav" (dict "p1" .p1.Parent "p2" .p2 )  }}
-{{ else if not .p1.IsHome }}
-{{ template "breadcrumbnav" (dict "p1" .p1.Site.Home "p2" .p2 )  }}
-{{ end }}
-{{ $isActive :=  eq .p1 .p2  }}
-<li class="breadcrumb-item{{ if $isActive }} active{{ end }}" {{ if $isActive }}aria-current="page"{{ end }}>
-	<a href="{{ .p1.RelPermalink }}">{{ .p1.LinkTitle }}</a>
-</li>
-{{ end }}
diff --git a/layouts/partials/changed-in.html b/layouts/partials/changed-in.html
deleted file mode 100644
index 8a815904..00000000
--- a/layouts/partials/changed-in.html
+++ /dev/null
@@ -1,14 +0,0 @@
-{{/*
-    Renders the "Changed in [version]:" blocks for x-changedInMatrixVersion
-    annotations for openapi parameters
-
-    Takes a single 'changes_dict' parameter, which should be a map of
-    version -> details pairs.
-*/ -}}
-{{ range $ver, $details := .changes_dict -}}
-    <br><br>
-    <strong>
-      Changed in <code>v{{ $ver }}</code>:
-    </strong>
-    {{ $details | markdownify }}
-{{ end }}
diff --git a/layouts/partials/changelogs/.gitkeep b/layouts/partials/changelogs/.gitkeep
deleted file mode 100644
index e69de29b..00000000
diff --git a/layouts/partials/changelogs/v1.1.md b/layouts/partials/changelogs/v1.1.md
deleted file mode 100644
index b8e0832d..00000000
--- a/layouts/partials/changelogs/v1.1.md
+++ /dev/null
@@ -1,174 +0,0 @@
-<!--
-This is a header file for the generated changelog.
-
-Variables:
-    v1.1  = Replaced by the version number (eg: v1.2)
-    November 09, 2021     = Replaced by the date (eg: April 01, 2021)
--->
-
-## v1.1
-
-<table class="release-info">
-<tr><th>Git commit</th><td><a href="https://github.com/matrix-org/matrix-doc/tree/v1.1">https://github.com/matrix-org/matrix-doc/tree/v1.1</a></td>
-<tr><th>Release date</th><td>November 09, 2021</td>
-</table>
-
-<!-- Intentionally blank line to ensure headers work in the concatenated changelog -->
-### Client-Server API
-
-
-<strong>Breaking Changes</strong>
-
-
-- Document `curve25519-hkdf-sha256` key agreement method for SAS verification, and deprecate old method as per [MSC2630](https://github.com/matrix-org/matrix-doc/pull/2630). ([#2687](https://github.com/matrix-org/matrix-doc/issues/2687))
-- Add `m.key.verification.ready` and `m.key.verification.done` to key verification framework as per [MSC2366](https://github.com/matrix-org/matrix-doc/pull/2366). ([#3139](https://github.com/matrix-org/matrix-doc/issues/3139))
-
-
-<strong>Deprecations</strong>
-
-
-- Deprecate starting verifications that don't start with `m.key.verification.request` as per [MSC3122](https://github.com/matrix-org/matrix-doc/pull/3122). ([#3199](https://github.com/matrix-org/matrix-doc/issues/3199))
-
-
-<strong>New Endpoints</strong>
-
-
-- Add key backup (`/room_keys/*`) endpoints as per [MSC1219](https://github.com/matrix-org/matrix-doc/pull/1219). ([#2387](https://github.com/matrix-org/matrix-doc/issues/2387), [#2639](https://github.com/matrix-org/matrix-doc/issues/2639))
-- Add `POST /keys/device_signing/upload` and `POST /keys/signatures/upload` as per [MSC1756](https://github.com/matrix-org/matrix-doc/pull/1756). ([#2536](https://github.com/matrix-org/matrix-doc/issues/2536))
-- Add `/knock` endpoint as per [MSC2403](https://github.com/matrix-org/matrix-doc/pull/2403). ([#3154](https://github.com/matrix-org/matrix-doc/issues/3154))
-- Add `/login/sso/redirect/{idpId}` as per [MSC2858](https://github.com/matrix-org/matrix-doc/pull/2858). ([#3163](https://github.com/matrix-org/matrix-doc/issues/3163))
-
-
-<strong>Removed Endpoints</strong>
-
-
-- Remove unimplemented `m.login.oauth2` and `m.login.token` user-interactive authentication mechanisms as per [MSC2610](https://github.com/matrix-org/matrix-doc/pull/2610) and [MSC2611](https://github.com/matrix-org/matrix-doc/pull/2611). ([#2609](https://github.com/matrix-org/matrix-doc/issues/2609))
-
-
-<strong>Backwards Compatible Changes</strong>
-
-
-- Document how clients can advise recipients that it is withholding decryption keys as per [MSC2399](https://github.com/matrix-org/matrix-doc/pull/2399). ([#2399](https://github.com/matrix-org/matrix-doc/issues/2399))
-- Add cross-signing properties to the response of `POST /keys/query` as per [MSC1756](https://github.com/matrix-org/matrix-doc/pull/1756). ([#2536](https://github.com/matrix-org/matrix-doc/issues/2536))
-- Document Secure Secret Storage and Sharing as per [MSC1946](https://github.com/matrix-org/matrix-doc/pull/1946) and [MSC2472](https://github.com/matrix-org/matrix-doc/pull/2472). ([#2597](https://github.com/matrix-org/matrix-doc/issues/2597))
-- Add a `device_id` parameter to login fallback as per [MSC2604](https://github.com/matrix-org/matrix-doc/pull/2604). ([#2709](https://github.com/matrix-org/matrix-doc/issues/2709))
-- Added a common set of translations for SAS Emoji. ([#2728](https://github.com/matrix-org/matrix-doc/issues/2728))
-- Added support for `reason` on all membership events and related endpoints as per [MSC2367](https://github.com/matrix-org/matrix-doc/pull/2367). ([#2795](https://github.com/matrix-org/matrix-doc/issues/2795))
-- Add a 404 `M_NOT_FOUND` error to push rule endpoints as per [MSC2663](https://github.com/matrix-org/matrix-doc/pull/2663). ([#2796](https://github.com/matrix-org/matrix-doc/issues/2796))
-- Make `reason` and `score` parameters optional in the content reporting API as per [MSC2414](https://github.com/matrix-org/matrix-doc/pull/2414). ([#2807](https://github.com/matrix-org/matrix-doc/issues/2807))
-- Allow guests to get the list of members for a room as per [MSC2689](https://github.com/matrix-org/matrix-doc/pull/2689). ([#2808](https://github.com/matrix-org/matrix-doc/issues/2808))
-- Add support for spoilers as per [MSC2010](https://github.com/matrix-org/matrix-doc/pull/2010) and [MSC2557](https://github.com/matrix-org/matrix-doc/pull/2557), and `color` attribute as per [MSC2422](https://github.com/matrix-org/matrix-doc/pull/2422). ([#3098](https://github.com/matrix-org/matrix-doc/issues/3098))
-- Add `<details>` and `<summary>` to the suggested HTML subset as per [MSC2184](https://github.com/matrix-org/matrix-doc/pull/2184). ([#3100](https://github.com/matrix-org/matrix-doc/issues/3100))
-- Add key verification using in-room messages as per [MSC2241](https://github.com/matrix-org/matrix-doc/pull/2241). ([#3139](https://github.com/matrix-org/matrix-doc/issues/3139), [#3150](https://github.com/matrix-org/matrix-doc/issues/3150))
-- Add information about using SSSS for cross-signing and key backup. ([#3147](https://github.com/matrix-org/matrix-doc/issues/3147))
-- Add key verification method using QR codes as per [MSC1544](https://github.com/matrix-org/matrix-doc/pull/1544). ([#3149](https://github.com/matrix-org/matrix-doc/issues/3149))
-- Document how clients can simplify usage of Secure Secret Storage as per [MSC2874](https://github.com/matrix-org/matrix-doc/pull/2874). ([#3151](https://github.com/matrix-org/matrix-doc/issues/3151))
-- Add support for knocking, as per [MSC2403](https://github.com/matrix-org/matrix-doc/pull/2403). ([#3154](https://github.com/matrix-org/matrix-doc/issues/3154), [#3254](https://github.com/matrix-org/matrix-doc/issues/3254))
-- Multiple SSO providers are possible through `m.login.sso` as per [MSC2858](https://github.com/matrix-org/matrix-doc/pull/2858). ([#3163](https://github.com/matrix-org/matrix-doc/issues/3163))
-- Add `device_id` to `/account/whoami` response as per [MSC2033](https://github.com/matrix-org/matrix-doc/pull/2033). ([#3166](https://github.com/matrix-org/matrix-doc/issues/3166))
-- Downgrade identity server discovery failures to `FAIL_PROMPT` as per [MSC2284](https://github.com/matrix-org/matrix-doc/pull/2284). ([#3169](https://github.com/matrix-org/matrix-doc/issues/3169))
-- Re-version all endpoints to be `v3` as a starting point instead of `r0` as per [MSC2844](https://github.com/matrix-org/matrix-doc/pull/2844). ([#3421](https://github.com/matrix-org/matrix-doc/issues/3421))
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Fix issues with `age` and `unsigned` being shown in the wrong places. ([#2591](https://github.com/matrix-org/matrix-doc/issues/2591))
-- Fix definitions for room version capabilities. ([#2592](https://github.com/matrix-org/matrix-doc/issues/2592))
-- Fix various typos throughout the specification. ([#2594](https://github.com/matrix-org/matrix-doc/issues/2594), [#2599](https://github.com/matrix-org/matrix-doc/issues/2599), [#2809](https://github.com/matrix-org/matrix-doc/issues/2809), [#2878](https://github.com/matrix-org/matrix-doc/issues/2878), [#2885](https://github.com/matrix-org/matrix-doc/issues/2885), [#2888](https://github.com/matrix-org/matrix-doc/issues/2888), [#3116](https://github.com/matrix-org/matrix-doc/issues/3116), [#3339](https://github.com/matrix-org/matrix-doc/issues/3339))
-- Clarify link to OpenID Connect specification. ([#2605](https://github.com/matrix-org/matrix-doc/issues/2605))
-- Clarify the behaviour of SSO login and UI-Auth. ([#2608](https://github.com/matrix-org/matrix-doc/issues/2608))
-- Remove spurious `room_id` from `/sync` examples. ([#2629](https://github.com/matrix-org/matrix-doc/issues/2629))
-- Reorganize information in Push Notifications module for clarity. ([#2634](https://github.com/matrix-org/matrix-doc/issues/2634))
-- Improve consistency and clarity of event schema `title`s. ([#2647](https://github.com/matrix-org/matrix-doc/issues/2647))
-- Fix schema issues in `m.key.verification.accept` and secret storage. ([#2653](https://github.com/matrix-org/matrix-doc/issues/2653))
-- Reword "UI Authorization" to "User-Interactive Authentication" to be more clear. ([#2667](https://github.com/matrix-org/matrix-doc/issues/2667))
-- Fix schemas for push rule actions to represent their alternative object form. ([#2669](https://github.com/matrix-org/matrix-doc/issues/2669))
-- Fix usage of `highlight` tweak for consistency. ([#2670](https://github.com/matrix-org/matrix-doc/issues/2670))
-- Clarify the behaviour of `state` for `/sync` with lazy-loading. ([#2754](https://github.com/matrix-org/matrix-doc/issues/2754))
-- Clarify description of `m.room.redaction` event. ([#2814](https://github.com/matrix-org/matrix-doc/issues/2814))
-- Mark `messages` as a required JSON body field in `PUT /_matrix/client/r0/sendToDevice/{eventType}/{txnId}` calls. ([#2928](https://github.com/matrix-org/matrix-doc/issues/2928))
-- Correct examples of `client_secret` request body parameters so that they do not include invalid characters. ([#2985](https://github.com/matrix-org/matrix-doc/issues/2985))
-- Fix example MXC URI for `m.presence`. ([#3091](https://github.com/matrix-org/matrix-doc/issues/3091))
-- Clarify that event bodies are untrusted, as per [MSC2801](https://github.com/matrix-org/matrix-doc/pull/2801). ([#3099](https://github.com/matrix-org/matrix-doc/issues/3099))
-- Fix the maximum event size restriction (65535 bytes -> 65536). ([#3127](https://github.com/matrix-org/matrix-doc/issues/3127))
-- Update `Access-Control-Allow-Headers` recommendation to fit CORS specification. ([#3225](https://github.com/matrix-org/matrix-doc/issues/3225))
-- Explicitly state that `replacement_room` is a room ID in `m.room.tombstone` events. ([#3233](https://github.com/matrix-org/matrix-doc/issues/3233))
-- Clarify that all request bodies are required. ([#3238](https://github.com/matrix-org/matrix-doc/issues/3238), [#3332](https://github.com/matrix-org/matrix-doc/issues/3332))
-- Add missing titles to some scheams. ([#3330](https://github.com/matrix-org/matrix-doc/issues/3330))
-- Add User-Interactive Authentication fields to cross-signing APIs as per [MSC1756](https://github.com/matrix-org/matrix-doc/pull/1756). ([#3331](https://github.com/matrix-org/matrix-doc/issues/3331))
-- Mention that a canonical alias event should be added when a room is created with an alias. ([#3337](https://github.com/matrix-org/matrix-doc/issues/3337))
-- Add an 'API conventions' section to the Appendices. ([#3350](https://github.com/matrix-org/matrix-doc/issues/3350))
-- Clarify the documentation around the pagination tokens used by `/sync`, `/rooms/{room_id}/messages`, `/initialSync`, `/rooms/{room_id}/initialSync`, and `/notifications`. ([#3353](https://github.com/matrix-org/matrix-doc/issues/3353))
-- Remove the inaccurate 'Pagination' section. ([#3366](https://github.com/matrix-org/matrix-doc/issues/3366))
-- Clarify how `redacted_because` is meant to work. ([#3411](https://github.com/matrix-org/matrix-doc/issues/3411))
-- Remove extraneous `mimetype` from `EncryptedFile` examples, as per [MSC2582](https://github.com/matrix-org/matrix-doc/pull/2582). ([#3412](https://github.com/matrix-org/matrix-doc/issues/3412))
-- Describe how [MSC2844](https://github.com/matrix-org/matrix-doc/pull/2844) affects the `/versions` endpoint. ([#3420](https://github.com/matrix-org/matrix-doc/issues/3420))
-- Fix documentation errors around `threepid_creds`. ([#3471](https://github.com/matrix-org/matrix-doc/issues/3471))
-
-
-### Server-Server API
-
-
-<strong>New Endpoints</strong>
-
-
-- Add `/make_knock` and `/send_knock` endpoints as per [MSC2403](https://github.com/matrix-org/matrix-doc/pull/2403). ([#3154](https://github.com/matrix-org/matrix-doc/issues/3154))
-
-
-<strong>Backwards Compatible Changes</strong>
-
-
-- Add cross-signing information to `GET /user/keys` and `GET /user/devices/{userId}`, `m.device_list_update` EDU, and a new `m.signing_key_update` EDU as per [MSC1756](https://github.com/matrix-org/matrix-doc/pull/1756). ([#2536](https://github.com/matrix-org/matrix-doc/issues/2536))
-- Add support for knocking, as per [MSC2403](https://github.com/matrix-org/matrix-doc/pull/2403). ([#3154](https://github.com/matrix-org/matrix-doc/issues/3154))
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Specify that `GET /_matrix/federation/v1/make_join/{roomId}/{userId}` can return a 404 if the room is unknown. ([#2688](https://github.com/matrix-org/matrix-doc/issues/2688))
-- Fix various typos throughout the specification. ([#2888](https://github.com/matrix-org/matrix-doc/issues/2888), [#3116](https://github.com/matrix-org/matrix-doc/issues/3116), [#3128](https://github.com/matrix-org/matrix-doc/issues/3128), [#3207](https://github.com/matrix-org/matrix-doc/issues/3207))
-- Correct the `/_matrix/federation/v1/user/devices/{userId}` response which actually returns `"self_signing_key"` instead of `"self_signing_keys"`. ([#3312](https://github.com/matrix-org/matrix-doc/issues/3312))
-- Explain the reasons why `<hostname>` TLS certificate is needed rather than `<delegated_hostname>` for SRV delegation. ([#3322](https://github.com/matrix-org/matrix-doc/issues/3322))
-- Tweak the example PDU diagram to better demonstrate situations with multiple `prev_events`. ([#3340](https://github.com/matrix-org/matrix-doc/issues/3340))
-
-
-### Application Service API
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Fix various typos throughout the specification. ([#2888](https://github.com/matrix-org/matrix-doc/issues/2888))
-
-
-### Identity Service API
-
-
-<strong>New Endpoints</strong>
-
-
-- Add `GET /_matrix/identity/versions` API as per [MSC2320](https://github.com/matrix-org/matrix-doc/pull/2320). ([#3101](https://github.com/matrix-org/matrix-doc/issues/3101))
-
-
-<strong>Removed Endpoints</strong>
-
-
-- The v1 identity service API has been removed in favour of the v2 API, as per [MSC2713](https://github.com/matrix-org/matrix-doc/pull/2713). ([#3170](https://github.com/matrix-org/matrix-doc/issues/3170))
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Fix various typos throughout the specification. ([#2888](https://github.com/matrix-org/matrix-doc/issues/2888))
-- Clarify that some identifiers must be case folded prior to processing, as per [MSC2265](https://github.com/matrix-org/matrix-doc/pull/2265). ([#3167](https://github.com/matrix-org/matrix-doc/issues/3167), [#3176](https://github.com/matrix-org/matrix-doc/issues/3176))
-- Describe how [MSC2844](https://github.com/matrix-org/matrix-doc/pull/2844) affects the `/versions` endpoint. ([#3459](https://github.com/matrix-org/matrix-doc/issues/3459))
-
-
-### Push Gateway API
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Clarify where to get information about the various parameter values for the notify endpoint. ([#2763](https://github.com/matrix-org/matrix-doc/issues/2763))
diff --git a/layouts/partials/changelogs/v1.2.md b/layouts/partials/changelogs/v1.2.md
deleted file mode 100644
index bce9ea66..00000000
--- a/layouts/partials/changelogs/v1.2.md
+++ /dev/null
@@ -1,151 +0,0 @@
-<!--
-This is a header file for the generated changelog.
-
-Variables:
-    v1.2  = Replaced by the version number (eg: v1.2)
-    February 02, 2022     = Replaced by the date (eg: April 01, 2021)
--->
-
-## v1.2
-
-<table class="release-info">
-<tr><th>Git commit</th><td><a href="https://github.com/matrix-org/matrix-doc/tree/v1.2">https://github.com/matrix-org/matrix-doc/tree/v1.2</a></td>
-<tr><th>Release date</th><td>February 02, 2022</td>
-</table>
-
-<!-- Intentionally blank line to ensure headers work in the concatenated changelog -->
-### Client-Server API
-
-
-<strong>Breaking Changes</strong>
-
-
-- The `prev_content` field is now returned inside the `unsigned` property of events, rather than at the top level, as per [MSC3442](https://github.com/matrix-org/matrix-doc/pull/3442). ([#3524](https://github.com/matrix-org/matrix-doc/issues/3524))
-- The `aliases` property from the chunks returned by `/publicRooms`, as per [MSC2432](https://github.com/matrix-org/matrix-doc/pull/2432). ([#3624](https://github.com/matrix-org/matrix-doc/issues/3624))
-
-
-<strong>New Endpoints</strong>
-
-
-- Add the Space Hierarchy API (`GET /_matrix/client/v1/rooms/{roomId}/hierarchy`) as per [MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946). ([#3610](https://github.com/matrix-org/matrix-doc/issues/3610))
-- Add `/_matrix/client/v1/register/m.login.registration_token/validity` as per [MSC3231](https://github.com/matrix-org/matrix-doc/pull/3231). ([#3616](https://github.com/matrix-org/matrix-doc/issues/3616))
-
-
-<strong>Backwards Compatible Changes</strong>
-
-
-- Extend `/_matrix/client/r0/login` to accept a `m.login.appservice`, as per [MSC2778](https://github.com/matrix-org/matrix-doc/pull/2778). ([#3324](https://github.com/matrix-org/matrix-doc/issues/3324))
-- Add support for `restricted` rooms as per [MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083), [MSC3289](https://github.com/matrix-org/matrix-doc/pull/3289), and [MSC3375](https://github.com/matrix-org/matrix-doc/pull/3375). ([#3387](https://github.com/matrix-org/matrix-doc/issues/3387))
-- Add `is_guest` to `/account/whoami` as per [MSC3069](https://github.com/matrix-org/matrix-doc/pull/3069). ([#3605](https://github.com/matrix-org/matrix-doc/issues/3605))
-- Expand guest access to sending any room event and state event as per [MSC3419](https://github.com/matrix-org/matrix-doc/pull/3419). ([#3605](https://github.com/matrix-org/matrix-doc/issues/3605))
-- Add Spaces and room types as per [MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) and [MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946). ([#3610](https://github.com/matrix-org/matrix-doc/issues/3610))
-- Add new `m.set_displayname`, `m.set_avatar_url`, and `m.3pid_changes` capabilities as per [MSC3283](https://github.com/matrix-org/matrix-doc/pull/3283). ([#3614](https://github.com/matrix-org/matrix-doc/issues/3614))
-- Add support for fallback keys (optional keys used once one-time keys run out), as per [MSC2732](https://github.com/matrix-org/matrix-doc/pull/2732). ([#3615](https://github.com/matrix-org/matrix-doc/issues/3615))
-- Add token-authenticated registration support as per [MSC3231](https://github.com/matrix-org/matrix-doc/pull/3231). ([#3616](https://github.com/matrix-org/matrix-doc/issues/3616))
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Make `AesHmacSha2KeyDescription` consistent with `KeyDescription` in marking `name` as optional. ([#3481](https://github.com/matrix-org/matrix-doc/issues/3481))
-- Fix various typos throughout the specification. ([#3482](https://github.com/matrix-org/matrix-doc/issues/3482), [#3495](https://github.com/matrix-org/matrix-doc/issues/3495), [#3509](https://github.com/matrix-org/matrix-doc/issues/3509), [#3535](https://github.com/matrix-org/matrix-doc/issues/3535), [#3591](https://github.com/matrix-org/matrix-doc/issues/3591), [#3601](https://github.com/matrix-org/matrix-doc/issues/3601), [#3611](https://github.com/matrix-org/matrix-doc/issues/3611), [#3671](https://github.com/matrix-org/matrix-doc/issues/3671), [#3680](https://github.com/matrix-org/matrix-doc/issues/3680))
-- Explicitly mention RFC5870 in the definition of `m.location` events ([#3492](https://github.com/matrix-org/matrix-doc/issues/3492))
-- Add `403 M_FORBIDDEN` error code to `/profile/{userId}` as per [MSC3550](https://github.com/matrix-org/matrix-doc/pull/3550). ([#3530](https://github.com/matrix-org/matrix-doc/issues/3530))
-- Clarify the description of the `/sync` API, including a fix to an ASCII art diagram. ([#3543](https://github.com/matrix-org/matrix-doc/issues/3543))
-- Clarify that `base_url` in client `well_known` may or may not include trailing slash. ([#3562](https://github.com/matrix-org/matrix-doc/issues/3562))
-- Clarify which signature to check when decrypting `m.olm.v1.curve25519-aes-sha2` messages. ([#3573](https://github.com/matrix-org/matrix-doc/issues/3573))
-- Clarify what "Stripped State" is and what purpose it serves, as per [MSC3173](https://github.com/matrix-org/matrix-doc/pull/3173). ([#3606](https://github.com/matrix-org/matrix-doc/issues/3606))
-- Clarify how to interpret missing one-time key counts. ([#3636](https://github.com/matrix-org/matrix-doc/issues/3636))
-- Correct the schema for the responses  for various API endpoints. ([#3650](https://github.com/matrix-org/matrix-doc/issues/3650))
-- Clarify that group mentions are no longer in the specification. ([#3652](https://github.com/matrix-org/matrix-doc/issues/3652))
-- Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. ([#3658](https://github.com/matrix-org/matrix-doc/issues/3658))
-- Fix the rendering of the responses for various API endpoints. ([#3674](https://github.com/matrix-org/matrix-doc/issues/3674))
-
-
-### Server-Server API
-
-
-<strong>New Endpoints</strong>
-
-
-- Add the Space Hierarchy API (`GET /_matrix/federation/v1/hierarchy/{roomId}`) as per [MSC2946](https://github.com/matrix-org/matrix-doc/pull/2946). ([#3610](https://github.com/matrix-org/matrix-doc/issues/3610), [#3660](https://github.com/matrix-org/matrix-doc/issues/3660))
-
-
-<strong>Backwards Compatible Changes</strong>
-
-
-- Add support for `restricted` rooms as per [MSC3083](https://github.com/matrix-org/matrix-doc/pull/3083), [MSC3289](https://github.com/matrix-org/matrix-doc/pull/3289), and [MSC3375](https://github.com/matrix-org/matrix-doc/pull/3375). ([#3387](https://github.com/matrix-org/matrix-doc/issues/3387))
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Fix various typos throughout the specification. ([#3527](https://github.com/matrix-org/matrix-doc/issues/3527), [#3528](https://github.com/matrix-org/matrix-doc/issues/3528))
-- Clarify that `GET /_matrix/federation/v1/event_auth/{roomId}/{eventId}` does *not* return the auth chain for the full state of the room. ([#3583](https://github.com/matrix-org/matrix-doc/issues/3583))
-- Fix the rendering of the responses for various API endpoints. ([#3674](https://github.com/matrix-org/matrix-doc/issues/3674))
-
-
-### Application Service API
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Distinguish between "federation" event format as exchanged by the Federation API, and the "client" event formats as used in the client-server and AS APIs. ([#3658](https://github.com/matrix-org/matrix-doc/issues/3658))
-- Fix the rendering of the responses for various API endpoints. ([#3674](https://github.com/matrix-org/matrix-doc/issues/3674))
-- Correct the documentation for the response value for `GET /_matrix/app/v1/thirdparty/protocol/{protocol}`. ([#3675](https://github.com/matrix-org/matrix-doc/issues/3675))
-
-
-### Identity Service API
-
-
-<strong>Backwards Compatible Changes</strong>
-
-
-- Add the `room_type` to stored invites as per [MSC3288](https://github.com/matrix-org/matrix-doc/pull/3288). ([#3610](https://github.com/matrix-org/matrix-doc/issues/3610))
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Fix the rendering of the responses for various API endpoints. ([#3674](https://github.com/matrix-org/matrix-doc/issues/3674))
-
-
-### Push Gateway API
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Fix the rendering of the responses for various API endpoints. ([#3674](https://github.com/matrix-org/matrix-doc/issues/3674))
-
-
-### Room Versions
-
-
-<strong>Backwards Compatible Changes</strong>
-
-
-- Add Room Version 8 as per [MSC3289](https://github.com/matrix-org/matrix-doc/pull/3289). ([#3387](https://github.com/matrix-org/matrix-doc/issues/3387))
-- Add Room Version 9 as per [MSC3375](https://github.com/matrix-org/matrix-doc/pull/3375). ([#3387](https://github.com/matrix-org/matrix-doc/issues/3387))
-
-
-<strong>Spec Clarifications</strong>
-
-
-- Fully specify room versions to indicate what exactly is carried over from parent versions. ([#3432](https://github.com/matrix-org/matrix-doc/issues/3432), [#3661](https://github.com/matrix-org/matrix-doc/issues/3661))
-- Clarifications to sections on event IDs and event formats. ([#3501](https://github.com/matrix-org/matrix-doc/issues/3501))
-- Remove a number of fields which were incorrectly shown to form part of the `unsigned` data of a Federation PDU. ([#3522](https://github.com/matrix-org/matrix-doc/issues/3522))
-- Fix heading order of room version specifications to be consistent. ([#3683](https://github.com/matrix-org/matrix-doc/issues/3683))
-- Add missing "Signing key validity period" section to room version 6. ([#3683](https://github.com/matrix-org/matrix-doc/issues/3683))
-- Fix auth rules to allow membership of `knock` -> `leave` in v7, v8, and v9. ([#3694](https://github.com/matrix-org/matrix-doc/issues/3694))
-
-
-### Appendices
-
-
-<strong>Backwards Compatible Changes</strong>
-
-
-- Describe "Common Namespaced Identifier Grammar" as per [MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758). ([#3171](https://github.com/matrix-org/matrix-doc/issues/3171))
-- Describe the `matrix:` URI scheme as per [MSC2312](https://github.com/matrix-org/matrix-doc/pull/2312). ([#3608](https://github.com/matrix-org/matrix-doc/issues/3608))
diff --git a/layouts/partials/events/render-event.html b/layouts/partials/events/render-event.html
deleted file mode 100644
index 66e15db7..00000000
--- a/layouts/partials/events/render-event.html
+++ /dev/null
@@ -1,100 +0,0 @@
-{{/*
-
-  Renders a single event, given:
-
-    * `event_name`: the name we want to display for the event
-    * `event_data`: the event specification
-    * `desired_example_name` (optional): the exact name of the examples to render.
-    If `desired_example_name` is omitted we render all examples
-    whose names start with the `event_name`.
-
-*/}}
-
-{{ $event_name := .event_name }}
-{{ $desired_example_name := .desired_example_name }}
-{{ $event_data := .event_data }}
-
-<section class="rendered-data event">
-
-<details {{ if not .Site.Params.ui.rendered_data_collapsed }}open{{ end }}>
-<summary>
-
-  <h1 id="{{ anchorize $event_name }}">
-   <code>{{ $event_name }}</code>
-  </h1>
-
-  <hr/>
-
-{{ if (index $event_data "x-addedInMatrixVersion") }}
-  {{ partial "added-in" (dict "v" (index $event_data "x-addedInMatrixVersion")) }}
-{{ end }}
-{{ if (index $event_data "x-changedInMatrixVersion") }}
-  {{ partial "changed-in" (dict "changes_dict" (index $event_data "x-changedInMatrixVersion")) }}
-{{ end -}}
-
-{{ $event_data.description | markdownify }}
-
-</summary>
-
-{{ $state_key := index $event_data.properties "state_key" }}
-
-<table class="basic-info">
-  <tr>
-   <th>Event type:</th>
-   <td>{{ if $state_key }}State event{{ else }}Message event{{ end }}</td>
-  </tr>
-{{ if $state_key }}
-  <tr>
-   <th>State key</th>
-   <td>{{ $state_key.description | markdownify }}</td>
- </tr>
-{{ end }}
-</table>
-
-<h2>Content</h2>
-
-{{ $additional_types := partial "json-schema/resolve-additional-types" $event_data.properties.content }}
-
-{{ range $additional_types }}
-    {{ partial "openapi/render-object-table" (dict "caption" .title "properties" .properties "required" .required) }}
-{{end}}
-
-<h2>Examples</h2>
-
-{{ $all_examples := index site.Data "event-schemas" "examples" }}
-
-{{ range $example_name, $example := $all_examples }}
-
-    {{/*
-      This is to allow the msgtype template to work.
-      It lets callers specify exactly the name of the example they want
-    */}}
-    {{ if $desired_example_name }}
-        {{ if eq $example_name $desired_example_name }}
-            {{ $example_content := partial "json-schema/resolve-refs" (dict "schema" $example "path" "event-schemas/examples") }}
-```json
-{{ jsonify (dict "indent" "  ") $example_content }}
-```
-        {{ end }}
-    {{/*
-      If `$desired_example_name` is not given, we will include any
-      examples whose first part (before "$") matches the event name
-    */}}
-    {{ else }}
-
-        {{ $pieces := split $example_name "$" }}
-        {{ $example_base_name := index $pieces 0 }}
-        {{ if eq $event_name $example_base_name }}
-            {{ $example_content := partial "json-schema/resolve-refs" (dict "schema" $example "path" "event-schemas/examples") }}
-            {{ $example_json := jsonify (dict "indent" "  ") $example_content }}
-            {{ $example_json = replace $example_json "\\u003c" "<" }}
-            {{ $example_json = replace $example_json "\\u003e" ">" | safeHTML }}
-
-```json
-{{ $example_json }}
-```
-        {{ end }}
-    {{ end }}
-{{ end }}
-
-</section>
diff --git a/layouts/partials/footer.html b/layouts/partials/footer.html
deleted file mode 100644
index 3506f834..00000000
--- a/layouts/partials/footer.html
+++ /dev/null
@@ -1,39 +0,0 @@
-{{/*
-
-  A modified version of the footer.html partial in Docsy.
-
-*/}}
-
-{{ $links := .Site.Params.links }}
-<footer class="py-5 row d-print-none">
-  <div class="container-fluid mx-sm-5">
-    <div class="row">
-      <div class="col-12 text-center text-xs-center order-sm-3">
-        {{ with $links }}
-        {{ with index . "developer"}}
-        {{ template "footer-links-block"  . }}
-        {{ end }}
-        {{ end }}
-      </div>
-    </div>
-    <div class="row">
-      <div class="col-12 text-center py-2 order-sm-3">
-        {{ with .Site.Params.copyright }}<small>&copy; {{ now.Year}} {{ .}}</small>{{ end }}
-	{{ if not .Site.Params.ui.footer_about_disable }}
-		{{ with .Site.GetPage "about" }}<p class="mt-2"><a href="{{ .RelPermalink }}">{{ .Title }}</a></p>{{ end }}
-	{{ end }}
-      </div>
-    </div>
-  </div>
-</footer>
-{{ define "footer-links-block" }}
-<ul class="list-inline mb-0">
-  {{ range . }}
-  <li class="list-inline-item mx-2 h3" data-toggle="tooltip" data-placement="top" title="{{ .name }}" aria-label="{{ .name }}">
-    <a class="text-dark" target="_blank" rel="noopener noreferrer" href="{{ .url }}">
-      <i class="{{ .icon }}"></i>
-    </a>
-  </li>
-  {{ end }}
-</ul>
-{{ end }}
diff --git a/layouts/partials/hooks/body-end.html b/layouts/partials/hooks/body-end.html
deleted file mode 100644
index 377470d9..00000000
--- a/layouts/partials/hooks/body-end.html
+++ /dev/null
@@ -1,17 +0,0 @@
-{{/*
-
-  This template is included at the end of each page's `<body>`.
-
-  We're using it here to:
-
-  1) include the JS that generates the table of contents. It would be better
-  to generate the table of contents as part of the Hugo build process, but
-  that doesn't work nicely with the way we want to author client-server modules
-  as separate files.
-
-  2) highlight and scroll the ToC in the sidebar to match the place we are at
-  in the document.
-
-*/}}
-
-<script defer language="javascript" type="text/javascript"  src="{{ "js/toc.js" | urlize | relURL }}"></script>
diff --git a/layouts/partials/hooks/head-end.html b/layouts/partials/hooks/head-end.html
deleted file mode 100644
index 925c43cc..00000000
--- a/layouts/partials/hooks/head-end.html
+++ /dev/null
@@ -1,18 +0,0 @@
-{{/*
-
-  This template is included at the end of each page's `<head>`.
-
-  We're using it here to include the custom CSS for the Matrix spec.
-
-*/}}
-
-{{ $scss := "scss/custom.scss"}}
-{{ if .Site.IsServer }}
-{{/* Note the missing postCSS. This makes it snappier to develop in Chrome, but makes it look sub-optimal in other browsers. */}}
-{{ $css := resources.Get $scss | toCSS (dict "enableSourceMap" true) }}
-<link href="{{ $css.RelPermalink }}" rel="stylesheet">
-{{ else }}
-{{ $css := resources.Get $scss | toCSS (dict "enableSourceMap" false) | postCSS | minify | fingerprint }}
-<link rel="preload" href="{{ $css.RelPermalink }}" as="style">
-<link href="{{ $css.RelPermalink }}" rel="stylesheet" integrity="{{ $css.Data.integrity }}">
-{{ end }}
diff --git a/layouts/partials/json-schema/resolve-additional-types.html b/layouts/partials/json-schema/resolve-additional-types.html
deleted file mode 100644
index 26df52e5..00000000
--- a/layouts/partials/json-schema/resolve-additional-types.html
+++ /dev/null
@@ -1,92 +0,0 @@
-{{/*
-
-  Finds and returns all nested objects, given:
-
-  * `this_object`: a JSON schema object
-
-  Given a schema object, this template finds all nested objects under that
-  schema.
-
-  It "cleans" each object by copying only the parts of the objects that
-  the renderer needs, and adds the result to an array, `additional_objects`.
-
-  Finally it returns the array of all the objects it found.
-
-  Note that the returned array may contain duplicate objects.
-
-*/}}
-
-{{ $this_object := partial "json-schema/resolve-allof" . }}
-{{ $additional_objects := slice }}
-
-{{ if eq $this_object.type "object" }}
-
-    {{/*
-      Add the object we were passed into the $additional_objects array
-    */}}
-    {{ $additional_objects = $additional_objects | append (partial "clean-object" $this_object) }}
-
-    {{/*
-      Add any nested objects referenced in this object's `additionalProperties`
-    */}}
-    {{ if $this_object.additionalProperties }}
-        {{ if reflect.IsMap $this_object.additionalProperties }}
-            {{ $additional_objects = $additional_objects | append (partial "clean-object" $this_object.additionalProperties) }}
-
-            {{ range $key, $property := $this_object.additionalProperties.properties }}
-                {{ $additional_objects = partial "get-additional-objects" (dict "this_object" $property "additional_objects" $additional_objects) }}
-            {{ end }}
-
-        {{ end }}
-    {{ end }}
-
-    {{/*
-      Add any nested objects referenced in this object's `properties`
-    */}}
-    {{ range $key, $property := $this_object.properties}}
-        {{ $additional_objects = partial "get-additional-objects" (dict "this_object" $property "additional_objects" $additional_objects) }}
-    {{ end }}
-
-{{ end }}
-
-{{ if eq $this_object.type "array" }}
-    {{/*
-      Add any nested objects referenced in this object's `items`
-    */}}
-    {{ if reflect.IsSlice $this_object.items}}
-        {{ range $this_object.items }}
-            {{ $additional_objects = partial "get-additional-objects" (dict "this_object" . "additional_objects" $additional_objects) }}
-        {{ end }}
-    {{ else }}
-        {{ $additional_objects = partial "get-additional-objects" (dict "this_object" $this_object.items "additional_objects" $additional_objects) }}
-    {{ end }}
-{{ end }}
-
-{{ return $additional_objects }}
-
-
-{{/*
-  This actually makes the recursive call and adds the returned objects to the array
-*/}}
-{{ define "partials/get-additional-objects" }}
-    {{ $additional_objects := .additional_objects }}
-
-    {{ $this_object := partial "json-schema/resolve-allof" .this_object }}
-    {{ $more_objects := partial "json-schema/resolve-additional-types" $this_object }}
-    {{/*
-      As far as I know we don't have something like Array.concat(), so add them one at a time
-    */}}
-    {{ range $more_objects}}
-        {{ $additional_objects = $additional_objects | append (partial "clean-object" .) }}
-    {{ end }}
-    {{ return $additional_objects }}
-{{ end }}
-
-{{/*
-  Only copy the bits of the object that we actually care about.
-  This is needed for uniqify to work - otherwise objects that are the same
-  but with (for example) different examples will be considered different.
-*/}}
-{{ define "partials/clean-object" }}
-    {{ return (dict "title" .title "properties" .properties "required" .required "enum" .enum) }}
-{{ end }}
diff --git a/layouts/partials/json-schema/resolve-allof.html b/layouts/partials/json-schema/resolve-allof.html
deleted file mode 100644
index c7ffda15..00000000
--- a/layouts/partials/json-schema/resolve-allof.html
+++ /dev/null
@@ -1,102 +0,0 @@
-{{/*
-
-  Resolves the `allOf` keyword (https://swagger.io/specification/v2/#composition-and-inheritance-polymorphism),
-  given a JSON schema object.
-
-  `allOf` is used to support a kind of inheritance for JSON schema objects.
-
-  An object can reference a "parent" object using `allOf`, and it then inherits
-  its parent's properties. If the same property is present in the child, then
-  we use the child's version (the child overrides the parent).
-
-  Of course the parent can itself inherit from *its* parent, so we recurse to
-  handle that.
-
-  Note that `allOf` is only resolved at the top level of the schema object. For
-  example, if you call this on an API definition which defines a `parameter`
-  which has an allOf schema, it will not be resolved. To handle this, the
-  openapi templates call resolve-allof for every schema object that they
-  process.
-*/}}
-
-{{ $ret := . }}
-{{ $original := . }}
-
-{{/*
-  We special-case 'required', and accumulate the values from all the 'allOf'
-  entries (rather than simply overriding them). Start the accumulation here.
-*/}}
-
-{{ $required := .required }}
-{{ if not $required }}
-    {{ $required := slice }}
-{{ end }}
-
-{{ with $ret.allOf }}
-
-    {{/*
-      construct a new dict, with each of the allOf entries merged into it in
-      turn.
-    */}}
-    {{ $all_of_values := dict }}
-    {{ range . }}
-        {{ with .required }}
-            {{ $required = union $required . }}
-        {{ end }}
-
-        {{/*
-          With merge, values from the second argument override those from the first argument.
-          So this order will accumulate values from allOf items, allowing later ones to override earlier
-
-          Note also that `merge` does a *deep* merge - nested maps are also
-          merged. (Slices are replaced though.)
-        */}}
-        {{ $all_of_values = merge $all_of_values . }}
-    {{ end }}
-
-    {{/*
-      Finally, merge in the original, allowing the original to override allOf.
-    */}}
-    {{ $ret = merge $all_of_values $ret }}
-
-    {{/*
-      Except that if allOf *itself* contains allOf (ie, the parent also
-      inherits from a grandparent), then we replace allOf in the original
-      with that in the parent. Below, we see that this has happened, and
-      recurse.
-
-      TODO: surely it would be better to simply do the recursion as we iterate
-      though the allOf list above - not least because we might have multiple
-      parents with different grandparents, and by doing this we only get one
-      set of grandparents.
-    */}}
-    {{ with $all_of_values.allOf }}
-        {{ $ret = merge $ret (dict "allOf" . ) }}
-    {{ end }}
-
-    {{/*
-       special-case 'required': replace it with the union of all the
-       'required' arrays from the original and allOf values.
-
-       XXX: but first we merge in the original 'required', again? why
-          do we do that? it should already have been done at the start.
-    */}}
-    {{ with $ret.required }}
-        {{ $required = union $required $ret.required }}
-    {{ end }}
-
-    {{ $ret = merge $ret (dict "required" $required) }}
-{{ end }}
-
-{{/*
-  If we replaced the 'allOf' dict with one from a grandparent, we now
-  need to recurse.
-*/}}
-{{ if ne $ret.allOf $original.allOf }}
-
-    {{ $resolved := partial "json-schema/resolve-allof" $ret }}
-    {{ $ret = merge $ret $resolved }}
-
-{{ end }}
-
-{{ return $ret }}
diff --git a/layouts/partials/json-schema/resolve-example.html b/layouts/partials/json-schema/resolve-example.html
deleted file mode 100644
index 90620b72..00000000
--- a/layouts/partials/json-schema/resolve-example.html
+++ /dev/null
@@ -1,47 +0,0 @@
-{{/*
-
-  For complex objects, example content is sometimes attached to the
-  object's individual properties (and subproperties...), so to get
-  a complete example for the whole object we need to iterate through
-  its properties (and subproperties...) and assemble them.
-
-  That's what this template does.
-
-*/}}
-
-{{ $this_object := partial "json-schema/resolve-allof" . }}
-
-{{ $example := $this_object.example }}
-
-{{ if eq $this_object.type "object" }}
-    {{ if not $example }}
-        {{ $example = dict }}
-    {{ end }}
-
-    {{ range $key, $property := $this_object.properties}}
-        {{ $this_property_example := partial "json-schema/resolve-example" $property }}
-        {{ if $this_property_example }}
-            {{ $example = merge (dict $key $this_property_example) $example }}
-        {{ end }}
-    {{ end }}
-
-{{ else if eq $this_object.type "array" }}
-
-    {{ if not $example }}
-        {{/* the "items" within an array can either be an object (where we have a
-             list of items which match the schema), or a list (for tuple
-             validation, where each item has a different schema).
-
-             TODO: support tuple validation here.
-        */}}
-        {{ if reflect.IsMap $this_object.items }}
-            {{ $items_example := partial "json-schema/resolve-example" $this_object.items }}
-            {{ $example = slice $items_example }}
-        {{ else }}
-            {{ $example = slice }}
-        {{ end }}
-    {{ end }}
-
-{{ end }}
-
-{{ return $example }}
diff --git a/layouts/partials/json-schema/resolve-refs.html b/layouts/partials/json-schema/resolve-refs.html
deleted file mode 100644
index 1d99201d..00000000
--- a/layouts/partials/json-schema/resolve-refs.html
+++ /dev/null
@@ -1,65 +0,0 @@
-{{/*
-
-  Resolves the `$ref` JSON schema keyword, by recursively replacing
-  it with the object it points to.
-
-  This template uses [`Scratch`](https://gohugo.io/functions/scratch/)
-  rather than a normal `dict` because with `dict` you can't replace key values:
-  https://discourse.gohugo.io/t/how-can-i-add-set-and-delete-keys-in-a-dictionary/29661
-
-*/}}
-
-{{ $schema := .schema }}
-{{ $path := .path}}
-
-{{ $ret := $schema }}
-
-{{ if reflect.IsMap $schema }}
-
-    {{ $scratch := newScratch }}
-    {{ $scratch.Set "result_map" dict }}
-
-    {{ $ref_value := index $schema "$ref"}}
-    {{ if $ref_value}}
-        {{ $full_path := path.Join $path $ref_value }}
-        {{/*
-          Apparently Hugo doesn't give us a nice way to split the extension off a filename.
-        */}}
-        {{ $without_ext := replaceRE "\\.[^\\.]*$" "" $full_path }}
-        {{ $pieces := split $without_ext "/" }}
-
-        {{ $ref := index site.Data $pieces }}
-
-        {{ $new_path := (path.Split $full_path).Dir}}
-        {{ $result_map := partial "json-schema/resolve-refs" (dict "schema" $ref "path" $new_path)}}
-        {{ if $result_map}}
-            {{ $scratch.Set "result_map" $result_map }}
-        {{end }}
-    {{ end }}
-
-
-    {{ range $key, $value := $schema }}
-        {{ if ne $key "$ref" }}
-            {{ $resolved := partial "json-schema/resolve-refs" (dict "schema" $value "path" $path) }}
-            {{ $scratch.SetInMap "result_map" $key $resolved }}
-        {{ end }}
-    {{ end }}
-
-    {{ $ret = $scratch.Get "result_map" }}
-
-{{ end }}
-
-{{ if reflect.IsSlice $schema }}
-
-    {{ $result_slice := slice }}
-
-    {{ range $schema }}
-        {{ $resolved := partial "json-schema/resolve-refs" (dict "schema" . "path" $path) }}
-        {{ $result_slice = $result_slice | append $resolved }}
-    {{ end }}
-
-    {{ $ret = $result_slice }}
-
-{{ end }}
-
-{{ return $ret }}
diff --git a/layouts/partials/navbar.html b/layouts/partials/navbar.html
deleted file mode 100644
index e78ee9c4..00000000
--- a/layouts/partials/navbar.html
+++ /dev/null
@@ -1,55 +0,0 @@
-{{/*
-
-  A version of the navbar.html partial in Docsy, only modified
-	to include the spec version, which is calculated using an
-  inline `version-string` partial.
-
-*/}}
-
-{{ $cover := .HasShortcode "blocks/cover" }}
-<nav class="js-navbar-scroll navbar navbar-expand navbar-light {{ if $cover}} td-navbar-cover {{ end }}flex-column flex-md-row td-navbar">
-        <a class="navbar-brand" href="{{ .Site.Home.RelPermalink }}">
-		<span class="navbar-logo">{{ with resources.Get "icons/logo.svg" }}{{ ( . | minify).Content | safeHTML }}{{ end }}</span><span class="font-weight-bold">specification</span><span class="navbar-version"> &mdash; {{ partial "version-string" . }}</span>
-	</a>
-	<div class="td-navbar-nav-scroll ml-md-auto" id="main_navbar">
-		<ul class="navbar-nav mt-2 mt-lg-0">
-
-			<li class="nav-item mr-4 mb-2 mb-lg-0"><a href="https://matrix.org/foundation/">Foundation</a>
-			</li>
-
-      <li class="nav-item mr-4 mb-2 mb-lg-0"><a href="https://matrix.org/faq/">FAQs</a>
-			</li>
-
-      <li class="nav-item mr-4 mb-2 mb-lg-0"><a href="https://matrix.org/blog/posts">Blog</a>
-      </li>
-
-			{{ if  .Site.Params.versions }}
-			<li class="nav-item dropdown d-none d-lg-block">
-				{{ partial "navbar-version-selector.html" . }}
-			</li>
-			{{ end }}
-			{{ if  (gt (len .Site.Home.Translations) 0) }}
-			<li class="nav-item dropdown d-none d-lg-block">
-				{{ partial "navbar-lang-selector.html" . }}
-			</li>
-			{{ end }}
-		</ul>
-	</div>
-	<div class="navbar-nav d-none d-lg-block">{{ partial "search-input.html" . }}</div>
-</nav>
-
-
-{{ define "partials/version-string" }}
-    {{ $ret := "unstable version"}}
-
-    {{ $status := .Site.Params.version.status }}
-
-    {{ if ne $status "unstable"}}
-        {{ $path := path.Join "changelogs" }}
-
-        {{/* produces a string similar to "version v1.5" */}}
-        {{ $ret = delimit (slice "version v" .Site.Params.version.major "." .Site.Params.version.minor) "" }}
-    {{ end }}
-
-    {{ return $ret }}
-{{ end }}
diff --git a/layouts/partials/openapi/render-api.html b/layouts/partials/openapi/render-api.html
deleted file mode 100644
index db10b98c..00000000
--- a/layouts/partials/openapi/render-api.html
+++ /dev/null
@@ -1,54 +0,0 @@
-{{/*
-
-  Render an HTTP API, given:
-
-  * `api_data`: the OpenAPI/Swagger data
-  * `base_url`: the base URL: that is, the part we glue onto the front
-  of each value in `paths` to get a complete URL.
-  * `path`: the directory under /data where we found this API definition.
-  We use this to resolve "$ref" values, since they are relative to the schema's
-  location.
-
-*/}}
-
-{{ $api_data := index .api_data }}
-{{ $base_url := .base_url }}
-{{ $path := .path }}
-
-{{ range $path_name, $path_data := $api_data.paths }}
-
-    {{ $endpoint := delimit (slice $base_url $path_name ) "" }}
-
-    {{/* note that a `paths` entry can be a $ref */}}
-
-    {{ $params := dict "endpoint" $endpoint "path" $path }}
-
-    {{ with $path_data.get }}
-
-        {{ $operation_params := merge $params (dict "method" "GET" "operation_data" . ) }}
-        {{ partial "openapi/render-operation" $operation_params }}
-
-    {{ end }}
-
-    {{ with $path_data.post }}
-
-        {{ $operation_params := merge $params (dict "method" "POST" "operation_data" . ) }}
-        {{ partial "openapi/render-operation" $operation_params }}
-
-    {{ end }}
-
-    {{ with $path_data.put }}
-
-        {{ $operation_params := merge $params (dict "method" "PUT" "operation_data" . ) }}
-        {{ partial "openapi/render-operation" $operation_params }}
-
-    {{ end }}
-
-    {{ with $path_data.delete }}
-
-        {{ $operation_params := merge $params (dict "method" "DELETE" "operation_data" . ) }}
-        {{ partial "openapi/render-operation" $operation_params }}
-
-    {{ end }}
-
-{{ end }}
diff --git a/layouts/partials/openapi/render-object-table.html b/layouts/partials/openapi/render-object-table.html
deleted file mode 100644
index e132af30..00000000
--- a/layouts/partials/openapi/render-object-table.html
+++ /dev/null
@@ -1,98 +0,0 @@
-{{/*
-
-  Render a table listing the properties of an object, given:
-
-  * `caption`: optional caption for the table
-  * `properties`: dictionary of the properties to list, each given as:
-  `property_name` : `property_data`
-  * `required`: array containing the names of required properties.
-  In some cases (such as response body specifications) this isn't used, and
-  instead properties have a `required` boolean attribute. We support this too.
-
-*/}}
-
-{{ $caption := .caption }}
-{{ $properties := .properties}}
-{{ $required := .required}}
-
-{{ if $properties }}
-
-<table class>
- {{ with $caption }}
- <caption>{{ . }}</caption>
- {{ end }}
- <thead>
-  <th class="col-name">Name</th>
-  <th class="col-type">Type</th>
-  <th class="col-description">Description</th>
- </thead>
-
-    {{ range $property_name, $property := $properties }}
-
-        {{ $property := partial "json-schema/resolve-allof" $property }}
-
-        {{/*
-            If the property has a `title`, use that rather than `type`.
-            This means we can write things like `EventFilter` rather than `object`.
-        */}}
-        {{ $type := $property.type}}
-        {{ if $property.title }}
-            {{ $type = $property.title }}
-        {{ end }}
-
-        {{/*
-            If the property is an array, indicate this with square brackets,
-            like `[type]`.
-        */}}
-        {{ if eq $type "array"}}
-            {{ $items := $property.items }}
-            {{ if $property.items }}
-                {{ $items = partial "json-schema/resolve-allof" $property.items }}
-            {{ end }}
-            {{ $inner_type := $items.type }}
-            {{ if $items.title }}
-                {{ $inner_type = $items.title }}
-            {{ end }}
-            {{ $type = delimit (slice "[" $inner_type "]") "" }}
-        {{ end }}
-
-        {{/*
-            If the property is an enum, indicate this.
-        */}}
-        {{ if (and (eq $type "string") ($property.enum)) }}
-            {{ $type = "enum" }}
-        {{ end }}
-
-        {{/*
-            If the property uses `additionalProperties` to describe its
-            internal structure, handle this.
-        */}}
-        {{ if reflect.IsMap $property.additionalProperties }}
-            {{ if $property.additionalProperties.title }}
-                {{ $type = delimit (slice "{ string: " $property.additionalProperties.title "}" ) "" }}
-            {{ end }}
-        {{ end }}
-
-        {{/*
-          Handle two ways of indicating "required", one for simple parameters,
-          the other for request and response body objects.
-        */}}
-        {{ $required := cond (or (in $required $property_name) ( eq $property.required true )) true false }}
-
- <tr>
-  <td><code>{{ $property_name }}</code></td>
-  <td><code>{{ $type }}</code></td>
-  <td>
-    {{ if $required }}<strong>Required: </strong>{{end -}}
-    {{ $property.description | markdownify -}}
-    {{ if eq $type "enum"}}<p>One of: <code>{{ $property.enum }}</code>.</p>{{ end -}}
-    {{ if (index $property "x-addedInMatrixVersion") }}{{ partial "added-in" (dict "v" (index $property "x-addedInMatrixVersion")) }}{{ end -}}
-    {{ if (index $property "x-changedInMatrixVersion") }}{{ partial "changed-in" (dict "changes_dict" (index $property "x-changedInMatrixVersion")) }}{{ end -}}
-  </td>
- </tr>
-
-    {{ end }}
-
-</table>
-
-{{ end }}
diff --git a/layouts/partials/openapi/render-operation.html b/layouts/partials/openapi/render-operation.html
deleted file mode 100644
index 6d516d06..00000000
--- a/layouts/partials/openapi/render-operation.html
+++ /dev/null
@@ -1,72 +0,0 @@
-{{/*
-
-  Render a single HTTP API operation: that is, a method+endpoint combination, given:
-
-  * `method`: the method, e.g. GET, PUT
-  * `endpoint`: the endpoint
-  * `operation_data`: the OpenAPI/Swagger data for the operation
-  * `path`: the path where this definition was found, to enable us to resolve "$ref"
-
-  This template renders the operation as a `<section>` containing:
-
-    * an `<h1>` heading containing the method and endpoint
-    * a `<details>` element containing the details, including:
-      * operation description
-      * basic info about the operation
-      * request details
-      * response details
-
-*/}}
-
-{{ $method := .method }}
-{{ $endpoint := .endpoint }}
-{{ $operation_data := .operation_data }}
-{{ $path := .path }}
-
-<section class="rendered-data http-api {{ $method }}">
-
-<details {{ if not site.Params.ui.rendered_data_collapsed }}open{{ end }}>
-<summary>
-
-  <h1 id="{{ lower $method }}{{ anchorize $endpoint }}">
-   <span class="http-api-method {{ $method }}">{{ $method }}</span>
-   <span class="endpoint{{ if $operation_data.deprecated }} deprecated-inline{{ end }}">{{ $endpoint }}</span>
-  </h1>
-
-  <hr/>
-
-{{ if $operation_data.deprecated }}
-    {{ partial "alert" (dict "type" "warning" "omit_title" "true" "content" "This API is deprecated and will be removed from a future release.") }}
-{{ end }}
-
-{{ if (index $operation_data "x-addedInMatrixVersion") }}
-  {{ partial "added-in" (dict "v" (index $operation_data "x-addedInMatrixVersion")) }}
-{{ end }}
-{{ if (index $operation_data "x-changedInMatrixVersion") }}
-  {{ partial "changed-in" (dict "changes_dict" (index $operation_data "x-changedInMatrixVersion")) }}
-{{ end -}}
-
-<p>{{ $operation_data.description | markdownify }}</p>
-
-</summary>
-
-<table class="basic-info">
-  <tr>
-   <th>Rate-limited:</th>
-   {{ $rate_limited := index $operation_data.responses "429" }}
-   <td>{{ if $rate_limited }}Yes{{ else }}No{{ end }}</td>
-  </tr>
- <tr>
-  <th>Requires authentication:</th>
-  <td>{{ if $operation_data.security }}Yes{{ else }}No{{ end }}</td>
- </tr>
-</table>
-
-<hr/>
-{{ partial "openapi/render-request"   (dict "parameters" $operation_data.parameters "path" $path) }}
-<hr/>
-{{ partial "openapi/render-responses" (dict "responses"  $operation_data.responses  "path" $path) }}
-
-</details>
-
-</section>
diff --git a/layouts/partials/openapi/render-parameters.html b/layouts/partials/openapi/render-parameters.html
deleted file mode 100644
index 2b4fb09d..00000000
--- a/layouts/partials/openapi/render-parameters.html
+++ /dev/null
@@ -1,30 +0,0 @@
-{{/*
-
-  Render the parameters of a given type, given:
-
-  * `parameters`: OpenAPI/Swagger data specifying the parameters
-  * `type`: the type of parameters to render: "header, ""path", "query"
-  * `caption`: caption to use for the table
-
-  This template renders a single table containing parameters of the given type.
-
-*/}}
-
-{{ $parameters := .parameters }}
-{{ $type := .type }}
-{{ $caption := .caption }}
-
-{{ $parameters_of_type := where $parameters "in" $type }}
-
-{{ with $parameters_of_type }}
-
-    {{/* convert parameters into the format that render-object-table expects to see */}}
-    {{ $param_dict := dict }}
-    {{ range $parameter := . }}
-        {{ $param_dict = merge $param_dict (dict $parameter.name (dict "type" $parameter.type "description" $parameter.description "required" $parameter.required "enum" $parameter.enum)  )}}
-    {{ end }}
-
-    {{/* and render the parameters */}}
-    {{ partial "openapi/render-object-table" (dict "caption" $caption "properties" $param_dict) }}
-
-{{ end }}
diff --git a/layouts/partials/openapi/render-request.html b/layouts/partials/openapi/render-request.html
deleted file mode 100644
index 5e801299..00000000
--- a/layouts/partials/openapi/render-request.html
+++ /dev/null
@@ -1,61 +0,0 @@
-{{/*
-
-  Render the request part of a single HTTP API operation, given:
-
-  * `parameters`: OpenAPI/Swagger data specifying the parameters
-  * `path`: the path where this definition was found, to enable us to resolve "$ref"
-
-  This template renders:
-  * the "simple parameters" (header, path, query parameters)
-  * body parameters, which may be more complex, containing nested objects
-  * response body examples
-
-*/}}
-
-{{ $parameters := .parameters }}
-{{ $path := .path }}
-
-<h2>Request</h2>
-
-{{ if $parameters }}
-
-    {{ $simple_parameters := where $parameters "in" "!=" "body"}}
-    {{ if $simple_parameters }}
-<h3>Request parameters</h3>
-
-        {{ partial "openapi/render-parameters" (dict "parameters" $simple_parameters "type" "header" "caption" "header parameters") }}
-        {{ partial "openapi/render-parameters" (dict "parameters" $simple_parameters "type" "path" "caption" "path parameters") }}
-        {{ partial "openapi/render-parameters" (dict "parameters" $simple_parameters "type" "query" "caption" "query parameters") }}
-
-    {{ end }}
-
-    {{ $body_parameters := where $parameters "in" "body"}}
-    {{ if $body_parameters }}
-<h3>Request body</h3>
-
-        {{/* at most one body param is allowed by the spec */}}
-        {{ $body_parameter := index $body_parameters 0 }}
-        {{ $schema := partial "json-schema/resolve-refs" (dict "schema" $body_parameter.schema "path" $path) }}
-        {{ $schema := partial "json-schema/resolve-allof" $schema }}
-
-        {{ $additional_types := partial "json-schema/resolve-additional-types" $schema }}
-        {{ $additional_types = uniq $additional_types }}
-        {{ range $additional_types }}
-            {{ partial "openapi/render-object-table" (dict "caption" .title "properties" .properties "required" .required) }}
-        {{ end }}
-
-<h3>Request body example</h3>
-
-        {{ $example := partial "json-schema/resolve-example" $schema }}
-        {{ $example_json := jsonify (dict "indent" "  ") $example }}
-        {{ $example_json = replace $example_json "\\u003c" "<" }}
-        {{ $example_json = replace $example_json "\\u003e" ">" | safeHTML }}
-
-```json
-{{ $example_json }}
-```
-    {{ end }}
-
-{{ else }}
-<p>No request parameters or request body.</p>
-{{ end }}
diff --git a/layouts/partials/openapi/render-responses.html b/layouts/partials/openapi/render-responses.html
deleted file mode 100644
index 79636945..00000000
--- a/layouts/partials/openapi/render-responses.html
+++ /dev/null
@@ -1,99 +0,0 @@
-{{/*
-
-  Render the response part of a single HTTP API operation, given:
-
-  * `responses`: OpenAPI/Swagger data specifying the responses
-  * `path`: the path where this definition was found, to enable us to resolve "$ref"
-
-  This template renders:
-  * a summary of all the different responses
-  * details of the body for each response code
-  * body parameters, which may be more complex, containing nested objects
-  * response body examples
-
-*/}}
-
-{{ $responses := .responses }}
-{{ $path := .path }}
-
-<h2>Responses</h2>
-
-<table class>
- <thead>
-  <th class="col-status">Status</th>
-  <th class="col-status-description">Description</th>
- </thead>
-
-{{ range $code, $response := $responses }}
-
- <tr>
-  <td><code>{{ $code }}</code></td>
-  <td>{{ $response.description | markdownify }}</td>
- </tr>
-
-{{ end }}
-
-</table>
-
-{{ range $code, $response := $responses }}
-    {{ if $response.schema }}
-
-<h3>{{$code}} response</h3>
-
-        {{ $schema := partial "json-schema/resolve-refs" (dict "schema" $response.schema "path" $path) }}
-        {{ $schema := partial "json-schema/resolve-allof" $schema }}
-
-        {{/*
-          All this is to work out how to express the content of the response
-          in the case where it is an array.
-        */}}
-        {{ if eq $schema.type "array" }}
-            {{ $type_of := "" }}
-            {{ if reflect.IsSlice $schema.items }}
-                {{ $types := slice }}
-                {{ range $schema.items }}
-                    {{ if .title }}
-                        {{ $types = $types | append .title}}
-                    {{ else }}
-                        {{ $types = $types | append .type }}
-                    {{ end }}
-                {{ end }}
-                {{ $type_of = delimit $types ", "}}
-            {{ else }}
-                {{ $type_of = $schema.items.title }}
-            {{ end }}
-<p>Array of <code>{{ $type_of }}</code>.</p>
-        {{ end }}
-
-
-        {{/*
-          render object tables for any objects referenced in the
-          response. (This will be a no-op for response types which aren't
-          objects or arrays.)
-        */}}
-        {{ $additional_types := partial "json-schema/resolve-additional-types" $schema }}
-        {{ $additional_types = uniq $additional_types }}
-        {{ range $additional_types }}
-            {{ partial "openapi/render-object-table" (dict "caption" .title "properties" .properties "required" .required) }}
-        {{ end }}
-
-        {{/*
-           render an example. currently this is only supported for arrays and objects.
-        */}}
-        {{ if or (eq $schema.type "object") (eq $schema.type "array") }}
-            {{ $example := partial "json-schema/resolve-example" $schema }}
-            {{ if $response.examples }}
-                {{ $example = partial "json-schema/resolve-refs" (dict "schema" $response.examples "path" $path) }}
-                {{ $example = index $example "application/json" }}
-            {{ end }}
-
-            {{ $example_json := jsonify (dict "indent" "  ") $example }}
-            {{ $example_json = replace $example_json "\\u003c" "<" }}
-            {{ $example_json = replace $example_json "\\u003e" ">" | safeHTML }}
-
-```json
-{{ $example_json }}
-```
-        {{ end }}
-    {{ end }}
-{{ end }}
diff --git a/layouts/partials/sidebar-tree.html b/layouts/partials/sidebar-tree.html
deleted file mode 100644
index 17c181cc..00000000
--- a/layouts/partials/sidebar-tree.html
+++ /dev/null
@@ -1,64 +0,0 @@
-{{/*
-
-  A version of the sidebar-tree.html partial in Docsy, with a few small
-  modifications:
-
-  * include `div#toc` for the ToC
-  * start the sidebar at the root (homepage) since for us that is the Matrix
-  overview page
-  * omit module pages, which we don't want to be directly accessible
-  (we only use them as raw material for the client-server spec)
-
-*/}}
-
-{{/* We cache this partial for bigger sites and set the active class client side. */}}
-{{ $shouldDelayActive := ge (len .Site.Pages) 2000 }}
-<div id="td-sidebar-menu" class="td-sidebar__inner{{ if $shouldDelayActive }} d-none{{ end }}">
-  <div id="content-mobile">
-  <form class="td-sidebar__search d-flex align-items-center">
-    {{ partial "search-input.html" . }}
-    <button class="btn btn-link td-sidebar__toggle d-md-none p-0 ml-3 fas fa-bars" type="button" data-toggle="collapse" data-target="#td-section-nav" aria-controls="td-docs-nav" aria-expanded="false" aria-label="Toggle section navigation">
-    </button>
-  </form>
-  </div>
-  <div id="content-desktop"></div>
-  <nav class="collapse td-sidebar-nav" id="td-section-nav">
-    {{ template "section-tree-nav-section" (dict "page" . "section" .Site.Home.CurrentSection "delayActive" $shouldDelayActive "indent" 0)  }}
-    <hr/>
-    <div id = "toc"></div>
-  </nav>
-</div>
-
-{{ define "section-tree-nav-section" }}
-    {{ $s := .section }}
-    {{ $p := .page }}
-    {{ $shouldDelayActive := .delayActive }}
-    {{ $indent := .indent }}
-    {{ $active := eq $p.RelPermalink $s.RelPermalink }}
-    {{ $show := or ($p.IsAncestor $s) ($p.IsDescendant $s) }}
-    {{ $sid := $s.RelPermalink | anchorize }}
-<ul class="td-sidebar-nav__section pr-md-3">
-  <li class="td-sidebar-nav__section-title">
-    <a  href="{{ $s.RelPermalink }}" class="align-left pl-0 pr-2{{ if not $show }} collapsed{{ end }}{{ if $active}} active{{ end }} td-sidebar-link td-sidebar-link__section indent-{{$indent}}">{{ $s.LinkTitle }}</a>
-    {{ $pages := where (union $s.Pages $s.Sections).ByWeight ".Params.toc_hide" "!=" true }}
-    {{ $pages = where $pages "Type" "!=" "module"}}
-    {{ $pages := $pages | first 50 }}
-    {{ if gt (len $pages) 0 }}
-    <ul>
-        {{ range $pages }}
-            {{ if .IsPage }}
-                {{ $mid := printf "m-%s" (.RelPermalink | anchorize) }}
-                {{ $active := eq . $p }}
-      <li class="collapse {{ if $show }}show{{ end }}" id="{{ $sid }}">
-        <a class="td-sidebar-link td-sidebar-link__page {{ if and (not $shouldDelayActive) $active }} active{{ end }} indent-{{add $indent 1}}" id="{{ $mid }}" href="{{ .RelPermalink }}">{{ .LinkTitle }}</a>
-      </li>
-            {{ else }}
-                {{ $indent := add $indent 1 }}
-                {{ template "section-tree-nav-section" (dict "page" $p "section" . "indent" $indent) }}
-            {{ end }}
-        {{ end }}
-    </ul>
-    {{ end }}
-  </li>
-</ul>
-{{ end }}
diff --git a/layouts/partials/version-banner.html b/layouts/partials/version-banner.html
deleted file mode 100644
index 66850dc1..00000000
--- a/layouts/partials/version-banner.html
+++ /dev/null
@@ -1,22 +0,0 @@
-{{/*
-
-  A modified version of the version-banner.html partial in Docsy.
-
-*/}}
-
-
-{{ $color := "primary" }}
-{{ $status := .Site.Params.version.status }}
-{{ $latest_version := .Site.Params.version.current_version_url }}
-{{ if eq $status "unstable"}}
-<div class="pageinfo pageinfo-{{ $color }} pageinfo-unstable">
-  <p>You're looking at an unstable version of this specification.
-  Unstable specifications may change at any time without notice.</p>
-  <p><a href="{{ $latest_version | safeURL }}">Switch to the current stable release</a>.</p>
-</div>
-{{ else if eq $status "historical" }}
-<div class="pageinfo pageinfo-{{ $color }}">
-  <p>You're looking at an old version of this specification.<p>
-  <p><a href="{{ $latest_version | safeURL }}">Switch to the current stable release</a>.</p>
-</div>
-{{ end }}
diff --git a/layouts/shortcodes/added-in.html b/layouts/shortcodes/added-in.html
deleted file mode 100644
index 4113d922..00000000
--- a/layouts/shortcodes/added-in.html
+++ /dev/null
@@ -1,8 +0,0 @@
-{{ $ver := .Params.v }}
-{{ $this := .Params.this }}
-
-{{ if $this }}
-  <span>**[New in this version]**</span>
-{{ else }}
-  <span>**[Added in `v{{ $ver }}`]**</span>
-{{ end }} {{/* Do not leave an empty line at the end of this file otherwise the inline behaviour breaks. */}}
\ No newline at end of file
diff --git a/layouts/shortcodes/boxes/note.html b/layouts/shortcodes/boxes/note.html
deleted file mode 100644
index 48c9d3c9..00000000
--- a/layouts/shortcodes/boxes/note.html
+++ /dev/null
@@ -1 +0,0 @@
-{{ partial "alert" (dict "type" "note" "content" .Inner) }}
diff --git a/layouts/shortcodes/boxes/rationale.html b/layouts/shortcodes/boxes/rationale.html
deleted file mode 100644
index 385bd4b6..00000000
--- a/layouts/shortcodes/boxes/rationale.html
+++ /dev/null
@@ -1 +0,0 @@
-{{ partial "alert" (dict "type" "rationale" "content" .Inner) }}
diff --git a/layouts/shortcodes/boxes/warning.html b/layouts/shortcodes/boxes/warning.html
deleted file mode 100644
index 6e884026..00000000
--- a/layouts/shortcodes/boxes/warning.html
+++ /dev/null
@@ -1 +0,0 @@
-{{ partial "alert" (dict "type" "warning" "content" .Inner) }}
diff --git a/layouts/shortcodes/changed-in.html b/layouts/shortcodes/changed-in.html
deleted file mode 100644
index 0eb35faa..00000000
--- a/layouts/shortcodes/changed-in.html
+++ /dev/null
@@ -1,8 +0,0 @@
-{{ $ver := .Params.v }}
-{{ $this := .Params.this }}
-
-{{ if $this }}
-  <span>**[Changed in this version]**</span>
-{{ else }}
-  <span>**[Changed in `v{{ $ver }}`]**</span>
-{{ end }} {{/* Do not leave an empty line at the end of this file otherwise the inline behaviour breaks. */}}
\ No newline at end of file
diff --git a/layouts/shortcodes/changelog/changelog-changes.html b/layouts/shortcodes/changelog/changelog-changes.html
deleted file mode 100644
index 9b0e71a9..00000000
--- a/layouts/shortcodes/changelog/changelog-changes.html
+++ /dev/null
@@ -1,89 +0,0 @@
-{{/*
-
-  This template is used to render the set of changes in the changelog page.
-
-  It expects to find a directory "changelogs" containing a subdirectory for
-  each of the 5 APIs in the specification. Inside each of these directories
-  it expects to find newsfragments describing changes to that API.
-
-  If the `version.status` setting in config.toml is anything other than
-  "unstable", then it also expects to find additional settings under
-  `version` in config.toml:
-  - `major`: the major version number of the release
-  - `minor`: the minor version number of the release
-  - `release_date`: the date of the release
-
-  The release tag is calculated as `v<major>.<minor>`; for example `v1.5`.
-
-  It then renders this into a table displayed before the list of changes.
-
-*/}}
-
-{{ $path := path.Join "changelogs" }}
-{{ $status := .Site.Params.version.status }}
-{{ $release_tag := delimit (slice "v" .Site.Params.version.major "." .Site.Params.version.minor) "" }}
-
-{{ if ne $status "unstable" }}
-<table class="release-info">
-<tr><th>Git commit</th><td><a href="https://github.com/matrix-org/matrix-doc/tree/{{ $release_tag }}">https://github.com/matrix-org/matrix-doc/tree/{{ $release_tag }}</a></td>
-<tr><th>Release date</th><td>{{ .Site.Params.version.release_date }}</td>
-</table>
-{{ end }}
-
-<h2 id=api-changes>Changes since last release</h2>
-{{ partial "render-api-changes" (dict "title" "Client-Server API" "id" "client-server-api" "path" (path.Join $path "client_server")) }}
-{{ partial "render-api-changes" (dict "title" "Server-Server API" "id" "server-server-api" "path" (path.Join $path "server_server")) }}
-{{ partial "render-api-changes" (dict "title" "Application Service API" "id" "application-service-api" "path" (path.Join $path "application_service")) }}
-{{ partial "render-api-changes" (dict "title" "Identity Service API" "id" "identity-service-api" "path" (path.Join $path "identity_service")) }}
-{{ partial "render-api-changes" (dict "title" "Push Gateway API" "id" "push-gateway-api" "path" (path.Join $path "push_gateway")) }}
-{{ partial "render-api-changes" (dict "title" "Room Versions" "id" "room-versions" "path" (path.Join $path "room_versions")) }}
-{{ partial "render-api-changes" (dict "title" "Appendices" "id" "appendices" "path" (path.Join $path "appendices")) }}
-
-{{ define "partials/render-api-changes" }}
-<h3 id="{{.id}}">{{ .title }}</h3>
-    {{ $api_path := .path }}
-    {{ $config_file := path.Join $api_path ".." "pyproject.toml" }}
-    {{ $config := readFile $config_file | transform.Unmarshal }}
-    {{ $news_path := path.Join $api_path "newsfragments" }}
-    {{ partial "render-newsfragments"  (dict "config" $config "news_path" $news_path )}}
-{{ end }}
-
-{{ define "partials/render-newsfragments" }}
-{{ $config := .config }}
-{{ $news_path := .news_path }}
-
-{{ $types := dict }}
-{{ range $config.tool.towncrier.type }}
-    {{ $types = merge $types (dict .directory (slice)) }}
-{{ end }}
-
-{{ range (readDir $news_path) }}
-
-    {{ $pieces := split .Name "." }}
-
-    {{ $ticket := index $pieces 0 }}
-    {{ $description := readFile (path.Join $news_path .Name ) }}
-    {{ $change_info := (dict "ticket" $ticket "description" $description )}}
-
-    {{ $type := index $pieces 1 }}
-    {{ $instances := index $types $type }}
-    {{ $instances = $instances | append $change_info }}
-    {{ $types = merge $types (dict $type $instances) }}
-
-{{ end }}
-
-<ul>
-{{ range $config.tool.towncrier.type }}
-    {{ $changes_of_type := (index $types .directory) }}
-    {{ if $changes_of_type }}
-<li>{{.name | safeHTML}}
-<p><ul>
-        {{ range $changes_of_type }}
-<li><a href="https://github.com/matrix-org/matrix-doc/issues/{{.ticket}}"><strong>{{ .ticket }}: </strong></a>{{ .description | markdownify }}</li>
-        {{ end }}
-</ul></p>
-</li>
-    {{ end }}
-{{ end }}
-</ul>
-{{ end }}
diff --git a/layouts/shortcodes/changelog/changelog-description.html b/layouts/shortcodes/changelog/changelog-description.html
deleted file mode 100644
index 3c719725..00000000
--- a/layouts/shortcodes/changelog/changelog-description.html
+++ /dev/null
@@ -1,19 +0,0 @@
-{{/*
-
-  This template is used to provide different content for the unstable spec
-  version and for a versioned release.
-
-*/}}
-
-{{ $status := .Site.Params.version.status }}
-
-{{ if eq $status "unstable"}}
-
-<p>This is the <strong>unstable</strong> version of the Matrix specification.</p>
-<p>This changelog lists changes made since the last release of the specification.</p>
-
-{{ else }}
-
-<p>This is version <strong>v{{ .Site.Params.version.major }}.{{ .Site.Params.version.minor }}</strong> of the Matrix specification.</p>
-
-{{ end }}
diff --git a/layouts/shortcodes/changelog/changelog-rendered.html b/layouts/shortcodes/changelog/changelog-rendered.html
deleted file mode 100644
index bbfd6e53..00000000
--- a/layouts/shortcodes/changelog/changelog-rendered.html
+++ /dev/null
@@ -1,2 +0,0 @@
-{{ $partial := .Params.p }}
-{{ partial $partial . }}
diff --git a/layouts/shortcodes/cs-module.html b/layouts/shortcodes/cs-module.html
deleted file mode 100644
index bd407df6..00000000
--- a/layouts/shortcodes/cs-module.html
+++ /dev/null
@@ -1,13 +0,0 @@
-{{/*
-
-    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.
-
-*/}}
-
-{{ $name := .Params.name }}
-
-{{ $page := .Site.GetPage (path.Join .Page.Dir "modules" (printf "%s%s" $name ".md"))}}
-{{ $page.Content }}
\ No newline at end of file
diff --git a/layouts/shortcodes/definition.html b/layouts/shortcodes/definition.html
deleted file mode 100644
index 2e000c73..00000000
--- a/layouts/shortcodes/definition.html
+++ /dev/null
@@ -1,63 +0,0 @@
-{{/*
-
-  This template is used to render EDUs and PDUs in the server-server and room versions specs.
-
-  It expects to be passed a `path` parameter, which is a path, relative to /data,
-  pointing to a schema file. The file extension is omitted. For example:
-
-      {{% definition path="api/server-server/definitions/edu" %}}
-
-  This template replaces the old {{definition_*}} template.
-
-*/}}
-
-{{ $path := .Params.path }}
-{{ $compact := .Params.compact }}
-{{ $pieces := split $path "/" }}
-
-{{/* The definition is referenced by the .path parameter */}}
-{{ $definition := index .Site.Data $pieces }}
-
-{{/* The base path, which we use to resolve $ref, omits the last component */}}
-{{ $pieces = first (sub (len $pieces) 1) $pieces}}
-{{ $path = delimit $pieces "/" }}
-
-{{/* Resolve $ref and allOf */}}
-{{ $definition = partial "json-schema/resolve-refs" (dict "schema" $definition "path" $path) }}
-{{ $definition = partial "json-schema/resolve-allof" $definition }}
-
-<section class="rendered-data definition">
-
-<details {{ if not $compact }}open{{ end }}>
-<summary>
-
-<h1>
- <code>{{ $definition.title }}</code>
-</h1>
-
-<hr/>
-
-{{ if (index $definition "x-addedInMatrixVersion") }}
-  {{ partial "added-in" (dict "v" (index $definition "x-addedInMatrixVersion")) }}
-{{ end }}
-
-{{ $definition.description | markdownify }}
-
-</summary>
-
-{{ $additional_types := partial "json-schema/resolve-additional-types" $definition }}
-{{ $additional_types = uniq $additional_types }}
-
-{{ range $additional_types }}
-    {{ partial "openapi/render-object-table" (dict "caption" .title "properties" .properties "required" .required) }}
-{{end}}
-
-<h2>Examples</h2>
-
-{{ $example := partial "json-schema/resolve-example" $definition }}
-
-```json
-{{ jsonify (dict "indent" "  ") $example }}
-```
-
-</section>
diff --git a/layouts/shortcodes/event-fields.html b/layouts/shortcodes/event-fields.html
deleted file mode 100644
index 83651c21..00000000
--- a/layouts/shortcodes/event-fields.html
+++ /dev/null
@@ -1,45 +0,0 @@
-{{/*
-
-  This template is used to render the fields that all basic events and room events
-  must or may contain.
-
-  It expects to be passed an `event_type` parameter, is the name of a file under
-  /data/event-schemas/core-event-schema. The file extension is omitted. For example:
-
-      {{% event-fields event_type="room_event" %}}
-
-  This template replaces the old {{common_event_fields}} and {{common_room_event_fields}} templates.
-
-*/}}
-
-{{ $event := index .Site.Data "event-schemas" "schema" "core-event-schema" .Params.event_type }}
-{{ $path := "event-schemas/schema/core-event-schema" }}
-
-{{ $event = partial "json-schema/resolve-refs" (dict "schema" $event "path" $path) }}
-{{ $event := partial "json-schema/resolve-allof" $event }}
-
-<section class="rendered-data event">
-
-<details {{ if not .Site.Params.ui.rendered_data_collapsed }}open{{ end }}>
-<summary>
-
-<h1>
- <code>{{ humanize $event.title }}</code>
-</h1>
-
-<hr/>
-
-{{ $event.description | markdownify }}
-
-</summary>
-
-{{ $event = merge $event (dict "title" "") }}
-
-{{ $additional_types := partial "json-schema/resolve-additional-types" $event }}
-{{ range $additional_types }}
-    {{ partial "openapi/render-object-table" (dict "caption" .title "properties" .properties "required" .required) }}
-{{end}}
-
-</details>
-
-</section>
diff --git a/layouts/shortcodes/event-group.html b/layouts/shortcodes/event-group.html
deleted file mode 100644
index 5e2900f0..00000000
--- a/layouts/shortcodes/event-group.html
+++ /dev/null
@@ -1,32 +0,0 @@
-{{/*
-
-  This template is used to render a group of events starting with a given prefix.
-
-  It expects to be passed a `group_name` parameter. For example:
-
-      {{% event-group group_name="m.call" %}}
-
-  The template will then render all events whose schema starts with the given name.
-
-  This template replaces the old {{*_events}} template.
-
-*/}}
-
-{{ $path := "event-schemas/schema" }}
-
-{{ $events := index .Site.Data "event-schemas" "schema" }}
-{{ $group_name := .Params.group_name }}
-
-{{ range $event_name, $event_data := $events }}
-
-    {{ $prefix := substr $event_name 0 (len $group_name) }}
-    {{ if eq $prefix $group_name }}
-
-        {{ $event_data = partial "json-schema/resolve-refs" (dict "schema" $event_data "path" $path) }}
-        {{ $event_data := partial "json-schema/resolve-allof" $event_data }}
-
-        {{ partial "events/render-event" (dict "event_name" $event_name "event_data" $event_data)}}
-
-    {{ end }}
-
-{{ end }}
diff --git a/layouts/shortcodes/event.html b/layouts/shortcodes/event.html
deleted file mode 100644
index 71c9c534..00000000
--- a/layouts/shortcodes/event.html
+++ /dev/null
@@ -1,20 +0,0 @@
-{{/*
-
-  This template is used to render an event.
-
-  It expects to be passed an `event` parameter, which is the name of a schema file under
-  "data/event-schemas/schema". The file extension is omitted. For example:
-
-      {{% event event="m.accepted_terms" %}}
-
-  This template replaces the old {{*_event}} template.
-
-*/}}
-
-{{ $event_data := index .Site.Data "event-schemas" "schema" .Params.event }}
-{{ $path := "event-schemas/schema" }}
-
-{{ $event_data = partial "json-schema/resolve-refs" (dict "schema" $event_data "path" $path) }}
-{{ $event_data := partial "json-schema/resolve-allof" $event_data }}
-
-{{ partial "events/render-event" (dict "event_name" .Params.event "event_data" $event_data)}}
diff --git a/layouts/shortcodes/http-api.html b/layouts/shortcodes/http-api.html
deleted file mode 100644
index 32e0ad41..00000000
--- a/layouts/shortcodes/http-api.html
+++ /dev/null
@@ -1,26 +0,0 @@
-{{/*
-
-  This template is used to render an HTTP API, given an OpenAPI/Swagger definition.
-
-  It expects to be passed two parameters:
-
-  * a `spec` parameter identifying the spec, which must be the name of
-  a directory under /data/api
-  * an `api` parameter, identifying an OpenAPI/Swagger definition,
-  which is the name of a schema file under "data/api/$spec".
-  The file extension is omitted. For example:
-
-      {{% http-api spec="server-server" api="public_rooms" %}}
-
-  This template replaces the old {{*_http_api}} template.
-
-*/}}
-
-{{ $spec := .Params.spec}}
-{{ $api := .Params.api}}
-
-{{ $api_data := index .Site.Data.api .Params.spec .Params.api }}
-{{ $base_url := $api_data.basePath }}
-{{ $path := delimit (slice "api" $spec) "/" }}
-
-{{ partial "openapi/render-api" (dict "api_data" $api_data "base_url" $base_url "path" $path) }}
diff --git a/layouts/shortcodes/msgtypes.html b/layouts/shortcodes/msgtypes.html
deleted file mode 100644
index ccdfda5f..00000000
--- a/layouts/shortcodes/msgtypes.html
+++ /dev/null
@@ -1,48 +0,0 @@
-{{/*
-
-  This template is used to render the `m.room.message` events.
-
-  It replaces the old {{msgtype_events}} template.
-
-*/}}
-
-{{ $path := "event-schemas/schema" }}
-{{ $compact := false }}
-
-{{/*
-  The old template starts with an explicit list of events, presumably
-  to define the order in which they are rendered.
-*/}}
-{{ $msgtypes := (slice "m.room.message$m.text" "m.room.message$m.emote" "m.room.message$m.notice" "m.room.message$m.image" "m.room.message$m.file") }}
-
-{{/*
-  It excludes `m.room.message$m.server_notice`
-*/}}
-{{ $excluded := slice "m.room.message$m.server_notice" }}
-
-{{/*
-  It then adds any other events that start with `m.room.message`.
-*/}}
-{{ $events := index .Site.Data "event-schemas" "schema" }}
-{{ $expected_prefix := "m.room.message$"}}
-{{ range $object_name, $event_data := $events }}
-
-    {{ $prefix := substr $object_name 0 (len $expected_prefix) }}
-    {{ if and (eq $prefix $expected_prefix) (not (in $excluded $object_name)) (not (in $msgtypes $object_name))  }}
-        {{ $msgtypes = $msgtypes | append $object_name }}
-    {{ end }}
-
-{{ end }}
-
-{{ $site_data := .Site.Data }}
-
-{{ range $msgtypes }}
-
-    {{ $event_data := index $site_data "event-schemas" "schema" . }}
-    {{ $event_data = partial "json-schema/resolve-refs" (dict "schema" $event_data "path" $path) }}
-    {{ $event_data := partial "json-schema/resolve-allof" $event_data }}
-
-    {{ $event_name := index (split . "$") 1 }}
-    {{ partial "events/render-event" (dict "event_name" $event_name "desired_example_name" . "event_data" $event_data)}}
-
-{{ end }}
diff --git a/layouts/shortcodes/proposal-tables.html b/layouts/shortcodes/proposal-tables.html
deleted file mode 100644
index f61f168b..00000000
--- a/layouts/shortcodes/proposal-tables.html
+++ /dev/null
@@ -1,81 +0,0 @@
-{{/*
-
-  This template is used to render tables of MSC proposals.
-
-  It expects there to be a "proposals.json" under /data/msc.
-  It expects "proposals.json" to contain an array of objects,
-  one for each MSC state. Each object contains:
-  * `title`: human-readable title for the state, like "Proposal In Review"
-  * `label`: the GitHub label used for the state, like "proposal-in-review"
-  * `proposals`: an array of objects, each of which represents an MSC and contains:
-      * `number`: GitHub issue number
-      * `url`: GitHub URL for this issue
-      * `title`: Issue title
-      * `created_at`: issue creation date
-      * `updated_at`: issue last-updated date
-      * `authors`: array of GitHub user names representing authors of this MSC
-      * `shepherd`: GitHub user name representing the shepherd of this MSC, or null
-      * `documentation`: Links to further documentation referenced in the GitHub issue
-
-  This data is scraped from GitHub using the /scripts/proposals.js Node script.
-  The script is run in CI: so typically if you run a local server the data will
-  be missing and no tables will be generated. If you do want to see the tables locally,
-  you can run the script locally:
-
-    npm install
-    npm run get-proposals
-
-  If this template does find the data, it renders one table for each MSC state,
-  containing a row for each MSC in that state.
-
-*/}}
-
-{{ $states := .Site.Data.msc.proposals }}
-
-{{ range $states }}
-<h3 id="{{.label}}" class="proposal-table-title">{{ .title }}</h3>
-    {{ if .proposals }}
-<table class="msc-table table">
-  <thead>
-    <tr>
-      <th>MSC</th>
-      <th>Title</th>
-      <th>Created at</th>
-      <th>Updated at</th>
-      <th>Docs</th>
-      <th>Author</th>
-      <th>Shepherd</th>
-    </tr>
-  </thead>
-
-  <tbody>
-        {{ range .proposals }}
-
-            {{ $index := 0 }}
-            {{ $docs_links_list := slice }}
-            {{ range .documentation }}
-                {{ $index = add $index 1 }}
-                {{ $docs_link := printf "<a href=\"%s\">%d</a>" . $index }}
-                {{ $docs_links_list = $docs_links_list | append $docs_link }}
-            {{ end }}
-            {{ $docs_links := delimit $docs_links_list ", " }}
-
-            {{ $authors_list := apply .authors "printf" "<a href=\"https://github.com/%s\">@%s</a>" "." "." }}
-            {{ $authors := delimit $authors_list ", " }}
-
-  <tr>
-      <td><a href="{{ .url }}">{{ .number }}</a></td>
-      <td>{{ .title }}</td>
-      <td>{{ .created_at }}</td>
-      <td>{{ .updated_at }}</td>
-      <td>{{ with $docs_links }}{{ $docs_links }}{{ end }}</td>
-      <td>{{ $authors }}</td>
-      <td>{{ with .shepherd }}<a href="https://github.com/{{ . }}">@{{ . }}</a>{{ end }}</td>
-  </tr>
-        {{ end }}
-  </tbody>
-</table>
-    {{ else }}
-<p>No MSCs are currently in this state.</p>
-    {{ end }}
-{{ end }}
diff --git a/layouts/shortcodes/rver-fragment.html b/layouts/shortcodes/rver-fragment.html
deleted file mode 100644
index 12c4d122..00000000
--- a/layouts/shortcodes/rver-fragment.html
+++ /dev/null
@@ -1,25 +0,0 @@
-{{/*
-
-    This template is used to render a "room version fragment". Fragments are blocks of
-    text which describe a portion of the room version specification. They should be
-    prefixed with the room version which introduces the fragment, and be reusable for
-    two or more versions.
-
-    The `name` parameter is the file name without extension.
-
-    The `withVersioning` parameter is optional and defaults to false. When true, any
-    mentions of "New in this version" from the `added-in` shortcode are removed prior
-    to rendering. This is useful if needing to use a fragment where part of it describes
-    new functionality in a given room version but isn't new for subsequent versions.
-
-*/}}
-
-{{ $name := .Params.name }}
-{{ $withVersioning := .Params.withVersioning }}
-
-{{ $page := .Site.GetPage (path.Join .Page.Dir "fragments" (printf "%s%s" $name ".md"))}}
-{{ $content := $page.Content }}
-{{ if not $withVersioning }}
-    {{ $content = (replace $content "[New in this version]" "") }}
-{{ end }}
-{{ $content | safeHTML }}
diff --git a/layouts/shortcodes/sas-emojis.html b/layouts/shortcodes/sas-emojis.html
deleted file mode 100644
index 5ce6a009..00000000
--- a/layouts/shortcodes/sas-emojis.html
+++ /dev/null
@@ -1,26 +0,0 @@
-{{/*
-
-  This template is used to render the table of SAS emoji table.
-
-  It replaces the old {{sas_emoji_table}} template.
-
-*/}}
-
-{{ $emoji_json := readFile "data-definitions/sas-emoji.json" | transform.Unmarshal }}
-
-<table>
-  <tr>
-    <th>Number</th>
-    <th>Emoji</th>
-    <th>Unicode</th>
-    <th>Description</th>
-  </tr>
-{{ range $emoji_json }}
-  <tr>
-    <td>{{ .number }}</td>
-    <td>{{ .emoji }}</td>
-    <td>{{ .unicode }}</td>
-    <td>{{ .description }}</td>
-  </tr>
-{{ end }}
-</table>
diff --git a/meta/documentation_style.rst b/meta/documentation_style.rst
deleted file mode 100644
index 3a17cbd6..00000000
--- a/meta/documentation_style.rst
+++ /dev/null
@@ -1,181 +0,0 @@
-Documentation Style
-===================
-
-Each document should begin with a brief single sentence to describe what this
-file contains: in this case a description of the style to write documentation
-in.
-
-Format
-------
-
-Documentation is written in Commonmark markdown.
-
-Sections
---------
-
-Markdown supports headings through the `#` prefix on text. Please avoid heavily
-nested titles (h6, or 6 `#` characters) and instead re-evaluate the document structure.
-
-Correct capitalisation for long section names
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Headings should be in `sentence case <https://apastyle.apa.org/style-grammar-guidelines/capitalization/sentence-case>`,
-as represented by this document.
-
-TODOs
------
-
-Any file in this repository might make it onto the matrix.org site, and as such
-we do not want ``TODO`` markers visible there. For internal comments, notes, TODOs,
-etc please use standard markdown comments (`<!-- TODO TravisR: Fix this -->`). Please
-include your name in the TODO comment so we know who to ask about it in the future.
-
-Line widths
------------
-
-We use 80 characters for line widths. This is a guideline and can be ignored IF
-AND ONLY IF it makes reading more legible. Use common sense.
-
-For proposals, please use 120 characters as a guide.
-
-Stylistic notes
----------------
-
-General
-~~~~~~~
-
-Try to write clearly and unambiguously. Remember that many readers will not
-have English as their first language.
-
-Prefer British English (colour, -ise) to American English.
-
-The word "homeserver" is spelt thus (rather than "home server", "Homeserver",
-or (argh) "Home Server"). However, an identity server is two words.
-
-An "identity server" (spelt thus) implements the Identity Service API (also spelt
-thus). However, "Application Services" (spelt thus) implement the Application Service
-API. Application Services should not be called "appservices" in documentation.
-
-.. Rationale: "homeserver" distinguishes from a "home server" which is a server
-   you have at home. "identity server" is clear, whereas "identityserver" is
-   horrible.
-
-Lists should:
-
-* Be introduced with a colon.
-* Be used where they provide clarity.
-* Contain entries which start with a capital and end with a full stop.
-
-When talking about properties in JSON objects, prefer the word "property" to "field",
-"member", or various other alternatives. For example: "this property will be set to
-X if ...". Also avoid the term "key" unless you are specifically talking about the
-*name* of a property - and be mindful of the scope for confusion with cryptographic
-keys.
-
-Changes between spec versions
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Sections should reference the Matrix spec version they were added/changed in. This
-is often a guess at what the next version will be - please use the currently released
-version with a minor version bump as the referenced version. For example, if the
-current version is `v1.1` then annotate your changes with `v1.2`.
-
-"Added/changed in" tags can be documented as the following:
-
-* `{{% added-in v="1.2" %}}` or `{{% changed-in v="1.2" %}}` within Markdown documents.
-* `x-addedInMatrixVersion` and `x-changedInMatrixVersion` within OpenAPI.
-
-In rare cases, `this=true` can be used on the Markdown syntax to adjust the wording.
-This is most commonly used in room version specifications.
-
-**Tip**: If you're trying to inline the Markdown version and getting unexpected results,
-try replacing the `%` symbols with `<` and `>`, changing how Hugo renders the shortcode.
-
-OpenAPI
-~~~~~~~
-
-When writing OpenAPI specifications for the API endpoints, follow these rules:
-
-* ``summary``: a phrase summarising what this API does. Start with a capital,
-  end with a full stop. Examples: "Sends an event."; "Searches the directory."
-
-* ``description``: a longer description of the behaviour of this API, written
-  in complete sentences. Use multiple paragraphs if necessary.
-
-  Example:
-
-      This API sends an event to the room. The server must ensure that the user
-      has permission to post events to this room.
-
-* ``operationId``: a camelCased unique identifier for this endpoint. This will
-  be used to automatically generate bindings for the endpoint.
-
-* Parameter and property ``description``\s: a phrase summarising the behaviour
-  of this parameter or property, optionally followed by sentences giving more
-  detailed explanations. Start with a capital, end with a full stop.
-
-  The description is also the place to define default values for optional
-  properties. Use the wording "Defaults to X [if unspecified]."
-
-  Some descriptions start with the word "Optional" to explicitly mark optional
-  properties and parameters. This is redundant. Instead, use the ``required``
-  property to mark those that are required.
-
-Room versions
-~~~~~~~~~~~~~
-
-Room versions are fully specified to cover the entirety of their composition for
-client and server implementations to reference. As such, they have a relatively
-strict format that must be followed, described below.
-
-These rules do not affect MSCs.
-
-The introduction must cover:
-
-* The version the new room version builds on, if any.
-* A brief (one or two line) description of what the room version is expected to
-  consist of. For example, "..., adding new redaction rules to cover memberships".
-
-The next section must then be "Client considerations" to help client developers avoid
-the naturally complex "Server implementation components" later on. This section must:
-
-* Clearly describe any and all changes which affect users of the Client-Server API.
-* Clearly make reference to the redaction rules. A copy/paste example of this is in
-  Room Version 3: "Though unchanged in this room version, clients which implement the
-  redaction algorithm locally should refer to the [redactions] section below for a full
-  overview."
-
-The next section must then be "Server implementation components". This section must:
-
-* Start with the copy/pasted warning that clients should skip or ignore the section.
-* Repeat the introduction using server-focused language. This includes repeating which
-  room version, if any, the room version builds upon.
-* Clearly describe any and all changes which affect server implementations. This
-  includes a "Redactions" section, even if covered by the client considerations section.
-  See Room Version 9 for an example.
-
-Finally, the last section must then be an "Unchanged since vX" section, where ``vX``
-is the room version the version builds upon. If the room version doesn't build upon
-another room version, this section is excluded.
-
-In each of the client, server, and unchanged sections the subheadings must be in the
-following order:
-
-* Redactions
-* Handling redactions (if applicable)
-* Event IDs (if applicable)
-* Event format
-* Authorization rules
-* State resolution
-* Canonical JSON
-* Signing key validity period (if applicable)
-
-Within a given room version, these subheadings must appear at least once. Applicability
-of the headings depends on the room version a new version builds upon: if the underlying
-room version contains the subheading, the new room version must also contain the subheading.
-
-The subheadings which are always deemed as client-affecting are:
-
-* Redactions
-
-When a new subheading is added, it must be referenced and ordered in this document.
diff --git a/meta/github-labels.rst b/meta/github-labels.rst
deleted file mode 100644
index f674b81b..00000000
--- a/meta/github-labels.rst
+++ /dev/null
@@ -1,91 +0,0 @@
-The following labels are used to help categorize issues:
-
-`spec-omission <https://github.com/matrix-org/matrix-doc/labels/spec-omission>`_
---------------------------------------------------------------------------------
-
-Things which have been implemented but not currently specified. These may range
-from entire API endpoints, to particular options or return parameters.
-
-Issues with this label will have been implemented in `Synapse
-<https://github.com/matrix-org/synapse>`_. Normally there will be a design
-document in Google Docs or similar which describes the feature.
-
-Examples:
-
-* `Spec PUT /directory/list <https://github.com/matrix-org/matrix-doc/issues/417>`_
-* `Unspec'd server_name request param for /join/{roomIdOrAlias}
-  <https://github.com/matrix-org/matrix-doc/issues/904>`_
-
-`clarification <https://github.com/matrix-org/matrix-doc/labels/clarification>`_
---------------------------------------------------------------------------------
-
-An area where the spec could do with being more explicit.
-
-Examples:
-
-* `Spec the implicit limit on /syncs
-  <https://github.com/matrix-org/matrix-doc/issues/708>`_
-
-* `Clarify the meaning of the currently_active flags in presence events
-  <https://github.com/matrix-org/matrix-doc/issues/686>`_
-
-`spec-bug <https://github.com/matrix-org/matrix-doc/labels/spec-bug>`_
-----------------------------------------------------------------------
-
-Something which is in the spec, but is wrong.
-
-Note: this is *not* for things that are badly designed or don't work well
-(for which see 'improvement' or 'feature') - it is for places where the
-spec doesn't match reality.
-
-Examples:
-
-* `swagger is wrong for directory PUT
-  <https://github.com/matrix-org/matrix-doc/issues/933>`_
-
-* `receipts section still refers to initialSync
-  <https://github.com/matrix-org/matrix-doc/issues/695>`_
-
-`improvement <https://github.com/matrix-org/matrix-doc/labels/improvement>`_
-----------------------------------------------------------------------------
-
-A suggestion for a relatively simple improvement to the protocol.
-
-Examples:
-
-* `We need a 'remove 3PID' API so that users can remove mappings
-  <https://github.com/matrix-org/matrix-doc/issues/620>`_
-* `We should mandate that /publicRooms requires an access_token
-  <https://github.com/matrix-org/matrix-doc/issues/612>`_
-
-`feature <https://github.com/matrix-org/matrix-doc/labels/feature>`_
---------------------------------------------------------------------
-
-A suggestion for a significant extension to the matrix protocol which
-needs considerable consideration before implementation.
-
-Examples:
-
-* `Peer-to-peer Matrix <https://github.com/matrix-org/matrix-doc/issues/710>`_
-* `Specify a means for clients to "edit" previous messages
-  <https://github.com/matrix-org/matrix-doc/issues/682>`_
-
-
-`wart <https://github.com/matrix-org/matrix-doc/labels/wart>`_
---------------------------------------------------------------
-
-A point where the protocol is inconsistent or inelegant, but which isn't really
-causing anybody any problems right now. Might be nice to consider fixing one
-day.
-
-
-`question <https://github.com/matrix-org/matrix-doc/labels/question>`_
-----------------------------------------------------------------------
-
-A thought or idea about the protocol which we aren't really sure whether to
-pursue or not.
-
-Examples:
-
-* `Should we prepend anti-eval code to our json responses?
-  <https://github.com/matrix-org/matrix-doc/issues/908>`_
diff --git a/meta/releasing.md b/meta/releasing.md
deleted file mode 100644
index 64a01a95..00000000
--- a/meta/releasing.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# How to release the specification
-
-The whole specification is now released as a single unit/artifact. This document is
-the process for releasing the specification and a description of how the (public)
-machinery works.
-
-## Prerequisites / preparation
-
-First, can we even release the spec? This stage is mostly preparation work needed
-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
-
-Assuming the preparation work is complete, all that remains is the actual specification
-release.
-
-1. Create a `release/v1.2` branch where `v1.2` is the version you're about to release.
-2. Update the `params.version` section of `config.toml` to use the following template:
-   ```toml
-   [params.version]
-   status = "stable"
-   current_version_url = "https://spec.matrix.org/latest"
-
-   # This will be the spec version you're releasing. If that's v1.2, then `major = "1"`
-   # and `minor = "2"`
-   major = "1"
-   minor = "2"
-
-   # Today's date. Please use the format implied here for consistency.
-   release_date = "October 01, 2021"
-   ```
-3. Commit the changes.
-4. Tag the branch with the spec release with a format of `v1.2` (if releasing Matrix 1.2).
-5. Push the release branch and the tag.
-6. 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.
-7. Check out and fast-forward `main` to the release branch.
-8. Generate the changelog. This is done *after* the tagging to ensure the rendered
-   changelog makes sense.
-   1. Activate your python virtual environment.
-   2. Run `./scripts/generate-changelog.sh v1.2 "October 01, 2021"` (using the correct
-      version number and same `release_date` format from the hugo config).
-   3. Commit the result.
-9. Create a new release on GitHub from the newly created tag.
-   * The title should be just "v1.2" (for example).
-   * The description should be a copy/paste of the changelog. The generated changelog
-     will be at `content/partials/changelogs/v1.2.md` - copy/paste verbatim.
-   * Upload the artifacts of the GitHub Actions build for the release to the GitHub
-     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.toml` on `main`:
-    ```toml
-    [params.version]
-    status = "unstable"
-    current_version_url = "https://spec.matrix.org/latest"
-    # major = "1"
-    # minor = "2"
-    # release_date = "October 01, 2021"
-    ```
-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.
-
-## Patching a release
-
-From time to time we'll need to update a release in the wild. Examples include fixing typos,
-updating build machinery, etc. Typically it is not considered a good idea to patch a release
-more than 1 month after the original release date - this is because the administrative effort
-is typically best reserved for the next release cycle.
-
-**Patch releases are not to be used for spec changes. Only typos and equivalent.**
-
-1. Add the required changes to the release branch (`release/v1.2` for example).
-2. Fast forward the `v1.2` tag to the release branch head.
-3. Push both the release branch and fast-forwarded tag.
-4. Wait for the GitHub Actions build to complete on the tag.
-5. Update the assets on the GitHub release to those generated by the latest Actions build.
-6. Deploy the release on the webserver. See internal wiki.
diff --git a/openapi_extensions.md b/openapi_extensions.md
deleted file mode 100644
index 6905d663..00000000
--- a/openapi_extensions.md
+++ /dev/null
@@ -1,75 +0,0 @@
-# OpenAPI Extensions
-
-For some functionality that is not directly provided by the OpenAPI v2
-specification, some extensions have been added that are to be consistent
-across the specification. The defined extensions are listed below. Extensions
-should not break parsers, however if extra functionality is required, aware
-parsers should be able to take advantage of the added syntax.
-
-## Using multiple files to describe API
-
-To ease API design and management, the API definition is split across several
-files. Each of these files is self-contained valid OpenAPI.
-
-There is no single root file in the source tree as OpenAPI requires; this file
-can be generated by `dump_swagger.py` (also doing the substitution mentioned
-above). The script does not convert the extensions described further in this
-document (`oneOf` and parameter exploding) so there can be minor
-interoperability issues with tooling that expects compliant Swagger.
-
-## Extensible Query Parameters
-
-<!-- TODO: Remove and change instances to 'explode' after OpenAPI/Swagger v3 update -->
-
-If a unknown amount of query parameters can be added to a request, the `name`
-must be `fields...`, with the trailing ellipses representing the possibility
-of more fields.
-
-Example:
-
-```
-  - in: query
-    name: fields...
-    type: string
-```
-
-## Using oneOf to provide type alternatives
-
-<!-- TODO: Remove this section after upgrading to OpenAPI v3 -->
-
-`oneOf` (available in JSON Schema and Swagger/OpenAPI v3 but not in v2)
-is used in cases when a simpler type specification as a list of types
-doesn't work, as in the following example:
-```
-  properties:
-    old: # compliant with old Swagger
-      type:
-        - string
-        - object # Cannot specify a schema here
-    new: # uses oneOf extension
-      oneOf:
-        - type: string
-        - type: object
-          title: CustomSchemaForTheWin
-          properties:
-            ...
-```
-
-## OpenAPI 3's "2xx" format for response codes
-
-<!-- TODO: Remove this section after upgrading to OpenAPI v3 -->
-
-In some cases, the schema will have HTTP response code definitions like
-`2xx`, `3xx`, and `4xx`. These indicate that a response code within those
-ranges (`2xx` = `200` to `299`) is valid for the schema.
-
-## Custom `x-addedInMatrixVersion` key
-
-This property is added throughout the OpenAPI schemas to denote which version
-of the Matrix specification added the associated object (endpoint, parameter,
-property, etc).
-
-## Custom `x-changedInMatrixVersion` key
-
-A variation of the above: indicates changes to the associated parameter in
-particular Matrix specification versions.
diff --git a/package-lock.json b/package-lock.json
deleted file mode 100644
index 7b6ba539..00000000
--- a/package-lock.json
+++ /dev/null
@@ -1,1629 +0,0 @@
-{
-  "name": "matrix-spec",
-  "version": "0.0.1",
-  "lockfileVersion": 2,
-  "requires": true,
-  "packages": {
-    "": {
-      "name": "matrix-spec",
-      "version": "0.0.1",
-      "license": "Apache-2.0",
-      "devDependencies": {
-        "autoprefixer": "^10.4.2",
-        "node-fetch": "^2.6.7",
-        "postcss-cli": "^8.2.13"
-      }
-    },
-    "node_modules/@nodelib/fs.scandir": {
-      "version": "2.1.3",
-      "resolved": "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.3.tgz",
-      "integrity": "sha512-eGmwYQn3gxo4r7jdQnkrrN6bY478C3P+a/y72IJukF8LjB6ZHeB3c+Ehacj3sYeSmUXGlnA67/PmbM9CVwL7Dw==",
-      "dev": true,
-      "dependencies": {
-        "@nodelib/fs.stat": "2.0.3",
-        "run-parallel": "^1.1.9"
-      },
-      "engines": {
-        "node": ">= 8"
-      }
-    },
-    "node_modules/@nodelib/fs.stat": {
-      "version": "2.0.3",
-      "resolved": "https://registry.npmjs.org/@nodelib/fs.stat/-/fs.stat-2.0.3.tgz",
-      "integrity": "sha512-bQBFruR2TAwoevBEd/NWMoAAtNGzTRgdrqnYCc7dhzfoNvqPzLyqlEQnzZ3kVnNrSp25iyxE00/3h2fqGAGArA==",
-      "dev": true,
-      "engines": {
-        "node": ">= 8"
-      }
-    },
-    "node_modules/@nodelib/fs.walk": {
-      "version": "1.2.4",
-      "resolved": "https://registry.npmjs.org/@nodelib/fs.walk/-/fs.walk-1.2.4.tgz",
-      "integrity": "sha512-1V9XOY4rDW0rehzbrcqAmHnz8e7SKvX27gh8Gt2WgB0+pdzdiLV83p72kZPU+jvMbS1qU5mauP2iOvO8rhmurQ==",
-      "dev": true,
-      "dependencies": {
-        "@nodelib/fs.scandir": "2.1.3",
-        "fastq": "^1.6.0"
-      },
-      "engines": {
-        "node": ">= 8"
-      }
-    },
-    "node_modules/ansi-regex": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
-      "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
-      "dev": true,
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/ansi-styles": {
-      "version": "4.3.0",
-      "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
-      "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
-      "dev": true,
-      "dependencies": {
-        "color-convert": "^2.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      },
-      "funding": {
-        "url": "https://github.com/chalk/ansi-styles?sponsor=1"
-      }
-    },
-    "node_modules/anymatch": {
-      "version": "3.1.1",
-      "resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.1.tgz",
-      "integrity": "sha512-mM8522psRCqzV+6LhomX5wgp25YVibjh8Wj23I5RPkPppSVSjyKD2A2mBJmWGa+KN7f2D6LNh9jkBCeyLktzjg==",
-      "dev": true,
-      "dependencies": {
-        "normalize-path": "^3.0.0",
-        "picomatch": "^2.0.4"
-      },
-      "engines": {
-        "node": ">= 8"
-      }
-    },
-    "node_modules/array-union": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/array-union/-/array-union-2.1.0.tgz",
-      "integrity": "sha512-HGyxoOTYUyCM6stUe6EJgnd4EoewAI7zMdfqO+kGjnlZmBDz/cR5pf8r/cR4Wq60sL/p0IkcjUEEPwS3GFrIyw==",
-      "dev": true,
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/at-least-node": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/at-least-node/-/at-least-node-1.0.0.tgz",
-      "integrity": "sha512-+q/t7Ekv1EDY2l6Gda6LLiX14rU9TV20Wa3ofeQmwPFZbOMo9DXrLbOjFaaclkXKWidIaopwAObQDqwWtGUjqg==",
-      "dev": true,
-      "engines": {
-        "node": ">= 4.0.0"
-      }
-    },
-    "node_modules/autoprefixer": {
-      "version": "10.4.2",
-      "resolved": "https://registry.npmjs.org/autoprefixer/-/autoprefixer-10.4.2.tgz",
-      "integrity": "sha512-9fOPpHKuDW1w/0EKfRmVnxTDt8166MAnLI3mgZ1JCnhNtYWxcJ6Ud5CO/AVOZi/AvFa8DY9RTy3h3+tFBlrrdQ==",
-      "dev": true,
-      "dependencies": {
-        "browserslist": "^4.19.1",
-        "caniuse-lite": "^1.0.30001297",
-        "fraction.js": "^4.1.2",
-        "normalize-range": "^0.1.2",
-        "picocolors": "^1.0.0",
-        "postcss-value-parser": "^4.2.0"
-      },
-      "bin": {
-        "autoprefixer": "bin/autoprefixer"
-      },
-      "engines": {
-        "node": "^10 || ^12 || >=14"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/postcss/"
-      },
-      "peerDependencies": {
-        "postcss": "^8.1.0"
-      }
-    },
-    "node_modules/binary-extensions": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.1.0.tgz",
-      "integrity": "sha512-1Yj8h9Q+QDF5FzhMs/c9+6UntbD5MkRfRwac8DoEm9ZfUBZ7tZ55YcGVAzEe4bXsdQHEk+s9S5wsOKVdZrw0tQ==",
-      "dev": true,
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/braces": {
-      "version": "3.0.2",
-      "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz",
-      "integrity": "sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==",
-      "dev": true,
-      "dependencies": {
-        "fill-range": "^7.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/browserslist": {
-      "version": "4.19.1",
-      "resolved": "https://registry.npmjs.org/browserslist/-/browserslist-4.19.1.tgz",
-      "integrity": "sha512-u2tbbG5PdKRTUoctO3NBD8FQ5HdPh1ZXPHzp1rwaa5jTc+RV9/+RlWiAIKmjRPQF+xbGM9Kklj5bZQFa2s/38A==",
-      "dev": true,
-      "dependencies": {
-        "caniuse-lite": "^1.0.30001286",
-        "electron-to-chromium": "^1.4.17",
-        "escalade": "^3.1.1",
-        "node-releases": "^2.0.1",
-        "picocolors": "^1.0.0"
-      },
-      "bin": {
-        "browserslist": "cli.js"
-      },
-      "engines": {
-        "node": "^6 || ^7 || ^8 || ^9 || ^10 || ^11 || ^12 || >=13.7"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/browserslist"
-      }
-    },
-    "node_modules/caniuse-lite": {
-      "version": "1.0.30001306",
-      "resolved": "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001306.tgz",
-      "integrity": "sha512-Wd1OuggRzg1rbnM5hv1wXs2VkxJH/AA+LuudlIqvZiCvivF+wJJe2mgBZC8gPMgI7D76PP5CTx8Luvaqc1V6OQ==",
-      "dev": true,
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/browserslist"
-      }
-    },
-    "node_modules/chokidar": {
-      "version": "3.4.2",
-      "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.4.2.tgz",
-      "integrity": "sha512-IZHaDeBeI+sZJRX7lGcXsdzgvZqKv6sECqsbErJA4mHWfpRrD8B97kSFN4cQz6nGBGiuFia1MKR4d6c1o8Cv7A==",
-      "dev": true,
-      "dependencies": {
-        "anymatch": "~3.1.1",
-        "braces": "~3.0.2",
-        "glob-parent": "~5.1.0",
-        "is-binary-path": "~2.1.0",
-        "is-glob": "~4.0.1",
-        "normalize-path": "~3.0.0",
-        "readdirp": "~3.4.0"
-      },
-      "engines": {
-        "node": ">= 8.10.0"
-      },
-      "optionalDependencies": {
-        "fsevents": "~2.1.2"
-      }
-    },
-    "node_modules/cliui": {
-      "version": "7.0.4",
-      "resolved": "https://registry.npmjs.org/cliui/-/cliui-7.0.4.tgz",
-      "integrity": "sha512-OcRE68cOsVMXp1Yvonl/fzkQOyjLSu/8bhPDfQt0e0/Eb283TKP20Fs2MqoPsr9SwA595rRCA+QMzYc9nBP+JQ==",
-      "dev": true,
-      "dependencies": {
-        "string-width": "^4.2.0",
-        "strip-ansi": "^6.0.0",
-        "wrap-ansi": "^7.0.0"
-      }
-    },
-    "node_modules/color-convert": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz",
-      "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==",
-      "dev": true,
-      "dependencies": {
-        "color-name": "~1.1.4"
-      },
-      "engines": {
-        "node": ">=7.0.0"
-      }
-    },
-    "node_modules/color-name": {
-      "version": "1.1.4",
-      "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz",
-      "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==",
-      "dev": true
-    },
-    "node_modules/dependency-graph": {
-      "version": "0.9.0",
-      "resolved": "https://registry.npmjs.org/dependency-graph/-/dependency-graph-0.9.0.tgz",
-      "integrity": "sha512-9YLIBURXj4DJMFALxXw9K3Y3rwb5Fk0X5/8ipCzaN84+gKxoHK43tVKRNakCQbiEx07E8Uwhuq21BpUagFhZ8w==",
-      "dev": true,
-      "engines": {
-        "node": ">= 0.6.0"
-      }
-    },
-    "node_modules/dir-glob": {
-      "version": "3.0.1",
-      "resolved": "https://registry.npmjs.org/dir-glob/-/dir-glob-3.0.1.tgz",
-      "integrity": "sha512-WkrWp9GR4KXfKGYzOLmTuGVi1UWFfws377n9cc55/tb6DuqyF6pcQ5AbiHEshaDpY9v6oaSr2XCDidGmMwdzIA==",
-      "dev": true,
-      "dependencies": {
-        "path-type": "^4.0.0"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/electron-to-chromium": {
-      "version": "1.4.63",
-      "resolved": "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.4.63.tgz",
-      "integrity": "sha512-e0PX/LRJPFRU4kzJKLvTobxyFdnANCvcoDCe8XcyTqP58nTWIwdsHvXLIl1RkB39X5yaosLaroMASWB0oIsgCA==",
-      "dev": true
-    },
-    "node_modules/emoji-regex": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz",
-      "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==",
-      "dev": true
-    },
-    "node_modules/escalade": {
-      "version": "3.1.1",
-      "resolved": "https://registry.npmjs.org/escalade/-/escalade-3.1.1.tgz",
-      "integrity": "sha512-k0er2gUkLf8O0zKJiAhmkTnJlTvINGv7ygDNPbeIsX/TJjGJZHuh9B2UxbsaEkmlEo9MfhrSzmhIlhRlI2GXnw==",
-      "dev": true,
-      "engines": {
-        "node": ">=6"
-      }
-    },
-    "node_modules/fast-glob": {
-      "version": "3.2.4",
-      "resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-3.2.4.tgz",
-      "integrity": "sha512-kr/Oo6PX51265qeuCYsyGypiO5uJFgBS0jksyG7FUeCyQzNwYnzrNIMR1NXfkZXsMYXYLRAHgISHBz8gQcxKHQ==",
-      "dev": true,
-      "dependencies": {
-        "@nodelib/fs.stat": "^2.0.2",
-        "@nodelib/fs.walk": "^1.2.3",
-        "glob-parent": "^5.1.0",
-        "merge2": "^1.3.0",
-        "micromatch": "^4.0.2",
-        "picomatch": "^2.2.1"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/fastq": {
-      "version": "1.8.0",
-      "resolved": "https://registry.npmjs.org/fastq/-/fastq-1.8.0.tgz",
-      "integrity": "sha512-SMIZoZdLh/fgofivvIkmknUXyPnvxRE3DhtZ5Me3Mrsk5gyPL42F0xr51TdRXskBxHfMp+07bcYzfsYEsSQA9Q==",
-      "dev": true,
-      "dependencies": {
-        "reusify": "^1.0.4"
-      }
-    },
-    "node_modules/fill-range": {
-      "version": "7.0.1",
-      "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz",
-      "integrity": "sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==",
-      "dev": true,
-      "dependencies": {
-        "to-regex-range": "^5.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/fraction.js": {
-      "version": "4.1.2",
-      "resolved": "https://registry.npmjs.org/fraction.js/-/fraction.js-4.1.2.tgz",
-      "integrity": "sha512-o2RiJQ6DZaR/5+Si0qJUIy637QMRudSi9kU/FFzx9EZazrIdnBgpU+3sEWCxAVhH2RtxW2Oz+T4p2o8uOPVcgA==",
-      "dev": true,
-      "engines": {
-        "node": "*"
-      },
-      "funding": {
-        "type": "patreon",
-        "url": "https://www.patreon.com/infusion"
-      }
-    },
-    "node_modules/fs-extra": {
-      "version": "9.0.1",
-      "resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-9.0.1.tgz",
-      "integrity": "sha512-h2iAoN838FqAFJY2/qVpzFXy+EBxfVE220PalAqQLDVsFOHLJrZvut5puAbCdNv6WJk+B8ihI+k0c7JK5erwqQ==",
-      "dev": true,
-      "dependencies": {
-        "at-least-node": "^1.0.0",
-        "graceful-fs": "^4.2.0",
-        "jsonfile": "^6.0.1",
-        "universalify": "^1.0.0"
-      },
-      "engines": {
-        "node": ">=10"
-      }
-    },
-    "node_modules/fsevents": {
-      "version": "2.1.3",
-      "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.1.3.tgz",
-      "integrity": "sha512-Auw9a4AxqWpa9GUfj370BMPzzyncfBABW8Mab7BGWBYDj4Isgq+cDKtx0i6u9jcX9pQDnswsaaOTgTmA5pEjuQ==",
-      "deprecated": "\"Please update to latest v2.3 or v2.2\"",
-      "dev": true,
-      "hasInstallScript": true,
-      "optional": true,
-      "os": [
-        "darwin"
-      ],
-      "engines": {
-        "node": "^8.16.0 || ^10.6.0 || >=11.0.0"
-      }
-    },
-    "node_modules/get-caller-file": {
-      "version": "2.0.5",
-      "resolved": "https://registry.npmjs.org/get-caller-file/-/get-caller-file-2.0.5.tgz",
-      "integrity": "sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==",
-      "dev": true,
-      "engines": {
-        "node": "6.* || 8.* || >= 10.*"
-      }
-    },
-    "node_modules/get-stdin": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-8.0.0.tgz",
-      "integrity": "sha512-sY22aA6xchAzprjyqmSEQv4UbAAzRN0L2dQB0NlN5acTTK9Don6nhoc3eAbUnpZiCANAMfd/+40kVdKfFygohg==",
-      "dev": true,
-      "engines": {
-        "node": ">=10"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
-      }
-    },
-    "node_modules/glob-parent": {
-      "version": "5.1.2",
-      "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz",
-      "integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==",
-      "dev": true,
-      "dependencies": {
-        "is-glob": "^4.0.1"
-      },
-      "engines": {
-        "node": ">= 6"
-      }
-    },
-    "node_modules/globby": {
-      "version": "11.0.1",
-      "resolved": "https://registry.npmjs.org/globby/-/globby-11.0.1.tgz",
-      "integrity": "sha512-iH9RmgwCmUJHi2z5o2l3eTtGBtXek1OYlHrbcxOYugyHLmAsZrPj43OtHThd62Buh/Vv6VyCBD2bdyWcGNQqoQ==",
-      "dev": true,
-      "dependencies": {
-        "array-union": "^2.1.0",
-        "dir-glob": "^3.0.1",
-        "fast-glob": "^3.1.1",
-        "ignore": "^5.1.4",
-        "merge2": "^1.3.0",
-        "slash": "^3.0.0"
-      },
-      "engines": {
-        "node": ">=10"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/sindresorhus"
-      }
-    },
-    "node_modules/graceful-fs": {
-      "version": "4.2.4",
-      "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.4.tgz",
-      "integrity": "sha512-WjKPNJF79dtJAVniUlGGWHYGz2jWxT6VhN/4m1NdkbZ2nOsEF+cI1Edgql5zCRhs/VsQYRvrXctxktVXZUkixw==",
-      "dev": true
-    },
-    "node_modules/ignore": {
-      "version": "5.1.8",
-      "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.1.8.tgz",
-      "integrity": "sha512-BMpfD7PpiETpBl/A6S498BaIJ6Y/ABT93ETbby2fP00v4EbvPBXWEoaR1UBPKs3iR53pJY7EtZk5KACI57i1Uw==",
-      "dev": true,
-      "engines": {
-        "node": ">= 4"
-      }
-    },
-    "node_modules/is-binary-path": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz",
-      "integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==",
-      "dev": true,
-      "dependencies": {
-        "binary-extensions": "^2.0.0"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/is-extglob": {
-      "version": "2.1.1",
-      "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz",
-      "integrity": "sha1-qIwCU1eR8C7TfHahueqXc8gz+MI=",
-      "dev": true,
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/is-fullwidth-code-point": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
-      "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
-      "dev": true,
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/is-glob": {
-      "version": "4.0.1",
-      "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.1.tgz",
-      "integrity": "sha512-5G0tKtBTFImOqDnLB2hG6Bp2qcKEFduo4tZu9MT/H6NQv/ghhy30o55ufafxJ/LdH79LLs2Kfrn85TLKyA7BUg==",
-      "dev": true,
-      "dependencies": {
-        "is-extglob": "^2.1.1"
-      },
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/is-number": {
-      "version": "7.0.0",
-      "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
-      "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
-      "dev": true,
-      "engines": {
-        "node": ">=0.12.0"
-      }
-    },
-    "node_modules/jsonfile": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-6.0.1.tgz",
-      "integrity": "sha512-jR2b5v7d2vIOust+w3wtFKZIfpC2pnRmFAhAC/BuweZFQR8qZzxH1OyrQ10HmdVYiXWkYUqPVsz91cG7EL2FBg==",
-      "dev": true,
-      "dependencies": {
-        "universalify": "^1.0.0"
-      },
-      "optionalDependencies": {
-        "graceful-fs": "^4.1.6"
-      }
-    },
-    "node_modules/lilconfig": {
-      "version": "2.0.4",
-      "resolved": "https://registry.npmjs.org/lilconfig/-/lilconfig-2.0.4.tgz",
-      "integrity": "sha512-bfTIN7lEsiooCocSISTWXkiWJkRqtL9wYtYy+8EK3Y41qh3mpwPU0ycTOgjdY9ErwXCc8QyrQp82bdL0Xkm9yA==",
-      "dev": true,
-      "engines": {
-        "node": ">=10"
-      }
-    },
-    "node_modules/merge2": {
-      "version": "1.4.1",
-      "resolved": "https://registry.npmjs.org/merge2/-/merge2-1.4.1.tgz",
-      "integrity": "sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==",
-      "dev": true,
-      "engines": {
-        "node": ">= 8"
-      }
-    },
-    "node_modules/micromatch": {
-      "version": "4.0.2",
-      "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.2.tgz",
-      "integrity": "sha512-y7FpHSbMUMoyPbYUSzO6PaZ6FyRnQOpHuKwbo1G+Knck95XVU4QAiKdGEnj5wwoS7PlOgthX/09u5iFJ+aYf5Q==",
-      "dev": true,
-      "dependencies": {
-        "braces": "^3.0.1",
-        "picomatch": "^2.0.5"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/nanoid": {
-      "version": "3.2.0",
-      "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.2.0.tgz",
-      "integrity": "sha512-fmsZYa9lpn69Ad5eDn7FMcnnSR+8R34W9qJEijxYhTbfOWzr22n1QxCMzXLK+ODyW2973V3Fux959iQoUxzUIA==",
-      "dev": true,
-      "peer": true,
-      "bin": {
-        "nanoid": "bin/nanoid.cjs"
-      },
-      "engines": {
-        "node": "^10 || ^12 || ^13.7 || ^14 || >=15.0.1"
-      }
-    },
-    "node_modules/node-fetch": {
-      "version": "2.6.7",
-      "resolved": "https://registry.npmjs.org/node-fetch/-/node-fetch-2.6.7.tgz",
-      "integrity": "sha512-ZjMPFEfVx5j+y2yF35Kzx5sF7kDzxuDj6ziH4FFbOp87zKDZNx8yExJIb05OGF4Nlt9IHFIMBkRl41VdvcNdbQ==",
-      "dev": true,
-      "dependencies": {
-        "whatwg-url": "^5.0.0"
-      },
-      "engines": {
-        "node": "4.x || >=6.0.0"
-      },
-      "peerDependencies": {
-        "encoding": "^0.1.0"
-      },
-      "peerDependenciesMeta": {
-        "encoding": {
-          "optional": true
-        }
-      }
-    },
-    "node_modules/node-releases": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/node-releases/-/node-releases-2.0.1.tgz",
-      "integrity": "sha512-CqyzN6z7Q6aMeF/ktcMVTzhAHCEpf8SOarwpzpf8pNBY2k5/oM34UHldUwp8VKI7uxct2HxSRdJjBaZeESzcxA==",
-      "dev": true
-    },
-    "node_modules/normalize-path": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
-      "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
-      "dev": true,
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/normalize-range": {
-      "version": "0.1.2",
-      "resolved": "https://registry.npmjs.org/normalize-range/-/normalize-range-0.1.2.tgz",
-      "integrity": "sha1-LRDAa9/TEuqXd2laTShDlFa3WUI=",
-      "dev": true,
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/path-type": {
-      "version": "4.0.0",
-      "resolved": "https://registry.npmjs.org/path-type/-/path-type-4.0.0.tgz",
-      "integrity": "sha512-gDKb8aZMDeD/tZWs9P6+q0J9Mwkdl6xMV8TjnGP3qJVJ06bdMgkbBlLU8IdfOsIsFz2BW1rNVT3XuNEl8zPAvw==",
-      "dev": true,
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/picocolors": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.0.0.tgz",
-      "integrity": "sha512-1fygroTLlHu66zi26VoTDv8yRgm0Fccecssto+MhsZ0D/DGW2sm8E8AjW7NU5VVTRt5GxbeZ5qBuJr+HyLYkjQ==",
-      "dev": true
-    },
-    "node_modules/picomatch": {
-      "version": "2.2.2",
-      "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.2.2.tgz",
-      "integrity": "sha512-q0M/9eZHzmr0AulXyPwNfZjtwZ/RBZlbN3K3CErVrk50T2ASYI7Bye0EvekFY3IP1Nt2DHu0re+V2ZHIpMkuWg==",
-      "dev": true,
-      "engines": {
-        "node": ">=8.6"
-      },
-      "funding": {
-        "url": "https://github.com/sponsors/jonschlinkert"
-      }
-    },
-    "node_modules/pify": {
-      "version": "2.3.0",
-      "resolved": "https://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
-      "integrity": "sha1-7RQaasBDqEnqWISY59yosVMw6Qw=",
-      "dev": true,
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/postcss": {
-      "version": "8.4.6",
-      "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.4.6.tgz",
-      "integrity": "sha512-OovjwIzs9Te46vlEx7+uXB0PLijpwjXGKXjVGGPIGubGpq7uh5Xgf6D6FiJ/SzJMBosHDp6a2hiXOS97iBXcaA==",
-      "dev": true,
-      "peer": true,
-      "dependencies": {
-        "nanoid": "^3.2.0",
-        "picocolors": "^1.0.0",
-        "source-map-js": "^1.0.2"
-      },
-      "engines": {
-        "node": "^10 || ^12 || >=14"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/postcss/"
-      }
-    },
-    "node_modules/postcss-cli": {
-      "version": "8.3.1",
-      "resolved": "https://registry.npmjs.org/postcss-cli/-/postcss-cli-8.3.1.tgz",
-      "integrity": "sha512-leHXsQRq89S3JC9zw/tKyiVV2jAhnfQe0J8VI4eQQbUjwIe0XxVqLrR+7UsahF1s9wi4GlqP6SJ8ydf44cgF2Q==",
-      "dev": true,
-      "dependencies": {
-        "chalk": "^4.0.0",
-        "chokidar": "^3.3.0",
-        "dependency-graph": "^0.9.0",
-        "fs-extra": "^9.0.0",
-        "get-stdin": "^8.0.0",
-        "globby": "^11.0.0",
-        "postcss-load-config": "^3.0.0",
-        "postcss-reporter": "^7.0.0",
-        "pretty-hrtime": "^1.0.3",
-        "read-cache": "^1.0.0",
-        "slash": "^3.0.0",
-        "yargs": "^16.0.0"
-      },
-      "bin": {
-        "postcss": "bin/postcss"
-      },
-      "engines": {
-        "node": ">=10"
-      },
-      "peerDependencies": {
-        "postcss": "^8.0.0"
-      }
-    },
-    "node_modules/postcss-cli/node_modules/chalk": {
-      "version": "4.1.0",
-      "resolved": "https://registry.npmjs.org/chalk/-/chalk-4.1.0.tgz",
-      "integrity": "sha512-qwx12AxXe2Q5xQ43Ac//I6v5aXTipYrSESdOgzrN+9XjgEpyjpKuvSGaN4qE93f7TQTlerQQ8S+EQ0EyDoVL1A==",
-      "dev": true,
-      "dependencies": {
-        "ansi-styles": "^4.1.0",
-        "supports-color": "^7.1.0"
-      },
-      "engines": {
-        "node": ">=10"
-      },
-      "funding": {
-        "url": "https://github.com/chalk/chalk?sponsor=1"
-      }
-    },
-    "node_modules/postcss-cli/node_modules/has-flag": {
-      "version": "4.0.0",
-      "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz",
-      "integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==",
-      "dev": true,
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/postcss-cli/node_modules/supports-color": {
-      "version": "7.2.0",
-      "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz",
-      "integrity": "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==",
-      "dev": true,
-      "dependencies": {
-        "has-flag": "^4.0.0"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/postcss-load-config": {
-      "version": "3.1.1",
-      "resolved": "https://registry.npmjs.org/postcss-load-config/-/postcss-load-config-3.1.1.tgz",
-      "integrity": "sha512-c/9XYboIbSEUZpiD1UQD0IKiUe8n9WHYV7YFe7X7J+ZwCsEKkUJSFWjS9hBU1RR9THR7jMXst8sxiqP0jjo2mg==",
-      "dev": true,
-      "dependencies": {
-        "lilconfig": "^2.0.4",
-        "yaml": "^1.10.2"
-      },
-      "engines": {
-        "node": ">= 10"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/postcss/"
-      },
-      "peerDependencies": {
-        "ts-node": ">=9.0.0"
-      },
-      "peerDependenciesMeta": {
-        "ts-node": {
-          "optional": true
-        }
-      }
-    },
-    "node_modules/postcss-reporter": {
-      "version": "7.0.5",
-      "resolved": "https://registry.npmjs.org/postcss-reporter/-/postcss-reporter-7.0.5.tgz",
-      "integrity": "sha512-glWg7VZBilooZGOFPhN9msJ3FQs19Hie7l5a/eE6WglzYqVeH3ong3ShFcp9kDWJT1g2Y/wd59cocf9XxBtkWA==",
-      "dev": true,
-      "dependencies": {
-        "picocolors": "^1.0.0",
-        "thenby": "^1.3.4"
-      },
-      "engines": {
-        "node": ">=10"
-      },
-      "funding": {
-        "type": "opencollective",
-        "url": "https://opencollective.com/postcss/"
-      },
-      "peerDependencies": {
-        "postcss": "^8.1.0"
-      }
-    },
-    "node_modules/postcss-value-parser": {
-      "version": "4.2.0",
-      "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-4.2.0.tgz",
-      "integrity": "sha512-1NNCs6uurfkVbeXG4S8JFT9t19m45ICnif8zWLd5oPSZ50QnwMfK+H3jv408d4jw/7Bttv5axS5IiHoLaVNHeQ==",
-      "dev": true
-    },
-    "node_modules/pretty-hrtime": {
-      "version": "1.0.3",
-      "resolved": "https://registry.npmjs.org/pretty-hrtime/-/pretty-hrtime-1.0.3.tgz",
-      "integrity": "sha1-t+PqQkNaTJsnWdmeDyAesZWALuE=",
-      "dev": true,
-      "engines": {
-        "node": ">= 0.8"
-      }
-    },
-    "node_modules/read-cache": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/read-cache/-/read-cache-1.0.0.tgz",
-      "integrity": "sha1-5mTvMRYRZsl1HNvo28+GtftY93Q=",
-      "dev": true,
-      "dependencies": {
-        "pify": "^2.3.0"
-      }
-    },
-    "node_modules/readdirp": {
-      "version": "3.4.0",
-      "resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.4.0.tgz",
-      "integrity": "sha512-0xe001vZBnJEK+uKcj8qOhyAKPzIT+gStxWr3LCB0DwcXR5NZJ3IaC+yGnHCYzB/S7ov3m3EEbZI2zeNvX+hGQ==",
-      "dev": true,
-      "dependencies": {
-        "picomatch": "^2.2.1"
-      },
-      "engines": {
-        "node": ">=8.10.0"
-      }
-    },
-    "node_modules/require-directory": {
-      "version": "2.1.1",
-      "resolved": "https://registry.npmjs.org/require-directory/-/require-directory-2.1.1.tgz",
-      "integrity": "sha1-jGStX9MNqxyXbiNE/+f3kqam30I=",
-      "dev": true,
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/reusify": {
-      "version": "1.0.4",
-      "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz",
-      "integrity": "sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==",
-      "dev": true,
-      "engines": {
-        "iojs": ">=1.0.0",
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/run-parallel": {
-      "version": "1.1.9",
-      "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.1.9.tgz",
-      "integrity": "sha512-DEqnSRTDw/Tc3FXf49zedI638Z9onwUotBMiUFKmrO2sdFKIbXamXGQ3Axd4qgphxKB4kw/qP1w5kTxnfU1B9Q==",
-      "dev": true
-    },
-    "node_modules/slash": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/slash/-/slash-3.0.0.tgz",
-      "integrity": "sha512-g9Q1haeby36OSStwb4ntCGGGaKsaVSjQ68fBxoQcutl5fS1vuY18H3wSt3jFyFtrkx+Kz0V1G85A4MyAdDMi2Q==",
-      "dev": true,
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/source-map-js": {
-      "version": "1.0.2",
-      "resolved": "https://registry.npmjs.org/source-map-js/-/source-map-js-1.0.2.tgz",
-      "integrity": "sha512-R0XvVJ9WusLiqTCEiGCmICCMplcCkIwwR11mOSD9CR5u+IXYdiseeEuXCVAjS54zqwkLcPNnmU4OeJ6tUrWhDw==",
-      "dev": true,
-      "peer": true,
-      "engines": {
-        "node": ">=0.10.0"
-      }
-    },
-    "node_modules/string-width": {
-      "version": "4.2.3",
-      "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
-      "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
-      "dev": true,
-      "dependencies": {
-        "emoji-regex": "^8.0.0",
-        "is-fullwidth-code-point": "^3.0.0",
-        "strip-ansi": "^6.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/strip-ansi": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
-      "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
-      "dev": true,
-      "dependencies": {
-        "ansi-regex": "^5.0.1"
-      },
-      "engines": {
-        "node": ">=8"
-      }
-    },
-    "node_modules/thenby": {
-      "version": "1.3.4",
-      "resolved": "https://registry.npmjs.org/thenby/-/thenby-1.3.4.tgz",
-      "integrity": "sha512-89Gi5raiWA3QZ4b2ePcEwswC3me9JIg+ToSgtE0JWeCynLnLxNr/f9G+xfo9K+Oj4AFdom8YNJjibIARTJmapQ==",
-      "dev": true
-    },
-    "node_modules/to-regex-range": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
-      "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
-      "dev": true,
-      "dependencies": {
-        "is-number": "^7.0.0"
-      },
-      "engines": {
-        "node": ">=8.0"
-      }
-    },
-    "node_modules/tr46": {
-      "version": "0.0.3",
-      "resolved": "https://registry.npmjs.org/tr46/-/tr46-0.0.3.tgz",
-      "integrity": "sha1-gYT9NH2snNwYWZLzpmIuFLnZq2o=",
-      "dev": true
-    },
-    "node_modules/universalify": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/universalify/-/universalify-1.0.0.tgz",
-      "integrity": "sha512-rb6X1W158d7pRQBg5gkR8uPaSfiids68LTJQYOtEUhoJUWBdaQHsuT/EUduxXYxcrt4r5PJ4fuHW1MHT6p0qug==",
-      "dev": true,
-      "engines": {
-        "node": ">= 10.0.0"
-      }
-    },
-    "node_modules/webidl-conversions": {
-      "version": "3.0.1",
-      "resolved": "https://registry.npmjs.org/webidl-conversions/-/webidl-conversions-3.0.1.tgz",
-      "integrity": "sha1-JFNCdeKnvGvnvIZhHMFq4KVlSHE=",
-      "dev": true
-    },
-    "node_modules/whatwg-url": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/whatwg-url/-/whatwg-url-5.0.0.tgz",
-      "integrity": "sha1-lmRU6HZUYuN2RNNib2dCzotwll0=",
-      "dev": true,
-      "dependencies": {
-        "tr46": "~0.0.3",
-        "webidl-conversions": "^3.0.0"
-      }
-    },
-    "node_modules/wrap-ansi": {
-      "version": "7.0.0",
-      "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz",
-      "integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==",
-      "dev": true,
-      "dependencies": {
-        "ansi-styles": "^4.0.0",
-        "string-width": "^4.1.0",
-        "strip-ansi": "^6.0.0"
-      },
-      "engines": {
-        "node": ">=10"
-      },
-      "funding": {
-        "url": "https://github.com/chalk/wrap-ansi?sponsor=1"
-      }
-    },
-    "node_modules/y18n": {
-      "version": "5.0.8",
-      "resolved": "https://registry.npmjs.org/y18n/-/y18n-5.0.8.tgz",
-      "integrity": "sha512-0pfFzegeDWJHJIAmTLRP2DwHjdF5s7jo9tuztdQxAhINCdvS+3nGINqPd00AphqJR/0LhANUS6/+7SCb98YOfA==",
-      "dev": true,
-      "engines": {
-        "node": ">=10"
-      }
-    },
-    "node_modules/yaml": {
-      "version": "1.10.2",
-      "resolved": "https://registry.npmjs.org/yaml/-/yaml-1.10.2.tgz",
-      "integrity": "sha512-r3vXyErRCYJ7wg28yvBY5VSoAF8ZvlcW9/BwUzEtUsjvX/DKs24dIkuwjtuprwJJHsbyUbLApepYTR1BN4uHrg==",
-      "dev": true,
-      "engines": {
-        "node": ">= 6"
-      }
-    },
-    "node_modules/yargs": {
-      "version": "16.2.0",
-      "resolved": "https://registry.npmjs.org/yargs/-/yargs-16.2.0.tgz",
-      "integrity": "sha512-D1mvvtDG0L5ft/jGWkLpG1+m0eQxOfaBvTNELraWj22wSVUMWxZUvYgJYcKh6jGGIkJFhH4IZPQhR4TKpc8mBw==",
-      "dev": true,
-      "dependencies": {
-        "cliui": "^7.0.2",
-        "escalade": "^3.1.1",
-        "get-caller-file": "^2.0.5",
-        "require-directory": "^2.1.1",
-        "string-width": "^4.2.0",
-        "y18n": "^5.0.5",
-        "yargs-parser": "^20.2.2"
-      },
-      "engines": {
-        "node": ">=10"
-      }
-    },
-    "node_modules/yargs-parser": {
-      "version": "20.2.9",
-      "resolved": "https://registry.npmjs.org/yargs-parser/-/yargs-parser-20.2.9.tgz",
-      "integrity": "sha512-y11nGElTIV+CT3Zv9t7VKl+Q3hTQoT9a1Qzezhhl6Rp21gJ/IVTW7Z3y9EWXhuUBC2Shnf+DX0antecpAwSP8w==",
-      "dev": true,
-      "engines": {
-        "node": ">=10"
-      }
-    }
-  },
-  "dependencies": {
-    "@nodelib/fs.scandir": {
-      "version": "2.1.3",
-      "resolved": "https://registry.npmjs.org/@nodelib/fs.scandir/-/fs.scandir-2.1.3.tgz",
-      "integrity": "sha512-eGmwYQn3gxo4r7jdQnkrrN6bY478C3P+a/y72IJukF8LjB6ZHeB3c+Ehacj3sYeSmUXGlnA67/PmbM9CVwL7Dw==",
-      "dev": true,
-      "requires": {
-        "@nodelib/fs.stat": "2.0.3",
-        "run-parallel": "^1.1.9"
-      }
-    },
-    "@nodelib/fs.stat": {
-      "version": "2.0.3",
-      "resolved": "https://registry.npmjs.org/@nodelib/fs.stat/-/fs.stat-2.0.3.tgz",
-      "integrity": "sha512-bQBFruR2TAwoevBEd/NWMoAAtNGzTRgdrqnYCc7dhzfoNvqPzLyqlEQnzZ3kVnNrSp25iyxE00/3h2fqGAGArA==",
-      "dev": true
-    },
-    "@nodelib/fs.walk": {
-      "version": "1.2.4",
-      "resolved": "https://registry.npmjs.org/@nodelib/fs.walk/-/fs.walk-1.2.4.tgz",
-      "integrity": "sha512-1V9XOY4rDW0rehzbrcqAmHnz8e7SKvX27gh8Gt2WgB0+pdzdiLV83p72kZPU+jvMbS1qU5mauP2iOvO8rhmurQ==",
-      "dev": true,
-      "requires": {
-        "@nodelib/fs.scandir": "2.1.3",
-        "fastq": "^1.6.0"
-      }
-    },
-    "ansi-regex": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/ansi-regex/-/ansi-regex-5.0.1.tgz",
-      "integrity": "sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==",
-      "dev": true
-    },
-    "ansi-styles": {
-      "version": "4.3.0",
-      "resolved": "https://registry.npmjs.org/ansi-styles/-/ansi-styles-4.3.0.tgz",
-      "integrity": "sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==",
-      "dev": true,
-      "requires": {
-        "color-convert": "^2.0.1"
-      }
-    },
-    "anymatch": {
-      "version": "3.1.1",
-      "resolved": "https://registry.npmjs.org/anymatch/-/anymatch-3.1.1.tgz",
-      "integrity": "sha512-mM8522psRCqzV+6LhomX5wgp25YVibjh8Wj23I5RPkPppSVSjyKD2A2mBJmWGa+KN7f2D6LNh9jkBCeyLktzjg==",
-      "dev": true,
-      "requires": {
-        "normalize-path": "^3.0.0",
-        "picomatch": "^2.0.4"
-      }
-    },
-    "array-union": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/array-union/-/array-union-2.1.0.tgz",
-      "integrity": "sha512-HGyxoOTYUyCM6stUe6EJgnd4EoewAI7zMdfqO+kGjnlZmBDz/cR5pf8r/cR4Wq60sL/p0IkcjUEEPwS3GFrIyw==",
-      "dev": true
-    },
-    "at-least-node": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/at-least-node/-/at-least-node-1.0.0.tgz",
-      "integrity": "sha512-+q/t7Ekv1EDY2l6Gda6LLiX14rU9TV20Wa3ofeQmwPFZbOMo9DXrLbOjFaaclkXKWidIaopwAObQDqwWtGUjqg==",
-      "dev": true
-    },
-    "autoprefixer": {
-      "version": "10.4.2",
-      "resolved": "https://registry.npmjs.org/autoprefixer/-/autoprefixer-10.4.2.tgz",
-      "integrity": "sha512-9fOPpHKuDW1w/0EKfRmVnxTDt8166MAnLI3mgZ1JCnhNtYWxcJ6Ud5CO/AVOZi/AvFa8DY9RTy3h3+tFBlrrdQ==",
-      "dev": true,
-      "requires": {
-        "browserslist": "^4.19.1",
-        "caniuse-lite": "^1.0.30001297",
-        "fraction.js": "^4.1.2",
-        "normalize-range": "^0.1.2",
-        "picocolors": "^1.0.0",
-        "postcss-value-parser": "^4.2.0"
-      }
-    },
-    "binary-extensions": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/binary-extensions/-/binary-extensions-2.1.0.tgz",
-      "integrity": "sha512-1Yj8h9Q+QDF5FzhMs/c9+6UntbD5MkRfRwac8DoEm9ZfUBZ7tZ55YcGVAzEe4bXsdQHEk+s9S5wsOKVdZrw0tQ==",
-      "dev": true
-    },
-    "braces": {
-      "version": "3.0.2",
-      "resolved": "https://registry.npmjs.org/braces/-/braces-3.0.2.tgz",
-      "integrity": "sha512-b8um+L1RzM3WDSzvhm6gIz1yfTbBt6YTlcEKAvsmqCZZFw46z626lVj9j1yEPW33H5H+lBQpZMP1k8l+78Ha0A==",
-      "dev": true,
-      "requires": {
-        "fill-range": "^7.0.1"
-      }
-    },
-    "browserslist": {
-      "version": "4.19.1",
-      "resolved": "https://registry.npmjs.org/browserslist/-/browserslist-4.19.1.tgz",
-      "integrity": "sha512-u2tbbG5PdKRTUoctO3NBD8FQ5HdPh1ZXPHzp1rwaa5jTc+RV9/+RlWiAIKmjRPQF+xbGM9Kklj5bZQFa2s/38A==",
-      "dev": true,
-      "requires": {
-        "caniuse-lite": "^1.0.30001286",
-        "electron-to-chromium": "^1.4.17",
-        "escalade": "^3.1.1",
-        "node-releases": "^2.0.1",
-        "picocolors": "^1.0.0"
-      }
-    },
-    "caniuse-lite": {
-      "version": "1.0.30001306",
-      "resolved": "https://registry.npmjs.org/caniuse-lite/-/caniuse-lite-1.0.30001306.tgz",
-      "integrity": "sha512-Wd1OuggRzg1rbnM5hv1wXs2VkxJH/AA+LuudlIqvZiCvivF+wJJe2mgBZC8gPMgI7D76PP5CTx8Luvaqc1V6OQ==",
-      "dev": true
-    },
-    "chokidar": {
-      "version": "3.4.2",
-      "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-3.4.2.tgz",
-      "integrity": "sha512-IZHaDeBeI+sZJRX7lGcXsdzgvZqKv6sECqsbErJA4mHWfpRrD8B97kSFN4cQz6nGBGiuFia1MKR4d6c1o8Cv7A==",
-      "dev": true,
-      "requires": {
-        "anymatch": "~3.1.1",
-        "braces": "~3.0.2",
-        "fsevents": "~2.1.2",
-        "glob-parent": "~5.1.0",
-        "is-binary-path": "~2.1.0",
-        "is-glob": "~4.0.1",
-        "normalize-path": "~3.0.0",
-        "readdirp": "~3.4.0"
-      }
-    },
-    "cliui": {
-      "version": "7.0.4",
-      "resolved": "https://registry.npmjs.org/cliui/-/cliui-7.0.4.tgz",
-      "integrity": "sha512-OcRE68cOsVMXp1Yvonl/fzkQOyjLSu/8bhPDfQt0e0/Eb283TKP20Fs2MqoPsr9SwA595rRCA+QMzYc9nBP+JQ==",
-      "dev": true,
-      "requires": {
-        "string-width": "^4.2.0",
-        "strip-ansi": "^6.0.0",
-        "wrap-ansi": "^7.0.0"
-      }
-    },
-    "color-convert": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/color-convert/-/color-convert-2.0.1.tgz",
-      "integrity": "sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==",
-      "dev": true,
-      "requires": {
-        "color-name": "~1.1.4"
-      }
-    },
-    "color-name": {
-      "version": "1.1.4",
-      "resolved": "https://registry.npmjs.org/color-name/-/color-name-1.1.4.tgz",
-      "integrity": "sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==",
-      "dev": true
-    },
-    "dependency-graph": {
-      "version": "0.9.0",
-      "resolved": "https://registry.npmjs.org/dependency-graph/-/dependency-graph-0.9.0.tgz",
-      "integrity": "sha512-9YLIBURXj4DJMFALxXw9K3Y3rwb5Fk0X5/8ipCzaN84+gKxoHK43tVKRNakCQbiEx07E8Uwhuq21BpUagFhZ8w==",
-      "dev": true
-    },
-    "dir-glob": {
-      "version": "3.0.1",
-      "resolved": "https://registry.npmjs.org/dir-glob/-/dir-glob-3.0.1.tgz",
-      "integrity": "sha512-WkrWp9GR4KXfKGYzOLmTuGVi1UWFfws377n9cc55/tb6DuqyF6pcQ5AbiHEshaDpY9v6oaSr2XCDidGmMwdzIA==",
-      "dev": true,
-      "requires": {
-        "path-type": "^4.0.0"
-      }
-    },
-    "electron-to-chromium": {
-      "version": "1.4.63",
-      "resolved": "https://registry.npmjs.org/electron-to-chromium/-/electron-to-chromium-1.4.63.tgz",
-      "integrity": "sha512-e0PX/LRJPFRU4kzJKLvTobxyFdnANCvcoDCe8XcyTqP58nTWIwdsHvXLIl1RkB39X5yaosLaroMASWB0oIsgCA==",
-      "dev": true
-    },
-    "emoji-regex": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/emoji-regex/-/emoji-regex-8.0.0.tgz",
-      "integrity": "sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==",
-      "dev": true
-    },
-    "escalade": {
-      "version": "3.1.1",
-      "resolved": "https://registry.npmjs.org/escalade/-/escalade-3.1.1.tgz",
-      "integrity": "sha512-k0er2gUkLf8O0zKJiAhmkTnJlTvINGv7ygDNPbeIsX/TJjGJZHuh9B2UxbsaEkmlEo9MfhrSzmhIlhRlI2GXnw==",
-      "dev": true
-    },
-    "fast-glob": {
-      "version": "3.2.4",
-      "resolved": "https://registry.npmjs.org/fast-glob/-/fast-glob-3.2.4.tgz",
-      "integrity": "sha512-kr/Oo6PX51265qeuCYsyGypiO5uJFgBS0jksyG7FUeCyQzNwYnzrNIMR1NXfkZXsMYXYLRAHgISHBz8gQcxKHQ==",
-      "dev": true,
-      "requires": {
-        "@nodelib/fs.stat": "^2.0.2",
-        "@nodelib/fs.walk": "^1.2.3",
-        "glob-parent": "^5.1.0",
-        "merge2": "^1.3.0",
-        "micromatch": "^4.0.2",
-        "picomatch": "^2.2.1"
-      }
-    },
-    "fastq": {
-      "version": "1.8.0",
-      "resolved": "https://registry.npmjs.org/fastq/-/fastq-1.8.0.tgz",
-      "integrity": "sha512-SMIZoZdLh/fgofivvIkmknUXyPnvxRE3DhtZ5Me3Mrsk5gyPL42F0xr51TdRXskBxHfMp+07bcYzfsYEsSQA9Q==",
-      "dev": true,
-      "requires": {
-        "reusify": "^1.0.4"
-      }
-    },
-    "fill-range": {
-      "version": "7.0.1",
-      "resolved": "https://registry.npmjs.org/fill-range/-/fill-range-7.0.1.tgz",
-      "integrity": "sha512-qOo9F+dMUmC2Lcb4BbVvnKJxTPjCm+RRpe4gDuGrzkL7mEVl/djYSu2OdQ2Pa302N4oqkSg9ir6jaLWJ2USVpQ==",
-      "dev": true,
-      "requires": {
-        "to-regex-range": "^5.0.1"
-      }
-    },
-    "fraction.js": {
-      "version": "4.1.2",
-      "resolved": "https://registry.npmjs.org/fraction.js/-/fraction.js-4.1.2.tgz",
-      "integrity": "sha512-o2RiJQ6DZaR/5+Si0qJUIy637QMRudSi9kU/FFzx9EZazrIdnBgpU+3sEWCxAVhH2RtxW2Oz+T4p2o8uOPVcgA==",
-      "dev": true
-    },
-    "fs-extra": {
-      "version": "9.0.1",
-      "resolved": "https://registry.npmjs.org/fs-extra/-/fs-extra-9.0.1.tgz",
-      "integrity": "sha512-h2iAoN838FqAFJY2/qVpzFXy+EBxfVE220PalAqQLDVsFOHLJrZvut5puAbCdNv6WJk+B8ihI+k0c7JK5erwqQ==",
-      "dev": true,
-      "requires": {
-        "at-least-node": "^1.0.0",
-        "graceful-fs": "^4.2.0",
-        "jsonfile": "^6.0.1",
-        "universalify": "^1.0.0"
-      }
-    },
-    "fsevents": {
-      "version": "2.1.3",
-      "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-2.1.3.tgz",
-      "integrity": "sha512-Auw9a4AxqWpa9GUfj370BMPzzyncfBABW8Mab7BGWBYDj4Isgq+cDKtx0i6u9jcX9pQDnswsaaOTgTmA5pEjuQ==",
-      "dev": true,
-      "optional": true
-    },
-    "get-caller-file": {
-      "version": "2.0.5",
-      "resolved": "https://registry.npmjs.org/get-caller-file/-/get-caller-file-2.0.5.tgz",
-      "integrity": "sha512-DyFP3BM/3YHTQOCUL/w0OZHR0lpKeGrxotcHWcqNEdnltqFwXVfhEBQ94eIo34AfQpo0rGki4cyIiftY06h2Fg==",
-      "dev": true
-    },
-    "get-stdin": {
-      "version": "8.0.0",
-      "resolved": "https://registry.npmjs.org/get-stdin/-/get-stdin-8.0.0.tgz",
-      "integrity": "sha512-sY22aA6xchAzprjyqmSEQv4UbAAzRN0L2dQB0NlN5acTTK9Don6nhoc3eAbUnpZiCANAMfd/+40kVdKfFygohg==",
-      "dev": true
-    },
-    "glob-parent": {
-      "version": "5.1.2",
-      "resolved": "https://registry.npmjs.org/glob-parent/-/glob-parent-5.1.2.tgz",
-      "integrity": "sha512-AOIgSQCepiJYwP3ARnGx+5VnTu2HBYdzbGP45eLw1vr3zB3vZLeyed1sC9hnbcOc9/SrMyM5RPQrkGz4aS9Zow==",
-      "dev": true,
-      "requires": {
-        "is-glob": "^4.0.1"
-      }
-    },
-    "globby": {
-      "version": "11.0.1",
-      "resolved": "https://registry.npmjs.org/globby/-/globby-11.0.1.tgz",
-      "integrity": "sha512-iH9RmgwCmUJHi2z5o2l3eTtGBtXek1OYlHrbcxOYugyHLmAsZrPj43OtHThd62Buh/Vv6VyCBD2bdyWcGNQqoQ==",
-      "dev": true,
-      "requires": {
-        "array-union": "^2.1.0",
-        "dir-glob": "^3.0.1",
-        "fast-glob": "^3.1.1",
-        "ignore": "^5.1.4",
-        "merge2": "^1.3.0",
-        "slash": "^3.0.0"
-      }
-    },
-    "graceful-fs": {
-      "version": "4.2.4",
-      "resolved": "https://registry.npmjs.org/graceful-fs/-/graceful-fs-4.2.4.tgz",
-      "integrity": "sha512-WjKPNJF79dtJAVniUlGGWHYGz2jWxT6VhN/4m1NdkbZ2nOsEF+cI1Edgql5zCRhs/VsQYRvrXctxktVXZUkixw==",
-      "dev": true
-    },
-    "ignore": {
-      "version": "5.1.8",
-      "resolved": "https://registry.npmjs.org/ignore/-/ignore-5.1.8.tgz",
-      "integrity": "sha512-BMpfD7PpiETpBl/A6S498BaIJ6Y/ABT93ETbby2fP00v4EbvPBXWEoaR1UBPKs3iR53pJY7EtZk5KACI57i1Uw==",
-      "dev": true
-    },
-    "is-binary-path": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/is-binary-path/-/is-binary-path-2.1.0.tgz",
-      "integrity": "sha512-ZMERYes6pDydyuGidse7OsHxtbI7WVeUEozgR/g7rd0xUimYNlvZRE/K2MgZTjWy725IfelLeVcEM97mmtRGXw==",
-      "dev": true,
-      "requires": {
-        "binary-extensions": "^2.0.0"
-      }
-    },
-    "is-extglob": {
-      "version": "2.1.1",
-      "resolved": "https://registry.npmjs.org/is-extglob/-/is-extglob-2.1.1.tgz",
-      "integrity": "sha1-qIwCU1eR8C7TfHahueqXc8gz+MI=",
-      "dev": true
-    },
-    "is-fullwidth-code-point": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/is-fullwidth-code-point/-/is-fullwidth-code-point-3.0.0.tgz",
-      "integrity": "sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==",
-      "dev": true
-    },
-    "is-glob": {
-      "version": "4.0.1",
-      "resolved": "https://registry.npmjs.org/is-glob/-/is-glob-4.0.1.tgz",
-      "integrity": "sha512-5G0tKtBTFImOqDnLB2hG6Bp2qcKEFduo4tZu9MT/H6NQv/ghhy30o55ufafxJ/LdH79LLs2Kfrn85TLKyA7BUg==",
-      "dev": true,
-      "requires": {
-        "is-extglob": "^2.1.1"
-      }
-    },
-    "is-number": {
-      "version": "7.0.0",
-      "resolved": "https://registry.npmjs.org/is-number/-/is-number-7.0.0.tgz",
-      "integrity": "sha512-41Cifkg6e8TylSpdtTpeLVMqvSBEVzTttHvERD741+pnZ8ANv0004MRL43QKPDlK9cGvNp6NZWZUBlbGXYxxng==",
-      "dev": true
-    },
-    "jsonfile": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/jsonfile/-/jsonfile-6.0.1.tgz",
-      "integrity": "sha512-jR2b5v7d2vIOust+w3wtFKZIfpC2pnRmFAhAC/BuweZFQR8qZzxH1OyrQ10HmdVYiXWkYUqPVsz91cG7EL2FBg==",
-      "dev": true,
-      "requires": {
-        "graceful-fs": "^4.1.6",
-        "universalify": "^1.0.0"
-      }
-    },
-    "lilconfig": {
-      "version": "2.0.4",
-      "resolved": "https://registry.npmjs.org/lilconfig/-/lilconfig-2.0.4.tgz",
-      "integrity": "sha512-bfTIN7lEsiooCocSISTWXkiWJkRqtL9wYtYy+8EK3Y41qh3mpwPU0ycTOgjdY9ErwXCc8QyrQp82bdL0Xkm9yA==",
-      "dev": true
-    },
-    "merge2": {
-      "version": "1.4.1",
-      "resolved": "https://registry.npmjs.org/merge2/-/merge2-1.4.1.tgz",
-      "integrity": "sha512-8q7VEgMJW4J8tcfVPy8g09NcQwZdbwFEqhe/WZkoIzjn/3TGDwtOCYtXGxA3O8tPzpczCCDgv+P2P5y00ZJOOg==",
-      "dev": true
-    },
-    "micromatch": {
-      "version": "4.0.2",
-      "resolved": "https://registry.npmjs.org/micromatch/-/micromatch-4.0.2.tgz",
-      "integrity": "sha512-y7FpHSbMUMoyPbYUSzO6PaZ6FyRnQOpHuKwbo1G+Knck95XVU4QAiKdGEnj5wwoS7PlOgthX/09u5iFJ+aYf5Q==",
-      "dev": true,
-      "requires": {
-        "braces": "^3.0.1",
-        "picomatch": "^2.0.5"
-      }
-    },
-    "nanoid": {
-      "version": "3.2.0",
-      "resolved": "https://registry.npmjs.org/nanoid/-/nanoid-3.2.0.tgz",
-      "integrity": "sha512-fmsZYa9lpn69Ad5eDn7FMcnnSR+8R34W9qJEijxYhTbfOWzr22n1QxCMzXLK+ODyW2973V3Fux959iQoUxzUIA==",
-      "dev": true,
-      "peer": true
-    },
-    "node-fetch": {
-      "version": "2.6.7",
-      "resolved": "https://registry.npmjs.org/node-fetch/-/node-fetch-2.6.7.tgz",
-      "integrity": "sha512-ZjMPFEfVx5j+y2yF35Kzx5sF7kDzxuDj6ziH4FFbOp87zKDZNx8yExJIb05OGF4Nlt9IHFIMBkRl41VdvcNdbQ==",
-      "dev": true,
-      "requires": {
-        "whatwg-url": "^5.0.0"
-      }
-    },
-    "node-releases": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/node-releases/-/node-releases-2.0.1.tgz",
-      "integrity": "sha512-CqyzN6z7Q6aMeF/ktcMVTzhAHCEpf8SOarwpzpf8pNBY2k5/oM34UHldUwp8VKI7uxct2HxSRdJjBaZeESzcxA==",
-      "dev": true
-    },
-    "normalize-path": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/normalize-path/-/normalize-path-3.0.0.tgz",
-      "integrity": "sha512-6eZs5Ls3WtCisHWp9S2GUy8dqkpGi4BVSz3GaqiE6ezub0512ESztXUwUB6C6IKbQkY2Pnb/mD4WYojCRwcwLA==",
-      "dev": true
-    },
-    "normalize-range": {
-      "version": "0.1.2",
-      "resolved": "https://registry.npmjs.org/normalize-range/-/normalize-range-0.1.2.tgz",
-      "integrity": "sha1-LRDAa9/TEuqXd2laTShDlFa3WUI=",
-      "dev": true
-    },
-    "path-type": {
-      "version": "4.0.0",
-      "resolved": "https://registry.npmjs.org/path-type/-/path-type-4.0.0.tgz",
-      "integrity": "sha512-gDKb8aZMDeD/tZWs9P6+q0J9Mwkdl6xMV8TjnGP3qJVJ06bdMgkbBlLU8IdfOsIsFz2BW1rNVT3XuNEl8zPAvw==",
-      "dev": true
-    },
-    "picocolors": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/picocolors/-/picocolors-1.0.0.tgz",
-      "integrity": "sha512-1fygroTLlHu66zi26VoTDv8yRgm0Fccecssto+MhsZ0D/DGW2sm8E8AjW7NU5VVTRt5GxbeZ5qBuJr+HyLYkjQ==",
-      "dev": true
-    },
-    "picomatch": {
-      "version": "2.2.2",
-      "resolved": "https://registry.npmjs.org/picomatch/-/picomatch-2.2.2.tgz",
-      "integrity": "sha512-q0M/9eZHzmr0AulXyPwNfZjtwZ/RBZlbN3K3CErVrk50T2ASYI7Bye0EvekFY3IP1Nt2DHu0re+V2ZHIpMkuWg==",
-      "dev": true
-    },
-    "pify": {
-      "version": "2.3.0",
-      "resolved": "https://registry.npmjs.org/pify/-/pify-2.3.0.tgz",
-      "integrity": "sha1-7RQaasBDqEnqWISY59yosVMw6Qw=",
-      "dev": true
-    },
-    "postcss": {
-      "version": "8.4.6",
-      "resolved": "https://registry.npmjs.org/postcss/-/postcss-8.4.6.tgz",
-      "integrity": "sha512-OovjwIzs9Te46vlEx7+uXB0PLijpwjXGKXjVGGPIGubGpq7uh5Xgf6D6FiJ/SzJMBosHDp6a2hiXOS97iBXcaA==",
-      "dev": true,
-      "peer": true,
-      "requires": {
-        "nanoid": "^3.2.0",
-        "picocolors": "^1.0.0",
-        "source-map-js": "^1.0.2"
-      }
-    },
-    "postcss-cli": {
-      "version": "8.3.1",
-      "resolved": "https://registry.npmjs.org/postcss-cli/-/postcss-cli-8.3.1.tgz",
-      "integrity": "sha512-leHXsQRq89S3JC9zw/tKyiVV2jAhnfQe0J8VI4eQQbUjwIe0XxVqLrR+7UsahF1s9wi4GlqP6SJ8ydf44cgF2Q==",
-      "dev": true,
-      "requires": {
-        "chalk": "^4.0.0",
-        "chokidar": "^3.3.0",
-        "dependency-graph": "^0.9.0",
-        "fs-extra": "^9.0.0",
-        "get-stdin": "^8.0.0",
-        "globby": "^11.0.0",
-        "postcss-load-config": "^3.0.0",
-        "postcss-reporter": "^7.0.0",
-        "pretty-hrtime": "^1.0.3",
-        "read-cache": "^1.0.0",
-        "slash": "^3.0.0",
-        "yargs": "^16.0.0"
-      },
-      "dependencies": {
-        "chalk": {
-          "version": "4.1.0",
-          "resolved": "https://registry.npmjs.org/chalk/-/chalk-4.1.0.tgz",
-          "integrity": "sha512-qwx12AxXe2Q5xQ43Ac//I6v5aXTipYrSESdOgzrN+9XjgEpyjpKuvSGaN4qE93f7TQTlerQQ8S+EQ0EyDoVL1A==",
-          "dev": true,
-          "requires": {
-            "ansi-styles": "^4.1.0",
-            "supports-color": "^7.1.0"
-          }
-        },
-        "has-flag": {
-          "version": "4.0.0",
-          "resolved": "https://registry.npmjs.org/has-flag/-/has-flag-4.0.0.tgz",
-          "integrity": "sha512-EykJT/Q1KjTWctppgIAgfSO0tKVuZUjhgMr17kqTumMl6Afv3EISleU7qZUzoXDFTAHTDC4NOoG/ZxU3EvlMPQ==",
-          "dev": true
-        },
-        "supports-color": {
-          "version": "7.2.0",
-          "resolved": "https://registry.npmjs.org/supports-color/-/supports-color-7.2.0.tgz",
-          "integrity": "sha512-qpCAvRl9stuOHveKsn7HncJRvv501qIacKzQlO/+Lwxc9+0q2wLyv4Dfvt80/DPn2pqOBsJdDiogXGR9+OvwRw==",
-          "dev": true,
-          "requires": {
-            "has-flag": "^4.0.0"
-          }
-        }
-      }
-    },
-    "postcss-load-config": {
-      "version": "3.1.1",
-      "resolved": "https://registry.npmjs.org/postcss-load-config/-/postcss-load-config-3.1.1.tgz",
-      "integrity": "sha512-c/9XYboIbSEUZpiD1UQD0IKiUe8n9WHYV7YFe7X7J+ZwCsEKkUJSFWjS9hBU1RR9THR7jMXst8sxiqP0jjo2mg==",
-      "dev": true,
-      "requires": {
-        "lilconfig": "^2.0.4",
-        "yaml": "^1.10.2"
-      }
-    },
-    "postcss-reporter": {
-      "version": "7.0.5",
-      "resolved": "https://registry.npmjs.org/postcss-reporter/-/postcss-reporter-7.0.5.tgz",
-      "integrity": "sha512-glWg7VZBilooZGOFPhN9msJ3FQs19Hie7l5a/eE6WglzYqVeH3ong3ShFcp9kDWJT1g2Y/wd59cocf9XxBtkWA==",
-      "dev": true,
-      "requires": {
-        "picocolors": "^1.0.0",
-        "thenby": "^1.3.4"
-      }
-    },
-    "postcss-value-parser": {
-      "version": "4.2.0",
-      "resolved": "https://registry.npmjs.org/postcss-value-parser/-/postcss-value-parser-4.2.0.tgz",
-      "integrity": "sha512-1NNCs6uurfkVbeXG4S8JFT9t19m45ICnif8zWLd5oPSZ50QnwMfK+H3jv408d4jw/7Bttv5axS5IiHoLaVNHeQ==",
-      "dev": true
-    },
-    "pretty-hrtime": {
-      "version": "1.0.3",
-      "resolved": "https://registry.npmjs.org/pretty-hrtime/-/pretty-hrtime-1.0.3.tgz",
-      "integrity": "sha1-t+PqQkNaTJsnWdmeDyAesZWALuE=",
-      "dev": true
-    },
-    "read-cache": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/read-cache/-/read-cache-1.0.0.tgz",
-      "integrity": "sha1-5mTvMRYRZsl1HNvo28+GtftY93Q=",
-      "dev": true,
-      "requires": {
-        "pify": "^2.3.0"
-      }
-    },
-    "readdirp": {
-      "version": "3.4.0",
-      "resolved": "https://registry.npmjs.org/readdirp/-/readdirp-3.4.0.tgz",
-      "integrity": "sha512-0xe001vZBnJEK+uKcj8qOhyAKPzIT+gStxWr3LCB0DwcXR5NZJ3IaC+yGnHCYzB/S7ov3m3EEbZI2zeNvX+hGQ==",
-      "dev": true,
-      "requires": {
-        "picomatch": "^2.2.1"
-      }
-    },
-    "require-directory": {
-      "version": "2.1.1",
-      "resolved": "https://registry.npmjs.org/require-directory/-/require-directory-2.1.1.tgz",
-      "integrity": "sha1-jGStX9MNqxyXbiNE/+f3kqam30I=",
-      "dev": true
-    },
-    "reusify": {
-      "version": "1.0.4",
-      "resolved": "https://registry.npmjs.org/reusify/-/reusify-1.0.4.tgz",
-      "integrity": "sha512-U9nH88a3fc/ekCF1l0/UP1IosiuIjyTh7hBvXVMHYgVcfGvt897Xguj2UOLDeI5BG2m7/uwyaLVT6fbtCwTyzw==",
-      "dev": true
-    },
-    "run-parallel": {
-      "version": "1.1.9",
-      "resolved": "https://registry.npmjs.org/run-parallel/-/run-parallel-1.1.9.tgz",
-      "integrity": "sha512-DEqnSRTDw/Tc3FXf49zedI638Z9onwUotBMiUFKmrO2sdFKIbXamXGQ3Axd4qgphxKB4kw/qP1w5kTxnfU1B9Q==",
-      "dev": true
-    },
-    "slash": {
-      "version": "3.0.0",
-      "resolved": "https://registry.npmjs.org/slash/-/slash-3.0.0.tgz",
-      "integrity": "sha512-g9Q1haeby36OSStwb4ntCGGGaKsaVSjQ68fBxoQcutl5fS1vuY18H3wSt3jFyFtrkx+Kz0V1G85A4MyAdDMi2Q==",
-      "dev": true
-    },
-    "source-map-js": {
-      "version": "1.0.2",
-      "resolved": "https://registry.npmjs.org/source-map-js/-/source-map-js-1.0.2.tgz",
-      "integrity": "sha512-R0XvVJ9WusLiqTCEiGCmICCMplcCkIwwR11mOSD9CR5u+IXYdiseeEuXCVAjS54zqwkLcPNnmU4OeJ6tUrWhDw==",
-      "dev": true,
-      "peer": true
-    },
-    "string-width": {
-      "version": "4.2.3",
-      "resolved": "https://registry.npmjs.org/string-width/-/string-width-4.2.3.tgz",
-      "integrity": "sha512-wKyQRQpjJ0sIp62ErSZdGsjMJWsap5oRNihHhu6G7JVO/9jIB6UyevL+tXuOqrng8j/cxKTWyWUwvSTriiZz/g==",
-      "dev": true,
-      "requires": {
-        "emoji-regex": "^8.0.0",
-        "is-fullwidth-code-point": "^3.0.0",
-        "strip-ansi": "^6.0.1"
-      }
-    },
-    "strip-ansi": {
-      "version": "6.0.1",
-      "resolved": "https://registry.npmjs.org/strip-ansi/-/strip-ansi-6.0.1.tgz",
-      "integrity": "sha512-Y38VPSHcqkFrCpFnQ9vuSXmquuv5oXOKpGeT6aGrr3o3Gc9AlVa6JBfUSOCnbxGGZF+/0ooI7KrPuUSztUdU5A==",
-      "dev": true,
-      "requires": {
-        "ansi-regex": "^5.0.1"
-      }
-    },
-    "thenby": {
-      "version": "1.3.4",
-      "resolved": "https://registry.npmjs.org/thenby/-/thenby-1.3.4.tgz",
-      "integrity": "sha512-89Gi5raiWA3QZ4b2ePcEwswC3me9JIg+ToSgtE0JWeCynLnLxNr/f9G+xfo9K+Oj4AFdom8YNJjibIARTJmapQ==",
-      "dev": true
-    },
-    "to-regex-range": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/to-regex-range/-/to-regex-range-5.0.1.tgz",
-      "integrity": "sha512-65P7iz6X5yEr1cwcgvQxbbIw7Uk3gOy5dIdtZ4rDveLqhrdJP+Li/Hx6tyK0NEb+2GCyneCMJiGqrADCSNk8sQ==",
-      "dev": true,
-      "requires": {
-        "is-number": "^7.0.0"
-      }
-    },
-    "tr46": {
-      "version": "0.0.3",
-      "resolved": "https://registry.npmjs.org/tr46/-/tr46-0.0.3.tgz",
-      "integrity": "sha1-gYT9NH2snNwYWZLzpmIuFLnZq2o=",
-      "dev": true
-    },
-    "universalify": {
-      "version": "1.0.0",
-      "resolved": "https://registry.npmjs.org/universalify/-/universalify-1.0.0.tgz",
-      "integrity": "sha512-rb6X1W158d7pRQBg5gkR8uPaSfiids68LTJQYOtEUhoJUWBdaQHsuT/EUduxXYxcrt4r5PJ4fuHW1MHT6p0qug==",
-      "dev": true
-    },
-    "webidl-conversions": {
-      "version": "3.0.1",
-      "resolved": "https://registry.npmjs.org/webidl-conversions/-/webidl-conversions-3.0.1.tgz",
-      "integrity": "sha1-JFNCdeKnvGvnvIZhHMFq4KVlSHE=",
-      "dev": true
-    },
-    "whatwg-url": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/whatwg-url/-/whatwg-url-5.0.0.tgz",
-      "integrity": "sha1-lmRU6HZUYuN2RNNib2dCzotwll0=",
-      "dev": true,
-      "requires": {
-        "tr46": "~0.0.3",
-        "webidl-conversions": "^3.0.0"
-      }
-    },
-    "wrap-ansi": {
-      "version": "7.0.0",
-      "resolved": "https://registry.npmjs.org/wrap-ansi/-/wrap-ansi-7.0.0.tgz",
-      "integrity": "sha512-YVGIj2kamLSTxw6NsZjoBxfSwsn0ycdesmc4p+Q21c5zPuZ1pl+NfxVdxPtdHvmNVOQ6XSYG4AUtyt/Fi7D16Q==",
-      "dev": true,
-      "requires": {
-        "ansi-styles": "^4.0.0",
-        "string-width": "^4.1.0",
-        "strip-ansi": "^6.0.0"
-      }
-    },
-    "y18n": {
-      "version": "5.0.8",
-      "resolved": "https://registry.npmjs.org/y18n/-/y18n-5.0.8.tgz",
-      "integrity": "sha512-0pfFzegeDWJHJIAmTLRP2DwHjdF5s7jo9tuztdQxAhINCdvS+3nGINqPd00AphqJR/0LhANUS6/+7SCb98YOfA==",
-      "dev": true
-    },
-    "yaml": {
-      "version": "1.10.2",
-      "resolved": "https://registry.npmjs.org/yaml/-/yaml-1.10.2.tgz",
-      "integrity": "sha512-r3vXyErRCYJ7wg28yvBY5VSoAF8ZvlcW9/BwUzEtUsjvX/DKs24dIkuwjtuprwJJHsbyUbLApepYTR1BN4uHrg==",
-      "dev": true
-    },
-    "yargs": {
-      "version": "16.2.0",
-      "resolved": "https://registry.npmjs.org/yargs/-/yargs-16.2.0.tgz",
-      "integrity": "sha512-D1mvvtDG0L5ft/jGWkLpG1+m0eQxOfaBvTNELraWj22wSVUMWxZUvYgJYcKh6jGGIkJFhH4IZPQhR4TKpc8mBw==",
-      "dev": true,
-      "requires": {
-        "cliui": "^7.0.2",
-        "escalade": "^3.1.1",
-        "get-caller-file": "^2.0.5",
-        "require-directory": "^2.1.1",
-        "string-width": "^4.2.0",
-        "y18n": "^5.0.5",
-        "yargs-parser": "^20.2.2"
-      }
-    },
-    "yargs-parser": {
-      "version": "20.2.9",
-      "resolved": "https://registry.npmjs.org/yargs-parser/-/yargs-parser-20.2.9.tgz",
-      "integrity": "sha512-y11nGElTIV+CT3Zv9t7VKl+Q3hTQoT9a1Qzezhhl6Rp21gJ/IVTW7Z3y9EWXhuUBC2Shnf+DX0antecpAwSP8w==",
-      "dev": true
-    }
-  }
-}
diff --git a/package.json b/package.json
deleted file mode 100644
index 892adea4..00000000
--- a/package.json
+++ /dev/null
@@ -1,27 +0,0 @@
-{
-  "name": "matrix-spec",
-  "version": "0.0.1",
-  "description": "Hugo theme for the Matrix specification.",
-  "main": "none.js",
-  "scripts": {
-    "get-proposals": "node ./scripts/proposals.js",
-    "test": "echo \"Error: no test specified\" && exit 1"
-  },
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/matrix-org/matrix-doc.git"
-  },
-  "author": "The Matrix.org Foundation C.I.C.",
-  "private": true,
-  "license": "Apache-2.0",
-  "bugs": {
-    "url": "https://github.com/matrix-org/matrix-doc"
-  },
-  "homepage": "https://github.com/matrix-org/matrix-doc#readme",
-  "devDependencies": {
-    "autoprefixer": "^10.4.2",
-    "node-fetch": "^2.6.7",
-    "postcss-cli": "^9.1.0",
-    "postcss": "^8.4.6"
-  }
-}
diff --git a/scripts/check-event-schema-examples.py b/scripts/check-event-schema-examples.py
deleted file mode 100755
index e5261c87..00000000
--- a/scripts/check-event-schema-examples.py
+++ /dev/null
@@ -1,146 +0,0 @@
-#!/usr/bin/env python
-#
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-
-import sys
-import json
-import os
-import traceback
-
-
-def import_error(module, package, debian, error):
-    sys.stderr.write((
-        "Error importing %(module)s: %(error)r\n"
-        "To install %(module)s run:\n"
-        "  pip install %(package)s\n"
-        "or on Debian run:\n"
-        "  sudo apt-get install python-%(debian)s\n"
-    ) % locals())
-    if __name__ == '__main__':
-        sys.exit(1)
-
-try:
-    import jsonschema
-except ImportError as e:
-    import_error("jsonschema", "jsonschema", "jsonschema", e)
-    raise
-
-try:
-    import yaml
-except ImportError as e:
-    import_error("yaml", "PyYAML", "yaml", e)
-    raise
-
-
-def load_file(path):
-    print("Loading reference: %s" % path)
-    if not path.startswith("file://"):
-        raise Exception("Bad ref: %s" % (path,))
-    path = path[len("file://"):]
-    with open(path, "r") as f:
-        if path.endswith(".json"):
-            return json.load(f)
-        else:
-            # We have to assume it's YAML because some of the YAML examples
-            # do not have file extensions.
-            return yaml.safe_load(f)
-
-
-def resolve_references(path, schema):
-    if isinstance(schema, dict):
-        # do $ref first
-        if '$ref' in schema:
-            value = schema['$ref']
-            path = os.path.abspath(os.path.join(os.path.dirname(path), value))
-            ref = load_file("file://" + path)
-            result = resolve_references(path, ref)
-            del schema['$ref']
-        else:
-            result = {}
-
-        for key, value in schema.items():
-            result[key] = resolve_references(path, value)
-        return result
-    elif isinstance(schema, list):
-        return [resolve_references(path, value) for value in schema]
-    else:
-        return schema
-
-
-def check_example_file(examplepath, schemapath):
-    with open(examplepath) as f:
-        example = resolve_references(examplepath, json.load(f))
-
-    with open(schemapath) as f:
-        schema = yaml.safe_load(f)
-
-    fileurl = "file://" + os.path.abspath(schemapath)
-    schema["id"] = fileurl
-    resolver = jsonschema.RefResolver(schemapath, schema, handlers={"file": load_file})
-
-    print ("Checking schema for: %r %r" % (examplepath, schemapath))
-    try:
-        jsonschema.validate(example, schema, resolver=resolver)
-    except Exception as e:
-        raise ValueError("Error validating JSON schema for %r %r" % (
-            examplepath, schemapath
-        ), e)
-
-
-def check_example_dir(exampledir, schemadir):
-    errors = []
-    for root, dirs, files in os.walk(exampledir):
-        for filename in files:
-            if filename.startswith("."):
-                # Skip over any vim .swp files.
-                continue
-            if filename.endswith(".json"):
-                # Skip over any explicit examples (partial event definitions)
-                continue
-            cwd = os.path.basename(os.path.dirname(os.path.join(root, filename)))
-            if cwd == "core":
-                # Skip checking the underlying definitions
-                continue
-            examplepath = os.path.join(root, filename)
-            schemapath = examplepath.replace(exampledir, schemadir)
-            if schemapath.find("$") >= 0:
-                schemapath = schemapath[:schemapath.find("$")]
-            # Automatically correct for file extension being stripped off
-            if not schemapath.endswith(".yaml"):
-                schemapath += ".yaml"
-            if not examplepath.endswith(".yaml"):
-                examplepath += ".yaml"
-            try:
-                check_example_file(examplepath, schemapath)
-            except Exception as e:
-                errors.append(sys.exc_info())
-    for (exc_type, exc_value, exc_trace) in errors:
-        traceback.print_exception(exc_type, exc_value, exc_trace)
-    if errors:
-        raise ValueError("Error validating examples")
-
-
-if __name__ == '__main__':
-    # Get the directory that this script is residing in
-    script_directory = os.path.dirname(os.path.realpath(__file__))
-
-    # Resolve the directories to check, relative to the script path
-    examples_directory = os.path.join(script_directory, "../data/event-schemas/examples")
-    schema_directory = os.path.join(script_directory, "../data/event-schemas/schema")
-
-    try:
-        check_example_dir(examples_directory, schema_directory)
-    except:
-        sys.exit(1)
diff --git a/scripts/check-swagger-sources.py b/scripts/check-swagger-sources.py
deleted file mode 100755
index 39e27f24..00000000
--- a/scripts/check-swagger-sources.py
+++ /dev/null
@@ -1,187 +0,0 @@
-#! /usr/bin/env python
-#
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-
-import sys
-import json
-import os
-
-
-def import_error(module, package, debian, error):
-    sys.stderr.write((
-        "Error importing %(module)s: %(error)r\n"
-        "To install %(module)s run:\n"
-        "  pip install %(package)s\n"
-        "or on Debian run:\n"
-        "  sudo apt-get install python-%(debian)s\n"
-    ) % locals())
-    if __name__ == '__main__':
-        sys.exit(1)
-
-try:
-    import jsonschema
-except ImportError as e:
-    import_error("jsonschema", "jsonschema", "jsonschema", e)
-    raise
-
-try:
-    import yaml
-except ImportError as e:
-    import_error("yaml", "PyYAML", "yaml", e)
-    raise
-
-
-def check_schema(filepath, example, schema):
-    example = resolve_references(filepath, example)
-    schema = resolve_references(filepath, schema)
-    resolver = jsonschema.RefResolver(filepath, schema, handlers={"file": load_file})
-    jsonschema.validate(example, schema, resolver=resolver)
-
-
-def check_parameter(filepath, request, parameter):
-    schema = parameter.get("schema")
-    example = schema.get('example')
-
-    if example and schema:
-        try:
-            print("Checking request schema for: %r %r" % (
-                filepath, request
-            ))
-            check_schema(filepath, example, schema)
-        except Exception as e:
-            raise ValueError("Error validating JSON schema for %r" % (
-                request
-            ), e)
-
-
-def check_response(filepath, request, code, response):
-    example = response.get('examples', {}).get('application/json')
-    schema = response.get('schema')
-    if example and schema:
-        try:
-            print ("Checking response schema for: %r %r %r" % (
-                filepath, request, code
-            ))
-            check_schema(filepath, example, schema)
-        except jsonschema.SchemaError as error:
-            for suberror in sorted(error.context, key=lambda e: e.schema_path):
-                print(list(suberror.schema_path), suberror.message, sep=", ")
-            raise ValueError("Error validating JSON schema for %r %r" % (
-                request, code
-            ), e)
-        except Exception as e:
-            raise ValueError("Error validating JSON schema for %r %r" % (
-                request, code
-            ), e)
-
-
-def check_swagger_file(filepath):
-    with open(filepath) as f:
-        swagger = yaml.safe_load(f)
-
-    for path, path_api in swagger.get('paths', {}).items():
-
-        for method, request_api in path_api.items():
-            request = "%s %s" % (method.upper(), path)
-            for parameter in request_api.get('parameters', ()):
-                if parameter['in'] == 'body':
-                    check_parameter(filepath, request, parameter)
-
-            try:
-                responses = request_api['responses']
-            except KeyError:
-                raise ValueError("No responses for %r" % (request,))
-            for code, response in responses.items():
-                check_response(filepath, request, code, response)
-
-
-def resolve_references(path, schema):
-    """Recurse through a given schema until we find a $ref key. Upon doing so,
-    check that the referenced file exists, then load it up and check all of the
-    references in that file. Continue on until we've hit all dead ends.
-
-    $ref values are deleted from schemas as they are validated, to prevent
-    duplicate work.
-    """
-    if isinstance(schema, dict):
-        # do $ref first
-        if '$ref' in schema:
-            # Pull the referenced filepath from the schema
-            referenced_file = schema['$ref']
-
-            # Referenced filepaths are relative, so take the current path's
-            # directory and append the relative, referenced path to it.
-            inner_path = os.path.join(os.path.dirname(path), referenced_file)
-
-            # Then convert the path (which may contiain '../') into a
-            # normalised, absolute path
-            inner_path = os.path.abspath(inner_path)
-
-            # Load the referenced file
-            ref = load_file("file://" + inner_path)
-
-            # Check that the references in *this* file are valid
-            result = resolve_references(inner_path, ref)
-
-            # They were valid, and so were the sub-references. Delete
-            # the reference here to ensure we don't pass over it again
-            # when checking other files
-            del schema['$ref']
-        else:
-            result = {}
-
-        for key, value in schema.items():
-            result[key] = resolve_references(path, value)
-        return result
-    elif isinstance(schema, list):
-        return [resolve_references(path, value) for value in schema]
-    else:
-        return schema
-
-
-def load_file(path):
-    print("Loading reference: %s" % path)
-    if not path.startswith("file://"):
-        raise Exception("Bad ref: %s" % (path,))
-    path = path[len("file://"):]
-    with open(path, "r") as f:
-        if path.endswith(".json"):
-            return json.load(f)
-        else:
-            # We have to assume it's YAML because some of the YAML examples
-            # do not have file extensions.
-            return yaml.safe_load(f)
-
-
-if __name__ == '__main__':
-    # Get the directory that this script is residing in
-    script_directory = os.path.dirname(os.path.realpath(__file__))
-
-    # Resolve the directory containing the swagger sources,
-    # relative to the script path
-    source_files_directory = os.path.realpath(os.path.join(script_directory, "../data"))
-
-    # Walk the source path directory, looking for YAML files to check
-    for (root, dirs, files) in os.walk(source_files_directory):
-        for filename in files:
-            if not filename.endswith(".yaml"):
-                continue
-
-            path = os.path.join(root, filename)
-
-            try:
-                check_swagger_file(path)
-            except Exception as e:
-                raise ValueError("Error checking file %s" % (path,), e)
diff --git a/scripts/css/basic.css b/scripts/css/basic.css
deleted file mode 100644
index fdf2980d..00000000
--- a/scripts/css/basic.css
+++ /dev/null
@@ -1,572 +0,0 @@
-/*
- * basic.css
- * ~~~~~~~~~
- *
- * Sphinx stylesheet -- basic theme.
- *
- * :copyright: Copyright 2007-2010 by the Sphinx team, see AUTHORS.
- * :license: BSD, see LICENSE for details.
- *
- */
-
-/* -- main layout ----------------------------------------------------------- */
-
-div.clearer {
-    clear: both;
-}
-
-/* -- relbar ---------------------------------------------------------------- */
-
-div.related {
-    width: 100%;
-    font-size: 90%;
-}
-
-div.related h3 {
-    display: none;
-}
-
-div.related ul {
-    margin: 0;
-    padding: 0 0 0 10px;
-    list-style: none;
-}
-
-div.related li {
-    display: inline;
-}
-
-div.related li.right {
-    float: right;
-    margin-right: 5px;
-}
-
-/* -- sidebar --------------------------------------------------------------- */
-
-div.sphinxsidebarwrapper {
-    padding: 10px 5px 0 10px;
-}
-
-div.sphinxsidebar {
-    float: left;
-    width: 230px;
-    margin-left: -100%;
-    font-size: 90%;
-}
-
-div.sphinxsidebar ul {
-    list-style: none;
-}
-
-div.sphinxsidebar ul ul,
-div.sphinxsidebar ul.want-points {
-    margin-left: 20px;
-    list-style: square;
-}
-
-div.sphinxsidebar ul ul {
-    margin-top: 0;
-    margin-bottom: 0;
-}
-
-div.sphinxsidebar form {
-    margin-top: 10px;
-}
-
-div.sphinxsidebar input {
-    border: 1px solid #98dbcc;
-    font-family: sans-serif;
-    font-size: 1em;
-}
-
-img {
-    border: 0;
-}
-
-/* -- search page ----------------------------------------------------------- */
-
-ul.search {
-    margin: 10px 0 0 20px;
-    padding: 0;
-}
-
-ul.search li {
-    padding: 5px 0 5px 20px;
-    background-image: url(file.png);
-    background-repeat: no-repeat;
-    background-position: 0 7px;
-}
-
-ul.search li a {
-    font-weight: bold;
-}
-
-ul.search li div.context {
-    color: #888;
-    margin: 2px 0 0 30px;
-    text-align: left;
-}
-
-ul.keywordmatches li.goodmatch a {
-    font-weight: bold;
-}
-
-/* -- index page ------------------------------------------------------------ */
-
-table.contentstable {
-    width: 90%;
-}
-
-table.contentstable p.biglink {
-    line-height: 150%;
-}
-
-a.biglink {
-    font-size: 1.3em;
-}
-
-span.linkdescr {
-    font-style: italic;
-    padding-top: 5px;
-    font-size: 90%;
-}
-
-/* -- general index --------------------------------------------------------- */
-
-table.indextable {
-    width: 100%;
-}
-
-table.indextable td {
-    text-align: left;
-    vertical-align: top;
-}
-
-table.indextable dl, table.indextable dd {
-    margin-top: 0;
-    margin-bottom: 0;
-}
-
-table.indextable tr.pcap {
-    height: 10px;
-}
-
-table.indextable tr.cap {
-    margin-top: 10px;
-    background-color: #f2f2f2;
-}
-
-img.toggler {
-    margin-right: 3px;
-    margin-top: 3px;
-    cursor: pointer;
-}
-
-div.modindex-jumpbox {
-    border-top: 1px solid #ddd;
-    border-bottom: 1px solid #ddd;
-    margin: 1em 0 1em 0;
-    padding: 0.4em;
-}
-
-div.genindex-jumpbox {
-    border-top: 1px solid #ddd;
-    border-bottom: 1px solid #ddd;
-    margin: 1em 0 1em 0;
-    padding: 0.4em;
-}
-
-/* -- general body styles --------------------------------------------------- */
-
-a.headerlink {
-    visibility: hidden;
-}
-
-h1:hover > a.headerlink,
-h2:hover > a.headerlink,
-h3:hover > a.headerlink,
-h4:hover > a.headerlink,
-h5:hover > a.headerlink,
-h6:hover > a.headerlink,
-dt:hover > a.headerlink {
-    visibility: visible;
-}
-
-div.document p.caption {
-    text-align: inherit;
-}
-
-div.document td {
-    text-align: left;
-}
-
-.field-list ul {
-    padding-left: 1em;
-}
-
-.first {
-    margin-top: 0 !important;
-}
-
-p.rubric {
-    margin-top: 30px;
-    font-weight: bold;
-}
-
-.align-left {
-    text-align: left;
-}
-
-.align-center {
-    clear: both;
-    text-align: center;
-}
-
-.align-right {
-    text-align: right;
-}
-
-/* -- sidebars -------------------------------------------------------------- */
-
-div.sidebar {
-    margin: 0 0 0.5em 1em;
-    border: 1px solid #ddb;
-    padding: 7px 7px 0 7px;
-    background-color: #ffe;
-    width: 40%;
-    float: right;
-}
-
-p.sidebar-title {
-    font-weight: bold;
-}
-
-/* -- topics ---------------------------------------------------------------- */
-
-div.topic {
-    border: 1px solid #ccc;
-    padding: 7px 7px 0 7px;
-    margin: 10px 0 10px 0;
-}
-
-p.topic-title {
-    font-size: 1.1em;
-    font-weight: bold;
-    margin-top: 10px;
-}
-
-/* -- admonitions ----------------------------------------------------------- */
-
-div.admonition {
-    margin-top: 10px;
-    margin-bottom: 10px;
-    padding: 7px;
-}
-
-div.admonition dt {
-    font-weight: bold;
-}
-
-div.admonition dl {
-    margin-bottom: 0;
-}
-
-p.admonition-title {
-    margin: 0px 10px 5px 0px;
-    font-weight: bold;
-}
-
-div.document p.centered {
-    text-align: center;
-    margin-top: 25px;
-}
-
-/* -- tables ---------------------------------------------------------------- */
-
-table.docutils {
-    border: 0;
-    border-collapse: collapse;
-}
-
-table.docutils td, table.docutils th {
-    padding: 1px 8px 1px 5px;
-    border-top: 0;
-    border-left: 0;
-    border-right: 0;
-    border-bottom: 1px solid #aaa;
-}
-
-table.field-list td, table.field-list th {
-    border: 0 !important;
-}
-
-table.footnote td, table.footnote th {
-    border: 0 !important;
-}
-
-th {
-    text-align: left;
-    padding-right: 5px;
-}
-
-table.citation {
-    border-left: solid 1px gray;
-    margin-left: 1px;
-}
-
-table.citation td {
-    border-bottom: none;
-}
-
-table.colwidths-auto caption {
-    font-family: 'Inconsolata', monospace;
-    font-weight: 800;
-    font-size: 120%;
-    padding: 5px;
-    text-align: left;
-    margin-bottom: 2px;
-}
-
-.section ol, .section li {
-    margin: 0px 0px 0px 30px !important;
-}
-
-p.httpheaders {
-    font-weight: 800;
-    font-size: 120%;
-    padding: 5px;
-    text-align: left;
-    margin-bottom: 2px;
-}
-
-table.colwidths-auto {
-    width:100%;
-    margin-top: 20px;
-}
-
-table.colwidths-auto tr td:nth-child(1) {
-    width: 15%;
-}
-
-table.colwidths-auto tr td:nth-child(2) {
-    width: 15%;
-    font-family: 'Inconsolata', monospace;
-}
-
-table.colwidths-auto tr td:nth-child(3) {
-    width: 70%;
-}
-
-
-/* -- other body styles ----------------------------------------------------- */
-
-ol.arabic {
-    list-style: decimal;
-}
-
-ol.loweralpha {
-    list-style: lower-alpha;
-}
-
-ol.upperalpha {
-    list-style: upper-alpha;
-}
-
-ol.lowerroman {
-    list-style: lower-roman;
-}
-
-ol.upperroman {
-    list-style: upper-roman;
-}
-
-dl {
-    margin-bottom: 15px;
-}
-
-dd p {
-    margin-top: 0px;
-}
-
-dd ul, dd table {
-    margin-bottom: 10px;
-}
-
-dd {
-    margin-top: 3px;
-    margin-bottom: 10px;
-    margin-left: 30px;
-}
-
-dt:target, .highlighted {
-    background-color: #fbe54e;
-}
-
-dl.glossary dt {
-    font-weight: bold;
-    font-size: 1.1em;
-}
-
-.field-list ul {
-    margin: 0;
-    padding-left: 1em;
-}
-
-.field-list p {
-    margin: 0;
-}
-
-.refcount {
-    color: #060;
-}
-
-.optional {
-    font-size: 1.3em;
-}
-
-.versionmodified {
-    font-style: italic;
-}
-
-.system-message {
-    background-color: #fda;
-    padding: 5px;
-    border: 3px solid red;
-}
-
-.footnote:target  {
-    background-color: #ffa
-}
-
-.line-block {
-    display: block;
-    margin-top: 1em;
-    margin-bottom: 1em;
-}
-
-.line-block .line-block {
-    margin-top: 0;
-    margin-bottom: 0;
-    margin-left: 1.5em;
-}
-
-.guilabel, .menuselection {
-    font-family: sans-serif;
-}
-
-.accelerator {
-    text-decoration: underline;
-}
-
-.classifier {
-    font-style: oblique;
-}
-
-/* -- proposals page -------------------------------------------------------- */
-
-#tables-of-tracked-proposals h2 {
-    padding-left: 10px;
-    position: -webkit-sticky;
-    position: sticky;
-}
-
-/* Move sticky headers below header bar on desktop */
-@media all and (min-width:980px) {
-    #tables-of-tracked-proposals h2 {
-        top: 52px;
-    }
-}
-
-/* Sticky headers stick to the top on mobile */
-@media all and (min-width:0px) and (max-width: 980px) {
-    #tables-of-tracked-proposals h2 {
-        top: 0px;
-    }
-}
-
-/* -- code displays --------------------------------------------------------- */
-
-pre {
-    overflow: auto;
-}
-
-td.linenos pre {
-    padding: 5px 0px;
-    border: 0;
-    background-color: transparent;
-    color: #aaa;
-}
-
-table.highlighttable {
-    margin-left: 0.5em;
-}
-
-table.highlighttable td {
-    padding: 0 0.5em 0 0.5em;
-}
-
-tt.descname {
-    background-color: transparent;
-    font-weight: bold;
-    font-size: 1.2em;
-}
-
-tt.descclassname {
-    background-color: transparent;
-}
-
-tt.xref, a tt {
-    background-color: transparent;
-    font-weight: bold;
-}
-
-h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
-    background-color: transparent;
-}
-
-.viewcode-link {
-    float: right;
-}
-
-.viewcode-back {
-    float: right;
-    font-family: sans-serif;
-}
-
-div.viewcode-block:target {
-    margin: -1px -10px;
-    padding: 0 10px;
-}
-
-/* -- math display ---------------------------------------------------------- */
-
-img.math {
-    vertical-align: middle;
-}
-
-div.document div.math p {
-    text-align: center;
-}
-
-span.eqno {
-    float: right;
-}
-
-/* -- printout stylesheet --------------------------------------------------- */
-
-@media print {
-    div.document,
-    div.documentwrapper,
-    div.bodywrapper {
-        margin: 0 !important;
-        width: 100%;
-    }
-
-    div.sphinxsidebar,
-    div.related,
-    div.footer,
-    #top-link {
-        display: none;
-    }
-}
-
diff --git a/scripts/css/blockquote.css b/scripts/css/blockquote.css
deleted file mode 100644
index 05fa73bc..00000000
--- a/scripts/css/blockquote.css
+++ /dev/null
@@ -1,4 +0,0 @@
-blockquote {
-    margin: 20px 0 30px;
-    padding-left: 20px;
-}
diff --git a/scripts/css/codehighlight.css b/scripts/css/codehighlight.css
deleted file mode 100644
index fafc43f4..00000000
--- a/scripts/css/codehighlight.css
+++ /dev/null
@@ -1,16 +0,0 @@
-pre.code .comment, code .comment { color: green }
-pre.code .keyword, code .keyword { color: darkred; font-weight: bold }
-pre.code .name.builtin, code .name.builtin { color: darkred; font-weight: bold }
-pre.code .name.tag, code .name.tag { color: darkgreen }
-pre.code .literal, code .literal { color: darkblue }
-pre.code .literal.number, code .literal.number { color: blue }
-
-
-/* HTTP Methods have class "name function" */
-pre.code.http .name.function,  code.http .name.function { color: black; font-weight: bold }
-/* HTTP Paths have class "name namespace" */
-pre.code.http .name.namespace, code.http .name.namespace { color: darkgreen }
-/* HTTP "HTTP" strings have class "keyword reserved" */
-pre.code.http .keyword.reserved, code.http .keyword.reserved { color: black; font-weight: bold }
-/* HTTP Header names have class "name attribute" */
-pre.code.http .name.attribute, code.http .name.attribute { color: black; font-weight: bold }
diff --git a/scripts/css/nature.css b/scripts/css/nature.css
deleted file mode 100644
index 69169129..00000000
--- a/scripts/css/nature.css
+++ /dev/null
@@ -1,295 +0,0 @@
-/*
- * nature.css_t
- * ~~~~~~~~~~~~
- *
- * Sphinx stylesheet -- nature theme.
- *
- * :copyright: Copyright 2007-2010 by the Sphinx team, see AUTHORS.
- * :license: BSD, see LICENSE for details.
- *
- */
- 
-/* -- page layout ----------------------------------------------------------- */
- 
-body {
-    font-family: Arial, sans-serif;
-    font-size: 100%;
-    /*background-color: #111;*/
-    color: #555;
-    margin: 0;
-    padding: 0;
-}
-
-div.documentwrapper {
-    float: left;
-    width: 100%;
-}
-
-div.bodywrapper {
-    margin: 0 0 0 230px;
-}
-
-hr {
-    border: 1px solid #B1B4B6;
-}
- 
-/*
-div.document {
-    background-color: #eee;
-}
-*/
- 
-div.document {
-    background-color: #ffffff;
-    color: #3E4349;
-    padding: 0 30px 30px 30px;
-    font-size: 0.9em;
-}
- 
-div.footer {
-    color: #555;
-    width: 100%;
-    padding: 13px 0;
-    text-align: center;
-    font-size: 75%;
-}
- 
-div.footer a {
-    color: #444;
-    text-decoration: underline;
-}
- 
-div.related {
-    background-color: #6BA81E;
-    line-height: 32px;
-    color: #fff;
-    text-shadow: 0px 1px 0 #444;
-    font-size: 0.9em;
-}
- 
-div.related a {
-    color: #E2F3CC;
-}
- 
-div.sphinxsidebar {
-    font-size: 0.75em;
-    line-height: 1.5em;
-}
-
-div.sphinxsidebarwrapper{
-    padding: 20px 0;
-}
- 
-div.sphinxsidebar h3,
-div.sphinxsidebar h4 {
-    font-family: Arial, sans-serif;
-    color: #222;
-    font-size: 1.2em;
-    font-weight: normal;
-    margin: 0;
-    padding: 5px 10px;
-    background-color: #ddd;
-    text-shadow: 1px 1px 0 white
-}
-
-div.sphinxsidebar h4{
-    font-size: 1.1em;
-}
- 
-div.sphinxsidebar h3 a {
-    color: #444;
-}
- 
- 
-div.sphinxsidebar p {
-    color: #888;
-    padding: 5px 20px;
-}
- 
-div.sphinxsidebar p.topless {
-}
- 
-div.sphinxsidebar ul {
-    margin: 10px 20px;
-    padding: 0;
-    color: #000;
-}
- 
-div.sphinxsidebar a {
-    color: #444;
-}
- 
-div.sphinxsidebar input {
-    border: 1px solid #ccc;
-    font-family: sans-serif;
-    font-size: 1em;
-}
-
-div.sphinxsidebar input[type=text]{
-    margin-left: 20px;
-}
- 
-/* -- body styles ----------------------------------------------------------- */
- 
-a {
-    color: #005B81;
-    text-decoration: none;
-}
- 
-a:hover {
-    color: #E32E00;
-    text-decoration: underline;
-}
- 
-div.document h1,
-div.document h2,
-div.document h3,
-div.document h4,
-div.document h5,
-div.document h6 {
-    font-family: Arial, sans-serif;
-    background-color: #BED4EB;
-    font-weight: normal;
-    color: #212224;
-    margin: 30px 0px 10px 0px;
-    padding: 5px 0 5px 10px;
-    text-shadow: 0px 1px 0 white
-}
- 
-div.document h1 { border-top: 20px solid white; margin-top: 0; font-size: 200%; }
-div.document h2 { font-size: 150%; background-color: #C8D5E3; }
-div.document h3 { font-size: 120%; background-color: #D8DEE3; }
-div.document h4 { font-size: 110%; background-color: #D8DEE3; }
-div.document h5 { font-size: 100%; background-color: #D8DEE3; }
-div.document h6 { font-size: 100%; background-color: #D8DEE3; }
- 
-a.headerlink {
-    color: #c60f0f;
-    font-size: 0.8em;
-    padding: 0 4px 0 4px;
-    text-decoration: none;
-}
- 
-a.headerlink:hover {
-    background-color: #c60f0f;
-    color: white;
-}
- 
-div.document p, div.document dd, div.document li {
-    line-height: 1.5em;
-}
- 
-div.admonition p.admonition-title + p {
-    display: inline;
-}
-
-div.highlight{
-    background-color: white;
-}
-
-div.note {
-    background-color: #eee;
-    border: 1px solid #ccc;
-}
- 
-div.seealso {
-    background-color: #ffc;
-    border: 1px solid #ff6;
-}
- 
-div.topic {
-    background-color: #eee;
-}
- 
-div.warning {
-    background-color: #ffe4e4;
-    border: 1px solid #f66;
-}
- 
-p.admonition-title {
-    display: inline;
-}
- 
-p.admonition-title:after {
-    content: ":";
-}
- 
-pre {
-    padding: 10px;
-    background-color: White;
-    color: #222;
-    line-height: 1.2em;
-    border: 1px solid #C6C9CB;
-    font-size: 1.1em;
-    margin: 1.5em 0 1.5em 0;
-    -webkit-box-shadow: 1px 1px 1px #d8d8d8;
-    -moz-box-shadow: 1px 1px 1px #d8d8d8;
-}
- 
-tt {
-    background-color: #ecf0f3;
-    color: #222;
-    /* padding: 1px 2px; */
-    font-size: 1.1em;
-    font-family: monospace;
-}
-
-.viewcode-back {
-    font-family: Arial, sans-serif;
-}
-
-div.viewcode-block:target {
-    background-color: #f4debf;
-    border-top: 1px solid #ac9;
-    border-bottom: 1px solid #ac9;
-}
-
-ul li dd {
-	margin-top: 0;
-}
-
-ul li dl {
-	margin-bottom: 0;
-}
-
-li dl dd {
-	margin-bottom: 0;
-}
-
-dd ul {
-	padding-left: 0;
-}
-
-li dd ul {
-	margin-bottom: 0;
-}
-
-table {
-    margin-top: 10px;
-    margin-bottom: 10px;
-    border: 0;
-    border-collapse: collapse;
-}
-
-td[colspan]:not([colspan="1"]) {
-    background: #eeeeee;
-    text-transform: capitalize;
-}
-
-thead {
-    background: #eeeeee;
-}
-
-div.admonition-rationale {
-    background-color: #efe;
-    border: 1px solid #ccc;
-}
-
-div.admonition-example {
-    background-color: #eef;
-    border: 1px solid #ccc;
-}
-
-div#table-of-contents ul {
-    list-style-type: none;
-}
diff --git a/scripts/css/pygments.css b/scripts/css/pygments.css
deleted file mode 100644
index a212151a..00000000
--- a/scripts/css/pygments.css
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
-Original styles generated from:
-    pygmentize -f html -S colorful -a pre.code > ./scripts/css/pygments.css
-
-Rules for which we don't want the syntax highlighter to kick in are commented
-out at the bottom.
-
-Windows users: if you regenerate this file, you'll need to re-save it as utf-8
-to make docutils happy.
-*/
-
-/* DIFFS */
-pre.code .gd { color: #A00000 } /* Generic.Deleted */
-pre.code .gi { color: #00A000 } /* Generic.Inserted */
-
-/* UNUSED */
-/*pre.code .hll { background-color: #ffffcc }*/
-/*pre.code  { background: #ffffff; }*/
-/*pre.code .c { color: #888888 } !* Comment *!*/
-/*pre.code .err { color: #FF0000; background-color: #FFAAAA } !* Error *!*/
-/*pre.code .k { color: #008800; font-weight: bold } !* Keyword *!*/
-/*pre.code .o { color: #333333 } !* Operator *!*/
-/*pre.code .ch { color: #888888 } !* Comment.Hashbang *!*/
-/*pre.code .cm { color: #888888 } !* Comment.Multiline *!*/
-/*pre.code .cp { color: #557799 } !* Comment.Preproc *!*/
-/*pre.code .cpf { color: #888888 } !* Comment.PreprocFile *!*/
-/*pre.code .c1 { color: #888888 } !* Comment.Single *!*/
-/*pre.code .cs { color: #cc0000; font-weight: bold } !* Comment.Special *!*/
-/*pre.code .ge { font-style: italic } !* Generic.Emph *!*/
-/*pre.code .gr { color: #FF0000 } !* Generic.Error *!*/
-/*pre.code .gh { color: #000080; font-weight: bold } !* Generic.Heading *!*/
-/*pre.code .go { color: #888888 } !* Generic.Output *!*/
-/*pre.code .gp { color: #c65d09; font-weight: bold } !* Generic.Prompt *!*/
-/*pre.code .gs { font-weight: bold } !* Generic.Strong *!*/
-/*pre.code .gu { color: #800080; font-weight: bold } !* Generic.Subheading *!*/
-/*pre.code .gt { color: #0044DD } !* Generic.Traceback *!*/
-/*pre.code .kc { color: #008800; font-weight: bold } !* Keyword.Constant *!*/
-/*pre.code .kd { color: #008800; font-weight: bold } !* Keyword.Declaration *!*/
-/*pre.code .kn { color: #008800; font-weight: bold } !* Keyword.Namespace *!*/
-/*pre.code .kp { color: #003388; font-weight: bold } !* Keyword.Pseudo *!*/
-/*pre.code .kr { color: #008800; font-weight: bold } !* Keyword.Reserved *!*/
-/*pre.code .kt { color: #333399; font-weight: bold } !* Keyword.Type *!*/
-/*pre.code .m { color: #6600EE; font-weight: bold } !* Literal.Number *!*/
-/*pre.code .s { background-color: #fff0f0 } !* Literal.String *!*/
-/*pre.code .na { color: #0000CC } !* Name.Attribute *!*/
-/*pre.code .nb { color: #007020 } !* Name.Builtin *!*/
-/*pre.code .nc { color: #BB0066; font-weight: bold } !* Name.Class *!*/
-/*pre.code .no { color: #003366; font-weight: bold } !* Name.Constant *!*/
-/*pre.code .nd { color: #555555; font-weight: bold } !* Name.Decorator *!*/
-/*pre.code .ni { color: #880000; font-weight: bold } !* Name.Entity *!*/
-/*pre.code .ne { color: #FF0000; font-weight: bold } !* Name.Exception *!*/
-/*pre.code .nf { color: #0066BB; font-weight: bold } !* Name.Function *!*/
-/*pre.code .nl { color: #997700; font-weight: bold } !* Name.Label *!*/
-/*pre.code .nn { color: #0e84b5; font-weight: bold } !* Name.Namespace *!*/
-/*pre.code .nt { color: #007700 } !* Name.Tag *!*/
-/*pre.code .nv { color: #996633 } !* Name.Variable *!*/
-/*pre.code .ow { color: #000000; font-weight: bold } !* Operator.Word *!*/
-/*pre.code .w { color: #bbbbbb } !* Text.Whitespace *!*/
-/*pre.code .mb { color: #6600EE; font-weight: bold } !* Literal.Number.Bin *!*/
-/*pre.code .mf { color: #6600EE; font-weight: bold } !* Literal.Number.Float *!*/
-/*pre.code .mh { color: #005588; font-weight: bold } !* Literal.Number.Hex *!*/
-/*pre.code .mi { color: #0000DD; font-weight: bold } !* Literal.Number.Integer *!*/
-/*pre.code .mo { color: #4400EE; font-weight: bold } !* Literal.Number.Oct *!*/
-/*pre.code .sa { background-color: #fff0f0 } !* Literal.String.Affix *!*/
-/*pre.code .sb { background-color: #fff0f0 } !* Literal.String.Backtick *!*/
-/*pre.code .sc { color: #0044DD } !* Literal.String.Char *!*/
-/*pre.code .dl { background-color: #fff0f0 } !* Literal.String.Delimiter *!*/
-/*pre.code .sd { color: #DD4422 } !* Literal.String.Doc *!*/
-/*pre.code .s2 { background-color: #fff0f0 } !* Literal.String.Double *!*/
-/*pre.code .se { color: #666666; font-weight: bold; background-color: #fff0f0 } !* Literal.String.Escape *!*/
-/*pre.code .sh { background-color: #fff0f0 } !* Literal.String.Heredoc *!*/
-/*pre.code .si { background-color: #eeeeee } !* Literal.String.Interpol *!*/
-/*pre.code .sx { color: #DD2200; background-color: #fff0f0 } !* Literal.String.Other *!*/
-/*pre.code .sr { color: #000000; background-color: #fff0ff } !* Literal.String.Regex *!*/
-/*pre.code .s1 { background-color: #fff0f0 } !* Literal.String.Single *!*/
-/*pre.code .ss { color: #AA6600 } !* Literal.String.Symbol *!*/
-/*pre.code .bp { color: #007020 } !* Name.Builtin.Pseudo *!*/
-/*pre.code .fm { color: #0066BB; font-weight: bold } !* Name.Function.Magic *!*/
-/*pre.code .vc { color: #336699 } !* Name.Variable.Class *!*/
-/*pre.code .vg { color: #dd7700; font-weight: bold } !* Name.Variable.Global *!*/
-/*pre.code .vi { color: #3333BB } !* Name.Variable.Instance *!*/
-/*pre.code .vm { color: #996633 } !* Name.Variable.Magic *!*/
-/*pre.code .il { color: #0000DD; font-weight: bold } !* Literal.Number.Integer.Long *!*/
diff --git a/scripts/css/tables.css b/scripts/css/tables.css
deleted file mode 100644
index 03ee1d85..00000000
--- a/scripts/css/tables.css
+++ /dev/null
@@ -1,4 +0,0 @@
-/* Column with header cells */
-table.docutils tbody th.stub {
-    background: #eeeeee;
-}
diff --git a/scripts/dump-swagger.py b/scripts/dump-swagger.py
deleted file mode 100755
index 82de8763..00000000
--- a/scripts/dump-swagger.py
+++ /dev/null
@@ -1,208 +0,0 @@
-#!/usr/bin/env python3
-
-# dump-swagger reads all of the swagger API docs used in spec generation and
-# outputs a JSON file which merges them all, for use as input to a swagger UI
-# viewer.
-# See https://github.com/swagger-api/swagger-ui for details of swagger-ui.
-
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-
-import argparse
-import errno
-import json
-import logging
-import os.path
-import re
-import sys
-import yaml
-
-
-scripts_dir = os.path.dirname(os.path.abspath(__file__))
-api_dir = os.path.join(os.path.dirname(scripts_dir), "data", "api")
-
-def resolve_references(path, schema):
-    if isinstance(schema, dict):
-        # do $ref first
-        if '$ref' in schema:
-            value = schema['$ref']
-            previous_path = path
-            path = os.path.join(os.path.dirname(path), value)
-            try:
-                with open(path, encoding="utf-8") as f:
-                    ref = yaml.safe_load(f)
-                result = resolve_references(path, ref)
-                del schema['$ref']
-                path = previous_path
-            except FileNotFoundError:
-                print("Resolving {}".format(schema))
-                print("File not found: {}".format(path))
-                result = {}
-        else:
-            result = {}
-
-        for key, value in schema.items():
-            result[key] = resolve_references(path, value)
-        return result
-    elif isinstance(schema, list):
-        return [resolve_references(path, value) for value in schema]
-    else:
-        return schema
-
-def prefix_absolute_path_references(text, base_url):
-    """Adds base_url to absolute-path references.
-
-    Markdown links in descriptions may be absolute-path references.
-    These won’t work when the spec is not hosted at the root, such as
-    https://spec.matrix.org/latest/
-    This turns all `[foo](/bar)` found in text into
-    `[foo](https://spec.matrix.org/latest/bar)`, with
-    base_url = 'https://spec.matrix.org/latest/'
-    """
-    return text.replace("](/", "]({}/".format(base_url))
-
-def edit_links(node, base_url):
-    """Finds description nodes and makes any links in them absolute."""
-    if isinstance(node, dict):
-        for key in node:
-            if isinstance(node[key], str):
-                node[key] = prefix_absolute_path_references(node[key], base_url)
-            else:
-                edit_links(node[key], base_url)
-    elif isinstance(node, list):
-        for item in node:
-            edit_links(item, base_url)
-
-parser = argparse.ArgumentParser(
-    "dump-swagger.py - assemble the Swagger specs into a single JSON file"
-)
-parser.add_argument(
-    "--base-url", "-b",
-    default="https://spec.matrix.org/unstable/",
-    help="""The base URL to prepend to links in descriptions. Default:
-    %(default)s""",
-)
-parser.add_argument(
-    "--spec-release", "-r", metavar="LABEL",
-    default="unstable",
-    help="""The spec release version to generate for. Default:
-    %(default)s""",
-)
-available_apis = {
-    "client-server": "Matrix Client-Server API",
-    "server-server": "Matrix Server-Server API",
-    "application-service": "Matrix Application Service API",
-    "identity": "Matrix Identity Service API",
-    "push-gateway": "Matrix Push Gateway API",
-}
-parser.add_argument(
-    "--api",
-    default="client-server",
-    choices=available_apis,
-    help="""The API to generate for. Default: %(default)s""",
-)
-parser.add_argument(
-    "-o", "--output",
-    default=os.path.join(scripts_dir, "swagger", "api-docs.json"),
-    help="File to write the output to. Default: %(default)s"
-)
-args = parser.parse_args()
-
-output_file = os.path.abspath(args.output)
-release_label = args.spec_release
-selected_api = args.api
-
-major_version = release_label
-match = re.match("^(r\d+)(\.\d+)*$", major_version)
-if match:
-    major_version = match.group(1)
-
-base_url = args.base_url.rstrip("/")
-
-logging.basicConfig()
-
-output = {
-    "basePath": "/",
-    "consumes": ["application/json"],
-    "produces": ["application/json"],
-    "host": "matrix.org",
-    # The servers value will be picked up by RapiDoc to provide a way
-    # to switch API servers. Useful when one wants to test compliance
-    # of their server with the API.
-    "servers": [
-        {
-            "url": "https://{homeserver_address}/",
-            "variables": {
-                "homeserver_address": {
-                    "default": "matrix-client.matrix.org",
-                    "description": "The base URL for your homeserver",
-                }
-            },
-        }
-    ],
-    "schemes": ["https"],
-    "info": {
-        "title": available_apis[selected_api],
-        "version": release_label,
-    },
-    "securityDefinitions": {},
-    "paths": {},
-    "swagger": "2.0",
-}
-
-selected_api_dir = os.path.join(api_dir, selected_api)
-try:
-    with open(os.path.join(selected_api_dir, 'definitions', 'security.yaml')) as f:
-        output['securityDefinitions'] = yaml.safe_load(f)
-except FileNotFoundError:
-    print("No security definitions available for this API")
-
-untagged = 0
-for filename in os.listdir(selected_api_dir):
-    if not filename.endswith(".yaml"):
-        continue
-    filepath = os.path.join(selected_api_dir, filename)
-
-    print("Reading swagger API: %s" % filepath)
-    with open(filepath, "r") as f:
-        api = yaml.safe_load(f.read())
-        api = resolve_references(filepath, api)
-
-        basePath = api['basePath']
-        for path, methods in api["paths"].items():
-            path = basePath + path
-            for method, spec in methods.items():
-                if path not in output["paths"]:
-                    output["paths"][path] = {}
-                output["paths"][path][method] = spec
-                if "tags" not in spec.keys():
-                    print("Warning: {} {} is not tagged ({}).".format(method.upper(), path, filename))
-                    untagged +=1
-if untagged != 0:
-    print("{} untagged operations, you may want to look into fixing that.".format(untagged))
-
-edit_links(output, base_url)
-
-print("Generating %s" % output_file)
-
-try:
-    os.makedirs(os.path.dirname(output_file))
-except OSError as e:
-    if e.errno != errno.EEXIST:
-        raise
-
-with open(output_file, "w") as f:
-    text = json.dumps(output, sort_keys=True, indent=4)
-    text = text.replace("%CLIENT_RELEASE_LABEL%", release_label)
-    f.write(text)
diff --git a/scripts/generate-changelog.sh b/scripts/generate-changelog.sh
deleted file mode 100644
index 1d82e5db..00000000
--- a/scripts/generate-changelog.sh
+++ /dev/null
@@ -1,37 +0,0 @@
-# /bin/bash
-
-# Usage: ./generate.sh v1.2 "April 01, 2021"
-
-set -e
-
-MAGIC_STRING="<!-- DO NOT REMOVE OR CHANGE - Release script puts next release here -->"
-
-cd changelogs
-
-# Pre-cleanup just in case it wasn't done on the last run
-rm -f rendered.*
-
-# Reversed order so that room versions ends up on the bottom
-towncrier --name "Appendices" --dir "./appendices" --config "./pyproject.toml" --yes
-towncrier --name "Room Versions" --dir "./room_versions" --config "./pyproject.toml" --yes
-towncrier --name "Push Gateway API" --dir "./push_gateway" --config "./pyproject.toml" --yes
-towncrier --name "Identity Service API" --dir "./identity_service" --config "./pyproject.toml" --yes
-towncrier --name "Application Service API" --dir "./application_service" --config "./pyproject.toml" --yes
-towncrier --name "Server-Server API" --dir "./server_server" --config "./pyproject.toml" --yes
-towncrier --name "Client-Server API" --dir "./client_server" --config "./pyproject.toml" --yes
-
-# Prepare the header
-cp header.md rendered.header.md
-sed -i "s/VERSION/$1/g" rendered.header.md
-sed -i "s/DATE/$2/g" rendered.header.md
-cat rendered.header.md rendered.md > rendered.final.md
-
-# Remove trailing whitespace (such as our intentionally blank RST headings)
-sed -i "s/[ ]*$//" rendered.final.md
-
-# Put the changelog in place
-mv rendered.final.md ../layouts/partials/changelogs/$1.md
-sed -i "s/$MAGIC_STRING/$MAGIC_STRING\n{{% changelog\\/changelog-rendered p=\"changelogs\\/$1.md\" %}}/" ../content/changelog.md
-
-# Cleanup
-rm -v rendered.*
diff --git a/scripts/i18n.py b/scripts/i18n.py
deleted file mode 100644
index bd9e3bbd..00000000
--- a/scripts/i18n.py
+++ /dev/null
@@ -1,32 +0,0 @@
-#!/usr/bin/env python3
-#
-# i18n.py: Generate and merge the i18n files for the spec.
-
-import json
-import sys
-import os
-import os.path
-
-scripts_dir = os.path.dirname(os.path.abspath(__file__))
-data_defs_dir = os.path.join(scripts_dir, "../data-definitions")
-
-def merge_sas_emoji_v1():
-    emoji = dict() # will be populated by a read
-    with open(os.path.join(data_defs_dir, "sas-emoji.json"), encoding="utf8") as f:
-        emoji = json.load(f)
-        for e in emoji:
-            e["translated_descriptions"] = dict()
-        pth = os.path.join(data_defs_dir, "sas-emoji-v1-i18n")
-        translations = [t for t in os.listdir(pth) if os.path.isfile(os.path.join(pth, t))]
-        for translation in translations:
-            if not translation.endswith(".json") or translation == "base.json":
-                continue
-            lang = translation[:-5] # trim off the json extension
-            with open(os.path.join(pth, translation), encoding="utf8") as lf:
-                descs = json.load(lf)
-                for e in emoji:
-                    e["translated_descriptions"][lang] = descs.get(e["description"])
-    with open(os.path.join(data_defs_dir, "sas-emoji.json"), mode="w+", encoding="utf8") as o:
-        json.dump(emoji, o, ensure_ascii=False, indent=4)
-
-merge_sas_emoji_v1()
diff --git a/scripts/package-lock.json b/scripts/package-lock.json
deleted file mode 100644
index 5e3937c2..00000000
--- a/scripts/package-lock.json
+++ /dev/null
@@ -1,287 +0,0 @@
-{
-  "name": "swagger-cli-validator",
-  "version": "0.0.1",
-  "lockfileVersion": 2,
-  "requires": true,
-  "packages": {
-    "": {
-      "name": "swagger-cli-validator",
-      "version": "0.0.1",
-      "license": "ISC",
-      "dependencies": {
-        "nopt": "^3.0.2",
-        "swagger-parser": "^10.0.3"
-      }
-    },
-    "node_modules/@apidevtools/json-schema-ref-parser": {
-      "version": "9.0.9",
-      "resolved": "https://registry.npmjs.org/@apidevtools/json-schema-ref-parser/-/json-schema-ref-parser-9.0.9.tgz",
-      "integrity": "sha512-GBD2Le9w2+lVFoc4vswGI/TjkNIZSVp7+9xPf+X3uidBfWnAeUWmquteSyt0+VCrhNMWj/FTABISQrD3Z/YA+w==",
-      "dependencies": {
-        "@jsdevtools/ono": "^7.1.3",
-        "@types/json-schema": "^7.0.6",
-        "call-me-maybe": "^1.0.1",
-        "js-yaml": "^4.1.0"
-      }
-    },
-    "node_modules/@apidevtools/openapi-schemas": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/@apidevtools/openapi-schemas/-/openapi-schemas-2.1.0.tgz",
-      "integrity": "sha512-Zc1AlqrJlX3SlpupFGpiLi2EbteyP7fXmUOGup6/DnkRgjP9bgMM/ag+n91rsv0U1Gpz0H3VILA/o3bW7Ua6BQ==",
-      "engines": {
-        "node": ">=10"
-      }
-    },
-    "node_modules/@apidevtools/swagger-methods": {
-      "version": "3.0.2",
-      "resolved": "https://registry.npmjs.org/@apidevtools/swagger-methods/-/swagger-methods-3.0.2.tgz",
-      "integrity": "sha512-QAkD5kK2b1WfjDS/UQn/qQkbwF31uqRjPTrsCs5ZG9BQGAkjwvqGFjjPqAuzac/IYzpPtRzjCP1WrTuAIjMrXg=="
-    },
-    "node_modules/@apidevtools/swagger-parser": {
-      "version": "10.0.3",
-      "resolved": "https://registry.npmjs.org/@apidevtools/swagger-parser/-/swagger-parser-10.0.3.tgz",
-      "integrity": "sha512-sNiLY51vZOmSPFZA5TF35KZ2HbgYklQnTSDnkghamzLb3EkNtcQnrBQEj5AOCxHpTtXpqMCRM1CrmV2rG6nw4g==",
-      "dependencies": {
-        "@apidevtools/json-schema-ref-parser": "^9.0.6",
-        "@apidevtools/openapi-schemas": "^2.0.4",
-        "@apidevtools/swagger-methods": "^3.0.2",
-        "@jsdevtools/ono": "^7.1.3",
-        "call-me-maybe": "^1.0.1",
-        "z-schema": "^5.0.1"
-      },
-      "peerDependencies": {
-        "openapi-types": ">=7"
-      }
-    },
-    "node_modules/@jsdevtools/ono": {
-      "version": "7.1.3",
-      "resolved": "https://registry.npmjs.org/@jsdevtools/ono/-/ono-7.1.3.tgz",
-      "integrity": "sha512-4JQNk+3mVzK3xh2rqd6RB4J46qUR19azEHBneZyTZM+c456qOrbbM/5xcR8huNCCcbVt7+UmizG6GuUvPvKUYg=="
-    },
-    "node_modules/@types/json-schema": {
-      "version": "7.0.9",
-      "resolved": "https://registry.npmjs.org/@types/json-schema/-/json-schema-7.0.9.tgz",
-      "integrity": "sha512-qcUXuemtEu+E5wZSJHNxUXeCZhAfXKQ41D+duX+VYPde7xyEVZci+/oXKJL13tnRs9lR2pr4fod59GT6/X1/yQ=="
-    },
-    "node_modules/abbrev": {
-      "version": "1.1.1",
-      "resolved": "https://registry.npmjs.org/abbrev/-/abbrev-1.1.1.tgz",
-      "integrity": "sha512-nne9/IiQ/hzIhY6pdDnbBtz7DjPTKrY00P/zvPSm5pOFkl6xuGrGnXn/VtTNNfNtAfZ9/1RtehkszU9qcTii0Q=="
-    },
-    "node_modules/argparse": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
-      "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q=="
-    },
-    "node_modules/call-me-maybe": {
-      "version": "1.0.1",
-      "resolved": "https://registry.npmjs.org/call-me-maybe/-/call-me-maybe-1.0.1.tgz",
-      "integrity": "sha1-JtII6onje1y95gJQoV8DHBak1ms="
-    },
-    "node_modules/commander": {
-      "version": "2.20.3",
-      "resolved": "https://registry.npmjs.org/commander/-/commander-2.20.3.tgz",
-      "integrity": "sha512-GpVkmM8vF2vQUkj2LvZmD35JxeJOLCwJ9cUkugyk2nuhbv3+mJvpLYYt+0+USMxE+oj+ey/lJEnhZw75x/OMcQ==",
-      "optional": true
-    },
-    "node_modules/js-yaml": {
-      "version": "4.1.0",
-      "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz",
-      "integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==",
-      "dependencies": {
-        "argparse": "^2.0.1"
-      },
-      "bin": {
-        "js-yaml": "bin/js-yaml.js"
-      }
-    },
-    "node_modules/lodash.get": {
-      "version": "4.4.2",
-      "resolved": "https://registry.npmjs.org/lodash.get/-/lodash.get-4.4.2.tgz",
-      "integrity": "sha1-LRd/ZS+jHpObRDjVNBSZ36OCXpk="
-    },
-    "node_modules/lodash.isequal": {
-      "version": "4.5.0",
-      "resolved": "https://registry.npmjs.org/lodash.isequal/-/lodash.isequal-4.5.0.tgz",
-      "integrity": "sha1-QVxEePK8wwEgwizhDtMib30+GOA="
-    },
-    "node_modules/nopt": {
-      "version": "3.0.6",
-      "resolved": "https://registry.npmjs.org/nopt/-/nopt-3.0.6.tgz",
-      "integrity": "sha1-xkZdvwirzU2zWTF/eaxopkayj/k=",
-      "dependencies": {
-        "abbrev": "1"
-      },
-      "bin": {
-        "nopt": "bin/nopt.js"
-      }
-    },
-    "node_modules/openapi-types": {
-      "version": "9.3.0",
-      "resolved": "https://registry.npmjs.org/openapi-types/-/openapi-types-9.3.0.tgz",
-      "integrity": "sha512-sR23YjmuwDSMsQVZDHbV9mPgi0RyniQlqR0AQxTC2/F3cpSjRFMH3CFPjoWvNqhC4OxPkDYNb2l8Mc1Me6D/KQ==",
-      "peer": true
-    },
-    "node_modules/swagger-parser": {
-      "version": "10.0.3",
-      "resolved": "https://registry.npmjs.org/swagger-parser/-/swagger-parser-10.0.3.tgz",
-      "integrity": "sha512-nF7oMeL4KypldrQhac8RyHerJeGPD1p2xDh900GPvc+Nk7nWP6jX2FcC7WmkinMoAmoO774+AFXcWsW8gMWEIg==",
-      "dependencies": {
-        "@apidevtools/swagger-parser": "10.0.3"
-      },
-      "engines": {
-        "node": ">=10"
-      }
-    },
-    "node_modules/validator": {
-      "version": "13.7.0",
-      "resolved": "https://registry.npmjs.org/validator/-/validator-13.7.0.tgz",
-      "integrity": "sha512-nYXQLCBkpJ8X6ltALua9dRrZDHVYxjJ1wgskNt1lH9fzGjs3tgojGSCBjmEPwkWS1y29+DrizMTW19Pr9uB2nw==",
-      "engines": {
-        "node": ">= 0.10"
-      }
-    },
-    "node_modules/z-schema": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/z-schema/-/z-schema-5.0.1.tgz",
-      "integrity": "sha512-Gp8xU2lULhREqTWj9t4BEAeA7M835n4fWJ9KjGWksV3wmLUdOJo2hAr+QYvkVZIGOOTyeN274g1f95dKRsgYgQ==",
-      "dependencies": {
-        "lodash.get": "^4.4.2",
-        "lodash.isequal": "^4.5.0",
-        "validator": "^13.6.0"
-      },
-      "bin": {
-        "z-schema": "bin/z-schema"
-      },
-      "engines": {
-        "node": ">=8.0.0"
-      },
-      "optionalDependencies": {
-        "commander": "^2.7.1"
-      }
-    }
-  },
-  "dependencies": {
-    "@apidevtools/json-schema-ref-parser": {
-      "version": "9.0.9",
-      "resolved": "https://registry.npmjs.org/@apidevtools/json-schema-ref-parser/-/json-schema-ref-parser-9.0.9.tgz",
-      "integrity": "sha512-GBD2Le9w2+lVFoc4vswGI/TjkNIZSVp7+9xPf+X3uidBfWnAeUWmquteSyt0+VCrhNMWj/FTABISQrD3Z/YA+w==",
-      "requires": {
-        "@jsdevtools/ono": "^7.1.3",
-        "@types/json-schema": "^7.0.6",
-        "call-me-maybe": "^1.0.1",
-        "js-yaml": "^4.1.0"
-      }
-    },
-    "@apidevtools/openapi-schemas": {
-      "version": "2.1.0",
-      "resolved": "https://registry.npmjs.org/@apidevtools/openapi-schemas/-/openapi-schemas-2.1.0.tgz",
-      "integrity": "sha512-Zc1AlqrJlX3SlpupFGpiLi2EbteyP7fXmUOGup6/DnkRgjP9bgMM/ag+n91rsv0U1Gpz0H3VILA/o3bW7Ua6BQ=="
-    },
-    "@apidevtools/swagger-methods": {
-      "version": "3.0.2",
-      "resolved": "https://registry.npmjs.org/@apidevtools/swagger-methods/-/swagger-methods-3.0.2.tgz",
-      "integrity": "sha512-QAkD5kK2b1WfjDS/UQn/qQkbwF31uqRjPTrsCs5ZG9BQGAkjwvqGFjjPqAuzac/IYzpPtRzjCP1WrTuAIjMrXg=="
-    },
-    "@apidevtools/swagger-parser": {
-      "version": "10.0.3",
-      "resolved": "https://registry.npmjs.org/@apidevtools/swagger-parser/-/swagger-parser-10.0.3.tgz",
-      "integrity": "sha512-sNiLY51vZOmSPFZA5TF35KZ2HbgYklQnTSDnkghamzLb3EkNtcQnrBQEj5AOCxHpTtXpqMCRM1CrmV2rG6nw4g==",
-      "requires": {
-        "@apidevtools/json-schema-ref-parser": "^9.0.6",
-        "@apidevtools/openapi-schemas": "^2.0.4",
-        "@apidevtools/swagger-methods": "^3.0.2",
-        "@jsdevtools/ono": "^7.1.3",
-        "call-me-maybe": "^1.0.1",
-        "z-schema": "^5.0.1"
-      }
-    },
-    "@jsdevtools/ono": {
-      "version": "7.1.3",
-      "resolved": "https://registry.npmjs.org/@jsdevtools/ono/-/ono-7.1.3.tgz",
-      "integrity": "sha512-4JQNk+3mVzK3xh2rqd6RB4J46qUR19azEHBneZyTZM+c456qOrbbM/5xcR8huNCCcbVt7+UmizG6GuUvPvKUYg=="
-    },
-    "@types/json-schema": {
-      "version": "7.0.9",
-      "resolved": "https://registry.npmjs.org/@types/json-schema/-/json-schema-7.0.9.tgz",
-      "integrity": "sha512-qcUXuemtEu+E5wZSJHNxUXeCZhAfXKQ41D+duX+VYPde7xyEVZci+/oXKJL13tnRs9lR2pr4fod59GT6/X1/yQ=="
-    },
-    "abbrev": {
-      "version": "1.1.1",
-      "resolved": "https://registry.npmjs.org/abbrev/-/abbrev-1.1.1.tgz",
-      "integrity": "sha512-nne9/IiQ/hzIhY6pdDnbBtz7DjPTKrY00P/zvPSm5pOFkl6xuGrGnXn/VtTNNfNtAfZ9/1RtehkszU9qcTii0Q=="
-    },
-    "argparse": {
-      "version": "2.0.1",
-      "resolved": "https://registry.npmjs.org/argparse/-/argparse-2.0.1.tgz",
-      "integrity": "sha512-8+9WqebbFzpX9OR+Wa6O29asIogeRMzcGtAINdpMHHyAg10f05aSFVBbcEqGf/PXw1EjAZ+q2/bEBg3DvurK3Q=="
-    },
-    "call-me-maybe": {
-      "version": "1.0.1",
-      "resolved": "https://registry.npmjs.org/call-me-maybe/-/call-me-maybe-1.0.1.tgz",
-      "integrity": "sha1-JtII6onje1y95gJQoV8DHBak1ms="
-    },
-    "commander": {
-      "version": "2.20.3",
-      "resolved": "https://registry.npmjs.org/commander/-/commander-2.20.3.tgz",
-      "integrity": "sha512-GpVkmM8vF2vQUkj2LvZmD35JxeJOLCwJ9cUkugyk2nuhbv3+mJvpLYYt+0+USMxE+oj+ey/lJEnhZw75x/OMcQ==",
-      "optional": true
-    },
-    "js-yaml": {
-      "version": "4.1.0",
-      "resolved": "https://registry.npmjs.org/js-yaml/-/js-yaml-4.1.0.tgz",
-      "integrity": "sha512-wpxZs9NoxZaJESJGIZTyDEaYpl0FKSA+FB9aJiyemKhMwkxQg63h4T1KJgUGHpTqPDNRcmmYLugrRjJlBtWvRA==",
-      "requires": {
-        "argparse": "^2.0.1"
-      }
-    },
-    "lodash.get": {
-      "version": "4.4.2",
-      "resolved": "https://registry.npmjs.org/lodash.get/-/lodash.get-4.4.2.tgz",
-      "integrity": "sha1-LRd/ZS+jHpObRDjVNBSZ36OCXpk="
-    },
-    "lodash.isequal": {
-      "version": "4.5.0",
-      "resolved": "https://registry.npmjs.org/lodash.isequal/-/lodash.isequal-4.5.0.tgz",
-      "integrity": "sha1-QVxEePK8wwEgwizhDtMib30+GOA="
-    },
-    "nopt": {
-      "version": "3.0.6",
-      "resolved": "https://registry.npmjs.org/nopt/-/nopt-3.0.6.tgz",
-      "integrity": "sha1-xkZdvwirzU2zWTF/eaxopkayj/k=",
-      "requires": {
-        "abbrev": "1"
-      }
-    },
-    "openapi-types": {
-      "version": "9.3.0",
-      "resolved": "https://registry.npmjs.org/openapi-types/-/openapi-types-9.3.0.tgz",
-      "integrity": "sha512-sR23YjmuwDSMsQVZDHbV9mPgi0RyniQlqR0AQxTC2/F3cpSjRFMH3CFPjoWvNqhC4OxPkDYNb2l8Mc1Me6D/KQ==",
-      "peer": true
-    },
-    "swagger-parser": {
-      "version": "10.0.3",
-      "resolved": "https://registry.npmjs.org/swagger-parser/-/swagger-parser-10.0.3.tgz",
-      "integrity": "sha512-nF7oMeL4KypldrQhac8RyHerJeGPD1p2xDh900GPvc+Nk7nWP6jX2FcC7WmkinMoAmoO774+AFXcWsW8gMWEIg==",
-      "requires": {
-        "@apidevtools/swagger-parser": "10.0.3"
-      }
-    },
-    "validator": {
-      "version": "13.7.0",
-      "resolved": "https://registry.npmjs.org/validator/-/validator-13.7.0.tgz",
-      "integrity": "sha512-nYXQLCBkpJ8X6ltALua9dRrZDHVYxjJ1wgskNt1lH9fzGjs3tgojGSCBjmEPwkWS1y29+DrizMTW19Pr9uB2nw=="
-    },
-    "z-schema": {
-      "version": "5.0.1",
-      "resolved": "https://registry.npmjs.org/z-schema/-/z-schema-5.0.1.tgz",
-      "integrity": "sha512-Gp8xU2lULhREqTWj9t4BEAeA7M835n4fWJ9KjGWksV3wmLUdOJo2hAr+QYvkVZIGOOTyeN274g1f95dKRsgYgQ==",
-      "requires": {
-        "commander": "^2.7.1",
-        "lodash.get": "^4.4.2",
-        "lodash.isequal": "^4.5.0",
-        "validator": "^13.6.0"
-      }
-    }
-  }
-}
diff --git a/scripts/package.json b/scripts/package.json
deleted file mode 100644
index d4342c56..00000000
--- a/scripts/package.json
+++ /dev/null
@@ -1,15 +0,0 @@
-{
-  "name": "swagger-cli-validator",
-  "version": "0.0.1",
-  "description": "",
-  "main": "validator.js",
-  "scripts": {
-    "test": "echo \"Error: no test specified\" && exit 1"
-  },
-  "author": "",
-  "license": "ISC",
-  "dependencies": {
-    "nopt": "^3.0.2",
-    "swagger-parser": "^10.0.3"
-  }
-}
diff --git a/scripts/proposals.js b/scripts/proposals.js
deleted file mode 100644
index 9a2d2b4e..00000000
--- a/scripts/proposals.js
+++ /dev/null
@@ -1,219 +0,0 @@
-"use strict";
-
-/**
- * This Node script fetches MSC proposals and stores them in /data/msc,
- * so they can be used by a Hugo template to render summary tables of them
- * in the specification.
- *
- * In detail, it:
- * - fetches all GitHub issues from matrix-doc 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
- */
-
-// built-in modules
-const path = require('path');
-const fs = require('fs');
-
-// third-party modules
-const fetch = require('node-fetch');
-
-// We will write proposals into the /data/msc directory
-const outputDir = path.join(__dirname, "../data/msc");
-
-/**
- * This defines the different proposal lifecycle states.
- * Each state has:
- * - `label`: a GitHub label used to identify issues in this state
- * - `title`: used for things like headings in renderings of the proposals
- */
-const states = [
-  {
-    label: "proposal-in-review",
-    title: "Proposal In Review"
-  },
-  {
-    label: "proposed-final-comment-period",
-    title: "Proposed Final Comment Period"
-  },
-  {
-    label: "final-comment-period",
-    title: "Final Comment Period"
-  },
-  {
-    label: "finished-final-comment-period",
-    title: "Finished Final Comment Period"
-  },
-  {
-    label: "spec-pr-missing",
-    title: "Spec PR Missing"
-  },
-  {
-    label: "spec-pr-in-review",
-    title: "Spec PR In Review"
-  },
-  {
-    label: "merged",
-    title: "Merged"
-  },
-  {
-    label: "proposal-postponed",
-    title: "Postponed"
-  },
-  {
-    label: "abandoned",
-    title: "Abandoned"
-  },
-  {
-    label: "obsolete",
-    title: "Obsolete"
-  }
-];
-
-let issues = [];
-
-/**
- * Fetch all the MSC proposals from GitHub.
- *
- * GitHub only lets us fetch 100 items at a time, and it gives us a `link`
- * response header containing the URL for the next batch.
- * So we will keep fetching until the response doesn't contain the "next" link.
- */
-async function getIssues() {
-
-  /**
-   * A pretty ugly function to get us the "next" link in the header if there
-   * was one, or `null` otherwise.
-   */
-  function getNextLink(header) {
-    const links = header.split(",");
-    for (const link of links) {
-      const linkPieces = link.split(";");
-      if (linkPieces[1] == ` rel=\"next\"`) {
-        const next = linkPieces[0].trim();
-        return next.substring(1, next.length-1);
-      }
-    }
-    return null;
-  }
-
-  let pageLink = "https://api.github.com/repos/matrix-org/matrix-doc/issues?state=all&labels=proposal&per_page=100";
-  while (pageLink) {
-    const response = await fetch(pageLink);
-    const issuesForPage = await response.json();
-    issues = issues.concat(issuesForPage);
-    const linkHeader = response.headers.get("link");
-    pageLink = getNextLink(linkHeader);
-  }
-}
-
-getIssues().then(processIssues);
-
-/**
- * Rather than just store the complete issue, we'll extract
- * only the pieces we need.
- * We'll also do some transformation of the issues, just because
- * it's easier to do in JS than in the template.
- */
-function getProposalFromIssue(issue) {
-
-  /**
-   * A helper function to fetch the contents of special
-   * directives in the issue body.
-   * Looks for a directive in the format:
-   * `^${directiveName}: (.+?)$`, returning the matched
-   *  part or null if the directive wasn't found.
-   */
-  function getDirective(directiveName, issue) {
-    const re = new RegExp(`^${directiveName}: (.+?)$`, "m");
-    const found = issue.body?.match(re);
-    return found? found[1]: null;
-  }
-
-  function getDocumentation(issue) {
-    const found = getDirective("Documentation", issue);
-    if (found) {
-      return found.split(",").map(a => a.trim());
-    } else {
-      return [];
-    }
-  }
-
-  function getAuthors(issue) {
-    const found = getDirective("Author", issue);
-    if (found) {
-      return found.split(",").map(a => a.trim().substr(1));
-    } else {
-      return [`${issue.user.login}`];
-    }
-  }
-
-  function getShepherd(issue) {
-    const found = getDirective("Shepherd", issue);
-    if (found) {
-      return found.substr(1);
-    } else {
-      return null;
-    }
-  }
-
-  return {
-    number: issue.number,
-    url: issue.html_url,
-    title: issue.title,
-    created_at: issue.created_at.substr(0, 10),
-    updated_at: issue.updated_at.substr(0, 10),
-    authors: getAuthors(issue),
-    shepherd: getShepherd(issue),
-    documentation: getDocumentation(issue)
-  }
-}
-
-/**
- * Returns the intersection of two arrays.
- */
-function intersection(array1, array2) {
-  return array1.filter(i => array2.includes(i));
-}
-
-/**
- * Given all the GitHub issues with a "proposal" label:
- * - group issues by the state they are in, and for each group:
- *     - extract the bits we need from each issue
- *     - write the result under /data/msc
- */
-function processIssues()  {
-  if (!fs.existsSync(outputDir)){
-    fs.mkdirSync(outputDir);
-  }
-  const output = [];
-  // make a group of "work in progress" proposals,
-  // which are identified by not having any of the state labels
-  const stateLabels = states.map(s => s.label);
-  const worksInProgress = issues.filter(issue => {
-    const labelsForIssue = issue.labels.map(l => l.name);
-    return intersection(labelsForIssue, stateLabels).length === 0;
-  });
-  output.push({
-    title: "Work In Progress",
-    label: "work-in-progress",
-    proposals: worksInProgress.map(issue => getProposalFromIssue(issue))
-  });
-  // for each defined state
-  for (const state of states) {
-    // get the set of issues for that state
-    const issuesForState = issues.filter(msc => {
-      return msc.labels.some(l => l.name === state.label);
-    });
-    // store it in /data
-    output.push({
-      title: state.title,
-      label: state.label,
-      proposals: issuesForState.map(issue => getProposalFromIssue(issue))
-    });
-  }
-  const outputData = JSON.stringify(output, null, '\t');
-  const outputFile = path.join(outputDir, `proposals.json`);
-  fs.writeFileSync(outputFile, outputData);
-}
diff --git a/scripts/requirements.txt b/scripts/requirements.txt
deleted file mode 100644
index 9d9f1167..00000000
--- a/scripts/requirements.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-# no doubt older versions would be fine for many of these but these were
-# current at the time of writing
-
-# jsonschema 3.0.0 objects to the $refs in our schema file. TODO: figure out
-# why.
-jsonschema >= 2.6.0, < 3.0.0
-
-PyYAML >= 3.12
-requests >= 2.18.4
-towncrier == 21.9.0rc1
diff --git a/scripts/swagger-http-server.py b/scripts/swagger-http-server.py
deleted file mode 100755
index 06d764aa..00000000
--- a/scripts/swagger-http-server.py
+++ /dev/null
@@ -1,55 +0,0 @@
-#!/usr/bin/env python
-
-# Runs an HTTP server on localhost:8000 which will serve the generated swagger
-# JSON so that it can be viewed in an online swagger UI.
-
-# Copyright 2016 OpenMarket Ltd
-#
-# 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.
-
-import argparse
-import os
-import http.server
-import socketserver
-
-# Thanks to http://stackoverflow.com/a/13354482
-class MyHTTPRequestHandler(http.server.SimpleHTTPRequestHandler):
-    def end_headers(self):
-        self.send_my_headers()
-        http.server.SimpleHTTPRequestHandler.end_headers(self)
-
-    def send_my_headers(self):
-        self.send_header("Access-Control-Allow-Origin", "*")
-
-
-if __name__ == '__main__':
-    scripts_dir = os.path.dirname(os.path.abspath(__file__))
-    parser = argparse.ArgumentParser()
-    parser.add_argument(
-        '--port', '-p',
-        type=int, default=8000,
-        help='TCP port to listen on (default: %(default)s)',
-    )
-    parser.add_argument(
-        'swagger_dir', nargs='?',
-        default=os.path.join(scripts_dir, 'swagger'),
-        help='directory to serve (default: %(default)s)',
-    )
-    args = parser.parse_args()
-
-    os.chdir(args.swagger_dir)
-
-    httpd = socketserver.TCPServer(("localhost", args.port),
-                                   MyHTTPRequestHandler)
-    print("Serving at http://localhost:%i/api-docs.json" % args.port)
-    httpd.serve_forever()
diff --git a/scripts/validator.js b/scripts/validator.js
deleted file mode 100644
index c20dd993..00000000
--- a/scripts/validator.js
+++ /dev/null
@@ -1,86 +0,0 @@
-"use strict";
-var fs = require("fs");
-var nopt = require("nopt");
-var parser = require("swagger-parser");
-var path = require("path");
-
-var opts = nopt({
-    "help": Boolean,
-    "schema": path
-}, {
-    "h": "--help",
-    "s": "--schema"
-});
-
-if (opts.help) {
-    console.log(
-        "Use swagger-parser to validate against Swagger 2.0\n"+
-        "Usage:\n"+
-        "  node validator.js -s <schema_file_or_folder>"
-    );
-    process.exit(0);
-}
-if (!opts.schema) {
-    console.error("No [s]chema specified.");
-    process.exit(1);
-}
-
-
-var errFn = function(err, api) {
-    if (!err) {
-        return;
-    }
-    console.error(err);
-    process.exit(1);
-};
-
-/**
- * @brief Produce a handler for parser.validate().
- * Recommended usage: `parser.validate(filename, makeHandler(filename));`
- * or `parser.validate(schema, makeHandler());`.
- * @param scope - usually a filename, this will be used to denote
- *                an (in)valid schema in console output; "Schema" if undefined
- * @returns {function} the handler that can be passed to parser.validate
- */
-function makeHandler(scope) {
-    if (!scope)
-        scope = "Schema";
-    return function(err, api, metadata) {
-        if (err) {
-            console.error("%s is not valid.", scope || "Schema");
-            errFn(err, api, metadata); // Won't return
-        }
-
-        Object.keys(api.paths).forEach(function (endpoint) {
-            var operationsMap = api.paths[endpoint];
-            Object.keys(operationsMap).forEach(function (verb) {
-                if (!operationsMap[verb]["operationId"]) {
-                    console.error("%s is not valid", scope);
-                    errFn("operationId is missing in " + endpoint + ", verb " + verb, api);
-                }
-            })
-        });
-
-        console.log("%s is valid.", scope);
-    }
-}
-
-var isDir = fs.lstatSync(opts.schema).isDirectory();
-if (isDir) {
-    console.log("Checking directory %s for .yaml files...", opts.schema);
-    fs.readdir(opts.schema, function(err, files) {
-        if (err) {
-            errFn(err); // Won't return
-        }
-        files.forEach(function(f) {
-            var suffix = ".yaml";
-            if (f.indexOf(suffix, f.length - suffix.length) > 0) {
-                parser.validate(path.join(opts.schema, f), makeHandler(f));
-            }
-        });
-    });
-}
-else{
-    parser.validate(opts.schema, makeHandler(opts.schema));
-}
-
diff --git a/static/css/fonts/Inter.css b/static/css/fonts/Inter.css
deleted file mode 100644
index c308cb83..00000000
--- a/static/css/fonts/Inter.css
+++ /dev/null
@@ -1,168 +0,0 @@
-/* cyrillic-ext */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 300;
-  src: url(../../fonts/Inter-cyrillic-ext-normal-300.woff2);
-  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
-}
-/* cyrillic */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 300;
-  src: url(../../fonts/Inter-cyrillic-normal-300.woff2);
-  unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
-}
-/* greek-ext */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 300;
-  src: url(../../fonts/Inter-greek-ext-normal-300.woff2);
-  unicode-range: U+1F00-1FFF;
-}
-/* greek */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 300;
-  src: url(../../fonts/Inter-greek-normal-300.woff2);
-  unicode-range: U+0370-03FF;
-}
-/* vietnamese */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 300;
-  src: url(../../fonts/Inter-vietnamese-normal-300.woff2);
-  unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+1EA0-1EF9, U+20AB;
-}
-/* latin-ext */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 300;
-  src: url(../../fonts/Inter-latin-ext-normal-300.woff2);
-  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
-}
-/* latin */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 300;
-  src: url(../../fonts/Inter-latin-normal-300.woff2);
-  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-/* cyrillic-ext */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 400;
-  src: url(../../fonts/Inter-cyrillic-ext-normal-400.woff2);
-  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
-}
-/* cyrillic */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 400;
-  src: url(../../fonts/Inter-cyrillic-normal-400.woff2);
-  unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
-}
-/* greek-ext */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 400;
-  src: url(../../fonts/Inter-greek-ext-normal-400.woff2);
-  unicode-range: U+1F00-1FFF;
-}
-/* greek */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 400;
-  src: url(../../fonts/Inter-greek-normal-400.woff2);
-  unicode-range: U+0370-03FF;
-}
-/* vietnamese */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 400;
-  src: url(../../fonts/Inter-vietnamese-normal-400.woff2);
-  unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+1EA0-1EF9, U+20AB;
-}
-/* latin-ext */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 400;
-  src: url(../../fonts/Inter-latin-ext-normal-400.woff2);
-  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
-}
-/* latin */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 400;
-  src: url(../../fonts/Inter-latin-normal-400.woff2);
-  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
-/* cyrillic-ext */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 700;
-  src: url(../../fonts/Inter-cyrillic-ext-normal-700.woff2);
-  unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
-}
-/* cyrillic */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 700;
-  src: url(../../fonts/Inter-cyrillic-normal-700.woff2);
-  unicode-range: U+0400-045F, U+0490-0491, U+04B0-04B1, U+2116;
-}
-/* greek-ext */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 700;
-  src: url(../../fonts/Inter-greek-ext-normal-700.woff2);
-  unicode-range: U+1F00-1FFF;
-}
-/* greek */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 700;
-  src: url(../../fonts/Inter-greek-normal-700.woff2);
-  unicode-range: U+0370-03FF;
-}
-/* vietnamese */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 700;
-  src: url(../../fonts/Inter-vietnamese-normal-700.woff2);
-  unicode-range: U+0102-0103, U+0110-0111, U+0128-0129, U+0168-0169, U+01A0-01A1, U+01AF-01B0, U+1EA0-1EF9, U+20AB;
-}
-/* latin-ext */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 700;
-  src: url(../../fonts/Inter-latin-ext-normal-700.woff2);
-  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
-}
-/* latin */
-@font-face {
-  font-family: 'Inter';
-  font-style: normal;
-  font-weight: 700;
-  src: url(../../fonts/Inter-latin-normal-700.woff2);
-  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
-}
diff --git a/static/css/fonts/README.md b/static/css/fonts/README.md
deleted file mode 100644
index aca33304..00000000
--- a/static/css/fonts/README.md
+++ /dev/null
@@ -1,30 +0,0 @@
-# Fonts
-
-## Inter.css
-
-`Inter.css` is a local copy of
-https://fonts.googleapis.com/css?family=Inter:300,300i,400,400i,700,700i, modified to pull
-font files (`.woff2`) from local sources. It was created
-using `download_google_fonts_css.py`.
-  
-## download_google_fonts_css.py
-
-`download_google_fonts_css.py` is a script that takes a google fonts CSS URL, downloads
-the file and linked fonts, then saves the fonts locally along with a modified CSS file to
-load them. Example call:
-
-```sh
-python3 download_google_fonts_css.py \
-  "https://fonts.googleapis.com/css?family=Inter:300,300i,400,400i,700,700i" \
-  ../../fonts \
-  ../../fonts 
-```
-  
-Which would pop out a `Inter.css` file that should be `@import url("Inter.css")`d
-somewhere in the site's SCSS (currently in
-[/assets/scss/_variables_project.scss](/assets/scss/_variables_project.scss)).
-
-Re-running the script and committing any new files is only necessary when a desired 
-font updates (not very often), or we want to change the font we're using. In that case,
-remove the existing font files at `/static/fonts/*.woff2` and re-run the script with a
-different URL.
diff --git a/static/css/fonts/download_google_fonts_css.py b/static/css/fonts/download_google_fonts_css.py
deleted file mode 100755
index cfb5c052..00000000
--- a/static/css/fonts/download_google_fonts_css.py
+++ /dev/null
@@ -1,134 +0,0 @@
-#!/usr/bin/env python3
-# Copyright 2021 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.
-
-# This script takes a google fonts CSS URL, downloads the referenced fonts locally
-# and spits out a modified CSS file which now points to those local fonts.
-#
-# Purely for the purposes of converting a website to use local font files instead of
-# making requests to Google Fonts.
-
-import re
-import requests
-import subprocess
-import sys
-
-# Pull the font filename to process and output directory to point at
-if len(sys.argv) < 4:
-    print(f"""
-Error: Not enough arguments.
-
-Usage: {sys.argv[0]} google_fonts_url font_directory css_font_path
-* google fonts url: A URL leading to a google font css file (i.e https://fonts.googleapis.com/css?family=Inter)
-* font directory: The location that font files will be downloaded to (i.e ../../fonts)
-* font path: The directory the resulting CSS will be pointing to, relative to site root (i.e /unstable/css/fonts).
-             This is where the browser will look for fonts.
-""")
-    sys.exit(1)
-
-google_fonts_url = sys.argv[1]
-font_output_dir = sys.argv[2]
-css_font_path = sys.argv[3]
-
-# Get font name
-if google_fonts_url.count(":") > 1:
-    # Account for font weights specified in the URL
-    # (i.e https://fonts.googleapis.com/css?family=Inter:300,300i,400,400i,700,700i)
-    url_match = re.match(r".*family=(.*):", google_fonts_url)
-else:
-    url_match = re.match(r".*family=(.*)", google_fonts_url)
-
-if not url_match:
-    print("Unable to extract font name, invalid google fonts URL:", google_fonts_url)
-    print("URL should look something like: https://fonts.googleapis.com/css?family=Inter...")
-    sys.exit(1)
-
-font_name = url_match.group(1)
-
-# Ensure font paths end with a trailing slash
-if not font_output_dir.endswith("/"):
-    font_output_dir += "/"
-if not css_font_path.endswith("/"):
-    css_font_path += "/"
-
-# Download the css file and split by newline
-resp = requests.get(
-    google_fonts_url,
-    # We need to set a believable user-agent, else google fonts won't give us
-    # all of the font weights we requested for some reason
-    headers={
-        "User-Agent": "User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:86.0) Gecko/20100101 Firefox/86.0"
-    }
-)
-if resp.status_code != 200:
-    print("Failed to download:", google_fonts_url, resp.status_code)
-    sys.exit(1)
-
-original_contents = resp.text.split("\n")
-
-# Download all referenced font files and write out new font file
-new_css_file_lines = []
-
-# Store metadata for helping give friendly names to each font file
-font_lang = None
-font_family = None
-font_style = None
-font_weight = 0
-for line in original_contents:
-    # Check if this line contains a font URL
-    match = re.match(r".*url\((.*)\) format.*", line)
-    if match:
-        # Download the font file
-        font_url = match.group(1)
-        print("Downloading font:", font_url)
-
-        resp = requests.get(font_url)
-        if resp.status_code == 200:
-            # Save the font file
-            filename = "%s-%s-%s-%d.woff2" % (
-                font_family, font_lang, font_style, font_weight
-            )
-            font_filepath = font_output_dir + filename
-            with open(font_filepath, "wb") as f:
-                print("Writing font file:", font_filepath)
-                f.write(resp.content)
-
-            # Replace google URL with local URL
-            line = re.sub(r"url\(.+\)", f"url({css_font_path + filename})", line)
-        else:
-            print("Warning: failed to download font file:", font_url)
-
-    # Check for font metadata. If there is some, we'll note it down and use it to help
-    # name font files when we write them out.
-    # Makes for nicer font filenames than fvQtMwCp50KnMw2boKod... etc.
-    font_lang_match = re.match(r"^/\* (.+) \*/$", line)
-    if font_lang_match:
-        font_lang = font_lang_match.group(1)
-    font_family_match = re.match(r".*font-family: '(.+)';$", line)
-    if font_family_match:
-        font_family = font_family_match.group(1)
-    font_style_match = re.match(r".*font-style: (.+);$", line)
-    if font_style_match:
-        font_style = font_style_match.group(1)
-    font_weight_match = re.match(r".*font-weight: (.+);$", line)
-    if font_weight_match:
-        font_weight = int(font_weight_match.group(1))
-
-    # Append the potentially modified line to the new css file
-    new_css_file_lines.append(line)
-
-# Write out the new font css file
-with open(font_name + ".css", "w") as f:
-    new_css_file_contents = "\n".join(new_css_file_lines)
-    f.write(new_css_file_contents)
diff --git a/static/css/fonts/requirements.txt b/static/css/fonts/requirements.txt
deleted file mode 100644
index f2293605..00000000
--- a/static/css/fonts/requirements.txt
+++ /dev/null
@@ -1 +0,0 @@
-requests
diff --git a/static/diagrams/README.md b/static/diagrams/README.md
deleted file mode 100644
index 0b74734c..00000000
--- a/static/diagrams/README.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Spec diagrams
-
-Non-ascii diagrams for the spec can be placed here for reference in the actual spec.
-Please include source material so the diagram can be recreated by a future editor.
-
-https://www.diagrams.net/ is a great ([open source](https://github.com/jgraph/drawio))
-tool for these sorts of things - include your `.drawio` file next to your diagram.
-
-Suggested settings for diagrams.net:
-* Export as PNG.
-* 100% size.
-* `20` for a border width.
-* No transparent background, shadow, or grid.
-* Include a copy of the diagram.
-
-To reference a diagram, use the absolute path when compiled. For example,
-`![membership-flow-diagram](/diagrams/membership.png)`
diff --git a/static/diagrams/membership.drawio b/static/diagrams/membership.drawio
deleted file mode 100644
index 8de798be..00000000
--- a/static/diagrams/membership.drawio
+++ /dev/null
@@ -1 +0,0 @@
-<mxfile host="Electron" modified="2022-02-18T05:31:13.369Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/16.5.1 Chrome/96.0.4664.110 Electron/16.0.7 Safari/537.36" etag="FwSKbslSItXwNPoLLuzM" version="16.5.1" type="device"><diagram id="4a_pTli-mcEMNPq0ciXK" name="Page-1">1VvZkto4FP0aqjIPdNnyBo9peklSnZmeoWayvKQECHC3sSghN5CvHxnLeFMbyeCFh1TQ9ZUX6Zyje6/UPWO02j0SuF5+xTPk9YA22/WMux4Auu4M2H+hZR9ZHE2LDAvizrhTYhi7vxE3xm6BO0ObjCPF2KPuOmucYt9HU5qxQULwNus2x172qWu4QAXDeAq9ovWbO6PLyDoATmL/hNzFMn6ybg+jKysYO/Mv2SzhDG9TJuO+Z4wIxjT6tdqNkBcOXjwuUb+Hd64eX4wgn8p0eNas3x+fbr2x/3O79n9ao2BI+zq/zRv0Av7F7A4v2PX5S9N9PBJoxgaGNzGhS7zAPvTuE+stwYE/Q+HjNNZKfJ4wXjOjzowviNI9n2UYUMxMS7ry+NXiJ/HX2+CATFHZd3BoQLJAtMQPRH7ht6QewAfsEeEVomTPHDh++9qNo5tG1IkgD1L3LQsMyPG1OPblt/tICNynHNZsTOkm9bTn0JA8Cgw5TjhRDDs3nWr+7Ef0Brne8evg+XzDRirbIzUEiekAIxVIFRDl+m8uRQVAZeGyXTKf8RoepnnLxEQSGm+IULSTmUymPZkRAxZvbxNi67E8LVOkjv1Ec50ZPeWhskXs8xBkIAMaJr2Q0g+v7vT1utgIJNloqrFRu9GG9qAKGZvEPwCiSZ3AVhQV7Vz6Pex+Y/HWj9SVux2/86Gxjxs+G4CoE7Di9rFb2Ej6HVpxx/oBYyjLt21Vk+9GEVMAjHABVtLLOfbpA1y5Xjg5Izb+Lgrl5E+0rUdMTbN1MR2IeBf4bTMvxTsWTVhy1NPTvIu71UI948JaLU2zsybbKMy1aJo7xRjLygVsoHXGCFeqSHs0d94Dtsde4XbChsFehL+g5+EtG0+gTfbFq2HHXyTwWLpWuPZhHUw8d9oDoxBDdPpHu4shqLQaOpnVUKuNkqYkJWWTmWYoqRc5ye7zTuzfxGy/N3GnwhixcoNy5W5gti3l4MfqeuSjOx2MlXWVeU9Qll2xQX0rtixgZIPlZuTBLMw0z3O7vGYb+SJL62u2MMhtUWSF+aVWiTL1MQYM69NYx7TPU9kYiPnqlGNlbxF9Je8lKgw2INfaiYBRO0aI+QAwDBi1q4kQs0uAbNKWw3ONSZs8oC+9BsiB17TlwKtcJAe553CSvFskL/gPcrxIFckvVs4R7qm0FdQkUXC1IFihcNgAntULgANg6LUItGXWg3Fdzz3HKN8IsrVS//Y2goBwd6MDsUo1cVdM/zOh6SfkvSHqTuF5LKkrVWQkN0GljRVVcBsxaeIoRysR5CbBanRKtIVhiDRQwdUAVV3OHcs6U84bEL5irvvqY8Embqdz3eN610Su+/W7/up/s/99HgXOuK/dYQT+FpwkCHfDhSN5ZamuZHUox4uKZLRkVw3zFPlMfQA6RD4haIAINOJSU/cTSkUpbwM1p0EzMIYdAk3p11740FLTm/CNnmgSsq+48l3qANNLsFrH/pBMz9Vw53wRl6zvXIaOsgnySToOHKuRSF83c6VzKxPpnyzV5PxbTGOHBUzf7ygiDHe98J0LhUwfH16M/Vuh1QSRYiUzQbauKCJS8bnCmYRcecwQ6AcQ6Idd1/aGIaww85gvKjEXR/xwuQ8nbHhLDyW0GTOCKnpzc5lELi2dPvZRbIre2mmoEq142DPM9WzTaUKqBrnExywvuJlmqX+LJ6+LStV+DaMR6BeDgwYiX/XixdDQzCYADYbZKptuqZWQc/4trr3C8yE8m8tLfdvn5c88a301RTt1IT9zh/yiOPuCbNsb//X58fafh/92v54o+fFZcJw0F3VUDTny19rFZaWkR/H0XHUASu9uqAPQzMhbv8VzcayZ/Mlf5J784aRx/z8=</diagram></mxfile>
\ No newline at end of file
diff --git a/static/diagrams/membership.png b/static/diagrams/membership.png
deleted file mode 100644
index 76198015..00000000
Binary files a/static/diagrams/membership.png and /dev/null differ
diff --git a/static/fonts/Inter-cyrillic-ext-normal-300.woff2 b/static/fonts/Inter-cyrillic-ext-normal-300.woff2
deleted file mode 100644
index 77f8fe74..00000000
Binary files a/static/fonts/Inter-cyrillic-ext-normal-300.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-cyrillic-ext-normal-400.woff2 b/static/fonts/Inter-cyrillic-ext-normal-400.woff2
deleted file mode 100644
index 0a28013d..00000000
Binary files a/static/fonts/Inter-cyrillic-ext-normal-400.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-cyrillic-ext-normal-700.woff2 b/static/fonts/Inter-cyrillic-ext-normal-700.woff2
deleted file mode 100644
index a5658ff7..00000000
Binary files a/static/fonts/Inter-cyrillic-ext-normal-700.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-cyrillic-normal-300.woff2 b/static/fonts/Inter-cyrillic-normal-300.woff2
deleted file mode 100644
index 9863e906..00000000
Binary files a/static/fonts/Inter-cyrillic-normal-300.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-cyrillic-normal-400.woff2 b/static/fonts/Inter-cyrillic-normal-400.woff2
deleted file mode 100644
index 9b199dff..00000000
Binary files a/static/fonts/Inter-cyrillic-normal-400.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-cyrillic-normal-700.woff2 b/static/fonts/Inter-cyrillic-normal-700.woff2
deleted file mode 100644
index e7c9b5c0..00000000
Binary files a/static/fonts/Inter-cyrillic-normal-700.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-greek-ext-normal-300.woff2 b/static/fonts/Inter-greek-ext-normal-300.woff2
deleted file mode 100644
index c5040704..00000000
Binary files a/static/fonts/Inter-greek-ext-normal-300.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-greek-ext-normal-400.woff2 b/static/fonts/Inter-greek-ext-normal-400.woff2
deleted file mode 100644
index 2133c2aa..00000000
Binary files a/static/fonts/Inter-greek-ext-normal-400.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-greek-ext-normal-700.woff2 b/static/fonts/Inter-greek-ext-normal-700.woff2
deleted file mode 100644
index 11f08273..00000000
Binary files a/static/fonts/Inter-greek-ext-normal-700.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-greek-normal-300.woff2 b/static/fonts/Inter-greek-normal-300.woff2
deleted file mode 100644
index e2d53b38..00000000
Binary files a/static/fonts/Inter-greek-normal-300.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-greek-normal-400.woff2 b/static/fonts/Inter-greek-normal-400.woff2
deleted file mode 100644
index 3d2f76d3..00000000
Binary files a/static/fonts/Inter-greek-normal-400.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-greek-normal-700.woff2 b/static/fonts/Inter-greek-normal-700.woff2
deleted file mode 100644
index 5b6ed500..00000000
Binary files a/static/fonts/Inter-greek-normal-700.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-latin-ext-normal-300.woff2 b/static/fonts/Inter-latin-ext-normal-300.woff2
deleted file mode 100644
index bf5bc647..00000000
Binary files a/static/fonts/Inter-latin-ext-normal-300.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-latin-ext-normal-400.woff2 b/static/fonts/Inter-latin-ext-normal-400.woff2
deleted file mode 100644
index ef110cb8..00000000
Binary files a/static/fonts/Inter-latin-ext-normal-400.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-latin-ext-normal-700.woff2 b/static/fonts/Inter-latin-ext-normal-700.woff2
deleted file mode 100644
index b42f8b12..00000000
Binary files a/static/fonts/Inter-latin-ext-normal-700.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-latin-normal-300.woff2 b/static/fonts/Inter-latin-normal-300.woff2
deleted file mode 100644
index 605d1b2d..00000000
Binary files a/static/fonts/Inter-latin-normal-300.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-latin-normal-400.woff2 b/static/fonts/Inter-latin-normal-400.woff2
deleted file mode 100644
index b5db4467..00000000
Binary files a/static/fonts/Inter-latin-normal-400.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-latin-normal-700.woff2 b/static/fonts/Inter-latin-normal-700.woff2
deleted file mode 100644
index f6215ed2..00000000
Binary files a/static/fonts/Inter-latin-normal-700.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-vietnamese-normal-300.woff2 b/static/fonts/Inter-vietnamese-normal-300.woff2
deleted file mode 100644
index 707bb805..00000000
Binary files a/static/fonts/Inter-vietnamese-normal-300.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-vietnamese-normal-400.woff2 b/static/fonts/Inter-vietnamese-normal-400.woff2
deleted file mode 100644
index c9fa5c59..00000000
Binary files a/static/fonts/Inter-vietnamese-normal-400.woff2 and /dev/null differ
diff --git a/static/fonts/Inter-vietnamese-normal-700.woff2 b/static/fonts/Inter-vietnamese-normal-700.woff2
deleted file mode 100644
index 0dfa0850..00000000
Binary files a/static/fonts/Inter-vietnamese-normal-700.woff2 and /dev/null differ
diff --git a/static/icons/unstable.png b/static/icons/unstable.png
deleted file mode 100644
index e870a38d..00000000
Binary files a/static/icons/unstable.png and /dev/null differ
diff --git a/static/js/toc.js b/static/js/toc.js
deleted file mode 100644
index fa36ba4a..00000000
--- a/static/js/toc.js
+++ /dev/null
@@ -1,314 +0,0 @@
-/*
-Copyright 2020, 2021 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.
-*/
-
-/*
-Account for id attributes that are in the sidebar nav
-*/
-function populateIds() {
-  const navItems = document.querySelectorAll(".td-sidebar-nav li");
-  return Array.from(navItems).map(item => item.id).filter(id => id != "");
-}
-
-/*
-Given an ID and an array of IDs, return s version of the original ID that's
-not equal to any of the IDs in the array.
-*/
-function uniquifyHeadingId(id, uniqueIDs) {
-  const baseId = id;
-  let counter = 0;
-  while (uniqueIDs.includes(id)) {
-    counter = counter + 1;
-    id = baseId + "-" + counter.toString();
-  }
-  return id;
-}
-
-/*
-Given an array of heading nodes, ensure they all have unique IDs.
-
-We have to do this mostly because of client-server modules, which are
-rendered separately then glued together with a template.
-Because heading IDs are generated in rendering, this means they can and will
-end up with duplicate IDs.
-*/
-function uniquifyHeadingIds(headings) {
-  const uniqueIDs = populateIds();
-  for (let heading of headings) {
-    const uniqueID = uniquifyHeadingId(heading.id, uniqueIDs);
-    uniqueIDs.push(uniqueID);
-    heading.id = uniqueID;
-  }
-}
-
-/*
-The document contains "normal" headings, and these have corresponding items
-in the ToC.
-
-The document might also contain H1 headings that act as titles for blocks of
-rendered data, like HTTP APIs or event schemas. Unlike "normal" headings,
-these headings don't appear in the ToC. But they do have anchor IDs to enable
-links to them. When someone follows a link to one of these "rendered data"
-headings we want to scroll the ToC to the item corresponding to the "normal"
-heading preceding the "rendered data" heading we have visited.
-
-To support this we need to add `data` attributes to ToC items.
-These attributes identify which "rendered data" headings live underneath
-the heading corresponding to that ToC item.
-*/
-function setTocItemChildren(toc, headings) {
-  let tocEntryForHeading  = null;
-  for (const heading of headings) {
-    // H1 headings are rendered-data headings
-    if (heading.tagName !== "H1") {
-      tocEntryForHeading = document.querySelector(`nav li a[href="#${heading.id}"]`);
-    } else {
-      // on the ToC entry for the parent heading,
-      // set a data-* attribute whose name is the child's fragment ID
-      tocEntryForHeading.setAttribute(`data-${heading.id}`, "true");
-    }
-  }
-}
-
-/*
-Generate a table of contents based on the headings in the document.
-*/
-function makeToc() {
-
-  // make the title from the H1
-  const h1 = document.body.querySelector("h1");
-  const title = document.createElement("a");
-  title.id = "toc-title";
-  title.setAttribute("href", "#");
-  title.textContent = h1.textContent;
-
-  // make the content
-  const content = document.body.querySelector(".td-content");
-  let headings = [].slice.call(content.querySelectorAll("h2, h3, h4, h5, h6, .rendered-data > details > summary > h1"));
-
-  // exclude headings that don't have IDs.
-  headings = headings.filter(heading => heading.id);
-  uniquifyHeadingIds(headings);
-
-  // exclude .rendered-data > h1 headings from the ToC
-  const tocTargets = headings.filter(heading => heading.tagName !== "H1");
-
-  // we have to adjust heading IDs to ensure that they are unique
-  const nav = document.createElement("nav");
-  nav.id = "TableOfContents";
-
-  const section = makeTocSection(tocTargets, 0);
-  nav.appendChild(section.content);
-  // append title and content to the #toc placeholder
-  const toc = document.body.querySelector("#toc");
-  toc.appendChild(title);
-  toc.appendChild(nav);
-
-  // tell ToC items about any rendered-data headings they contain
-  setTocItemChildren(section.content, headings);
-}
-
-// create a single ToC entry
-function makeTocEntry(heading) {
-  const li = document.createElement("li");
-  const a = document.createElement("a");
-  a.setAttribute("href", `#${heading.id}`);
-  a.textContent = heading.textContent;
-  li.appendChild(a);
-  return li;
-}
-
-/*
-Each ToC section is an `<ol>` element.
-ToC entries are `<li>` elements and these contain nested ToC sections,
-whenever we go to the next heading level down.
-*/
-function makeTocSection(headings, index) {
-  const ol = document.createElement("ol");
-  let previousHeading = null;
-  let previousLi = null;
-  let i = index;
-  const lis = [];
-  for (i; i < headings.length; i++) {
-    const thisHeading = headings[i];
-    if (previousHeading && (thisHeading.tagName > previousHeading.tagName)) {
-      // we are going down a heading level, create a new nested section
-      const section = makeTocSection(headings, i);
-      previousLi.appendChild(section.content);
-      i = section.index -1;
-    }
-    else if (previousHeading && (previousHeading.tagName > thisHeading.tagName)) {
-      // we have come back up a level, so a section is finished
-      for (let li of lis) {
-        ol.appendChild(li);
-      }
-      return {
-        content: ol,
-        index: i
-      }
-    }
-    else {
-      // we are still processing this section, so add this heading to the current section
-      previousLi = makeTocEntry(thisHeading);
-      lis.push(previousLi);
-      previousHeading = thisHeading;
-    }
-  }
-  for (let li of lis) {
-    ol.appendChild(li);
-  }
-  return  {
-    content: ol,
-    index: i
-  }
-}
-
-/*
-Set a new ToC entry.
-Clear any previously highlighted ToC items, set the new one,
-and adjust the ToC scroll position.
-*/
-function setTocEntry(newEntry) {
-  const activeEntries = document.querySelectorAll("#toc a.active");
-  for (const activeEntry of activeEntries) {
-    activeEntry.classList.remove('active');
-  }
-
-  newEntry.classList.add('active');
-  // don't scroll the sidebar nav if the main content is not scrolled
-  const nav = document.querySelector("#td-section-nav");
-  const content = document.querySelector("html");
-  if (content.scrollTop !== 0) {
-    nav.scrollTop = newEntry.offsetTop - 100;
-  } else {
-    nav.scrollTop = 0;
-  }
-}
-
-/*
-Test whether a node is in the viewport
-*/
-function isInViewport(node) {
-  const rect = node.getBoundingClientRect();
-  return (
-    rect.top >= 0 &&
-    rect.left >= 0 &&
-    rect.bottom <= (window.innerHeight || document.documentElement.clientHeight) &&
-    rect.right <= (window.innerWidth || document.documentElement.clientWidth)
-  );
-}
-
-/*
-The callback we pass to the IntersectionObserver constructor.
-
-Called when any of our observed nodes starts or stops intersecting
-with the viewport.
-*/
-function handleIntersectionUpdate(entries) {
-
-  /*
-  Special case: If the current URL hash matches a ToC entry, and
-  the corresponding heading is visible in the viewport, then that is
-  made the current ToC entry, and we don't even look at the intersection
-  observer data.
-  This means that if the user has clicked on a ToC entry,
-  we won't unselect it through the intersection observer.
-  */
-  const hash = document.location.hash;
-  if (hash) {
-    let tocEntryForHash = document.querySelector(`nav li a[href="${hash}"]`);
-    // if the hash isn't a direct match for a ToC item, check the data attributes
-    if (!tocEntryForHash) {
-      const fragment = hash.substring(1);
-      tocEntryForHash = document.querySelector(`nav li a[data-${fragment}]`);
-    }
-    if (tocEntryForHash) {
-      const headingForHash = document.querySelector(hash);
-      if (headingForHash && isInViewport(headingForHash)) {
-        setTocEntry(tocEntryForHash);
-        return;
-      }
-    }
-  }
-
-  let newEntry = null;
-
-  for (const entry of entries) {
-    if (entry.intersectionRatio > 0) {
-      const heading = entry.target;
-      /*
-      This sidebar nav consists of two sections:
-      * at the top, a sitenav containing links to other pages
-      * under that, the ToC for the current page
-
-      Since the sidebar scrolls to match the document position,
-      the sitenav will tend to scroll off the screen.
-
-      If the user has scrolled up to (or near) the top of the page,
-      we want to show the sitenav so.
-
-      So: if the H1 (title) for the current page has started
-      intersecting, then always scroll the sidebar back to the top.
-      */
-      if (heading.tagName === "H1" && heading.parentNode.tagName === "DIV") {
-        const nav = document.querySelector("#td-section-nav");
-        nav.scrollTop = 0;
-        return;
-      }
-      /*
-      Otherwise, get the ToC entry for the first entry that
-      entered the viewport, if there was one.
-      */
-      const id = entry.target.getAttribute('id');
-      let tocEntry = document.querySelector(`nav li a[href="#${id}"]`);
-      // if the id isn't a direct match for a ToC item,
-      // check the ToC entry's `data-*` attributes
-      if (!tocEntry) {
-        tocEntry = document.querySelector(`nav li a[data-${id}]`);
-      }
-      if (tocEntry && !newEntry) {
-        newEntry = tocEntry;
-      }
-    }
-  }
-
-  if (newEntry) {
-    setTocEntry(newEntry);
-    return;
-  }
-}
-
-/*
-Track when headings enter the viewport, and use this to update the highlight
-for the corresponding ToC entry.
-*/
-window.addEventListener('DOMContentLoaded', () => {
-
-  makeToc();
-
-  const toc = document.querySelector("#toc");
-  toc.addEventListener("click", event => {
-    if (event.target.tagName === "A") {
-      setTocEntry(event.target);
-    }
-  });
-
-  const observer = new IntersectionObserver(handleIntersectionUpdate);
-
-  document.querySelectorAll("h1, h2, h3, h4, h5, h6").forEach((section) => {
-    observer.observe(section);
-  });
-
-});
diff --git a/themes/docsy b/themes/docsy
deleted file mode 160000
index 5023a291..00000000
--- a/themes/docsy
+++ /dev/null
@@ -1 +0,0 @@
-Subproject commit 5023a2914528e012ecf3ec85a56028c00ee97dd2