Add option to report a user to the instance admin/mod of that user too


#1

This can probably be useful to avoid silencing/suspending complete instances. In this way an instance admin/mad can be better warned about misbehaving users on its instance.

I think this will very suitable for 1.5.

I made this Github issue:

Currently you can report users and their toots to the instance admin you are on. I like to request an extra option to report a user (incl toots) to the instance admin of that specific user.

Example:

  • User 5 at instance G (5@G) has a problem with toots of user 3 at instance K (3@K).
  • Current situation: 5@G reports toots of 3@K to the admin/mod of instance G
  • New situation: 5@G can also report the toots of 3@K to the admin/mod of instance K or it can choose to report to the instance admin/mod of instance K alone, so…

A user has three options (using a drop-down menu, with 1 (current) as default):

  1. It can report to its own instance admin/mod
  2. It can report to the instance admin/mod of the reported user
  3. It can report to both instance admin/mods*

* it should be made clear to both admins/mods that this report went to both admins/mods (so they have a change to consult each-other)


#2

federated reports! a classic feature request and an excellent one imo


#3

There seems to be an old issue on GitHub that is for the most part the same as my idea. Still I think this is necessary ASAP (1.5).

https://github.com/tootsuite/mastodon/issues/2176


#4

I’m against it. We saw with current dramas that there is a big issue about people wanting to impose their moderation to other instances. Each instance should be only moderating its own instance and should not have a say on other instances moderation.


#5

As an admin, I want to know when my users are causing trouble on other instances. It’s up to me to decide whether I should take any action. No one can ‘impose their moderation’ on my instance, but I want to be a part of the community and so I need to maintain some awareness.


#6

@Naouak You could simply block reports from that instance. Besides, it doesn’t mean you have to do it, but it’s a good idea just because most instances are not run by very large teams, and the more eyes, the more helpful.
Besides, as it is, the only course of action to report these things is to ping you directly.


#7

The current ‘dramas’ just show that a lot could be prevented if an admin knows about its misbehaving users.

Some people in the duplicate issue say that those remote reports should be anonymously, but I don’t think that’s a good idea, cause it will be subject to abuse.


#8

No the current drama is about mastodon.social moderators imposing their moderation on targaryen house under threat of silencing. When you are one of the main instance by user count/activity, it is just abusing and goes against decentralization principles.

If you want to make mastodon a more centralized network, you are adding the right feature.
If you want to make a true decentralized network, then each instance should manage its own moderation and only its own.


#9

What happened with targaryen could possibly have been prevented when the instance admin was earlier aware of misbehaving users.

This has nothing to do with centralization vs decentralization. Actually I’m in favor of as much decentralization as possible. Please don’t mix up things.


#10

He was aware of misbehaving user but decided that according to his moderation standard of his instance it should not be moderated. Mastodon.social did not agree and silence the whole instance instead of the single user.

Decentralization is about each instance doing whatever they want. The only thing that should be transmitted are statuses according to how Mastodon has been defined so far. Transmitting moderation reports is not only against the original definition but would also be a vector for attacks and instance admin harassment.


#11

You do not know if there were earlier mastodon.social users that had complains about this misbehaving user. If the remote reports where there, maybe those users had sent earlier sent reports to the targaryen admin and wasn’t this escalated. We don’t know and doesn’t make sense to talk about it afterwards. It is also not the only inter-instance issue we had.

The main issue here is that instance admins will have an option to know if users on their instance are misbehaving themselves. As @nbd already suggested, an instance admin can block remote reports or block/allow it from certain instances.

Decentralized doesn’t mean that instances are completely isolated. If they were, they were just a tiny walled garden.


#12

Have you read the stance of Wonderfall about this particular piece of moderation. Remote report would have not changed that (and he is also against the feature proposed in this thread from my discussions with him).

Remote report add a lot of issues that we don’t want to deal with. Here is an example I posted earlier on mastodon:

Here is an example on why sending moderation to another instance is bad:

My instance is about squids. We love to post squids pictures from times to times.

Let’s say that there is an instance with people that hate squids and some toots that federate from my instance to their instance are not according to their moderation policy.

Should I block users that post squids picture because of this other instance? This would not be fair.
Should I received all those reports? Hell no!

Each instance has its own moderation policy and this feature will only bothers us most of the time. I don’t want to deal with massive reports because some “safe-space” decided that one of my user is a Nazi.


#13

I don’t think we will agree on this matter. Of course every instance has its own moderation rule and I don’t disagree with that, but an instance also don’t want to be suspended or silenced by other instances most of the times. So it’s a good thing I think that an instance admin can choose to receive remote reports about its own users. So the admin can keep on eye on them how they behave outside the instance. So the admin can act proactively. The admin doesn’t have to act on the report, it can also consider it as a FYI or a CC.

But I don’t think we will convince eachother.


#14

Why is it about the instance when the issue is with one user? Why is mastodon.social silencing a whole instance for an issue with a particular user?

In my opinion, instance blocking/silencing was a mistake and we are fully continuing with it by identifying users with their instance and not as users.

When moderating on your instance, you should not even have to consider where the content comes from but only if it respect or not your moderation policies. Considering that, reporting users to other instance makes no sense and brings more problem that it will actually solve.


#15

I think we’re just trying to say that this feature can be seen as an oppressive way to tell the admin : “do your job, otherwise I won’t do yours and I’ll mute your entire instance”. Like you said, no one wants that. I think that you think this is rather a way to tell : “hey why don’t you take a look at this user so he’ll harm no one else, we already blocked him, do whatever you want, peacefully”.

But I think that in reality, and from what we’ve seen, things will happen differently (no need to tell the whole story again). Some admins will begin to abuse the feature in order to suggest their moderation policy to other admins, which is basically called an interference. I think we shouldn’t add an automatic way to do it. If an admin has something to say, we can still use direct messages, or mails, or whatever. It is more relevant because it will likely lead to a conversation about the moderation policies of both instances (and then admins decide what can be done).

If this feature were to be added, I think we should at least consider a way to :

  • Add comments. Words are so much better than pre-established reasons.
  • Ignore reports from an instance (perhaps we should consider a way to tell that reports won’t be treated).
  • Add a way to answer, again with words.

But starting from that, why not keep it the old way?

As a conclusion, I’d say this feature would be relevant if the moderation policy was the same everywhere. And I believe that actually, admins have enough tools to react accordingly, and no tool should replace admin communications.


#16

As we do not wish to censor your views of the recent events, we are not going to remove them from this thread.

But please keep the rest of the thread on topic in regards to the feature. (and keep in mind this forums guidelines as a whole)

This feature has been requested for a while, and it has been on my radar since long ago, as it would help admins look at reports against their own users from other instances. There has been a lot of misunderstandings regarding how reports work.
To a lot of mods it would be more useful to be able to see how their users behave against users of other servers, rather than receiving the reports of users from other servers, which they can’t really do anything about themselves. If that makes sense.
The feature would also avoid the diplomatic part of having to find the correct admin in the mastoverse, which for some admins may just be too time-consuming.

However, as Wonderfall says here, being able to ignore reports from chosen instances would be useful, or possibly combine with the ability to whitelist servers instead of opting out of servers (similar to the feature awoo.space uses for their federation).

Details which may be worth discussing in this thread would be:

  • How do we avoid ddosing smaller instances with reports from other servers
  • Should sending reports be a through a pull, or a push?
  • How do we protect the anonnymity of local users, when the reports federate
  • How would we provide communication between admins for this
  • How could we combine a blocklist (for reports) and a whitelist?

#17

It seems like the content of reports biases admins in a lot of cases, and knowing which admins are seeing problems biases them as well.

It might be better to cut out user-report-to-other-instance and have ‘report’ simply go up the chain, and then each admin gets counts of how often a given user (say, Q@wubble) gets reported as a whole by ALL the instances that wubble hasn’t suspended.

Then all that’s seen is how much of a ruckus a given user is causing, and judgments about the reporting instances become impossible by definition.

Having three options for who to report to seems unnecessary to me, TBH. A user on an instance is presumed to trust the admin (and ergo shouldn’t need to not report to them), but the tendency of people to take reports personally and react badly suggests that perhaps it’s not helpful to have that channel in place.

Perhaps I’m missing something here, of course. (I often do.) Just some thoughts. :slight_smile:


#18

I’ll answer your questions in the same order:

  • The key here IMHO is to make the feature opt-in so that admins who do not care about federated reports, don’t have to look at them.
  • Reports should be push to make them federate as fast as possible.
  • Anonymity is going to be difficult for certain report cases, (examples - targeted harassment), since the target of the harassment is likely to be in the reported post.) I may have a solution for this that I will post after.
  • Maybe a version of the direct messaging system integrated directly into the reports system would be ideal for communications between admin(s).
  • I don’t really have an answer for the last question.

RE: Anonymity

Ideally, reports don’t immediately federate to the other server, it lands in the queue as normal and then the admin(s) of the local server can make the executive decision to federate said report. There should be an option to strip as much metadata from the post before sending it on to the other server’s admin, in case of sensitive matters like targeted harassment.


#19

How about this as an idea?

Ideally, the instance where the report is being made would either automatically or with a click from a mod or admin, send a message to the admin of the offending user’s instance. “Hey, admin@instance1 here. Received a report from one of my users about one of yours, specifically <link to user/toot>. This alert is just FYI, and of course does not require action from you.”

The local admin knows what’s going on, the remote admin is aware that something MIGHT be going on, and everyone’s free to do what they need to, based on their local policies and personal judgement.

as for Maloki’s questions:

  • Put a 60 second timer on it, either per reporting user or reported toot, or a flag “this toot has already been reported, thanks for helping keep this instance awesome!” I suppose it could work to keep a local log of reports, and simply send the admin of the remote instance an alert. “There have been reports, see -this URL- which includes the details: who, when, what etc.” And then limit those alerts to one a day, an hour, etc but keep the report list updated.
  • Anonymity is easy if you go with the ‘report’ class toot I mentioned above. Just strip the reporting username from it when sending it out. It comes from the admin, not the user.
  • Admins can reply to this toot if they want to discuss it.
  • If the ‘report’ toot comes from a system account ‘reportbot’, the receiving instance can silence that user from a specific instance if they’re tired of getting reports from some incompatibly administrated instance or other.

Now, this makes sense to me, but of course my own ideas are always awesome until punctured by reality and facts. :wink: But, as an admin and SysOp since ~1989, it seems sensible…


#20

I would say that I’m not sure that toots would be an ideal solution for relaying this information – people trying to game the harassment system could definitely abuse that. And I’d personally feel far less likely to report if I have to trust that everybody involved knows toots need to be treated as public (the system’s mechanisms are still not apparent to all users, even admin-level ones – if I’m understanding correctly, up until somewhat recently a m.s mod or admin was unaware users they muted could mention them and still show up in their notifications, frex).

Inside a single controlled system, it’d make sense – but Mastodon’s exposed interconnections might warrant more caution in handling interadmin communications about abuse, IMO.