Add block function for individual users

[grischard]

Users who receive abusive messages currently have to report the users to the admins. A recent case took too long to handle.

The website should make it possible for anyone to painlessly block messages from another user, the way you can block a pest on many social media sites.

If I block someone, it should stop them from sending me messages and commenting on my changesets and on my diary entries.

The UI should make it possible to block someone from the messages and from the user page. Once I've blocked someone, it should still be possible to report them, and of course to unblock them.

The admins should be able to see (and clear?) blocks for or by one user without having to mess with sql commands.

Admins and moderators should be able to send messages even when blocked.

[tomhughes]

Including an admin interface seems like an unnecessary distraction for an initial version at least - it's not clear when it would be used or even if it should be used. I can't imagine a situation where it would be appropriate for an admin to remove a block that a user had chosen to add.

I would say that the minimum necessary is a table listing blocks, a couple of appropriate links/buttons where users can block/unblock people and code in the message send function to respect blocks.

[grischard]

This might also be an opportunity to deal with #1946

[simonpoole]

...

If I block someone, it should stop them from .... and commenting on my changesets ... ...

Isn't providing such a facility a total non-starter?

Note that I -do- support fine grain control of access to the messaging system and potentially being able to block messages from individual users, though IMHO in general somebody sending any kind of unacceptable messages should simply be denied access.

[amandasaurus]

On Sat, 13 Mar 2021 17:43 +01:00, Simon Poole @.***> wrote:

If I block someone, it should stop them from .... and commenting on my changesets ... Isn't providing such a facility a total non-starter?

If one person (B) is harassing another (A), surely allowing B to comment on A's changesets is just allowing the harassment to continue?

However, I can understand the concern, because changeset discussion comments are (supposed to be) how we communicate about map edits, and the map itself. Perhaps, since changeset comments are public, people might not say things on it that they say in private messages, so maybe this isn't needed....

[dieterdreist]

sent from a phone

On 13 Mar 2021, at 18:19, Rory @.***> wrote:

However, I can understand the concern, because changeset discussion comments are (supposed to be) how we communicate about map edits, and the map itself. Perhaps, since changeset comments are public, people might not say things on it that they say in private messages, so maybe this isn't needed

+1, there should not be a way to block changeset comments. If someone behaves in an unacceptable way through changeset comments this can be publicly detected and dealt with

[gravitystorm]

+1, there should not be a way to block changeset comments. If someone behaves in an unacceptable way through changeset comments this can be publicly detected and dealt with

I like your faith in our moderators! But I disagree with it being sufficient. I know there are many examples of people feeling harassed by other users. Even if each message is reasonable, it can turn into unreasonable due to volume of comments, or other aspects of life that aren't visible to our moderators. For example, User A doesn't like User B for something that happened at school, and User A really doesn't want to see any comments from User B on their changesets.

But I agree that preventing changeset comments is a bad idea, since this is a collaborative project and they are an important part of this collaboration. I can easy imagine an un-collaborative person realising they can just block everyone else in their local area to avoid legitimate discussion of their work.

So my suggestion would be that when you block a user, they can't send you any direct messages. Beyond that, if you view anything created by them (like a changeset comment, diary entry, note, etc), then you see just a "This comment was made by a user that you have blocked (Show Comment)" or similar wording.

Would this be sufficient?

[gravitystorm]

Oh, and can someone please suggest another term for this feature, since we already have "user blocks" and that means something else :smile:

[simonpoole]

Oh, and can someone please suggest another term for this feature, since we already have "user blocks" and that means something else 😄

"silenced" or "muted" comes to mind.

[woodpeck]

Maybe we should call it "cocooning". For blissful mapping no matter what the others think of it. I can imagine many people who would like to use that a lot, because they are always right and the others are just harassing them. All the time!

Jokes aside, I don't like where this is going. At DWG we regularly block users for not replying to changeset comments - if someone points out a legitimate issue with your mapping, we (as a project) expect you to read that comment and at the very least stop making that mistake, or ideally reply to the changeset comment. Just because that comment came from someone you didn't like, doesn't mean you can ignore it. Now if we give people the technical means to ignore comments from individuals, we'd start enshrining the right to ignore people. What will happen if we block person X for blissfully repeating an error that person Y has pointed out umpteen times? "Outrage, you are forcing me to subject to Y's harassment!!!!" or what?

[grischard]

Ok, I think there's a consensus, and I've been convinced:

• No blocking of changeset comments
• A 'mute' button on messages
• A 'report' button on changeset comments

[matkoniecz]

A 'report' button on changeset comments

This one can look a bit ugly if it will look like any other button...

[grischard]

This one can look a bit ugly

Then it can be a text link, like on https://www.reddit.com/r/openstreetmap/ for example.

[matkoniecz]

Or like "report user" at user page, but even subtler

[simonpoole]

I've noticed, looking at EWG minutes and project descriptions, that this requirement from @grischard

Admins and moderators should be able to send messages even when blocked.

was dropped from the requirements for the CfP. I would consider this to be a must.

At the risk of creating scope slippage before anything has been done, there is the other long requested facility to be able to send messages from "the system" to users message inbox, particularly notifications of changeset comments. It would seem that this should at least be taken in to account when implementing this.

See https://github.com/openstreetmap/openstreetmap-website/issues/908 and https://github.com/openstreetmap/openstreetmap-website/issues/1387

@drolbr @tordanik

[mmd-osm]

A draft version seems to be in the making right now: https://github.com/osmfoundation/ewg_bidding/tree/draft/projects/ability-to-block-other-users

Let's wait until this proposal reaches a "ready for review" status. I'm sure there are other topics, which need further clarification, e.g. what is meant by "Inbox" (user's personal email inbox, or the inbox on osm.org, or even both?).

[tomhughes]

Well that's the problem with third parties designing features without consulting the people who actually know about the code...

[mmd-osm]

@drolbr just posted this one: https://community.openstreetmap.org/t/rfc-on-engineering-working-group-project/1542 & https://lists.openstreetmap.org/pipermail/dev/2022-May/031248.html

-> proposal is up for commenting now.

[tordans]

During the last EWG Meeting @grekko|s bid on the EWG project was accepted to implement the mute user feature as outlined in his proposal https://github.com/osmfoundation/ewg_bidding/tree/main/projects/ability-to-mute-other-users/proposals/gregory_igelmund-08-09-2023

[AntonKhorev]

There's an unread messages count available through the api. I don't see what's going to happen with it. If nothing, the user is going to receive notifications from apps like josm.

[grekko]

There's an unread messages count available through the api.

Thanks for the note. I was not aware of this yet.

Imo the API messages count should behave identical to how the web UI messages count behaves: It should not include muted messages.

I'm sure there are tests/specs for this. If not, I'll add them.

[AntonKhorev]

Editors like JOSM poll /api/0.6/user/details endpoint every few minutes. If JOSM sees unread message count going up, it shows a toast message.

[AntonKhorev]

Implemented in #4284, except for "admins should be able ..." which I didn't check.

[mmd-osm]

I'm closing this one, since feature was implemented in #4284. The "admins should be able..." requirement is likely not covered, otoh, it's not clear to me why this would be needed.