Better moderation capabilities in locked down rooms: challenge/response in lobby

[ilmari-lauhakangas]

The Document Foundation is interested in getting this feature implemented, if and only if it is accepted into upstream Jitsi. We will proceed with contracting, if this gets the green light from core devs. Implementation details could then be discussed in this issue. Ping @saghul @damencho

Scenario

During LibreOffice conference 2020 we had uninvited people over, so we had to lock the room (since we want to keep access as easy as possible we did not want to use passwords to lock the room, also we don’t know who will join beforehand, so distributing said password is not feasible). The problem with that is that while people can request access, there is no way to communicate before, and as people can freely choose a nick, they might be unsuspicious-looking but actually be the same person that was kicked earlier.

Proposal

Be able to initiate a chat with the person knocking, to give a simple challenge/response before granting access.

[damencho]

This sounds like an interesting feature and I see its challenge is the UI part. That part we may need to discuss with our UI designer ... if you have ideas on that part or mockups share them here ... so we can start that conversation

[umitdogan1]

Hi @damencho we will be developing discussed challenge/response feature for The Document Foundation, and later planning to open a PR to contribute to jitsi-meet with this nice and handy feature. @ilmari-lauhakangas is from the Document Foundation. Me and some other devs will show up here soon are from Doganbros

After some discussion with The Document Foundation and kicking off this comparatively small project, as doganbros we have been working on debugging and analyzing the current lobby feature on Jitsi to propose a solution for challenge/response feature. Finally, i want to share with you our solution proposal for challenge/response feature:

We did quite some research and debugging existing lobby features. Finally we concluded that it seems possible to set up a kind of chat between the knocking person in the lobby and the moderator. If the knocking feature (lobbing) is enabled and when a room is created, Jitsi also creates another room behind the scenes which is called 'lobby room'. When someone else enters the meeting initially, this person is also added to the lobby room and he is immediately removed from the lobby room when he is accepted or rejected. So only the moderator and the other pending possible attendees remain in the lobby room.

Jitsi communicates the possible attendees waiting in the lobby and the moderator in a "knock then accept/deny" messaging mechanism through the lobby room already. This functionality seems to be extended to set up chat communication between persons in the lobby and the moderator. Within this chat communication, the moderator can challenge the knocking person with a question and the knocking person can give a response accordingly then the moderator may accept or deny the joining request.

Since we are planning this feature to be part of Jitsi project, we will be trying to get your confirmation and validate our work before actually doing it. So we need your comments and suggestions on our solution proposal before going into UI Mockup. After finalizing UI mockup then we will share with you and try to get a confirmation for the actual implementation plan. And so on...

[damencho]

Just one thing, I noticed in your description you are talking about a single moderator, mind that everyone in the meeting can be moderator, consider having multiple moderators.
I need to run this through product, but in general sounds good, as ling there is a flag for disabling it ...

[umitdogan1]

Yes you are right. Give me some time to extend the proposal for multiple moderators scenario.

[umitdogan1]

Here is the updated solution proposal summary (updated part is bold):

We did quite some research and debugging existing lobby features. Finally we concluded that it seems possible to set up a kind of chat between the knocking person in the lobby and the moderator. If the knocking feature (lobbing) is enabled and when a room is created, Jitsi also creates another room behind the scenes which is called 'lobby room'. When someone else enters the meeting initially, this person is also added to the lobby room and he is immediately removed from the lobby room when he is accepted or rejected. So only the moderators and the other pending possible attendees remain in the lobby room.
Jitsi communicates the possible attendees waiting in the lobby and the moderators in a "knock then accept/deny" messaging mechanism through the lobby room already. This functionality can be extended to set up chat communication between persons in the lobby and the moderators. Within this chat communication, a moderator can choose to respond to a knock by initiating a challenge/response chat. Once any moderator has responded in this way, other moderators are notified, by the added chat button changing to display a message containing the name of the moderator already responding the challenge, the moderator can challenge the knocking person with a question and the knocking person can give a response accordingly then the moderator may accept or deny the joining request.

[umitdogan1]

@damencho any comments?

[damencho]

I need to talk with Product team about it, about the direction, or any other concerns... If you don't hear from me till next Monday, you can join the community call and present it there (I hope Emil will be there so you can discuss it).

[umitdogan1]

@damencho @ilmari-lauhakangas

Here is the scenario:
When a person in the lobby knocks, all moderators see him in the knocking participant list. One of the moderators may initiate a chat by clicking Chat button of the knocking participant. Then all moderators will get a notification message "X started a challenge/response chat with Y" where X is the name of the moderator and Y is the knocking participant. Only one moderator can do a challenge/response chat at a time. Todo so, other moderators who have not initiated the chat will see the chat button of the participant who is in chat with a moderator as a text (i.e. non clickable) "Chatting". The moderator who has started the challenge/response chat will be able to decide to accept or deny the knocking person by clicking Allow or Reject buttons on the knocking participant list. Also other moderators can accept or deny the knocking participant in the same way without chatting at anytime.

Here is the UI mockup:

[damencho]

I talked with Emil and he gave a green light. For the UI part we may contact design and ask for a proposal ...
I would vote for an icon for the chat instead of text, 3 text buttons on multiple rows ... looks weird ...

[umitdogan1]

Yes you are right, chat icon will be much more better. Ok will be waiting for your updates.

[damencho]

What updates do you mean?

[umitdogan1]

I thought you will be contacting with your design team to ask for a proposal and let us know. Am i right?

[damencho]

Ok, I will talk with them.

[umitdogan1]

@damencho any update?

[saghul]

Hey there, love this :-) I'd say you are welcome to start the implementation without the UI parts / with some crude UI while we get a design, WDYT? Looks to me like the UI will not be the biggest part of the task...

Also note this feature would need to also be implemented on mobile.

[umitdogan1]

Hi! Happy to hear that. Before starting the implementation let me share with you the implementation plan i.e. how will we do it. And yes mobile is also in the scoop, just after the web.

[saghul]

Sounds good!

[umitdogan1]

FYI. We are still working on the implementation plan, some debugging, mockup implementation and testing. Will share here soon.

[saghul]

Thanks for the update!

[umitdogan1]

The main and lobby rooms are created from the same ChatRoom class by Jitsi. We are trying to use the sendMessage and sendPrivateMessage api of the lobby room instance to send messages to participants in the lobby room but the messages don't get broadcasted to their end when we listen with the xmpp.message_received event. We checked the debug logs of Prosody and realized that the fire event is been triggered as well. Is there any reason why we can't receive message in the lobbyRoom when we use this api?

Listening for messages

APP.store.getState()['features/base/conference'].membersOnly.room.getLobby().lobbyRoom.on('xmpp.message_received', console.log) // listener for the attendee 

APP.store.getState()['features/base/conference'].conference.room.getLobby().lobbyRoom.on('xmpp.message_received', console.log) // listener for the moderator

Sending message

APP.store.getState()['features/base/conference'].conference.room.getLobby().lobbyRoom.sendMessage('My message', 'body') // moderator to attendee message

APP.store.getState()['features/base/conference'].membersOnly.room.getLobby().lobbyRoom.sendMessage('attendee message', 'body') // attendee to moderator message

Debug logs from Prosody

Nov 12 15:42:12 http.server     debug   Firing event: POST /http-bind
Nov 12 15:42:12 mod_bosh        debug   Handling new request table: 0x564948784c00: <body rid="3364291608" sid="c401a783-bfbb-4f5e-9224-48831a0329d0" xmlns="http://jabber.org/protocol/httpbind"><message to="test-room@lobby.meet.mydomain.com" type="groupchat" xmlns="jabber:client"><body>attendee message</bod$

We used a similar approach on the main room and everything worked correctly. We also didn't spot any difference between the debug logs of the lobby room messages and the main room messages. Is there any difference between how the backend handles messages for the lobby room and the main room?

[damencho]

Put a break point here and see where is dropped https://github.com/jitsi/lib-jitsi-meet/blob/c24130622ef3cf24078b0e5244a09e1d9c37dfd7/modules/xmpp/strophe.emuc.js#L161

[mkhstar]

Hi @damencho
I am working on the same project with @umitdogan1
We have actually tested that previously but it doesn't enter the onMessage at all. I attached a simple video below to demonstrate that

Screen.Recording.2021-11-16.at.6.32.36.PM.mov

[damencho]

You can do the same, but also opening the Network tab and check whether the message is sent and whether it is received over the network.

[mkhstar]

I just did some simple tests by using the network tab now. The message is sent but it is not received by anyone over the network

This is the post request it made while sending the request. I also got 200 ok response

<body rid="188043053" sid="6fd03772-f0f5-4b96-bce1-754b7a552764" xmlns="http://jabber.org/protocol/httpbind"><message to="test-room@lobby.mydomain.com" type="groupchat" xmlns="jabber:client"><body>My message</body></message></body>

But it was not broadcasted to anyone including the current user

[damencho]

hummm then it is filtered in prosody ... do you see something about this message when in debug mode?

[mkhstar]

As we stated above we actually see an event fired when we view the debug logs at the backend. But we don't really know why we can't receive the messages from the front end
Debug logs from Prosody

Nov 12 15:42:12 http.server     debug   Firing event: POST /http-bind
Nov 12 15:42:12 mod_bosh        debug   Handling new request table: 0x564948784c00: <body rid="3364291608" sid="c401a783-bfbb-4f5e-9224-48831a0329d0" xmlns="http://jabber.org/protocol/httpbind"><message to="test-room@lobby.meet.mydomain.com" type="groupchat" xmlns="jabber:client"><body>attendee message</bod$

[damencho]

Hum ... something is dropping you should see message received delivered
I suspect being dropping it here https://github.com/jitsi/jitsi-meet/blob/master/resources/prosody-plugins/mod_muc_lobby_rooms.lua but couldn't find something suspicious at the moment.

You can try and see when you do same with main room what are the debug logs that you miss when you do with lobby ...
check filterStanza method for the lobby maybe its filtered there.

[mkhstar]

Hi @damencho we realized that the messages were filtered out by the filter_stanza. Thanks a lot

[umitdogan1]

Here is a video rec. by @mkhstar showing POC workout
https://www.loom.com/share/fadfc808c3e047f9a6311b2cdef3f587

[umitdogan1]

Here is the implementation plan. @saghul @damencho any comments.

Jitsi Challenge-Response Feature Implementation Plan.pdf

[umitdogan1]

@saghul @damencho we are planning to start actual implementation this week. Any update from design team or can we start according to the design here ?

[umitdogan1]

We have started the implementation and planning to create a PR for challenge-response feature next week.

[saghul]

Looks like a solid plan, thanks for putting the document together!

[umitdogan1]

@saghul @damencho PRs are created for challenge-response feature. It is tested on web browsers supported by Jitsi as well as IOS and Android mobile devices.

[saghul]

@umitdogan1 Thanks! We are preparing a new release so it may take us a bit of time to get to it, but we will.

[umitdogan1]

@saghul any update? Or any estimation about the date for review or merge?

[saghul]

I'm off until the new year so no updates on my side. Not sure how busy damencho is but last I checked he was pretty busy.

[umitdogan1]

@saghul @damencho let's finish this up and introduce challenge/response feature to the community. What do you think?

[umitdogan1]

@saghul @damencho any update?

[mustahsin64]

Looks like a really useful feature to have, Please let us inform when this feature comes live :)

[umitdogan1]

Looks like a really useful feature to have, Please let us inform when this feature comes live :)

We were planing to create PR today but faced with new conflicts. Working on it. Stay tuned :)

[umitdogan1]

We had a pull on 19 Jan. from this commit b80531c

We have been resolving conflicts and ready for PR today. But, realized that there are lots of new commits related to lobby room and knocking participants feature which are causing new conflicts. Also, it seems lobby room and knocking participant UI has changed to a great extent since our last pull.

Today we will try to fix all issues and adapt UI of the lobby room chat (challenge/response) feature according to the latest update. Probably create a PR tomorrow.

We have a question probably to @saghul here, will there be constant changes in lobby room in the following days? Is it highly possible for us to face with new conflicts?

[umitdogan1]

@damencho @saghul PR is created
#10847

[stale]

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.

[saghul]

PR landed, closing.