Securing admin options from guests, another idea

meet.jit.si allows anonymous access to meeting and that is ok. Problem is that first one that comes into room gets moderator access. If he disconects another one gets those privileges.

Reasonable request is that only designated persons can have moderator rights. I saw multiple requests about this issue is and single answer is: meet.jit.si does not allow login so there is no way to assign moderators. That is understandable.

I am suggesting different approach, and seems not to be hard to implement.

When room is created there is option to set password. But that password is meant to be used for access to the room.

Why not add option for another - admin password? That means only if one enters admin password - he would get moderator privileges. Without that he will be just a guest.

Optionally, if no one accessed room with admin password, guests should be kept on hold, waiting for admin to get in. After he gets in, others may join too.

This still does not require user registrations. It is just separate password for admin privileges and moderator options are assigned only to those who join using admin password. Admin password may be shared to trusted people.

I think you’re missing the underlying driver for the decision to grant every user moderator-level privileges on meet.jit.si. It’s not just about login requirements, it’s also because meet.jit.si is a demo site - meaning, it allows any and everyone to test all the features of Jitsi. So, all users there have moderator-level access.

If you want more granular control, I’d recommend https://jaas.8x8.vc. JaaS allows you to have control over your Jitsi environment without the hassle of hosting/managing your own server. Otherwise, of course, there’s always the option of deploying your own Jitsi server.

This is not correct. All users are moderators on meet.jit.si.

The proposal sounds interesting. The only problem I see is that it’s easy to exploit: if the moderator leaves briefly, all other participants could leave quickly as well, thus causing the room to be destroyed and thus the admin password would be lost, because the state associated with a room is also destroyed.

We tested the idea of creating different URLs for users and moderators, and using tokens: GitHub - jitsi/moderated-meetings: Jitsi Moderated Meetings microservice - But this was never deployed on meet.jit.si.