Fun request I have, is to set Lobby ON after the first one joins the room. Something like “startWithVideoMuted: true,” or “startWithAudioMuted: true,” . Is there a plan to have this in the near future, maybe an “initMeetingWithLobbyON: true”? Does someone know a workaround to get this working?
Thanks for any comments and thoughts in advance!
I too would have the same need.
I would like to be able to ensure that the moderator as soon as he starts the room, has the lobby enabled by default to prevent participants from entering without permission.
In practice, Jitsi lacks the ability to set the room password before starting it, as well as the ability to enable the lobby before creating the room … too bad because the product is fabulous and I congratulate all the developers and @damencho who it often makes itself available to the community.
this would be a most awesome feature indeed. hopefully it comes with the next iterations of the lobby!
This is not that difficult, I just added this hook in lobby prosody plugin file.
host_module:hook('muc-set-affiliation', function(event) if jid_split(event.jid) ~= 'focus' and event.affiliation == 'owner' then handle_create_lobby(event); end end);
This enables lobby whenever a meeting is started.
This is most awesome! Thanks, it seems to work, just tried it.
Having the flexibility to enable/disable Lobby with an URL Parameter would be the absolute icing on the cake though.
Then again, if that is wanted, the moderator can disable the lobby as first thing -> having it by default is certainly the better approach. Hopefully this gets integrated into the next lobby iteration! (+ a knock sound)
Thanks a lot for your contribution!
*Edit: hmm though i may have caused a bug, where exactly does the the Hook need to be inserted?
once a lobby room was created (one participant still in) and a prosody ist restarted -> it will hang for a while, showing a serialization error for me)
Everything essentially works. I am getting:
Oct 31 14:41:18 mod_posix warn Received SIGTERM Oct 31 14:41:18 startup info Shutting down: Received SIGTERM Oct 31 14:41:18 general error Top-level error, please report: /usr/lib64/prosody/util/serialization.lua:38: Can't serialize function Oct 31 14:41:18 general error stack traceback: [C]: in function 'error' /usr/lib64/prosody/util/serialization.lua:38: in function </usr/lib64/prosody/util/serialization.lua:37> (tail call): ? /usr/lib64/prosody/util/serialization.lua:196: in function 'serialize_table' /usr/lib64/prosody/util/serialization.lua:194: in function 'serialize_table' /usr/lib64/prosody/util/serialization.lua:194: in function 'serialize_table' /usr/lib64/prosody/util/serialization.lua:194: in function 'serialize_table' /usr/lib64/prosody/util/serialization.lua:220: in function </usr/lib64/prosody/util/serialization.lua:218> (tail call): ? (tail call): ? ... /usr/lib64/prosody/util/events.lua:79: in function </usr/lib64/prosody/util/events.lua:75> (tail call): ? /usr/lib64/prosody/util/startup.lua:331: in function 'shutdown' /usr/lib64/prosody/modules/mod_posix.lua:173: in function </usr/lib64/prosody/modules/mod_posix.lua:170> [C]: in function 'wait' /usr/lib64/prosody/net/server_epoll.lua:729: in function </usr/lib64/prosody/net/server_epoll.lua:726> [C]: in function 'xpcall' /usr/lib64/prosody/../../bin/prosody:76: in function 'loop' /usr/lib64/prosody/../../bin/prosody:86: in main chunk [C]: ?
might be i am not editing/placing it properly in the lobby.lua -> any pointers welcome
Hi @snek, You will have to add this hook below muc-invite hook,
which is present in ‘process_host_module’ function as below -
-- process or waits to process the main muc component process_host_module(main_muc_component_config, function(host_module, host)
If you refer the prosody-plugins github link, here you can add the new hook.
Hope this helps
Edit: Also don’t forget to restart prosody service after making changes.
This is a good one, @Giri-sh-irke! Thanks for sharing.
I haven’t tested it, but what happens if for some reason the Moderator gets disconnected from the meeting (while others are still on) and has to get back in? Does the moderator role automatically bypass the lobby?
Hi @Freddie, I have a self hosted server which has a single moderator for a meeting enabled unlike https://meet.jit.si/. So whenever a moderator disconnects, someone from the meetings gets the moderator role and the previous moderator has to wait for his request to be accepted by the new moderator.
Even I am looking for some solution/workaround regarding bypassing some users from lobby.
@Giri-sh-irke - Aaaaah cool! Yeah, having the Moderator-role bypass the lobby would be crucial to implementing this, otherwise, it’s back to the same problem.
For anyone who wants to implement this nonetheless, they can additionally set a password as the Moderator once they get in the room, so if they happen to get disconnected, they can get back in without being barred by the lobby feature. The downside to this option though is that they lose that first-level moderator access level - meaning, they won’t be able to let knocking participants who come in after into the room.
most awesome, thanks again! it works now and the serialization/restart bug is gone as well. i noticed there was an updated lobby file too thanks to your link.
It is now placed like:
-- listens for invites for participants to join the main room host_module:hook('muc-invite', function(event) local room, stanza = event.room, event.stanza; local invitee = stanza.attr.to; local from = stanza:get_child('x', 'http://jabber.org/protocol/muc#user') :get_child('invite').attr.from; if lobby_muc_service and room._data.lobbyroom then local lobby_room_obj = lobby_muc_service.get_room_from_jid(room._data.lobbyroom); if lobby_room_obj then local occupant = lobby_room_obj:get_occupant_by_real_jid(invitee); if occupant then local display_name = occupant:get_presence():get_child_text( 'nick', 'http://jabber.org/protocol/nick'); notify_lobby_access(room, from, occupant.nick, display_name, true); end end end end); -- enforce lobby to be enabled on room creation / thanks to Giri-sh-irke / 79279 host_module:hook('muc-set-affiliation', function(event) if jid_split(event.jid) ~= 'focus' and event.affiliation == 'owner' then handle_create_lobby(event); end end);
@Freddie hmm if i set a password -> let someone in -> exit -> rejoin (with password) -> knock with another account -> i see the knock like expected, can rejoin and let users join. Hmm this is a SAML/Shibboleth protected domain though + “anonymous” authentication though, maybe that is part of it?
@snek yeah, Shibboleth makes a difference. When you use the vanilla ‘Secure domain’ option here, on getting back in after being disconnected, the system creates a new instance of your presence in the room and that instance does not see the knock prompts.
The auto lobby is not working for me.
addid this to the script. Nothing of the lobby is working anymore.
if jid_split(event.jid) ~= 'focus' and event.affiliation == 'owner' then handle_create_lobby(event); end
Thanks for any help or info.
I followed the @snek code and the only thing that changed is that the lobby isn’t available anymore in the security settings. The people still can enter without waiting in the lobby and they don’t need to input their names
I thought that a reboot of the server would work; but still nothing. I had to comment the changes in order to enable manually the lobby
Hi, every now and then it happens to find this error in the moderator’s console:
022-03-24T15: 15: 31.727Z [modules / xmpp / Lobby.js] Failed joining lobby Error: Missing lobbyRoomJid, cannot join lobby room
This error results in a room staying fake open (the moderator doesn’t get requests), only a room restart solves it (because the lobby starts up fine …)
This means that the lobbyRoomJid was not set. It is set by receiving the room disco-info or when you try to join the room and an error is received about it, the error contains the lobbyRoomJid.
Are you getting this when using only the jitsi-meet stock lobby modules or you are doing some other lobby enabling using custom modules?
I enable the lobby when the room is opened, by default. I use this hook:
host_module: hook (‘muc-set-affiliation’, function (event)
if jid_split (event.jid) ~ = ‘focus’ and event.affiliation == ‘owner’ then
So this is when there is a participant that is not the focus and someone/something has made the participant owner. This means that participant is already in the room and that it may had received the disco-info without the lobby room jid, so the participant is not aware there is a lobby room to join …
That is not the right moment to enable lobby. You need to enable it before the participant joins and just add the participant to the list of members.
Who is granting the owner for the participant, jicofo, or another module?
Now we take advantage of the authentication and also the reservation side jicofo (5390 stable version).
We plan to put into production the new version based on stable 7001 and reservation on prosody.
At the moment we wanted to avoid that “Failed joining lobby Error” anomaly until we release the new version.
So it is jicofo setting the owner of the room … in that case, I’m not sure there is a workaround at this moment … need to look at the code and think about it …
When adding this the lobby option is gone from security settings but also not enabled