Thanks for the response, and for giving this consideration.
I'm interested enough to look at putting something together, if you'd be interested in any contributed code. Just FYI, I've been fighting the spam fight for several decades, first on Usenet, then as 'postmaster' and network admin at a regional ISP. When I got out of that game, about 4 years ago, our small ISP was handling over 20 milion SMTP delivery attempts per day, of which we were rejecting a fraction under 99% as spam. I hate spam. I like killing spam. It makes me happy.
I 100% agree about the performance issues, and keeping processing to a minimum during posting, especially if it involves calls to remote 3rd party API's. But this isn't something I'd imagine being applied site wide. I'm only wanting it for my one forum which needs to be open for guest access, running as the last line of spam defense. StopHumanSpam will get most of it, without AnyApi getting involved. And I'd probably code in time limits on the remote API access during posting, so if all the designated API's haven't responded within that timeout, just mark the post for moderation and move on.
I'd also like it as a stopgap for when I get some new spam that manages to slip through, like the "bbcode in URL tag" thing we just fixed. I find there's usually something once or a month or so which manages to get through, one way or another, otherwise known as the Spam Du Jour. And it'd be nice to have a stopgap measure like AnyApi I could enable on all affected forums while I track and fix the SdJ, as I'm fairly sure at least one of the RBL's out there would catch most of them.
I also like your idea of a cron job, although it might be better to just have a simple 'toolkit' backend interface for manually kicking off AnyApi batch runs. It'd be nice to be able to specify (say) a node / forum and a date range, and have AnyApi run through those posts, applying the posting rules retroactively, to help clean up after an SdJ outbreak, once we're out of Zero Day and the perps are in the RBL's. Likewise, it might be good to be able to do the same thing to the user database, specifying a date range and applying the registration rules, to help fix any outbreaks of Registration Hack Du Jour.
This is obviously all just my $0.02, but it just seems like a natural progression for AnyApi. Essentially making AnyApi an API itself. Your code is already structured so it would be very easy to extract the existing registration controller, so AnyApi itself just becomes the library and overall settings for the remote API's. Then things like AnyApiRegistration, AnyApiPost, AnyApiToolkit, etc. could be split out in to separate little addons that just add the controller shim and some application specific settings.
If you took that approach a little further, it would be awesome to have your complete range of spam products built the same way, as libraries with a consistent internal API, which can be called through an Uber API. So someone can just call UberAPI::isSpam($data, $options), where $options includes a list of the spam checks they want done (human, country, anyapi, etc), and $data is a 'superset' data structure with things like ip, content, username, email, etc. that covers everything the various spam libraries need by way of data. You seem to be working towards "bundling" your products anyway, and again this just feels like part of a natural progression for your work.
Anway, I've ranted on for long enough. As I said, I'd be happy to work on building an AnyApiPost as a separate little addon, with absolute minimal changes to your existing code, so all it really is, is a shim with a small controller and a few settings which calls the AnyApi model methods. If you like it, all well and good. If not, it's something I would still use on my sites. And if all you folded in to your code was any minimal changes needed to allow other addons to drive AnyApi, I'd be a happy man.
-- hugh
![[TAC] Any Spam API](/community/data/resource_icons/1/1467.jpg?1577369589){kind=icon}
)
I thought about quoting you in my sig
