-
Notifications
You must be signed in to change notification settings - Fork 383
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
base: main
Are you sure you want to change the base?
MSC3985: Break-out rooms #3985
Conversation
Signed-off-by: Šimon Brandner <simon.bra.ag@gmail.com>
9031e12
to
bcc67d9
Compare
|
||
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. |
There was a problem hiding this comment.
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? :)
There was a problem hiding this comment.
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 <simon.bra.ag@gmail.com>
"!roomId1": { | ||
"via": ["example.org", "other.example.org"], | ||
"users": ["userId1", "userId2"] | ||
}, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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?
Signed-off-by: Šimon Brandner <simon.bra.ag@gmail.com>
"content": { | ||
"m.breakout": { | ||
"!roomId1": { | ||
"via": ["example.org", "other.example.org"], |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, good point...
There was a problem hiding this comment.
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....
There was a problem hiding this comment.
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. 😢
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. |
There was a problem hiding this comment.
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?
Hi, what's the status of this MSC? What are we missing to finish this? Would love to contribute. Seems like a very useful MSC :) |
Done with a community 🎩 on as a part of my high-school graduation thesis
Rendered