How to incorporate MSC3173 (stripped state for all) into the spec?

[turt2live]

MSC3173

This MSC is a bit awkward because it doesn't make any behavioural changes to the spec, but I feel it's important to acknowledge/formalize the behaviour it mentions in the actual spec. One such approach could be to make the invite_room_state and similar fields a first-class citizen within the spec, alongside the likes of Room Events and State Events. We'd effectively have a definition for what a Stripped State Event is and use that throughout the spec in reference. A concern with this approach is that it might be taking it a bit too far when some other representation would be more suited.

Do people have ideas on how to practically represent this MSC?

[clokep]

We'd effectively have a definition for what a Stripped State Event is and use that throughout the spec in reference.

This was my thought of how we would represent it, but I don't know if there's a clearer way. I think consolidating all of that together into a single definition would be clearer though!

[richvdh]

I have some ideas (indeed, an incomplete matrix-doc branch) around clarifying https://spec.matrix.org/unstable/client-server-api/#types-of-room-events to emphasise that this is the "serialised" form of events which are sent over the C-S api, as opposed to the "raw" events that are sent over federation. (said branch is currently a bit blocked behind #3524). I think it would be a relatively natural home for the definition of a "stripped state event".

One problem with putting it there is that it applies as much to the S-S API as it does the C-S API; still, it's not the only place we have that problem.

[turt2live]

The more we get the individual sections in a position to be airlifted out of the client-server spec the closer we are to making those cross-cutting clarifications to the whole spec, I think. This is a prime opportunity to put new information in a place that is easily cut and pasted out to a different place down the road.

[turt2live]

see #3606