New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative to the Code of Conduct : Federated blocking/allowing Lists #1092

Closed
Astyan-42 opened this Issue Apr 6, 2017 · 5 comments

Comments

Projects
None yet
5 participants
@Astyan-42

Astyan-42 commented Apr 6, 2017

The Mastodon federation regroup many instances, inside of them there is many people with differents views.
Theses views collides on the moderation and the Code of Conduct policy.
I understand this topic can be important for many of us, of every side of the issue. So try to discuss respectfully.

Through a discussion on Mastodon I found an idea that could be a viable alternative of the Code of Conduct for all.
Two feature request already in the issue could be use as a part of it :

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.
The fact adblockers works particularly well with community lists make me think this could be an effective and personalized way to do moderation.
I believe this could make the moderation decentralized and adapted to every need (freedom peoples, anti-spam peoples, anti-bot peoples, anti-troll peoples, safe space peoples, etc...). And even to cover other needs.
Plus it avoid different moderation per instance (like the moderation is really in the hands of the end users) and let the sys-admin of an instance really focus on the sys-admin work and not finding a good moderation team.

In detail:

  • A federated blocking list is simply a list of accounts banned, you will never see there toot or retoot and they will not be able to follow you.
  • A federated allowing list is a list of accounts accepted, you will see toot or retoot and allow theses accounts to follow you. All the other accounts cannot.
  • Lists combine (you can use more than one list and you can use allowing list and blocking list. In this case the account in the allowing and blocking list will be block)
  • Activate lists are chosen by the end user. The admin of an instance can choose to have defaults lists but the end user can change them.
  • Users can create and moderate federated lists.
  • Users subscribing to a federated list receive automatic update of the list.
  • Users can send request to add an account to the federated list he/she subscribe too.
  • Federated lists can be change with the api, allowing bots to manage lists. This could allow the bots to do cool stuff like bayesian filtering.
@wxcafe

This comment has been minimized.

Show comment
Hide comment
@wxcafe

wxcafe Apr 10, 2017

Contributor

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:

  • one, it moves the moderation responsibility from admins to users, which makes the platform more difficult to use and to trust for people who get harassed, and
  • two, it's not as efficient: every user has to subscribe to the shared blocklist. It only removes the blocked users from the federated timeline for users who subscribed, and so the environment for new users isn't safe.

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.

Contributor

wxcafe commented Apr 10, 2017

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:

  • one, it moves the moderation responsibility from admins to users, which makes the platform more difficult to use and to trust for people who get harassed, and
  • two, it's not as efficient: every user has to subscribe to the shared blocklist. It only removes the blocked users from the federated timeline for users who subscribed, and so the environment for new users isn't safe.

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.

@wxcafe wxcafe closed this Apr 10, 2017

@wxcafe wxcafe added the wontfix label Apr 10, 2017

@npdoty

This comment has been minimized.

Show comment
Hide comment
@npdoty

npdoty Dec 2, 2017

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?

npdoty commented Dec 2, 2017

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?

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Dec 3, 2017

Collaborator

@npdoty the specific proposal in this issue was to remove admin-level blocking roles and replace it with a federated block list. if you have a different proposal, that would probably be a different issue.

Collaborator

nightpool commented Dec 3, 2017

@npdoty the specific proposal in this issue was to remove admin-level blocking roles and replace it with a federated block list. if you have a different proposal, that would probably be a different issue.

@nightpool

This comment has been minimized.

Show comment
Hide comment
@nightpool

nightpool Dec 3, 2017

Collaborator

for the record, I think the answer to that would probably also be "I don't think it's a good idea", but there are different reasons behind it.... we could discuss it here or in a different thread.

Collaborator

nightpool commented Dec 3, 2017

for the record, I think the answer to that would probably also be "I don't think it's a good idea", but there are different reasons behind it.... we could discuss it here or in a different thread.

@deutrino

This comment has been minimized.

Show comment
Hide comment
@deutrino

deutrino Dec 5, 2017

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.

deutrino commented Dec 5, 2017

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.

abcang added a commit to pixiv/mastodon that referenced this issue Jun 4, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment