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.

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

MSC3985: Break-out rooms #3985

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Changes from 3 commits
Commits
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
88 changes: 88 additions & 0 deletions proposals/3985-break-out.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,88 @@
# MSC3985: Break-out rooms

VoIP applications such as Zoom or MS Teams support break-out rooms - a mechanism
for splitting users into multiple calls. This proposal suggests a mechanism for
break-out rooms in Matrix which would not be limited to VoIP use-cases.
Copy link
Contributor

Choose a reason for hiding this comment

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

This sounds really useful for me personally to split out some discussions. I think what I would still need is a way to force users to only talk in the breakout room temporarily. Do you have some easy ideas for that, that might be easy to cover in a follow up MSC? :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, that's a good point. I don't think I have anything in mind. The best I can think of atm is just temporarily changing permissions


## Proposal

When a user wants to break-out the "parent" room's users into multiple "child"
rooms, their client should first create those rooms and then send an
`m.breakout` event:

```json5
{
"type": "m.breakout",
"state_key": "",
"content": {
"m.breakout": {
"!roomId1": {
"via": ["example.org", "other.example.org"],
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess this technically isn't the fault of the MSC itself but the via process in itself how it currently is handled, but how would this get updated if the via servers get stale? Are we expecting the event to be short-lived enough for this to be no concern? Or should they get updated if some condition is met (like last person on an HS left)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think the space MSC solves this either?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I don't think it does. But it's just another area where this "bug" happens. And in theory, this MSC still has the chance to do something about it. :) Hence, I was pointing it out. Though of course it may be better to solve that in another dedicated MSC? Not sure what's the best tbh.

"users": ["userId1", "userId2"]
},
Copy link
Member

Choose a reason for hiding this comment

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

Would it be helpful to add some more information about the room? Such as a stripped state event list, so that users can more easily choose which room to join?

Copy link
Contributor

Choose a reason for hiding this comment

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

Having a topic or a name might indeed be helpful. In University, we had them for example named by Groups. "Group 1", "Group 2"... Something like that might be nice to have.

Copy link
Member

Choose a reason for hiding this comment

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

I wonder if storing that in the breakout rooms and then using something like the /hierarchy API would alleviate duplication...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was thinking we'd use MSC3266 to avoid the duplication and the info getting out of sync

Using the /hierarchy is definitely an interesting idea... I wonder if m.space.child should be used if we'd go that route but I don't really like how it would mean the info is spread over multiple events

Copy link
Member

Choose a reason for hiding this comment

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

Could also modify that API to return different events or something for different room types 🤷 There's a lot of ways to cut it...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think we can just use the room name and topic and so don't have to modify the API?

"!roomId2": {
"via": ["example.org", "other.example.org"]
}
}
}
}
```

This event contains a map of the "child" rooms along with their `via`s. The
event may also include information about the users who are suggested to join a
given "child" room.

When the event is received by the other clients in the room, they should give
their users the option to join the given rooms. If the user is suggested to join
a specific room, the UI should reflect that.

There should only ever be one set of break-out rooms with the `state_key` always
being `""`.

Break-out rooms can live on long after the break-out happens as regular
standalone rooms. The `m.breakout` state event can be emptied, so that the
"parent" no longer links to the "children".

### "Child" rooms' `join_rule`s

The "child" rooms may have `join_rules` of the `m.breakout` event's creator's or
their client's choosing. A few common examples are:

- The "child" room has a `join_rule` of `restricted` indicating that only the
members of the "parent" room can join.
- The "child" room has `join_rule` if `invite` indicating that only the invited
SimonBrandner marked this conversation as resolved.
Show resolved Hide resolved
users can join. In this case, the room information in the `m.breakout` event
should include the list of users who are suggested to join the given room.
- The "child" room has a `join_rule` of `public` indicating anyone can join.
This would usually happen if the "parent" room was also public.

SimonBrandner marked this conversation as resolved.
Show resolved Hide resolved
### VoIP use-case

If a user is participating in a call when the event is sent, they should either
Copy link
Contributor

Choose a reason for hiding this comment

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

Mostly a UX question that might be beyond the scope of MSC process, but should this be semi-automatic (like Zoom does it) or would the expected behavior be that the user has to reconfirm joining it? (This comment is not a concern against the MSC. So imho it should not be considered as part of the process. It's just an implementation question)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I feel like this could be client-specific

start a call or join an existing call in the "child" room, if there is one.

### Security

In public rooms, special precautions should be taken. In most cases, regular
users shouldn't be allowed to send `m.breakout` events. But if they are, the
client should warn the user, if the event is coming from an unknown user (one
with whom we don't have a DM) who is not an admin/moderator either.

## Potential issues
Copy link
Member

Choose a reason for hiding this comment

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

If you're in a large call and want to create, say, 10 breakout rooms, rate limiting could become a problem. A separate MSC could make it possible to bulk-create rooms, perhaps?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, good point...

Copy link
Member

@clokep clokep Mar 29, 2023

Choose a reason for hiding this comment

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

I had written MSC3192 while doing the spaces stuff....

Copy link
Member

Choose a reason for hiding this comment

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

Oh, but you're concerned about creating the rooms... yeah I'm not sure how to differentiate it from spam. 😢


None that I can think of.

## Alternatives

An alternative for the VoIP use-case would be having multiple calls in one room
along with multiple threads for chat. While this works alright for some
use-cases, it has its limitations.
Comment on lines +77 to +79

Choose a reason for hiding this comment

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

Could you describe an example use-case where threads are not sufficient?


## Unstable prefix

While this MSC is unstable, `org.matrix.msc3985.breakout` should be used instead
of `m.breakout`.

## Dependencies

None that I can think of.