Restrict creation of rooms


Dear all,

thanks for creating the Jitsi Meet tool. It’s very useful, works well, and it was easy to set up. Unfortunately, authentication seems to be a lot harder to configure the way that I want it than I initially thought.

Basically, I want to continue to use the anonymous login mode that is configured after installation, where anybody can join a conference room if they know the link, but I would like to restrict the list of possible names for conferences rooms. That means anyone who knows the name of an existent chat room (that I will create in advance as an admin) can join without providing login details, but unless they know the name of a chatroom it’s impossible to create a room. This is meant to prevent abuse of our system for purposes not related to our service.

I found out that by setting the restrict_room_creation for Prosody, I can restrict the creation of rooms to admins. Is there a command line tool that I can run to automatically create a chat room and send its name to the users who I would like to invite to join?

Many thanks & best wishes,



Hey Philipp and welcome.

The current use of the muc in jitsi-meet was always directed in a way to not keep any state on the xmpp server. A room is created when first accessed and destroyed when the last person leaves. This allows flexibility and scalability. For example, if you need creating rooms and you have multiple as we call them shards, multiple xmpp servers, you will need cluster and you step in very complicated deployments.

But I think you can accomplish this with a simple prosody module, which will catch the event of trying to create a room, will check using a rest call service is the room name allowed and will return an error if not allowed … something like that, the problem in the implementation will be that room creations is not async while the call to a service will be …
Or you can implement this as an authentication provider, as we had done for tokens …
There are multiple approaches based on using a simple prosody module, which will keep scalability and simplicity of deployments.



Dear Damian,

thanks so much for your reply. Your help is very much appreciated.

With the authentication provider, would this require users to sign in or anything similar? I know that my users may be put off by any unnecessary step in using the service, so I want to make usage as simple as feasibly possible. I.e., I would prefer if users could just follow a link and end up in the right video channel.

Regarding the Prosody module, do you think the desired functionality could be accomplished using the MUC Access Control module?

Many thanks again for your support,
All the best wishes,



Sorry, I also just found the MUC Restrict Rooms module, maybe that could do the job? I need to find out how to define the allowed chat room names dynamically though. You mentioned something related to rest call services?



Well you can get inspired from that module and from the jwt auth module how it is fetching the public key:
and use the same to query for your dynamic values.