mirror of
https://github.com/element-hq/synapse.git
synced 2026-11-03 15:52:48 +00:00
Paul ChobertandEric Eastwood
3c46a10955
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>
1.4 KiB
1.4 KiB
Experimental Features API
This API allows a server administrator to enable or disable some experimental features on a per-user basis. The currently supported features are:
- MSC3881: enable remotely toggling push notifications for another client
- MSC3575: enable experimental sliding sync support
To use it, you will need to authenticate by providing an access_token
for a server admin: see Admin API.
Enabling/Disabling Features
This API allows a server administrator to enable experimental features for a given user. The request must provide a body containing the user id and listing the features to enable/disable in the following format:
{
"features": {
"msc3026":true,
"msc3881":true
}
}
where true is used to enable the feature, and false is used to disable the feature.
The API is:
PUT /_synapse/admin/v1/experimental_features/<user_id>
Listing Enabled Features
To list which features are enabled/disabled for a given user send a request to the following API:
GET /_synapse/admin/v1/experimental_features/<user_id>
It will return a list of possible features and indicate whether they are enabled or disabled for the user like so:
{
"features": {
"msc3026": true,
"msc3881": false,
"msc3967": false
}
}