MSC4186 Sliding Sync seems to be missing high-level stewardship on pagination strategies

Arguably a bit weird to be opening an issue about an MSC here but I'd argue MSC4186 Sliding Sync is so far along that it's quasi-specced. This concern also applies to several extension MSCs and so there's no 'natural' place to have a discussion about this, except maybe to make a self-contained issue like this one...

---

In recent MSCs proposing Sliding Sync extensions, there have been discussions about the pagination strategies of the items that those extensions will carry.

Different MSC extensions are going in different ways and it feels to me that we are missing some kind of 'stewardship' or 'taste' as to which direction the overall project should be going.

This issue seeks to lay some of the discussed options on the table and then perhaps we have a good start to think about the desired end state.

## Strategies

### Explicit backward pagination (using a companion endpoint)

In this strategy, the Sliding Sync response only includes a limited number of the **latest** items, e.g. 100 latest items. In other words, it includes items from the 'newest' side of the backlog.
The items are paginated by the request/response-level (global) `pos` token.

If the client missed some items, because there are more items than the limit allows to return in one response, then the response includes some token that the client can use to backpaginate the gap.

This backpagination occurs on a companion endpoint (not the `/sync` endpoint).

Extensions using this strategy:

- [MSC4308: Thread Subscriptions extension to Sliding Sync](https://github.com/matrix-org/matrix-spec-proposals/pull/4308)

Good:
- Clients get the latest data first, which is *typically* most useful.
- Clients don't have to retrieve the entire backlog if they don't want to.

Bad:
- Needs a separate companion endpoint.
- Clients need to be able to track multiple gaps, if they want to eventually get all the data.
- Clients need to (transactionally) persist another pagination token in their store.
- (For some types of item) races between subsequent `/sync` requests and the companion endpoint backpagination requests mean that returned items need `bump_stamp`s (or similar) to distinguish which response contains the latest information. (See: [MSC4308: Thread Subscriptions extension to Sliding Sync § Use of `bump_stamp`](https://github.com/matrix-org/matrix-spec-proposals/blob/4d88858787dd73ff948368e3cd58b124fcfed9bd/proposals/4308-sliding-sync-ext-thread-subscriptions.md#use-of-bump_stamp))

### Explicit forward pagination (using per-extension tokens)

In this strategy, the Sliding Sync extension does not use the request/response-level (global) `pos` token and instead specifies its own extension-level pagination tokens.

The extension response includes a limited number of items, from the 'oldest' side of the backlog and the extension-level pagination token advances.

Extensions using this strategy:

- [MSC3885: Sliding Sync Extension: To-Device messages](https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/msc3885/proposals/3885-sliding-sync-to-device.md)
- [MSC4354: Sticky Events § Sliding Sync extension](https://github.com/matrix-org/matrix-spec-proposals/blob/ad1203d0c15043a11a2540ff49d8137f931b74db/proposals/4354-sticky-events.md#msc4186-simplified-sliding-sync)

Good:
- No separate endpoint needed.
- Clients can turn off the extension when it's not desired and not lose their 'position'.

Bad:
- Clients get oldest data first, which is not always bad but often seems to be.
- Particularly of interest is that (for some extensions where this is relevant), the oldest data can then be 'overwritten' by newer data in a subsequent sync, briefly flashing stale data at the user even though the server had more recent data available. (In MSC4354 this risk has been referred to as 'Flickering' — TODO add a link to a discussion point)
- Clients need to (transactionally) persist another pagination token in their store.

### Implicit Forward Pagination

In this strategy, the Sliding Sync response only includes a limited number of items, from the 'oldest' side of the backlog.

Pagination is controlled by the request/response-level (global) `pos` token.
Subsequent sliding sync requests will walk forwards through the backlog of items

No extensions in Sliding Sync use this strategy. However, some 'oldschool' sync streams use this strategy (e.g. to-device messages).

Good:
- Clients don't need to manage any extra tokens, all the pagination happens 'automatically', which is easy for the clients to deal with.

Bad:
- Clients get oldest data first, which is not always bad but often seems to be.
- The `/sync` request will 'hot-loop' (return immediately) until the backlog is cleared. This is intensive for mobile clients and also might starve out the processing of other streams
- Clients can't control/slow down receiving the entire backlog.
- This strategy is one of the aspects that some consider to have made oldschool sync complex and brittle. ([[ref]](https://github.com/element-hq/synapse/pull/18695#discussion_r2223748883))

### No pagination

Technically, we can choose to not paginate at all and just return the entire set of unseen data in the Sliding Sync response.

Good:

- Very simple

Bad:

- Sends data of unbounded size to the client

Extensions using this strategy:

- [MSC3959: Sliding Sync Extension: Account Data](https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/ssext-account-data/proposals/3959-sliding-sync-account-data.md)

Read MSC4186 alongside the pagination sections of MSC4308, MSC3885, MSC4354, and MSC3959. Compare the four strategies and the trade-offs listed here, then determine what project-wide guidance or follow-up changes are needed. Done means the preferred direction is agreed and documented for current and future Sliding Sync extensions.

Written by the indexing model from the issue text.