Clarification needed in invite stripped state

[t3chguy]

Two areas of the spec doc talk about invite stripped state:

https://matrix.org/docs/spec/client_server/r0.6.1#m-room-member
invite_room_state in the Unsigned of your own m.room.member event

and

https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-client-r0-sync
rooms.invite.<room_id>.invite_state

The stored event has the invite_room_state field but Synapse strips it when including the membership event in invite_state. https://github.com/matrix-org/synapse/blob/develop/synapse/rest/client/v2_alpha/sync.py#L326-L341
The /state API doesn't work in Synapse pre-join so it seems like a client has no way to ever see a invite_room_state in the real world.

js-sdk respects invite_state but also expects a invite_room_state at the top level (sibling of unsigned) of an event for whatever reason which is obviously wrong.

[anoadragon453]

Indeed, Synapse does not make this field accessible to clients. Clients should instead make use of invite_state in a /sync response.

invite_room_state is included in the unsigned field of a m.room.member event when using the v1 Federation invite endpoint: https://spec.matrix.org/v1.4/server-server-api/#put_matrixfederationv1inviteroomideventid

In v2, stripped invite state has moved to a field in the request body.

I think this all happened because Synapse does a bit of a hack to store stripped state that it receives from an invite over federation, storing it in the unsigned field of an event and then popping that field whenever it needs to return that event to a client or server. The only area it doesn't pop that field is when sending events to application services.

Regardless, it should be removed from the CS spec.

[zecakeh]

For some follow up here, it seems that the field is actually present for appservices, and it was decided in #1273 (comment) that an MSC should be created to move the fields from the CS API to the AS API.