[stevenicr]

I've been thinking a lot about moderating with online communications, decentralized and federated makes the solutions even more complex. It's not easy to filter when the people you want to filter have some tech knowledge. I've been dealing with that for years. One bad person in a country near this one has access to thousands of VPNs, and is simply unstoppable.

I've been kicking around the idea of having multiple filter options for each server and each user.

I am very interested in how others would tackle this. Particularly interested in blocking / filter options with matrix and similar systems.

I am imagining a block servers list, block cidr list, and a set of human moderators that can 'add on the fly' to a list they control - these lists being set to block by default. With options to whitelist individual users or ips on a server basis and per user basis.

I'd like to give each user an option to turn off these filters all at once, or whitelist different servers for example.

I also want to have a page showing for example, a blocklist of servers, and a blocklist of users, and a list of the moderators, like a list of nightclub 'bouncers' - so that people can make comments about them - if one bouncer does block lots of bad things, but also blocked a few people who had differing politics for example, it would be nice to have a way to see and discuss that and give people options to have a different bouncer blocking their message box.

There's some of my random thoughts on the issue, I'd like to see what others have come up with. When exploring rocket chat and similar, what I have seen so far is that these comm platforms are working with teams of non hostile users in mind and defending against the kind of issues initially described here is not really something any portal is prepared to handle well. Yet, hopefully. I have been asking about different mod tools and how to implement multiple layers for the various threats / issues.

I also think sometimes people in a group need to be set to not see new users to the group by default, and only after a certain amount of time can a newer user be seen by the main others in a group - things like that.

[Todamont]

Actually, being a D* podmin for 7 years gave me a lot of time to reflect on fair moderation. Good moderation means letting people say things that you disagree with, essentially, as long as it is legal content. However, as the owner of a webserver, I do have the prerogative to lay down the rules of what can be served there, and so a part of good moderation is setting up a fair and rational TOS that is publicly posted, and applying those rules fairly to all accounts, equally.

For example, a rational TOS would not have people banned for complaining about CP on the network. A rational TOS would not ban people for "too many comments" on a github issue ticket without defining what the time limits for posting are. Spam is unsolicited commercial advertisment posts, so those are a clearly-defined special category.

I think meta-moderation, where people are randomly assigned to review each other's mod actions for sensibility, and some consensus/reputation score could be utilized to arbitrate that. I also think random rotation of moderatorship to people with good recent reputation/kharma over a 6 or 12 month period could be utilised, to great effect, to prevent "tyrant" mods.

In a federated network such as Diaspora, I think you need some tools for federation of the moderatorship actions, such as the ability to share blocklists among pods, with standardized TOS terms that several pods could subscribe to. That's what I suggested in their github issues system, right before they banned me.

[stevenicr]

"ability to share blocklists among pods, with standardized TOS terms that several pods could subscribe to" - is one of the things I was thinking would be a nice thing to make available - however I think it should not be on by default for new server setups (assuming it's a server setup to run one of these pods things you mention, I am considering this from my little understanding of how rocket chat and matrix and riot and things like that can work, I think it's similar in nature)

So I think it's great to have these kind of blocklists available to pods / servers / whatever instances, but I would like to see it as opt in, and selectivley able to opt out of whichever ones for any reason by the server / instance operator, and I think it should be optional for the users to opt out of whichever blocklists as well.

I can imagine there are many server/instance operators that would not want their users to be able to override the blocklists and I think that is fine, but I would also want people to post publicly, or at least available to their registered members, which lists were being used - so some transparency in the censoring.

I also think there needs to me be more safe space options, as I mentioned above - perhaps "rooms" where only known users who had been around for X amount of months or whatever could enter -

because, I think no matter how many blocklists are made, no matter how many cidr's are blocked, the truly evil trolls will find ways to circumvent the blocks, and they will get in, and they will post things you and your users do not want to see - and blocking them will make it more of a game and more of a win when they do get in,

So things can be made a bit better I think, but unless you enter a password protected chat area with just you and one other person you know - not being open to anyone else in the world - there is going to be risk. To think that any kind of shared censor list is going to make a magical space safe is not considering the ability and desire of those who want to ruin it.

On some of my sites I have several million ip addys blocked, a few countries via geoip, and yet I have still spent more than a dozen weeks of life researching ips for proxies / VPN, blocking those subnets, writing to ISPs and companies, filing complaints, contacting police in multiple countries, putting together evidence, dealing with lawyers, censoring "bad words" - all kinds of things.

In the end, I have limited some of the bad stuff that was posted by people who did not read our rules, I have stopped some of the spam bots. But, there is a kid in Canada that still comes in and ruins the whole thing for dozens of our users pretty much any time he wants. Sometimes its several times a day, sometimes it's once a week. I have found no way to actually stop it 100%.

So I look forward to some of these newer apps getting stronger with multiple moderation abilities. I do think we need to be careful forcing any one, or multiple people's ideas of what should be blocked on other people - as I have had good moderators and bad ones, and some that blocked some people for the wrong reasons - and deplatforming the non-popular is not the reason for the mod powers imho - and even with lots of mods we can't stop it all.

you've apparently seen much of this ebb and flow over the 7 years and finally had enough - I can relate, it's not easy. One of things we decided was forced vacation breaks for the mods to keep sanity and perspective.

The more options the better imho, so long as they are optional.

[Todamont]

> So I think it's great to have these kind of blocklists available to pods / servers / whatever instances, but I would like to see it as opt in, and selectivley able to opt out of whichever ones for any reason by the server / instance operator, and I think it should be optional for the users to opt out of whichever blocklists as well.

Yes, I agree with this. The end effect of this will be self-partitioning of the network, however, I think.

There are actually some pods who do a great job of tracking down bad users, and they have a full staff, and I trust their podmins. I should be able to offload a lot of the work of gatekeeping a TOS standard, to them, if I desire.

I totally agree it should be optional too. I clearly stated that in my posts to the D* github issues. But they just banned me, said trying to take action to moderate CP off the network was censorship, and they were going to ban me for it, ironically. That's when I started suspecting the D* core devs may actually be protecting their CP network, or even possibly profitting from the CP on their network.