Distinguish room state and timeline events in MSC2762

[robintown]

Currently, MSC2762 is ambiguous as to whether it gives widgets a way to actually listen to the state of a room. The read_events action is said to only return zero or one events if you include a state_key, which suggests that the m.receive.state_event capability is meant to expose clients to room state entries rather than simply, state events that show up in the timeline. However, there seems to be no real reason to withhold timeline events from the widget just because they happen to have a state_key—state events may still have semantics in certain applications even if they don't belong to the resolved room state.

The proposal here is to more clearly distinguish room state updates from incoming timeline events by:

1. Saying that read_events always returns timeline events, rather than performing room state lookups
2. Introducing an update_state to proactively push all room state that the widget is interested in, and communicate any further updates as they occur

The idea is to make the widget API reflect the design of Simplified Sliding Sync and MSC4222 by sending the same state events twice: once to say "this is an event in the timeline" and again to say "this is a state update". In clients this has given us the means to finally track room state reliably, to guide implementations toward the "pit of success", and hopefully it'll have the same effect for widgets too.

Implementations:

• Distinguish room state and timeline events matrix-widget-api#116
• Distinguish room state and timeline events when dealing with widgets element-hq/element-web#28681
• Distinguish room state and timeline events in embedded clients matrix-js-sdk#4574

[toger5]

Will it then also send another room_state_synced action?
I am not sure I like the concept of room state synced. I think it does not match matrix. It gives the false impression that room state can be in sync but this is nothing we can prove with the matrix protocol.
For example there is no difference for the widget between:

• all state has been synced and then a ms later new state is received by the server (that is already 2min old) and gets send to the widget
• not all state is synced, one event is missing (2mins old) and it is synced in the next ms.

Both cases are equivalent but one gives you the state synced before the 2min old event and the other one after.
A widget using state needs to be able to deal with all possible state changes and states. Since it is required to be reactive to all scenarios one can argue that there is no special logic it can do when all state is loaded.

[robintown]

Updated this according to our discussion: update_state now sends an array so that room_state_synced is unnecessary.

[turt2live]

@robintown it's not clear to me if this is meant to be an MSC, or is a way to allow the team to review some changes before including in the proposal.

[robintown]

It's the latter, yes