At the end of the day yesterday, I added another layer of spam prevention to user registrations, powered by Akismet. Over the last 15 hours, it’s blocked 18 bot signups that slipped through our own filters (which blocked 587 bots over the same time period).
To implement this, I forked a Go library for the Akismet API, and updated it with Go module support, unmerged PRs, docs improvements, and tagged releases. Soon, I’ll also add this spam prevention to WriteFreely — I think many open instances will appreciate it.
Continuing yesterday’s work on “outside contributors,” some new perspectives:
Now, there are three “person” concepts in Write.as: User, Team Member, and Author. The first two, User and Member, are private structures that primarily hold permission data and contextual settings (User: password + email for the platform; Member: role + email for the team).
An Author, however, is a public structure meant to hold publicly-known information, like a bio and post authorship. Most blogging platforms don’t make the distinction between an Author and a User like this. But this allows us to minimize data collection and eliminate unnecessary work for writers (a single-user blog doesn’t really need an author bio, because the blog is the bio).
I often think of our UX like various gentle slopes of increasing friction and weight — from simplicity to complexity, or zero to full data collection. With this new user structure, we can maintain a gentle slope from writing alone to writing with others. The experience for a single blog author doesn’t change at all — the added work only shows up at the precise moment someone decides they want to write with others, and specifically, that they want some kind of public authorship known to readers (that is, we’ll still enable you to have a multi-author blog that conceals the identity of individual writers).
#dev #teams #ux
Over the past few days, I developed a variety of spam-fighting tools for Write.as. Where we only had account silencing and IP address banning in place before, now we can actively block user registrations using certain email addresses — whether individual addresses or entire domains. I’ve also combined all possible actions for known spammers — silence, ban email, ban IP — into a single “block” action.
Next, I plan to create a process for human users to go through to verify their status as a non-spammer. This will essentially be a custom captcha test particularly suited for Write.as, which doesn’t rely on any third parties (like Google). If that works well, we should be able to adequately stop spammers through automated filtering (which is working quite well), while allowing real users to slip through and use the platform with minimal interruption.