This is a real short blog post to propose two or three ways that librelist could do its initial list “moderation”. Actually, moderation isn’t the right word, but rather “list quality control” is probably better. The state goal of these three strategies is simply to allow for people to reduce spam and griefers while at the same time not giving list Nazis air to breathe. These are also just proposals, so read it and then if you have comments join the meta@librelist.com mailing list to hash it out.
Before I get into the proposals, I just wanted to say that I finished putting a whole whack of bugs and features into the support.librelist.com bug tracker. If you have any suggestions to improve on it, ideas of how to do a list better, or pretty much anything go ahead and put it there.
Most of the current tickets are very simple and doable items that I think any decent Django or Python hacker could crank out in a short time. That means if you’re interested in helping then let me know.
I’ll be hanging out on the #librelist@irc.freenode.org IRC channel from now on fielding questions and discussing things with folks.
Before I get into the proposals, I want you to turn off that little programmer bit in your head that somehow convinces you that the world is binary where you can only have moderation XOR anarchy. Maybe back in the day when coding an email application was a pain. With Librelist I’ve got Lamson and Django so it is entirely possible to come up with a moderation feature that satisfies a richer feature set than the simple “Nazis vs. Trolls” trope you’re used to hearing.
Alright, on with the proposals.
To understand the feature requirements for moderation we need some goals. Keep in mind that no moderation will be perfect, and you can easily come up with scenarios that will work around anything we come up with. In fact, doing this with Lamson means that anyone with Lamson can probably work around it.
Therefore, we should focus on just some initial goals that will work right now, and keep in mind that these will need to be constantly tweaked and worked on as the spammers evade the measures.
With those goals in mind I’ve teased out two potential list quality strategies that might work.
The purpose of this strategy is to create a moderation system that is controlled by the members and involves little actual intervention by any one member. How it would work is at the bottom of each email that goes out will be a simple link to “hate” the email. Something like the following:
From: spammy@126-123-118-140.vzw.com To: lamson@librelist.com Subject: YOU HAVE A CHRISTMAS CARD Hey! You've won a christmas card from your friends. Go check it out! http://yougotscrewed.com/ ---- http://librelist.com/hate/116cc4e003b7df3a7af4a27404291dfb
This link would only go out on emails, it wouldn’t end up on the archives at all so that web crawlers don’t accidentally hit it.
If you hit an email that you hate, then you hit that link, it goes to a simple web page that tells you to pick either “Spam” or “Troll” and then it’s done. You would log in so that we can track your own rating stats to also prevent abuse.
After this it’s a simple matter of collecting up spam or troll stats for the list and blocking any email addresses that get “too much”. What is “too much” will depend on the stats for the list, but the effect will be that the email address is either taken out of circulation entirely, or it is throttled.
Spam will be put into a block list, and patterns will be identified and added to the spam blocking system to prevent that same type of spam for the entire site.
For trolls the simplest is to of course just block them too, but I think that’s not very useful. Instead we may be able to implement a few clever throttling techniques that leverages their hatred for the common good:
In the “help mark spam” case, you’re basically making them use a spam captcha. You just show them 3-4 messages that have been reported as spam, and one message that’s not spam. If they get it right then their email goes through because they paid the “troll tax”. If they don’t then they have to do it again.
A huge problem with the above the “cabal”, where a small group of jerks just go and collectively hit the hate link to squash an opinion. This is where tracking how they rate people and who they rated comes in.
First, we can also block people who are marking too many trolls or too many consistently. Some simple statistics would detect that their behavior is way beyond other members and consider them a troll by default.
A more useful measure though is to show the troll and anyone else who voted them as a troll. Simply reporting who the raters are might be enough to deter the cabals since it’d be easy to spot who they are. This is also important since it seems cabals like to work in secret and present an image of not collaborating.
One problem with the above is that many of the moderators of a list feel that they are the “owners” of it. For these people they will never move to a system where the members have a voice in the communication, and instead feel they need to exact total control over the communications (sounds like old school marketing).
A common thread with these style of list owners is that they are doing a service for the members since they know what’s best. Their belief is that nobody minds because they are able to prevent spam, trolls, and all sorts of unsavory characters.
Let’s put aside the legitimacy of running an “open” project and then controlling the community with an iron fist, or the intense work required to maintain a list this way once it reaches a certain side. Instead, let’s focus on a proposed way that would give a moderator their required control without sacrificing free speech.
The concept of Sousveillance is simply that the watchers need to be watched, since power corrupts. Yes, moderators believe that nobody would be interested in their moderation habits, but the truth is, if they are doing nothing wrong then there’s no reason they can’t let people see what they moderate and why. In fact, letting members see how the list is moderated would work as a valid feedback loop to inform them of proper conduct.
In the “Moderator With Sousveillance” strategy, the moderator(s) would have a web interface to see recent emails and who sent them. They would then be able to flag email as spam or troll and have those message removed from the archives. The initial emails would already be sent out, but blocking subsequent emails would happen immediately.
The “Sousveillance” part however comes from that any list member can see a list of the emails a moderator has moderated. If they find that the moderator is crushing dissenting opinion, block free speech, or otherwise behaving properly, then they can flag the moderator themselves as being a fascist.
To complete the feedback loop, the list of mailing lists would simply indicate that this list is run by a jerk so that people who join can have an informed opinion of whether they should join or not.
Interestingly enough, it would also be possible to track when a troll rates the moderator as a fascist, and then award those moderators with the “Sting Wielder” rating for being really great at killing trolls.
The purpose of course is to keep moderators honest, and in a way protect them from themselves. As I said before, if they’re doing nothing wrong, then they’ve got nothing to hide.
The third proposal is a blending of the above, where members can rate an email as spam or troll, but a moderator has final say on the matter if they need. In this model, you would still have the “hate link” on each email, but the link wouldn’t bother asking the user what they thought it was. This is to prevent a bias in the view of the moderator.
Once an email is flagged as hated, it would go in the moderator’s queue for review. The simplest review process could be nothing more than a web interface the moderator hits to rate troll/spam. It could also just be that the rating stands unless reverted by the moderator.
In addition, the features of sousveillance would still stand where people who might want to join a list could see the moderation and rating quality of the members, and members can see squashed communications if they want.
Implementation of these three proposals doesn’t involve any new technology or fancy interfaces. It’s pretty much the existing mailing list, plus either one simple web interface for moderators, members, or both. It could get fancy further down the line, but for now it most likely doesn’t need much.
In fact, proposal #1 could be implemented right now without any Django code. The hate link would be a unique identifier, so when someone hits it, we simple log it to the web server’s log file and show them a thanks page. After that a periodic log analyzer pulls up messages that have been marked and does its thing adding them to a block list.
Proposal #2 potentially requires the most interface and development since it would involve what’s basically an email UI for a moderator to use (on top of the already planned listings).
Proposal #3 is interesting because it actually may be the best strategy and might be easy to implement right now. Users could hit a link that just logs to a web server log as mentioned above, and then once enough hits come in, the moderator is emailed and asked to revert the decision if they disagree. By default the member voting stands, but the moderator could read the periodic batch report, see someone who’s getting dog-piled, and then go in and reverse the decision.
These are my proposed ideas so far. Normally I would just implement one and then let people try it out, but I thought it’d be good to get feedback on what some folks liked between these three.
If you have comments and want to talk about the proposals, just join meta@librelist.com and start talking.