jitsi-meet
jitsi-meet copied to clipboard
Turn on lobby by default for each newly created room
Is your feature request related to a problem you are facing? I differentiate conference participants between moderators and regular participants. I authenticate users with JWT, where I also set a moderator boolean field. To achieve this, I use a custom prosody plugin: https://github.com/mfts/jitsi-token-moderation-plugin/
Now I would also like to have lobby turned for each room so only moderators can enter.
Describe the solution you'd like I would like to turn on lobby by default for all newly created rooms and let only moderators join without having to request access. There will be two scenarios:
-
Moderator is first to enter the room:
- Can join normally because s/he is a moderator
- Lobby is not blocking him/her from entering
-
Regular participant is first to enter the room:
- Cannot join/create the conference, because a lobby is set which requires a moderator to enter first
- Participant sees a screen, moderator is not present yet, please wait (or come back later)
We currently don't have a setting for enabling the lobby by default. I guess we'd need that first.
Allowing a moderator to skip the lobby is a bit of a chicken and egg problem, because you can only be a moderator once inside a room, and the lobby prevents you from entering.
At a glance I think we'd need some extra info in the token to make it work, thus limiting that functionality only to token based authentication.
This has been determined to be a deal-breaking feature for our organization. One idea I had was to add some small settings to the meeting create screen, a slider on the side for "enable lobby" and if ticked, when you press "go" host authentication pops up before proceeding? I'm not sure how the back-end works, but it seems it solves the chicken and egg problem before joining the actual meeting.
this may be relevant to the discussion: https://community.jitsi.org/t/start-a-room-with-lobby-enabled/79279/4
Hey @saghul
We currently don't have a setting for enabling the lobby by default.
any news on this? I really need this feature! :-)
Best Robert
No updates on this, sorry.
Allowing a moderator to skip the lobby is a bit of a chicken and egg problem, because you can only be a moderator once inside a room, and the lobby prevents you from entering.
This makes the lobby-feature basically unuseable if you use authentification on your setup. Because as soon as you disconnect you cannot rejoin the meeting, if there is no moderator left.
Allowing a moderator to skip the lobby is a bit of a chicken and egg problem, because you can only be a moderator once inside a room, and the lobby prevents you from entering.
This makes the lobby-feature basically unuseable if you use authentification on your setup. Because as soon as you disconnect you cannot rejoin the meeting, if there is no moderator left.
as workaround, one can set a password. that way, anyone who knows the password can re-enter (and then become moderator again). i admit this will not be a workaround for everyone, but may be usefull for some.
... Allowing a moderator to skip the lobby is a bit of a chicken and egg problem, because you can only be a moderator once inside a room, and the lobby prevents you from entering.
At a glance I think we'd need some extra info in the token to make it work, thus limiting that functionality only to token based authentication.
Any updates on this? Without decent re-entry for moderators the lobby feature is not working for us ...
The lobby function is extremely wanted. I know that there was a progress with it: https://community.jitsi.org/t/how-to-how-do-i-use-the-new-lobby-feature/73100 and https://community.jitsi.org/t/lobby-waiting-room/27752/53 but since it locks out the moderators it's not in a state that could be used. I've read that generally there is nothing in Jitsi-meet to setup special characteristics for rooms, but some rooms have their characteristics and need a way to reflect it in Jitsi.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
The lobby can be activated with this hook, but I'm not sure if the event is always processed in time. Should run before the hook defined in mod_token_verification.lua using default priority.
module:hook("muc-room-pre-create", function(event)
if module:get_option_boolean("muc_lobby_default", false) then
log('debug', 'auto-enabling lobby for room "%s".', roomname);
local stanza = event.stanza;
local roomname = jid.split(stanza.attr.to);
prosody.events.fire_event("create-lobby-room", event);
end
end, 5);
Now nobody can create a room with this hook. Everyone goes to the lobby. In mod_muc_lobby_rooms.lua there are several rules to bypass the lobby. One could add a module setting the room password using a database. Or mod_muc_lobby_rooms.lua may be extended to read the token (copy-paste from mod_token_moderation.lua):
if is_token_room_owner(event.origin) == true then
whitelistJoin = true;
end
...
function is_token_room_owner(origin)
if origin.auth_token then
-- Extract token body and decode it
local dotFirst = origin.auth_token:find("%.");
if dotFirst then
local dotSecond = origin.auth_token:sub(dotFirst + 1):find("%.");
if dotSecond then
local bodyB64 = origin.auth_token:sub(dotFirst + 1, dotFirst + dotSecond - 1);
local body = json.decode(basexx.from_url64(bodyB64));
return body["moderator"] == true;
end;
end;
end;
end;
However, I'm still unsure how to hide the knockButton
"Ask to Join". Should say "Please wait" instead, still being able to enter a password.
Keeping the thread alive, is Jitsi coming up with the default lobby feature any time soon? Any ETA for it. What we are trying to implement as we do not want the client to come in before the moderator, like in Zoom the host automatically becomes host even after it joined late in the meeting with no lobby. But, in jitsi, the first person to enter the room is moderator and not the one who set the meeting. We would want the client to wait in the lobby until it is accepted by the moderator, but then how will the room know if this is the one who set the meeting, so zoom has personal meeting ID for it, which Jitsi does not. Can someone please help on this one ? Thanks in advance.
You can use moderated.jitsi.net to create rooms where you decide who the moderator is.
The problem then is that if people wait for the moderator to arrive they are automatically let in before the moderator has the chance to enable the lobby.
Since rooms don't exist until someone joins, we have a chicken and egg problem here, because there is no clear way to decide if the lobby should be enabled for a given room.
Hey Saghul, thanks for the help. I have self hosted Jitsi on AWS. I know you mentioned the chicken and egg problem, but do you think, would there be a possibility that I can make a solution of default waiting room for all given room for participants like zoom, zoom has the option while scheduling but before the meeting started of enabling the waiting room and can I include the feature for the moderator as who set the meeting would be the only one to bypass the waiting room. would that be a possibility for custom or it jitsi having a solution for this in mind ?
We currently don't have a solution nor are we working on one at this moment, sorry.
Thanks for the information.
Maybe this could be solved when using the JWT token authentication, currently jitsi considers anyone with a jwt a administrator, therefore, the admins could sort of "skip" the lobby, anyone else, should wait on the lobby for any of the admins to "aprove" of him.
this could be further "improved" if there was a indicator inside the JWT if that person/user is a admin, to further mitigate any authorization issues.
There is now a prosody plugin in jitsi-contrib to autostart lobby for all rooms -- https://github.com/shawnchin/prosody-plugins/tree/main/lobby_autostart
As mentioned in the discussion above, this is only practical if you have some means for moderators to bypass the lobby. There's another plugin coming soon that will offer that based on JWT attributes -- https://github.com/jitsi-contrib/prosody-plugins/pull/13
I've intentionally separate the notion of "moderator" with the ability to bypass lobby. This allows for user cases where you might want to allow certain non-moderators to join without being manually admitted, and perhaps to have some moderators still subject to the lobby.
This seems to be a nice approach. Though it would be nice to allow authenticated users (Moderators) to inmediately enter the lobby. Is there an "default passwort for room" feature I am unaware about? Will have to look at the upcoming JWT token feature, though then I will need to run an JWT Service somewhere for users to authenticate against and get a Token i assume?
Very nice that this is not forgotten and progress happening. thanks @shawnchin
Is there an "default password for room" feature I am unaware about?
I don't think there is official support for that, but there are several posts in community with suggestions on how to achieve that.
though then I will need to run an JWT Service somewhere for users to authenticate against and get a Token i assume?
Yup.
Would setting MEET_MODERATOR key to true in the .env file address this?
There is now a prosody plugin in jitsi-contrib to autostart lobby for all rooms -- https://github.com/shawnchin/prosody-plugins/tree/main/lobby_autostart
As mentioned in the discussion above, this is only practical if you have some means for moderators to bypass the lobby. There's another plugin coming soon that will offer that based on JWT attributes -- jitsi-contrib/prosody-plugins#13
I've intentionally separate the notion of "moderator" with the ability to bypass lobby. This allows for user cases where you might want to allow certain non-moderators to join without being manually admitted, and perhaps to have some moderators still subject to the lobby.
There is now a prosody plugin in jitsi-contrib to autostart lobby for all rooms -- https://github.com/shawnchin/prosody-plugins/tree/main/lobby_autostart
As mentioned in the discussion above, this is only practical if you have some means for moderators to bypass the lobby. There's another plugin coming soon that will offer that based on JWT attributes -- https://github.com/jitsi-contrib/prosody-plugins/pull/13
I've intentionally separate the notion of "moderator" with the ability to bypass lobby. This allows for user cases where you might want to allow certain non-moderators to join without being manually admitted, and perhaps to have some moderators still subject to the lobby.
Closing since this is now possible. Thanks @shawnchin !
Would setting MEET_MODERATOR key to true in the .env file address this?
Hmm curious, what config file (jicofo?) is influenced by this environment setting?
AFAIK, there is not such env var so should not influence anything.
Would setting MEET_MODERATOR key to true in the .env file address this?
Hmm curious, what config file (jicofo?) is influenced by this environment setting?
My bad, I'm running a customized version. Although what helped us in our setup was implementing this plugin to use with our tokens: https://github.com/nvonahsen/jitsi-token-moderation-plugin
@saghul How can I turn on/off lobby when create room using iOS sdk? before create room we are showing our own screen and on that screen user can select lobby option turn on/off.
do we have any function in iOS sdk to handle this?
There is no API function for that, you'll need to be in the meeting.
@saghul We hide jitsi default toolbox as there are lots of option. (toolbox.enabled = false) So as there is no API function and We are hiding toolbox. we are not able to use this feature. Am I correct?
Also we need apis for list of participant who waiting in lobby. moderator can accept and reject their request. (This is also out custome ui)
We are hiding toolbox. we are not able to use this feature. Am I correct?
Correct.
Also we need apis for list of participant who waiting in lobby. moderator can accept and reject their request. (This is also out custome ui)
We provide a UI already, adding extra APIs to recreate a custom UI is not high on our roadmap...
Sorry to insist on this topic, but I was wondering if it wouldn't be possible for an authenticated user have the same treatment as someone joining a meeting with JWT. I have a working instance that uses JWT and it works fine, and now was experimenting with LDAP authentication hoping all authenticated users could join rooms as moderators.
Of course, after the room is opened there would have to be means to keep authenticating users, maybe enabling some small button under the main join button for guests. This would also solve the issue with orphaned rooms, if for some reason the last moderator was disconnected from the room.