From 5f22967730eb2aab05919e1f54558b8a1ed69ff4 Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Wed, 9 Jul 2025 12:32:37 +0100 Subject: [PATCH 01/13] MSC4308 (sliding sync ext. thread subscriptions): init --- ...8-sliding-sync-ext-thread-subscriptions.md | 94 +++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 proposals/4308-sliding-sync-ext-thread-subscriptions.md diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md new file mode 100644 index 00000000000..5cbfe5e0a7e --- /dev/null +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -0,0 +1,94 @@ +MSC4308: Thread Subscriptions extension to Sliding Sync +=== + +## Background and Summary + +Threads were introduced in [version 1.4 of the Matrix Specification](https://spec.matrix.org/v1.13/changelog/v1.4/) as a way to isolate conversations in a room, making it easier for users to track specific conversations that they care about (and ignore those that they do not). + +Threads Subscriptions are proposed in [MSC4306](https://github.com/matrix-org/matrix-spec-proposals/blob/rei/msc_thread_subscriptions/proposals/4306-thread-subscriptions.md) as a way for users to efficiently indicate which threads they care about, for the purposes of receiving updates. + +Sliding Sync is proposed in [MSC4186](https://github.com/matrix-org/matrix-spec-proposals/blob/erikj/sss/proposals/4186-simplified-sliding-sync.md) as a paginated replacement to `/_matrix/client/v3/sync` with smaller response bodies and lower latency. +The `/_matrix/client/v3/sync` endpoint is notorious in real-world applications of Matrix for producing large response bodies (to the amplified detriment of mobile clients) and the high latency caused by waiting for the server to calculate that full payload. + +This MSC proposes an 'extension' to Sliding Sync that allows clients to opt-in to receiving updates to the user's thread subscriptions. + +## Proposal + +The Sliding Sync request format is extended to include the `thread_subscriptions` extension as follows: + +```jsonc +{ + // ... + + "extensions": { + // ... + + // Used to opt-in to receiving updates to thread subscriptions. + "thread_subscriptions": { + // Maximum number of thread subscription changes to receive. + // Defaults to 100. + "limit": 100, + } + } +} +``` + +The response format is then extended to compensate: + +```jsonc +{ + // ... + + "extensions": { + // ... + + // Returns a limited window of updates to thread subscriptions + "thread_subscriptions": { + "changed": [ + { + "room_id": "!roomid:example.org", + "root_event_id": "$abc123", + + "subscribed": true, + + // must be present when subscribed is true, + // but must be absent when subscribed is false + "automatic": true + }, + { + "room_id": "!roomid:example.org", + "root_event_id": "$def456", + + "subscribed": false + }, + ... + ] + } + } +} +``` + +## Potential issues + +When clients start a fresh sync with no initial state, it may be the case that there is a backlog of many thread_subscriptions to send down to the client. + +Servers MAY choose to return Thread Subscription Settings in an order that is more heuristically-useful to the client, such as 'most recently updated' or 'threads with most recent activity first', instead of 'oldest first'. This could be either for all Thread Subscriptions, or only the backlogged ones. + +## Alternatives + + +## Limitations + + +## Security considerations + +- No particular security issues anticipated. + +## Unstable prefix + +TODO + +## Dependencies + +- [MSC4186 Sliding Sync](https://github.com/matrix-org/matrix-spec-proposals/blob/erikj/sss/proposals/4186-simplified-sliding-sync.md) +- [MSC4306 Threads Subscriptions](https://github.com/matrix-org/matrix-spec-proposals/blob/rei/msc_thread_subscriptions/proposals/4306-thread-subscriptions.md) From 8ba12b44c4e6ec1cff799a4968ad631d30ae1566 Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Fri, 8 Aug 2025 16:49:38 +0100 Subject: [PATCH 02/13] Restructure response and add companion endpoint --- ...8-sliding-sync-ext-thread-subscriptions.md | 135 ++++++++++++++---- 1 file changed, 105 insertions(+), 30 deletions(-) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index 5cbfe5e0a7e..6859ed11b5e 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -10,23 +10,30 @@ Threads Subscriptions are proposed in [MSC4306](https://github.com/matrix-org/ma Sliding Sync is proposed in [MSC4186](https://github.com/matrix-org/matrix-spec-proposals/blob/erikj/sss/proposals/4186-simplified-sliding-sync.md) as a paginated replacement to `/_matrix/client/v3/sync` with smaller response bodies and lower latency. The `/_matrix/client/v3/sync` endpoint is notorious in real-world applications of Matrix for producing large response bodies (to the amplified detriment of mobile clients) and the high latency caused by waiting for the server to calculate that full payload. -This MSC proposes an 'extension' to Sliding Sync that allows clients to opt-in to receiving updates to the user's thread subscriptions. +This MSC proposes an 'extension' to Sliding Sync that allows clients to opt-in to receiving real-time updates to the user's thread subscriptions. + +To handle the case in which there have been many updates to the user's thread subscriptions and there are too many to return in +Sliding Sync, a new companion endpoint is proposed to allow backpaginating thread subscriptions on the client's terms. ## Proposal +### Sliding Sync extension + The Sliding Sync request format is extended to include the `thread_subscriptions` extension as follows: ```jsonc { // ... - + "extensions": { // ... - - // Used to opt-in to receiving updates to thread subscriptions. + + // Used to opt-in to receiving changes to thread subscriptions. "thread_subscriptions": { - // Maximum number of thread subscription changes to receive. + // Maximum number of thread subscription changes to receive + // in the response. // Defaults to 100. + // Servers may impose a smaller limit than what is requested here. "limit": 100, } } @@ -38,41 +45,105 @@ The response format is then extended to compensate: ```jsonc { // ... - + "extensions": { // ... - - // Returns a limited window of updates to thread subscriptions + + // Returns a limited window of changes to thread subscriptions + // Only the latest changes are returned in this window. "thread_subscriptions": { - "changed": [ - { - "room_id": "!roomid:example.org", - "root_event_id": "$abc123", - - "subscribed": true, - - // must be present when subscribed is true, - // but must be absent when subscribed is false - "automatic": true - }, - { - "room_id": "!roomid:example.org", - "root_event_id": "$def456", - - "subscribed": false + "changed": { + "!roomId1:example.org": { + // New subscription + "$threadId1": { + "automatic": true + }, + // New subscription + // or subscription changed to manual + "$threadId2": { + "automatic": false + }, + // Represents a removed subscription + "$threadId3": null }, - ... - ] + "$roomId2:example.org": { + // ... + } + // ... + }, + + // A token that can be used to backpaginate other thread subscription + // changes that occurred since the last sync, but that were not + // included in this response. + // + // Only present when some thread subscriptions have been missed out + // from the response because there are too many of them. + "gap": "OPAQUE_TOKEN" } } } ``` -## Potential issues +If two changes occur to the same subscription, only the latter change ever needs +to be sent to the client. \ +Servers do not need to store intermediate subscription states. + + +### Companion endpoint for backpaginating thread subscription changes + +``` +GET /_matrix/v1/thread_subscriptions +``` + +URL parameters: -When clients start a fresh sync with no initial state, it may be the case that there is a backlog of many thread_subscriptions to send down to the client. +- `pos` (string, optional): a token used to continue backpaginating \ + The token is either acquired from a previous `/thread_subscriptions` response, + or a Sliding Sync response. \ + The token is opaque and has no client-discernible meaning. \ + If this token is not provided, then backpagination starts from the 'end'. + +- `limit` (int, optional; default `100`): a maximum number of thread subscriptions to fetch + in one response. \ + Must be greater than zero. Servers may impose a smaller limit than requested. + +Response body: + +``` +{ + // Required + "chunk": { + "!roomId1:example.org": { + // New subscription + "$threadId1": { + "automatic": true + }, + // New subscription + // or subscription changed to manual + "$threadId2": { + "automatic": false + }, + // Represents a removed subscription + "$threadId3": null + }, + "$roomId2:example.org": { + // ... + } + }, + // If there are still more thread subscriptions to fetch, + // a new `pos` token the client can use to walk further + // backwards. + "pos": "OPAQUE_TOKEN" +} +``` + +If two changes occur to the same subscription, only the latter change ever needs +to be sent to the client. \ +Servers do not need to store intermediate subscription states. + + +## Potential issues -Servers MAY choose to return Thread Subscription Settings in an order that is more heuristically-useful to the client, such as 'most recently updated' or 'threads with most recent activity first', instead of 'oldest first'. This could be either for all Thread Subscriptions, or only the backlogged ones. ## Alternatives @@ -86,7 +157,11 @@ Servers MAY choose to return Thread Subscription Settings in an order that is mo ## Unstable prefix -TODO +Whilst this proposal is unstable, a few unstable prefixes must be observed by experimental implementations: + +- the Sliding Sync extension is called `io.element.msc4306.thread_subscriptions` instead of `thread_subscriptions` +- the companion endpoint is called `/_matrix/client/unstable/io.element.msc4308/thread_subscriptions` instead of `/_matrix/v1/thread_subscriptions` + ## Dependencies From 878f8f5bc48655bc9eda7f373dced62d8f03b22e Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Mon, 11 Aug 2025 14:15:09 +0100 Subject: [PATCH 03/13] Fix typo in unstable prefix --- proposals/4308-sliding-sync-ext-thread-subscriptions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index 6859ed11b5e..df6bed3f995 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -159,7 +159,7 @@ Servers do not need to store intermediate subscription states. Whilst this proposal is unstable, a few unstable prefixes must be observed by experimental implementations: -- the Sliding Sync extension is called `io.element.msc4306.thread_subscriptions` instead of `thread_subscriptions` +- the Sliding Sync extension is called `io.element.msc4308.thread_subscriptions` instead of `thread_subscriptions` - the companion endpoint is called `/_matrix/client/unstable/io.element.msc4308/thread_subscriptions` instead of `/_matrix/v1/thread_subscriptions` From 6029082d8726f095f83ebb3ef70e3572be03e967 Mon Sep 17 00:00:00 2001 From: reivilibre Date: Tue, 12 Aug 2025 13:41:06 +0100 Subject: [PATCH 04/13] Update proposals/4308-sliding-sync-ext-thread-subscriptions.md Co-authored-by: Eric Eastwood --- proposals/4308-sliding-sync-ext-thread-subscriptions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index df6bed3f995..7686c61343a 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -109,7 +109,7 @@ URL parameters: Response body: -``` +```jsonc { // Required "chunk": { From 9e03a0626a57e4d91e85f1904662aa8b436bd47d Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Tue, 12 Aug 2025 15:46:59 +0100 Subject: [PATCH 05/13] Follow /messages pagination convention a bit more closely --- ...8-sliding-sync-ext-thread-subscriptions.md | 23 +++++++++++++++---- 1 file changed, 18 insertions(+), 5 deletions(-) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index 7686c61343a..4b1eb86203a 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -72,13 +72,16 @@ The response format is then extended to compensate: // ... }, - // A token that can be used to backpaginate other thread subscription + // A pair of tokens that can be used to backpaginate other thread subscription // changes that occurred since the last sync, but that were not // included in this response. // + // The tokens are to be used with the `/thread_subscriptions` endpoint + // as `from` and `to` parameters with `dir=b`. + // // Only present when some thread subscriptions have been missed out // from the response because there are too many of them. - "gap": "OPAQUE_TOKEN" + "prev": {"from": "OPAQUE_TOKEN", "to": "OPAQUE_TOKEN"} } } } @@ -97,16 +100,23 @@ GET /_matrix/v1/thread_subscriptions URL parameters: -- `pos` (string, optional): a token used to continue backpaginating \ +- `dir` (string, required): always `b` (backward), to mirror other pagination + endpoints. The forward direction is not yet specified to be implemented. + +- `from` (string, optional): a token used to continue backpaginating \ The token is either acquired from a previous `/thread_subscriptions` response, or a Sliding Sync response. \ The token is opaque and has no client-discernible meaning. \ If this token is not provided, then backpagination starts from the 'end'. +- `to` (string, optional): a token used to limit the backpagination \ + The token can be acquired from a Sliding Sync response. + - `limit` (int, optional; default `100`): a maximum number of thread subscriptions to fetch in one response. \ Must be greater than zero. Servers may impose a smaller limit than requested. + Response body: ```jsonc @@ -131,9 +141,9 @@ Response body: } }, // If there are still more thread subscriptions to fetch, - // a new `pos` token the client can use to walk further + // a new `from` token the client can use to walk further // backwards. - "pos": "OPAQUE_TOKEN" + "end": "OPAQUE_TOKEN" } ``` @@ -141,6 +151,9 @@ If two changes occur to the same subscription, only the latter change ever needs to be sent to the client. \ Servers do not need to store intermediate subscription states. +The pagination structure of this endpoint matches that of the `/messages` endpoint, but fixed +to the backward direction (`dir=b`). +For simplicity, the `start` response field is removed as it is entirely redundant. ## Potential issues From ede25dfe066ad72caa661e98609c9dd8ac1d676e Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Tue, 12 Aug 2025 15:51:05 +0100 Subject: [PATCH 06/13] Fix missing /client in path --- proposals/4308-sliding-sync-ext-thread-subscriptions.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index 4b1eb86203a..667acb581aa 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -95,7 +95,7 @@ Servers do not need to store intermediate subscription states. ### Companion endpoint for backpaginating thread subscription changes ``` -GET /_matrix/v1/thread_subscriptions +GET /_matrix/client/v1/thread_subscriptions ``` URL parameters: @@ -173,7 +173,7 @@ For simplicity, the `start` response field is removed as it is entirely redundan Whilst this proposal is unstable, a few unstable prefixes must be observed by experimental implementations: - the Sliding Sync extension is called `io.element.msc4308.thread_subscriptions` instead of `thread_subscriptions` -- the companion endpoint is called `/_matrix/client/unstable/io.element.msc4308/thread_subscriptions` instead of `/_matrix/v1/thread_subscriptions` +- the companion endpoint is called `/_matrix/client/unstable/io.element.msc4308/thread_subscriptions` instead of `/_matrix/client/v1/thread_subscriptions` ## Dependencies From a5e3e785909dbadf14ff3c4b49da52fae0616f75 Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Tue, 12 Aug 2025 15:54:48 +0100 Subject: [PATCH 07/13] Should re-use `to` token --- proposals/4308-sliding-sync-ext-thread-subscriptions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index 667acb581aa..61c5c895065 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -142,7 +142,7 @@ Response body: }, // If there are still more thread subscriptions to fetch, // a new `from` token the client can use to walk further - // backwards. + // backwards. (The `to` token, if used, should be reused.) "end": "OPAQUE_TOKEN" } ``` From 058ce7f5556ef1168fa02dce5567be58e1fb2c77 Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Mon, 18 Aug 2025 16:03:15 +0100 Subject: [PATCH 08/13] Rejig backpagination to use prev_batch (like /sync <> /messages) --- .../4308-sliding-sync-ext-thread-subscriptions.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index 61c5c895065..14ccd3c0215 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -72,16 +72,18 @@ The response format is then extended to compensate: // ... }, - // A pair of tokens that can be used to backpaginate other thread subscription + // A token that can be used to backpaginate other thread subscription // changes that occurred since the last sync, but that were not // included in this response. // - // The tokens are to be used with the `/thread_subscriptions` endpoint - // as `from` and `to` parameters with `dir=b`. + // The token is to be used with the `/thread_subscriptions` endpoint + // as `from`, with `dir`=`b`. + // The `pos` parameter in the **request** would be used for the `to` + // parameter. // // Only present when some thread subscriptions have been missed out // from the response because there are too many of them. - "prev": {"from": "OPAQUE_TOKEN", "to": "OPAQUE_TOKEN"} + "prev_batch": "OPAQUE_TOKEN" } } } @@ -105,7 +107,7 @@ URL parameters: - `from` (string, optional): a token used to continue backpaginating \ The token is either acquired from a previous `/thread_subscriptions` response, - or a Sliding Sync response. \ + or the `prev_batch` in a Sliding Sync response. \ The token is opaque and has no client-discernible meaning. \ If this token is not provided, then backpagination starts from the 'end'. @@ -149,12 +151,13 @@ Response body: If two changes occur to the same subscription, only the latter change ever needs to be sent to the client. \ -Servers do not need to store intermediate subscription states. +Servers MUST not send intermediate subscription states to clients. The pagination structure of this endpoint matches that of the `/messages` endpoint, but fixed to the backward direction (`dir=b`). For simplicity, the `start` response field is removed as it is entirely redundant. + ## Potential issues From 5cf9c906a284288a50464b124638066c2ec4d2a5 Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Tue, 19 Aug 2025 16:17:28 +0100 Subject: [PATCH 09/13] Split the response format and introduce bump_stamps --- ...8-sliding-sync-ext-thread-subscriptions.md | 68 ++++++++++++++----- 1 file changed, 52 insertions(+), 16 deletions(-) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index 14ccd3c0215..68aa1617f92 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -52,23 +52,38 @@ The response format is then extended to compensate: // Returns a limited window of changes to thread subscriptions // Only the latest changes are returned in this window. "thread_subscriptions": { - "changed": { + // Threads that have been subscribed, or had their subscription + // changed. + // + // Optional. If omitted, has the same semantics as an empty map. + "subscribed": { "!roomId1:example.org": { // New subscription "$threadId1": { - "automatic": true + "automatic": true, + "bump_stamp": 4000 }, // New subscription // or subscription changed to manual "$threadId2": { - "automatic": false - }, - // Represents a removed subscription - "$threadId3": null + "automatic": false, + "bump_stamp": 4210 + } }, "$roomId2:example.org": { // ... } + }, + // Threads that have been unsubscribed. + // + // Optional. If omitted, has the same semantics as an empty map. + "unsubscribed": { + "!roomId3:example.org": { + // Represents a removed subscription + "$threadId3": { + "bump_stamp": 4242 + } + }, // ... }, @@ -81,8 +96,8 @@ The response format is then extended to compensate: // The `pos` parameter in the **request** would be used for the `to` // parameter. // - // Only present when some thread subscriptions have been missed out - // from the response because there are too many of them. + // Optional. Only present when some thread subscriptions have been + // missed out from the response because there are too many of them. "prev_batch": "OPAQUE_TOKEN" } } @@ -93,7 +108,6 @@ If two changes occur to the same subscription, only the latter change ever needs to be sent to the client. \ Servers do not need to store intermediate subscription states. - ### Companion endpoint for backpaginating thread subscription changes ``` @@ -123,25 +137,33 @@ Response body: ```jsonc { - // Required - "chunk": { + "subscribed": { "!roomId1:example.org": { // New subscription "$threadId1": { - "automatic": true + "automatic": true, + "bump_stamp": 4000 }, // New subscription // or subscription changed to manual "$threadId2": { - "automatic": false - }, - // Represents a removed subscription - "$threadId3": null + "automatic": false, + "bump_stamp": 4210 + } }, "$roomId2:example.org": { // ... } }, + "unsubscribed": { + "!roomId3:example.org": { + // Represents a removed subscription + "$threadId3": { + "bump_stamp": 4242 + } + }, + // ... + }, // If there are still more thread subscriptions to fetch, // a new `from` token the client can use to walk further // backwards. (The `to` token, if used, should be reused.) @@ -157,6 +179,20 @@ The pagination structure of this endpoint matches that of the `/messages` endpoi to the backward direction (`dir=b`). For simplicity, the `start` response field is removed as it is entirely redundant. +### Use of `bump_stamp` + +The `bump_stamp`s within each thread subscription can be used for determining which +state is latest, for example when a concurrent `/thread_subscriptions` backpagination request +and `/sync` request both return information about the same thread subscription. + +The semantics of the `bump_stamp` are that for two updates about the same thread, +the update with the higher `bump_stamp` is later and renders the update with the lower +`bump_stamp` obsolete. + +Clients MUST NOT interpret any other semantics of the `bump_stamp`; other than the semantics +above they do not have any special meaning. +Notably, `bump_stamp`s MUST NOT be compared between different threads, because servers MAY +treat `bump_stamp`s as per-thread. ## Potential issues From 5b51570214c752ec4978cfe9d699f65b7c1c6bac Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Fri, 19 Sep 2025 17:03:55 +0100 Subject: [PATCH 10/13] Add enabled request field --- proposals/4308-sliding-sync-ext-thread-subscriptions.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index 68aa1617f92..5b8679d10df 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -30,6 +30,8 @@ The Sliding Sync request format is extended to include the `thread_subscriptions // Used to opt-in to receiving changes to thread subscriptions. "thread_subscriptions": { + // Must be specified and true to enable the extension. + "enabled": true, // Maximum number of thread subscription changes to receive // in the response. // Defaults to 100. From cef3446ed3db0e49a56b617cc83ced0ac4a7a522 Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Fri, 19 Sep 2025 17:18:55 +0100 Subject: [PATCH 11/13] bump_stamp don't reset between SS sessions or even devices, but maybe users --- proposals/4308-sliding-sync-ext-thread-subscriptions.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index 5b8679d10df..72194f8c3e2 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -196,6 +196,10 @@ above they do not have any special meaning. Notably, `bump_stamp`s MUST NOT be compared between different threads, because servers MAY treat `bump_stamp`s as per-thread. +`bump_stamp`s are independent of the sliding sync session and remain valid for comparison +even if the sliding sync connection is reset, or if the device is changed. +Servers do not need to make `bump_stamp`s consistent across different users. + ## Potential issues From b3ac5ee7fed8fca5ec40313073140614d5e66403 Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Fri, 19 Sep 2025 17:26:05 +0100 Subject: [PATCH 12/13] bump_stamps are js_ints --- proposals/4308-sliding-sync-ext-thread-subscriptions.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index 72194f8c3e2..a8cc2e2f0d3 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -196,6 +196,8 @@ above they do not have any special meaning. Notably, `bump_stamp`s MUST NOT be compared between different threads, because servers MAY treat `bump_stamp`s as per-thread. +`bump_stamp` MUST be an ECMAScript-compatible (Canonical JSON-compatible) integer. + `bump_stamp`s are independent of the sliding sync session and remain valid for comparison even if the sliding sync connection is reset, or if the device is changed. Servers do not need to make `bump_stamp`s consistent across different users. From 4d88858787dd73ff948368e3cd58b124fcfed9bd Mon Sep 17 00:00:00 2001 From: "Olivier Wilkinson (reivilibre)" Date: Fri, 19 Sep 2025 17:29:06 +0100 Subject: [PATCH 13/13] Try to clarify which token we use --- proposals/4308-sliding-sync-ext-thread-subscriptions.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/4308-sliding-sync-ext-thread-subscriptions.md b/proposals/4308-sliding-sync-ext-thread-subscriptions.md index a8cc2e2f0d3..20311844ffa 100644 --- a/proposals/4308-sliding-sync-ext-thread-subscriptions.md +++ b/proposals/4308-sliding-sync-ext-thread-subscriptions.md @@ -128,7 +128,9 @@ URL parameters: If this token is not provided, then backpagination starts from the 'end'. - `to` (string, optional): a token used to limit the backpagination \ - The token can be acquired from a Sliding Sync response. + The token, originally acquired from `pos` in a Sliding Sync response, + would be the same one used as the `pos` **request** parameter in the + Sliding Sync request that returned the `prev_batch`. - `limit` (int, optional; default `100`): a maximum number of thread subscriptions to fetch in one response. \