Diaspora: Allow to close remote accounts on own pod

[SuperTux88]

In addition to #7463, a podmin should be able to also close remote spam-accounts on their own pod (also including all comments of that person and also sending retractions for comments on local posts, where the pod is allowed to send retractions).

Additionally a pod should block/reject new posts/comments from a locally closed remote person. So optimally they would still be processed and send back retractions for comments on local posts (like ignore/block does), but nothing is persisted.

[Tectract]

We should not "ban remote accounts", as obviously that is not possible nor desireable.

Here's my suggested solution, it consists of:

1. The ability to block users by username and IP

2. The ability to share blocklists, via a voluntary subscription system between pods, when you can add a pod's blocklist to your own, via admin tools.

3. Blocklists should include the reason for the ban, and there should be some tool for reviewing these, or possible a STANDARDIZED TOS that many pods subscribe to, that could be referred to here. Maybe there is already such a standardized / proposed TOS?

   (note) if we had a standardized TOS that podmins could subscribe to, this TOS itself could be tied into a shared blocklist system.

4. Users on a pod's blocklist should not be allowed to post anything to pod from which they are "blocked", and their posts also should not be allowed to be RESHARED to the pod from which they are blocked

5. Consider a consensus or reputation system among pods. Pods with many many users on the blocklists of many many pods should have a lower reputation in this system

6. Right now it seems possible to de-federate from a single pod, simply be removing the DB entries, or even through the admin tools, currently. It may be desireable to share not only blocklists of users/IP addresses, but also PODS that have super-low "reputation" score or simply by a podmin's custom list.

I want to point out in this thread, that, FAIR MODERATION is not censorship. Every pod should have a reasonable and FAIR terms of service and good moderation is all about enforcing those TOS fairly and equally to all users. Things like "insults" should not be banned, this thread is mainly in reference to keeping things like Islamic terror and radical hategroups off of D*, according to voluntary terms of service and fair moderation rules.

[Tectract]

I think for most users the ability to ignore is plenty, however ignores should include reshares from the ignored user. I think that's a separate ticket, maybe it already exists?

[SuperTux88]

No, that's not the topic here. Every pod is different and independent. You won't see a central censorship system on diaspora, and that was already discussed on discourse and I won't discuss this here again (and I need to ban you here too if you try to discuss it again).

This issue is about YOU as a podmin can do on YOUR pod what YOU want. It's to make moderation features better for podmins so they can block remote users easier to keep their pods clean.

[Tectract]

Fair moderation is not censorship. Having a terms of service is not censorship, every social media site has a terms of service. You of all people should know that as a podmin.

I'm suggesting a centralized moderation system to prevent D* from being used as a platform for hatespeech, because I SEE THAT HAPPENING RIGHT NOW, and I see no action being taken to stop it.

I won't discuss this here again

Why not? Isn't this the thread for discussing moderation (and the lack of effective moderation tools) on D*?

[Tectract]

In fact what I'm suggesting is not even centralized, it's an opt-in blocklist system linked to a common TOS, that each podmin could interface with. I think that's better than what currently exists, which is nothing.

[creckord]

In the meantime, is there a suggested workaround?

I see a handful of remote accounts federated to my pod with full-on or at least borderline illegal content in my jurisdiction that I need to get rid of. From what I could gather about those accounts' history, they're tolerated on their home pods, so I have to deal with them on my end.

A few Google hits mention invalidating their public keys in the database, and there is also this (repo), but I'm not sure if either is a safe way to go about this.