Apologies for this second post. This one should be the last. I’ve continued thinking about the best way to handle moderation in the fediverse, especially because I believe that the fediverse as a whole will live or die based on how moderation is handled.

I’ve worked in the past with email products, email being one of the clearest examples of federated networks. Even though email is quite different since there’s no public messages, I believe we can draw some inspiration regarding how to handle federation and moderation. More specifically regarding a key metric that also applies to the fediverse: the degree of “spamminess” of a message.

But let’s first see some of the principles.

Principle 1: Local content, local values

This principle states that instance administrators should not be expected to host or make available content that goes against their values and beliefs. What is included in this principle:

• Restricting certain content in local communities.
• Restricting local users from displaying certain behavior, even when commenting in remote communities.
• Silencing (not yet implemented) or removing individual remote communities so that they do not show in their list of communities or their feed, thus not giving them a platform.

Most important this principle incentivizes every user to find a home instance that matches their beliefs and values.

Principle 2: Everyone cleans their own turf

Reports made about remote users or content in remote instances should be handled first and foremost by remote community moderators and, in second instance, by remote admins.

Users should block content or users after reporting and enough time should be allowed for remote instances, especially smaller ones, to react to a report.

Local admins might act immediately if it’s an urgent matter such as doxxing and private information, or they can issue a temp ban of, for example 3 days, during which the remote community has time to catch up. Ideally, however, local admins will not have to deal with issues caused by remote users on remote communities. This is because it’s not feasible for smaller instances to do moderate the whole userbase of a large instance. We need to learn to delegate those reports and have them resolve remotely even if we receive them.

If the remote instance does not moderate effectively or according to our beliefs and values, the third principle comes into play.

Principle 3: Users and communities have a degree of spamminess and of utility.

Let’s talk about spamminess first. Basically every interaction can be judged on its degree of “spamminess”.

• If a remote user forces itself into a community to send offensive messages, that’s spam.
• If a remote user is sharing their opinion in a thread created specifically to discuss such opinions, that’s not spam.

Whether a comment is spammy or not depends on the nature of the interaction. If someone is going out of their way to cause drama, the interaction is probably spammy. Basically we need to ask ourselves if the user has been asked or is allowedto share their opinion.

Spammy users should be banned by the instance that hosts them. If that’s not the case, then this could count as a strike against the user’s instance. If a remote instance has been given enough time to fix issues and they still keep enabling spammy users, then it could be grounds for a block not unlike there’s blocklist for mail servers that send spam.

Examples of spammy behavior:

• Brigading
• Trolling
• Going out of their way to cause drama or irritate others
• Concern trolling
• And of course, not correctly setting NSFW flags These are all examples of forced / involuntary interactions that should be avoided at all costs.

Now what about remote users that display a controversial opinion in threads where they were asked to share such opinion (ie, they are civil)?

In that case the instance admin should ask themselves about the utility of this remote user or remote instance.

Provided they act in a civil manner and they are not spammy it might be reasonable to a) not act against them, b) silence them (not yet implemented on lemmy) or c) block them in local communities only (not yet implemented on lemmy).

A civil user with controversial opinion, depending on the context and what these opinions are might still have some utility. For example, they could contribute positively in other places with tech guides, interesting content, etc… and we do not want to be overzealous in blocking them. Maybe it’s something we can leave up to each user (thus the importance of users learning to block).

Anyways, the idea here is that the admin team needs to make a judgement call on the perceived utility and decide which action is better. Given that the user is civil maybe a silence or a block on local communities suffices. This is all relative and every admin will need to decide on their own.

The most important point: whether a civil user with controversial opinions is banned, silenced or otherwise, the user’s home instance should not be affected. Mostly. Let me explain.

Regarding instances themselves, they also have a utility score. For example, if an instance is solely dedicated to the support of values that I find strongly offensive, then there’s little point in federating with them. It’s unlikely that I’ll get any net utility from either their users or communities.

However, this could be different with large general instances where maybe I’ll end up flagging 1000 different users which are civil but have controversial opinions, but I still get utility from the other 99%.

Of course this only works if these remote users are not spammy. If a remote instance is large and enables spammy users as described above, then this 1% of users could very well cause me to block the whole instance, especially if we are constantly harassed by them. I suspect this is what could have happened recently with beehaw, but I don’t want to get into that since this post is about general guidelines that I’ve been thinking about.

In summary, regarding principle 3:

• Spammy users are bad actors that drastically lower the utility of the remote instance that hosts them
• Instances that enable spammy users are bad actors have drastically low utility.
• Remote users that are civil but have controversial opinions have lower utility, but action can be variable depending on context.
• The severity of an action should depend on the utility of a user or an instance.

And this brings me to my last point: We instance admins need to be extremely realistic about the utility that our userbase derives from remote instances and remote users.

I can’t emphasize this enough. Suppose I’m an instance admin and I see one of these civil users with controversial opinions in the wild, I can’t fucking go on a crusade and threaten to defederate the whole instance because they allowed a discussion to happen the contents of which I don’t agree with. I can’t use my userbase as a blunt tool to threaten defederation from instances who don’t have my same world view.

Referring back to the first principle, as instance admin it’s understandable that I don’t want to host or platform certain opinions and I need all the tools to block these remote communities, users and even instances that are solely or overwhelmingly dedicated to something I strongly oppose.

However, if we want federated alternatives to succeed it does not make sense for Gmail block Outlook because Sundar Pichai doesn’t like Satya Nadella’s world view / politics / opinions. That would be weaponizing of your userbase.

Which brings me to the last principle:

Principle 4: don’t weaponize your userbase to try to impose your values

• If you don’t like X, Y, Z remote communities on your instance, hide them or block them (this covers the first principle of not giving a platform to content you strongly disagree with).
• If a remote user is spammy or an instance enables spammy behavior, block them.
• If a remote user or remote instance is dedicated so overwhelmingly to something that you and your users see no value in federating with them, silence them or block them.
• However, instance admins should not threaten with defederation because a remote instance which otherwise has plenty of utility, has some aspects that they disagree with, especially if civility is maintained. At worst, that remote instance should be unlisted from public timelines or made “follower-only” (following the first principle), but not outright blocked.

The reason I bring this up is because I have a huge fear that we could end up waging petty wars and splitting up the fediverse, decreasing the overall usefulness of federated alternatives. If this happens we will never succeed.

In summary:

• You’re not forced to platform content you disagree with
• Focus on moderating your instance and your users and ask other instances to keep theirs moderated.
• Go harsh against spammy interactions, be moderate if it remains civil (unless utility is definitely negative. Be realistic and admit to yourself that a single controversial discussion won’t eliminate the utility of an instance that’s otherwise fine.).
• Don’t threaten with de-federating from an instance that your users find useful only because it allows civil non-spammy content that you disagree with. At worst make it subscriber-only or block only specific communities so that you don’t give a platform to the parts that you disagree with. If in doubt let your users block remote content.

Note: making a remote instance’s content invisible unless a user is subscribed to that instance’s community (unlisted/subscribers-only) is not a feature that lemmy currently supports but I hope will be implemented soon.