From bcc67d970da9f6191e2a2e1c8823726053774429 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=A0imon=20Brandner?= Date: Mon, 27 Mar 2023 11:15:44 +0200 Subject: [PATCH 1/4] Break-out rooms MSC MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Šimon Brandner --- proposals/3985-break-out.md | 66 +++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 proposals/3985-break-out.md diff --git a/proposals/3985-break-out.md b/proposals/3985-break-out.md new file mode 100644 index 00000000000..2ee5f55e175 --- /dev/null +++ b/proposals/3985-break-out.md @@ -0,0 +1,66 @@ +# 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. + +## 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": "cvsiu2813", + "content": { + "m.breakout": { + "!roomId1": { + "via": ["example.org", "other.example.org"], + "users": ["userId1", "userId2"] + }, + "!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. + +If a user is participating in a call when the event is sent, they should either +start a call or join an existing call in the "child" room, if there is one. + +The "child" rooms may have `join_rules` of the user's, which has initiated the +break-out, or their client's choosing. + +## Potential issues + +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. + +## Security considerations + +None that I can think of. + +## 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. From 638e4ea48088e85e0188516770d289dc9351c0fb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=A0imon=20Brandner?= Date: Mon, 27 Mar 2023 13:53:38 +0200 Subject: [PATCH 2/4] Give a few join rule examples MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Šimon Brandner --- proposals/3985-break-out.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/proposals/3985-break-out.md b/proposals/3985-break-out.md index 2ee5f55e175..81c2f69abe4 100644 --- a/proposals/3985-break-out.md +++ b/proposals/3985-break-out.md @@ -39,8 +39,16 @@ a specific room, the UI should reflect that. If a user is participating in a call when the event is sent, they should either start a call or join an existing call in the "child" room, if there is one. -The "child" rooms may have `join_rules` of the user's, which has initiated the -break-out, or their client's choosing. +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 + 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. ## Potential issues From 393d5f6e9b6f8eaf5a6df8121e5e03aa3e62fce2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=A0imon=20Brandner?= Date: Mon, 27 Mar 2023 19:25:17 +0200 Subject: [PATCH 3/4] Take suggestions into account MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Šimon Brandner --- proposals/3985-break-out.md | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/proposals/3985-break-out.md b/proposals/3985-break-out.md index 81c2f69abe4..6f309100937 100644 --- a/proposals/3985-break-out.md +++ b/proposals/3985-break-out.md @@ -13,7 +13,7 @@ rooms, their client should first create those rooms and then send an ```json5 { "type": "m.breakout", - "state_key": "cvsiu2813", + "state_key": "", "content": { "m.breakout": { "!roomId1": { @@ -36,8 +36,14 @@ 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. -If a user is participating in a call when the event is sent, they should either -start a call or join an existing call in the "child" room, if there is one. +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: @@ -50,6 +56,18 @@ their client's choosing. A few common examples are: - The "child" room has a `join_rule` of `public` indicating anyone can join. This would usually happen if the "parent" room was also public. +### VoIP use-case + +If a user is participating in a call when the event is sent, they should either +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 None that I can think of. @@ -60,10 +78,6 @@ 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. -## Security considerations - -None that I can think of. - ## Unstable prefix While this MSC is unstable, `org.matrix.msc3985.breakout` should be used instead From 70dc2fa404ad4fb1ca5937486d7e6902988a5006 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C5=A0imon=20Brandner?= Date: Sun, 4 Feb 2024 18:27:59 +0100 Subject: [PATCH 4/4] Fix typo Co-authored-by: Jaryk --- proposals/3985-break-out.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3985-break-out.md b/proposals/3985-break-out.md index 6f309100937..7864cdc7f39 100644 --- a/proposals/3985-break-out.md +++ b/proposals/3985-break-out.md @@ -50,7 +50,7 @@ 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 +- The "child" room has `join_rule` of `invite` indicating that only the invited 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.