@xyhhx@nso.group
What I read about it online usually falls in between "I don't like that I have to wait and my phone runs hot, I hate the ones who use this thing and the person who created it and its mascot…" and "It's just a magic box that works, shut up!" — in both cases it's not about how works.
I've read about it on its developer's website, but I've never looked into its code. If you think that I didn't do a good enough job and you did better, then it shouldn't be hard for you to explain why exactly it works. Let's take a hypothetical case: your website gets scraped from a dozen different addresses — what would the difference be with Anubis and without it?
The way i see it: without Anubis your server has to process requests from 12 different addresses coming in parallel and with enough requests coming from each address it would choke — rate-limiting solves this, but of course it might become a problem for someone who has no intention of abusing your server, but still makes many requests in short period of time.
With Anubis there is an initial burst when the scraping starts if requests start coming from all the addresses at the same time. Then there is a delay — the clients have to compute hashes, and then there comes a second burst and your sever still has to deal with all the requests.
The only difference — clients have some computation to do. It might take them slightly more or less time and the second burst would be more evenly distributed, that is true — but if client workload for you is just an undesirable side-effect, you can do the same introducing a random delay and throw away the reticulating splines^W^Wcomputing hashes part.
That's it — it's a delay, not a slowdown. Rate-limiting is real slow down as requests get queued and processed at a steady rate, you can improve it further experimenting with bursting in nginx.
Anything I'm missing? "You don't understand, it's a magic box that works!" is not a good enough explanation 😜

@mirabilos@toot.mirbsd.org @feliks@chaos.social @clive@saturation.social