I’d like to get everyone’s input on potential future spam prevention built into WriteFreely.
Today we deal with a sizable amount of SEO / backlink spam on Write.as, thanks to our anonymous / no sign-up publishing feature. But I know spammers have quickly made it into various open WriteFreely instances as well – some are filled with it. So I’d like to figure out how we might help, especially to make it easier on open-instance admins.
Here are a few ideas to get the conversation started.
Required email confirmation
WriteFreely currently doesn’t require an email address to sign up. This is by design, to make signup painless and give people privacy, should they choose it. Unfortunately, it also makes it easy for spammers to quickly create accounts.
Possible solution: We could add a configuration option for admins that would require users to sign up with an email address and confirm that email address before accessing the instance.
Possible downsides: This only adds friction; additional controls will be needed for spammers that get in.
User approval queue
Along with our existing registration options (open, closed, invites), we might add a new option: approval required. Like Mastodon and other platforms, this would notify the admin when a user asks to sign up, so they could approve or deny the request.
New user states
Today, admins can simply “silence” a user, which prevents them from publishing new posts. There are more controls we could add to help admins more surgically moderate their communities. We might also pair this with simple automation to reduce admin workload (think Discourse’s “user trust levels”). For example:
- Optionally require approval before publishing to the public Reader. Here we might only notify the admin when a user:
- Switches to Public blog visibility, and
- Publishes their first Public blog post
- Add moderation option to disable Public visibility setting, either for an entire user or for individual blogs
- Mark users as either “trusted”, “untrusted”, or “unknown” (default), and tie different abilities to those states
- Optionally, add different ways to get to a “trusted” state, e.g. manual admin action, verifying email address, being a long-time user, making several posts without any reported problems, submitting payment, etc.
Automated post blocking
We might add light, automated filtering for spam users that make it onto an instance. To reduce circumvention, I could imagine a simple hosted service that would accept a chunk of plain text and return whether or not it looks like spam. If it’s classified as spam, WriteFreely could perform certain actions automatically:
- Completely block publishing that post
- Publish with a limited audience (author-only)
- Hold the post and notify the admin, so they can make the determination
- Publish normally and notify the admin, so they can easily take further action if needed
This is something we could easily launch on Write.as, since we’ve gotten pretty good at blocking spam. But of course, I’m wary of a few aspects of this solution:
- Diminished privacy from sending all content to a spam filtering service.
- Centralized decision making – with a centralized service comes a single group classifying content.
So if we did go this route, we’d standardize the API and add instructional resources so anyone could launch their own service, and make sure admins could choose the service that fits them best.
What does everyone think of these ideas? What ideas do you have?