MSC4222: Adding state_after to sync v2

[erikjohnston]

This is to allow clients to opt-in to a change of the sync v2 API that allows them to correctly track the state of the room.

Rendered

[turt2live]

Implementation requirements:

• Server - Add experimental support for MSC4222 element-hq/synapse#17888
• Client - Support MSC4222 state_after matrix-js-sdk#4487

[toger5]

This kind of usage of the timeline section should be not impacted at all.
We still send all state events (even if they might be wrong) in the timeline section so clients using those state event to render things in the timeline should be not impacted at all.

Suggested change

	Clients will not be able to tell when a state change happened within the timeline. This was used by some clients to
	render e.g. display names of users at the time they sent the message (rather than their current display name), though
	e.g. Element clients have moved away from this UX. This behavior can be replicated in the same way that clients dealt
	with messages received via pagination (i.e. calling `/messages`), by walking the timeline backwards and inspecting the
	`unsigned.prev_state` field. While this can lead to incorrect results, this is no worse than the previous situation.
	As before clients will not be able to tell when a state change happened within the timeline. This was used by some clients to
	render e.g. display names of users at the time they sent the message (rather than their current display name), though
	e.g. Element clients have moved away from this UX.
	This MSC allows to compute the current state correctly. It does not fix the behavior for the state history in the timeline. So clients using such an approach still will face the same issues they had before this MSC.
	A proper solution for this usecase would be to paginate back state using the `replaces_state` id. With this one can find all actual state event ids. This list of id's can be used in combination with the timeline history to filter for invalid and valid state changes.

[erikjohnston]

I guess what I wanted to make clear was that clients will need to change how they calculate the "state at each event", and that that behaviour is really considered best-effort at best.

[Gnuxie]

The format of returned state in required_state is a list of events. This does now allow the server to indicate if a "state reset" has happened which removed an entry from the state entirely (rather than it being replaced with another event).

Does this issue from MSC4186: Simplified Sliding Sync apply to this MSC too?

[erikjohnston]

Mmm, that is true. I guess there is an open question as to whether we want to try and fix that here or not 🤔