Files
synapse/docs
Paul ChobertandEric Eastwood 3c46a10955 Stabilise MSC4222: support the stable use_state_after identifiers on /sync (#20170)
Part of #19414 (Support Matrix 1.16).

⚠️ Before merging, wait for the following PRs to be merged first:
- https://github.com/element-hq/synapse/pull/20081
- https://github.com/element-hq/synapse/pull/20169
- https://github.com/element-hq/synapse/pull/20171

---

Since Matrix 1.16, the
[spec](https://spec.matrix.org/v1.19/client-server-api/#get_matrixclientv3sync)
defines the stable identifiers for
[MSC4222](https://github.com/matrix-org/matrix-spec-proposals/pull/4222):
the `use_state_after` query parameter on `GET /_matrix/client/v3/sync`,
and the `state_after` room response field:

> **`use_state_after`** — `boolean` — Controls whether to receive state
changes between the previous sync and the start of the timeline, or
between the previous sync and the end of the timeline. If this is set to
`true`, servers MUST respond with the state between the previous sync
and the end of the timeline in `state_after` and MUST omit `state`. […]
>
> **`state_after`** — […] Required if `use_state_after` was set to true
in the request, even if it is empty. Added in `v1.16`
>
> — [Matrix
Spec](https://spec.matrix.org/v1.19/client-server-api/#get_matrixclientv3sync)

Synapse so far only implemented the unstable identifiers
(`org.matrix.msc4222.use_state_after` /
`org.matrix.msc4222.state_after`), gated behind the `msc4222_enabled`
experimental flag and the per-user experimental features admin API.

This PR:

- accepts the stable `use_state_after` query parameter, unconditionally,
and responds with the stable `state_after` field. The unstable query
parameter is kept for a transition period; clients opting in with it get
the unstable response field name back, so unstable-era clients see an
unchanged wire format. If both parameters are set, the stable one wins.
- removes the `msc4222_enabled` experimental flag and the `msc4222`
per-user feature from the experimental features admin API, since the
behaviour is no longer gated.

### Pull Request Checklist

<!-- Please read
https://element-hq.github.io/synapse/latest/development/contributing_guide.html
before submitting your pull request -->

* [x] Pull request is based on the develop branch
* [x] Pull request includes a [changelog
file](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#changelog).
The entry should:
- Be a short description of your change which makes sense to users.
"Fixed a bug that prevented receiving messages from other servers."
instead of "Moved X method from `EventStore` to `EventWorkerStore`.".
  - Use markdown where necessary, mostly for `code blocks`.
  - End with either a period (.) or an exclamation mark (!).
  - Start with a capital letter.
- Feel free to credit yourself, by adding a sentence "Contributed by
@github_username." or "Contributed by [Your Name]." to the end of the
entry.
* [x] [Code
style](https://element-hq.github.io/synapse/latest/code_style.html) is
correct (run the
[linters](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#run-the-linters))

---------

Co-authored-by: Eric Eastwood <madlittlemods@gmail.com>
2026-10-08 15:14:23 +02:00
..
2024-02-06 09:26:55 +00:00
2023-12-13 16:37:10 +00:00
2023-12-13 16:15:22 +00:00
2025-05-20 13:31:05 +00:00
2026-08-13 11:13:36 +01:00
2023-12-13 16:15:22 +00:00
2023-12-13 16:37:10 +00:00

Synapse Documentation

The documentation is currently hosted here. Please update any links to point to the new website instead.

About

This directory currently holds a series of markdown files documenting how to install, use and develop Synapse. The documentation is readable directly from this repository, but it is recommended to instead browse through the website for easier discoverability.

Adding to the documentation

Most of the documentation currently exists as top-level files, as when organising them into a structured website, these files were kept in place so that existing links would not break. The rest of the documentation is stored in folders, such as setup, usage, and development etc. All new documentation files should be placed in structured folders. For example:

To create a new user-facing documentation page about a new Single Sign-On protocol named "MyCoolProtocol", one should create a new file with a relevant name, such as "my_cool_protocol.md". This file might fit into the documentation structure at:

  • Usage
    • Configuration
      • User Authentication
        • Single Sign-On
          • My Cool Protocol

Given that, one would place the new file under usage/configuration/user_authentication/single_sign_on/my_cool_protocol.md.

Note that the structure of the documentation (and thus the left sidebar on the website) is determined by the list in SUMMARY.md. The final thing to do when adding a new page is to add a new line linking to the new documentation file:

- [My Cool Protocol](usage/configuration/user_authentication/single_sign_on/my_cool_protocol.md)

Building the documentation

The documentation is built with mdbook, and the outline of the documentation is determined by the structure of SUMMARY.md.

Building the documentation requires running some python. Ensure you have set up poetry, then run:

poetry install --only docs --no-root

to install just the python dependencies needed to build the documentation.

Then, install mdbook, which will convert the source markdown to HTML pages.

Finally, from the root of the repository, build the documentation with:

poetry run mdbook build

The rendered contents will be outputted to a new book/ directory at the root of the repository. Please note that index.html is not built by default, it is created by copying over the file welcome_and_overview.html to index.html during deployment. Thus, when running mdbook serve locally the book will initially show a 404 in place of the index due to the above. Do not be alarmed!

You can also have mdbook host the docs on a local webserver with hot-reload functionality via:

mdbook serve

The URL at which the docs can be viewed at will be logged.

Synapse configuration documentation

The Configuration Manual page is generated from a YAML file, schema/synapse-config.schema.yaml. To add new options or modify existing ones, first edit that file, then run scripts-dev/gen_config_documentation.py to generate an updated Configuration Manual markdown file.

Build the book as described above to preview it in a web browser.

Configuration and theming

The look and behaviour of the website is configured by the book.toml file at the root of the repository. See mdbook's documentation on configuration for available options.

The site can be themed and additionally extended with extra UI and features. See website_files/README.md for details.