MSC3985: Break-out rooms #3985
MSC3985: Break-out rooms #3985
Conversation
SimonBrandner
added
feature
Signed-off-by: Šimon Brandner <[email protected]>
SimonBrandner
force-pushed
the
msc/break-out
branch
from
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.
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.
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]>
| "!roomId1": { | ||
| "via": ["example.org", "other.example.org"], | ||
| "users": ["userId1", "userId2"] | ||
| }, |
There was a problem hiding this comment.
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.
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.
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.
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.
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.
I think we can just use the room name and topic and so don't have to modify the API?
turt2live
added
kind:feature
Signed-off-by: Šimon Brandner <[email protected]>
SimonBrandner
requested review from
deepbluev7,
MTRNord,
uhoreg and
clokep
and removed request for
deepbluev7 and
MTRNord
| "content": { | ||
| "m.breakout": { | ||
| "!roomId1": { | ||
| "via": ["example.org", "other.example.org"], |
There was a problem hiding this comment.
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.
I don't think the space MSC solves this either?
There was a problem hiding this comment.
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.
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.
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.
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.
Hmm, good point...
There was a problem hiding this comment.
I had written MSC3192 while doing the spaces stuff....
There was a problem hiding this comment.
Oh, but you're concerned about creating the rooms... yeah I'm not sure how to differentiate it from spam. 😢
Co-authored-by: Jaryk <[email protected]>
| 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.
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