MSC3417: Call room room type

[SimonBrandner]

Requires #3401

Rendered

[turt2live]

generally seems fine, and very straightforward - thanks for writing it up!

[HybridEidolon]

I argue that using a separate room type has a different meaning entirely, and I give m.space as an example of this: it's very obvious that an m.space room is not a regular chat room and should not be used for chat messages (though it technically can). Should that assumption apply to all explicitly typed rooms in general? Should a chat client that does not recognize a room type hide that room from its room list? If so, doesn't that mean the chat of a call room becomes invisible to those clients, even though a user might reasonably expect to be able to see the chat of a call room even if a client doesn't support calls?

This concern with room types might also apply to MSC3815 (Third Room Worlds), where it might make sense for a client user to be able to see the text chat of a room with an ongoing World, even if the client doesn't directly support Third World.

I believe the m.room call intent already implies that any regular room can become a call room in the sense of room mutability, and as such there is no special distinction between a regular room and a call room for the purposes of text chat. So I'm not sure why a client would hide the chat history of such a room if a room call is started. Unless the concern is about UX confusion where the chat is folded away.

I tripped on this issue while messing around with Element sending call state events with the room intent; Element (and by extension matrix-js-sdk) does not seem to recognize Rooms as having ongoing m.room calls yet unless the room itself has the UnstableCall (org.matrix.msc3417.call) type. So in the presence of this MSC and MSC3401, it is already unclear what a conforming client should do with m.room intent calls.

[Susurrus]

Is the m.intent supposed to always be m.room in this scenario?