Define the semantics for state events sent in a thread

[richvdh]

It seems currently to be undefined what should happen if somebody sends a state event with an m.thread relationship type.

Obviously the room state will be updated (because servers will not care about the m.relates_to), but I'm concerned that clients might choose to hide the state transition in a thread, which would be confusing at best.

[richvdh]

This seems vaguely analogous to edits of state events, which are explicitly forbidden (to avoid confusing effects like element-hq/element-web#21851)

[turt2live]

the spec makes light mention of aggregations/bundles not applying to state events, so it's probably safe to say that state events can't belong in a thread.

https://spec.matrix.org/v1.4/client-server-api/#aggregations

[richvdh]

the spec makes light mention of aggregations/bundles not applying to state events,

that would suggest that a state event can't be the root of a thread, but it could still be part of a thread, which is my concern here.

But yes, I think the only sane thing is to forbid that. It's just that we need to tell servers and clients to ignore m.thread relations on state events.

[clokep]

But yes, I think the only sane thing is to forbid that. It's just that we need to tell servers and clients to ignore m.thread relations on state events.

I really see no reason (with the current relation semantics) for any state event to have relations. I think I'd propose not allowing relations to a state event and not allowing state events to have relations.

[richvdh]

I feel like I should be able to add a reaction to a state event. Not that that will work, since aggregations don't work on state events.