From working with hashcash and anti-spam, using a proof of work puzzle as a rate modulator is far more effective if you extended the application protocol to inc

From working with hashcash and anti-spam, using a proof of work puzzle as a rate modulator is far more effective if you extended the application protocol to include that hashcash token. Using a Hashcash token to HTTP would have multiple wins: - Puts the load on the sender, i.e. server hands off the token request and then drops the connection, leaving it free to serve somebody else. - Token size is dynamic. - rate limiting a client - hug of death resistance - token inflation resistance - CURL and Wget or any other programmatic HTTP request can be made to work with the addition of a Hashcash token. At a crayon sketch level, the protocol works something like this: HTTP request WITH header stamp: available. Server returns a 3xx <stamp size required> Next request Stamp: <stamp matching required stamp size> header HTTP request then completes. Put this protocol into Firefox/Chromium, and the usefulness of this protocol would increase as people upgrade their browsers. If we do not get a `Stamp-Available` header, then the system will revert to the Anubis mechanism. One advantage of the Anubis interrupting is that can be used to advertise the presence and value of upgrading to an Anubis++ browser. I.e. You don't get the interrupting web page telling you all about Anubis and Anubis++, and you join the resistance pushing back against AI scrapers.