Support breakout rooms?

[bollwyvl]

trafficstars

Apparently breakout rooms are one of the things that people need in order to leave proprietary solutions which are not offered by Jitsi yet.

There are a number of open source (and otherwise) solutions listed on the jitsi wiki, so there's plenty of prior art, and Lab seems flexible enough to adopt one of these approaches... and who knows, maybe reuse code.

As I'm not a heavy user of this feature, if somebody could do a sketch of...

• how they would see this working to support chatting about interactive computing
• what might have to change in what's already in the extension
• how the single user and hub experience might be different

... I'm pretty sure we could figure out a way to do it.

[bollwyvl]

#14 exposes (and thinly documents) an IVideoChatManager which could likely be used to implement breakout rooms, if they don't belong in this/the current extension... presumably it would involve:

• building some more rooms in the UI
  • e.g. nested underneath the room
• knowing who's participating
• picking which participants go in which rooms
• sending custom chat messages
• receiving and showing some UI, e.g. Foo has invited you to join Breakout Room 1. [JOIN]
• having some way to return to the previous Meet (I'm pretty sure you can't somehow stay lurking in the first room, at least with how we're using the iframes)

[bollwyvl]

Good news: the current API, with access to the IVideoChatManager.meet is indeed sufficient to implement this feature. Found some more discussions on the jitsi discourse. In a little more detail than above:

• when the IVideoChatManager.onMeetChanged fires for meet X, each participant would...
  • meet.addListener('endpointTextMessageReceived', listener)
• when ready to do a breakout, the moderator would...
  • click some Start Breakout Session button
  • meet.getParticipantsInfo()
    • build up the UI for
      • who's participating
      • places to send participants, creating new meets Y an Z
      • a way to match the two
      • the "rules" of the session (e.g. how long)
  • meet.executeCommand('sendEndpointTextMessage', 'receiverParticipantId', '...some JSON...')
    • to each participant
• each participant then would...
  • parse the JSON
  • show a toast, go right to the new meet, show a timer, etc.
  • another UI would stick around with "return to meet X"

A slightly weird thing: the first participant to arrive would then become the moderator :shrug:... but maybe we need to re-work the concept of "current meet," to allow the owner of the room X to get to Y and Z first, and multiplex all the rooms... maybe turn off all the sound, cut the video quality down to the lowest setting, etc. and let them lurk between different ones.

On the backend, as we're talking about firming up the API spec, we may want to allow each room to have its own rooms underneath it, so that a Hub could have these things already dialed, but still allow them to be modified/tweaked at runtime.

Huzzah!