⛔ Banning users and guests - Overview

[nickvergessen]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Overview

1. We need an option to prevent guests from rejoining a call/chat/conversation when the moderator removed them Guests can immediately re-join a public meeting after being removed by the moderator #1423
2. Similarly there should be an option to block "logged in" users from rejoining open conversations when the moderator removed them.

For 1. we will use an IP based approach, 2. can be solved by recording actor type+id, additionally we will log the moderator performing the ban, a timestamp and allow providing a text note.

Blocking a participant will not allow them to join the conversation. It is okay to be still shown in search results?

Tickets

• API ⛔ Banning users and guests - API #12292
  • Contract ⛔ feat(ban): Contract for banning attendees and IP/ranges #12259
• Frontend ⛔ Banning users and guests - Frontend #12293
• iOS ⛔ Banning users and guests - iOS talk-ios#1650
• Android ⛔ Banning users and guests - Android talk-android#3898

[Antreesy]

It is okay to be still shown in search results?

If there is a possibilty to unban person, I'd say yes. Then we can mark them in search results as banned (with a reason e.t.c) and on click perform both: unban + invite.
Otherwise it would complicate things to navigate to another tab/list/ whatever we come up with, find needed person, unban it from there, and only then add to a conversation

[DorraJaouad]

For 1. we will use an IP based approach, 2. can be solved by recording actor type+id, additionally we will log the moderator performing the ban, a timestamp and allow providing a text note.

What if, a logged-in user gets blocked from an open conversation and then join the conversation as a guest? Shouldn't 1 and 2. be solved both with IP based approach ?

[nickvergessen]

Shouldn't 1 and 2. be solved both with IP based approach ?

Might be a special case, we can have IP block in optional addition when the conversation is public, but since multiple people could be on the same connection (offices, etc.) we need to be able to block individuals instead of IPs.

It is okay to be still shown in search results?

If there is a possibilty to unban person, I'd say yes. Then we can mark them in search results as banned (with a reason e.t.c) and on click perform both: unban + invite.
Otherwise it would complicate things to navigate to another tab/list/ whatever we come up with, find needed person, unban it from there, and only then add to a conversation

I think you misunderstood. I was referring to list the room e.g. in open conversations for the blocked user, similarly the name of a conversation the user got blocked from is not "private" I would say.

Of course we need the option to unban attendees/IPs. But this can be burried in the moderation settings of the conversation

[SystemKeeper]

How are we naming that feature user-facing (e.g. when showing it in the conversation settings to list all bans)?

• Banned actors -> I think we don't have actor user-facing right now. Could also sound weird when translated
• Banned users ?
• Banned users and guests ?
• Banned participants?

Edit:
Also do we use the word "Unban" to remove a ban? Or do we go with something like "Remove ban"? I could image that "Unban" might be tricky to translate.

[nickvergessen]

Copying from #12292 (comment)

• RequireModeratorParticipant is also true for 1:1 conversations. Do we allow blocking in 1:1 ?

No, banning is not supported in one-to-one

• Does internalNote has a maximum length we need to enforce?

Let's say 4k?

• We do have the information actorType and actorId about the person that did add the ban. Should we also include the actorDisplayname? Otherwise we can only show the actorId to the user, which might be weird (e.g. LDAP). Same probably for the banned participant in case we can determine a displayname?

That makes sense

• Do we allow to directly ban an IP? According to the contract, this would be possible by specifying ip as actorType.
  Since we don't know the IP of any of the participants, I am not sure this is correct?
  

  spreed/lib/Controller/BanController.php

  Line 36 in 3cda633

  * @param 'users'|'groups'|'circles'|'emails'|'federated_users'|'phones'|'ip' $actorType Type of actor to ban, or `ip` when banning a clients remote address

That's right, I never thought about this. The plan was to allow banning an IP. But yeah we don't have a record of the guests IP atm so we need to think a bit more about it.