Show the list of muted/blocked users/instances by the instance in about/more

[Dostoi]

Currently if an admin mute/block users/instances you can't know if they do write it themselves somewhere.
It would be better for both users and admins if it would be added automatically to a page (about/more is an example).

This way the admin wouldn't have to manually do it every time.
And users would be able to know who is muted/blocked while using the instance . Or before coming to this instance it would be easier for them to chose to come in or not as they would know who they could reach and by whom could they be reached.

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[ghost]

Users are blocked or muted because you don't want to hear from them anymore. Listing them would just invite arguments. Plus the list might be pretty long for instances that have been around for a while.

For whole instances it might be useful, although that list too can grow quite long.

[ghost]

Users are blocked or muted because you don't want to hear from them anymore. Listing them would just invite arguments. Plus the list might be pretty long for instances that have been around for a while.

For whole instances it might be useful, although that list too can grow quite long.

[Dostoi]

"Users are blocked or muted because you don't want to hear from them anymore."
I can understand that argument when you're an user but it is different when you are an instance because your decision will impact all your users and they deserve to know how you are really handling the instance.
And they have the right to argue with it because it impacts their account (or you just specify in the code of conduct that if they disagree they just have to leave) and admin can't just do as they want, they also have an obligation toward their user. It goes both way

"Plus the list might be pretty long"
It's not an issue if it's put on its own page.
Plus users deserve more transparency to be able to leave the instance if they disagree with the moderation of the instance.

For example my instance doesn't have a page like this, doesn't say if there are muted/block account. I have no way to know if they just don't do anything or just don't talk about it as they're not responding to people asking them.

[Dostoi]

"Users are blocked or muted because you don't want to hear from them anymore."
I can understand that argument when you're an user but it is different when you are an instance because your decision will impact all your users and they deserve to know how you are really handling the instance.
And they have the right to argue with it because it impacts their account (or you just specify in the code of conduct that if they disagree they just have to leave) and admin can't just do as they want, they also have an obligation toward their user. It goes both way

"Plus the list might be pretty long"
It's not an issue if it's put on its own page.
Plus users deserve more transparency to be able to leave the instance if they disagree with the moderation of the instance.

For example my instance doesn't have a page like this, doesn't say if there are muted/block account. I have no way to know if they just don't do anything or just don't talk about it as they're not responding to people asking them.

[gled-rs]

I favor a list like this.

At least new users would know what the moderation team has done in the past, and choose more wisely if they still want to join or not the instance.

[gled-rs]

I favor a list like this.

At least new users would know what the moderation team has done in the past, and choose more wisely if they still want to join or not the instance.

[deutrino]

I'd like to see this but I think it would work best if limited to instance blocks only. User blocks are too granular, not enough consumers of this data would care, and it would invite arguments.

[deutrino]

I'd like to see this but I think it would work best if limited to instance blocks only. User blocks are too granular, not enough consumers of this data would care, and it would invite arguments.

[deutrino]

I'm gonna amend my prior comment, having seen some related Discourse(tm) from admins on Mastodon: I think this should be a feature, but instance admins should be able to choose whether or not the list is published.

My perspective is as someone who tries to avoid way too many options and as someone who won't use an instance which won't share their instance-level blocklist. I've also read statements from a couple admins of "safe speech" instances who made good points about why they choose not to publish their instance-level blocklist. I believe it would be best for the fediverse as a whole to have this feature, but allow it to be toggled.

[deutrino]

I'm gonna amend my prior comment, having seen some related Discourse(tm) from admins on Mastodon: I think this should be a feature, but instance admins should be able to choose whether or not the list is published.

My perspective is as someone who tries to avoid way too many options and as someone who won't use an instance which won't share their instance-level blocklist. I've also read statements from a couple admins of "safe speech" instances who made good points about why they choose not to publish their instance-level blocklist. I believe it would be best for the fediverse as a whole to have this feature, but allow it to be toggled.

[fsnk]

I'm 100% in favour of potential users being informed up front of any issues they might have communicating with users other servers.

I think @deutrino's suggestion of being able to toggle this is a good compromise. I wouldn't personally use a server that doesn't make this information available to its users because I wouldn't trust the administration. But likewise, it seems some people wouldn't trust any administration that makes information about federation blocks available to users. It should be possible to accommodate both.

In the case an instance opts in, it should display the block list as it appears in the admin interface, with the server name, block level, and media setting. (I think block lists that include reasons for the block are often used to generate drama, and the why isn't relevant to a potential user, only whether they're really going to be able to talk to their friends, no matter what server they're on.)

If an instance opts out, there should still be some kind of "Federation Status" area; it should be boilerplate stating the instance chooses not to make its block list public. (There's no reason to hide that from a potential user, and this information should be standardized on the display, like user count and number of instances federated with, to help new users make an informed choice.)

[fsnk]

I'm 100% in favour of potential users being informed up front of any issues they might have communicating with users other servers.

I think @deutrino's suggestion of being able to toggle this is a good compromise. I wouldn't personally use a server that doesn't make this information available to its users because I wouldn't trust the administration. But likewise, it seems some people wouldn't trust any administration that makes information about federation blocks available to users. It should be possible to accommodate both.

In the case an instance opts in, it should display the block list as it appears in the admin interface, with the server name, block level, and media setting. (I think block lists that include reasons for the block are often used to generate drama, and the why isn't relevant to a potential user, only whether they're really going to be able to talk to their friends, no matter what server they're on.)

If an instance opts out, there should still be some kind of "Federation Status" area; it should be boilerplate stating the instance chooses not to make its block list public. (There's no reason to hide that from a potential user, and this information should be standardized on the display, like user count and number of instances federated with, to help new users make an informed choice.)

[deutrino]

It'd be extra great to make this available in machine-readable form for instance choosers like instances.social to consume ☺️

[deutrino]

It'd be extra great to make this available in machine-readable form for instance choosers like instances.social to consume ☺️