From 617804e3c71760e06572e7c1a64c5a1ecf957536 Mon Sep 17 00:00:00 2001 From: Johannes Marbach Date: Fri, 31 Oct 2025 08:09:37 +0100 Subject: [PATCH] Clarify how to use state_after ahead of declaring full support for its spec version Signed-off-by: Johannes Marbach --- .../client_server/newsfragments/2240.clarification | 1 + data/api/client-server/sync.yaml | 13 +++++++++---- 2 files changed, 10 insertions(+), 4 deletions(-) create mode 100644 changelogs/client_server/newsfragments/2240.clarification diff --git a/changelogs/client_server/newsfragments/2240.clarification b/changelogs/client_server/newsfragments/2240.clarification new file mode 100644 index 000000000..07081f284 --- /dev/null +++ b/changelogs/client_server/newsfragments/2240.clarification @@ -0,0 +1 @@ +Clarify how to use `state_after` ahead of declaring full support for its spec version. diff --git a/data/api/client-server/sync.yaml b/data/api/client-server/sync.yaml index 966801808..8186dde57 100644 --- a/data/api/client-server/sync.yaml +++ b/data/api/client-server/sync.yaml @@ -133,10 +133,15 @@ paths: sync and the **start** of the timeline in `state` and MUST omit `state_after`. - Even if this is set to `true`, clients MUST update their local state - with events in `state` and `timeline` if `state_after` is missing in - the response, for compatibility with servers that don't support this - parameter. + Servers MAY implement this parameter ahead of declaring support for + the version of the spec in which it was introduced. Consequently, + clients MAY set this parameter to `true` regardless of the + [`/versions`](/client-server-api/#get_matrixclientversions) response. + If they do, they can infer whether the server actually supports this + parameter from the presence of `state_after` in the response. If + `state_after` is missing, clients MUST behave as if they had not + specified the parameter and update their local state with events + in `state` and `timeline`. By default, this is `false`. example: false