Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

MSC3417: Call room room type #3417

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

MSC3417: Call room room type #3417

Changes from 3 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
083dc78
Call room room type MSC
SimonBrandner Sep 30, 2021
d66be2e
Fix MSC number
SimonBrandner Sep 30, 2021
cf13078
Make call room type immutable
SimonBrandner Oct 2, 2021
60cf82d
Improve clarity
SimonBrandner Mar 19, 2022
d8cf45b
Improve codeblock
SimonBrandner Mar 19, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 70 additions & 0 deletions proposals/3417-call-room-type.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
# MSC3417 Call room room type

[MSC3401](https://github.com/matrix-org/matrix-doc/pull/3401) defines how native
Matrix group calls can work. It allows for immersive voice/video/call rooms.
[MSC1772](https://github.com/matrix-org/matrix-doc/pull/1772) is a proposal for
Matrix spaces. A part of this proposal is a way to specify a room type.

We should use the `type` field in the `m.room.create` state event to inform
clients about the fact a room is a call room.

## Proposal

This MSC proposes that when creating a call room the `type` field in the
`m.room.create` state event should be set to `m.call`. This way clients can
clearly distinguish between regular chat rooms and call rooms.

In the case of the `m.intent` field in the `m.call` state event getting out of
sync with the the `type` field in the `m.room.create` state event, the
information from the `m.room.create` state event should be preferred.
SimonBrandner marked this conversation as resolved.
Show resolved Hide resolved

### Example

```json
POST /_matrix/client/r0/createRoom HTTP/1.1
Content-Type: application/json
SimonBrandner marked this conversation as resolved.
Show resolved Hide resolved

{
"preset": "private_chat",
"name": "The Grand Duke Pub",
"topic": "All about happy hour",
"creation_content": {
"m.federate": false,
"type": "m.call",
}
}
```

## Potential issues

The `m.intent` field in the `m.call` state event could get out of sync with the
value of `type` in the `m.room.create` state event.

## Alternatives

### Using the `m.call` state event

Clients could look for the `m.call` state event and its `m.intent` field though
this feels weird as the room type feels like the place where we should put this.
It also is mutable which isn't ideal (see next section).

### Using the `m.room.type` state event

[MSC1840](https://github.com/matrix-org/matrix-doc/pull/1840) proposes a
different way to give rooms types. While we could use the `m.room.type` state
event, it is mutable which we'd like to avoid in the case of call rooms. Clients
supporting call rooms will present the chat in those rooms as secondary or not
present it at all, so it is beneficial for this to be immutable so that the chat
history isn't "lost" when changing the room type.
Comment on lines +53 to +56
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Additional notes

[MSC3088](https://github.com/matrix-org/matrix-doc/pull/3088) proposes a way for
room subtyping, this could be used in the future for things such as stage rooms,
though that isn't the focus of this MSC.

## Unstable prefix

|Stable |Unstable |
|--------|-------------------------|
|`m.call`|`org.matrix.msc3417.call`|