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.