Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Alternative to the Code of Conduct : Federated blocking/allowing Lists #1092
The Mastodon federation regroup many instances, inside of them there is many people with differents views.
Through a discussion on Mastodon I found an idea that could be a viable alternative of the Code of Conduct for all.
The idea is to copy the way an adblocker work. Many groups make differents lists (black/blocking and white/allowing list) and the end user is able to choose which lists he/she want to use.
Okay so I'm going to take the time to answer this, and then close it. It looks like most of the people working on the project agree with the point of view I'm going to develop (a bit) here.
Alright, so, what you're proposing is basically a system that works the same as twitter does already. At least, as it works the same as how people have hacked twitter to work. With things like Block Together and/or GGAutoBlocker, this feature works exactly as you described it except that it's not included in twitter's model.
This system is bad for two reasons:
Now, one thing with Mastodon is that you can use any instance that you want. Thus, if you want to get to an instance that doesn't do any filtering and doesn't have a code of conduct, you can easily do that. If, on the other hand, you want to join a community that has a CoC, and where people who attack you are not welcome (and are blocked quickly), you can also find one. Which is something that is simply not possible with Twitter.
The idea of an instance being a community (which is illustrated by the local timeline) is fundamentaly incompatible with people with completely opposite political ideas using the same communities.
Another point you talk about and I wanted to reply to was "let the sys-admin of an instance really focus on the sys-admin work and not finding a good moderation team". In my opinion, moderation should totally fall on the shoulders of the admin(s) of an instance. Moderation is part of hosting any forum or social network, or anything that other people use really.
Finally, I believe the Code of Conducts of each instance is a great thing for them to have : it allows users to know what is and is not okay to do there, what the tone and users of that instance look like, and whether or not that instance is the right place for them.
EDIT June 22nd : speaking in my own name, I don't think this idea is bad in and of itself, I just think it doesn't integrate well into the way Mastodon was conceptualized (the concept being that of blocklists, not of replacing Code of Conducts). This doesn't mean people aren't using Mastodon in other ways, and I believe a good enough PR with this feature would probably be accepted (again, I only speak for myself here). It definitely isn't a priority for the project and probably won't be for a long while, but if it's really important for you you can probably make a PR for it.
I'm unclear as to why these are considered two mutually exclusive alternatives: either we develop shared or subscribable blocklists or instances have codes of conduct and admins/moderators moderate users and federation with other instances. I want both of those things!
Mastodon has individual block features now, even though we have administrator and moderator roles. I would understand shared or subscribable lists as a way to further decrease user effort; I don't have to create the whole list myself if someone else that I trust has already done so.
Per your edit, @wxcafe, is the idea that this wouldn't ever be on the open issues list as it's not a priority, but a complete PR that did develop this issue could be opened later?
I don't see where this proposes to remove other types of blocking. I understood the proposal as a request for a new feature.
From a perspective of "how likely is this to ever ship, given the realities of software development, testing, and maintenance:" the federating/subscribing/etc machinery seems like a lot of work. I think there is a minimum viable implementation here: a textbox where users can paste lists, and/or a text field where they can paste a url to a list which is then loaded (and perhaps polled periodically thereafter).
If this basic feature were implemented and a lot of people ended up using it, that's a signal that it may merit the considerably greater complexity of federating lists, etc.
BTW, I have another perspective on the "who should do the moderating" question.
First, it is not realistic to expect every instance to have highly responsive and dedicated moderators, especially for a decentralized project where you can spin up a new instance in Docker (or whatever) in 3 hours. People start instances as hobbies or for their friends. People have jobs, people go on vacations. And so on. In those cases, users may need tools of their own.
Second, brigading-type harassment happens in real time. Moderation may not. Assuming that instance admins will handle all moderation quasi-centralizes moderation on a system that is inherently decentralized. Users may be able to respond more quickly and certainly in a more granular fashion when brigading is happening.
Third, shared blocklists reduce the drama load experienced by administrators due to moderation decisions. There is less threat of "who federates with whom" drama when groups of users are collectively making their own decisions about who they want to talk to, while not affecting neighbors on their local instances by clamoring for instance-level blocks.
There are downsides to shared blocklists which I'm not listing here. And for the record, I personally am not interested in "safe speech" and so on, I prefer "open speech" and have started a list of instances with minimal instance block policies. However, Mastodon has a lot of users who do want a very reliably pleasant timeline.
Bottom line, I think shared blocklists are an okay compromise between the concerns of "safe speech" users and users who don't care so much about that. It's perhaps not the most precise tool, but it carries a lot less potential for collateral damage than overzealous instance-level blocking.