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

Conversation

SimonBrandner
Copy link
Contributor

@SimonBrandner SimonBrandner commented Mar 27, 2023

Done with a community 🎩 on as a part of my high-school graduation thesis



Rendered

@SimonBrandner SimonBrandner added feature Suggestion for a significant extension which needs considerable consideration proposal A matrix spec change proposal needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Mar 27, 2023
@SimonBrandner SimonBrandner changed the title MSC: Break-out rooms MSC3985: Break-out rooms Mar 27, 2023
Signed-off-by: Šimon Brandner <[email protected]>
@SimonBrandner SimonBrandner marked this pull request as ready for review March 27, 2023 09:22

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

Signed-off-by: Šimon Brandner <[email protected]>
proposals/3985-break-out.md Outdated Show resolved Hide resolved
proposals/3985-break-out.md Outdated Show resolved Hide resolved
"!roomId1": {
"via": ["example.org", "other.example.org"],
"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?

proposals/3985-break-out.md Show resolved Hide resolved
@turt2live turt2live added kind:feature MSC for not-core and not-maintenance stuff voip and removed feature Suggestion for a significant extension which needs considerable consideration labels Mar 27, 2023
Signed-off-by: Šimon Brandner <[email protected]>
@SimonBrandner SimonBrandner requested review from deepbluev7, MTRNord, uhoreg and clokep and removed request for deepbluev7 and MTRNord March 27, 2023 17:36
"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.


### 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

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. 😢

proposals/3985-break-out.md Outdated Show resolved Hide resolved
Co-authored-by: Jaryk <[email protected]>
Comment on lines +77 to +79
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.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind:feature MSC for not-core and not-maintenance stuff needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. proposal A matrix spec change proposal voip
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants