Spam prevention is one topic that cannot be avoided as Nostr expands its user base.

There is a product called anubis. It seems to be intended more for crawl prevention than spam prevention. However, I wondered if it could be applied to Nostr.

NIP-13: Proof of Work

An existing straightforward approach is NIP-13, which you may already be familiar with. In NIP-13, PoW is performed when an event is published, and the proof is embedded in the event in the form of an ID with a string of zeros at the beginning. However, this must be done every time an event is generated.

NIP-42: Authentication of clients to relays

Another related NIP is NIP-42. The relay sends a “challenge” to the client at any time, and the client signs this challenge to prove that it indeed possesses the secret key.

What if we combine these?

Here, we consider adding a specification that indicates that the relay is requesting a PoW with a difficulty greater than a certain level (e.g., a “difficulty” tag). When responding to this, the client must provide NIP-13 PoW with the same difficulty (or higher) when responding.

Relays can send challenges of any difficulty level depending on the risk associated with the connection (pubkey or source IP address). Of course, they can also choose not to request any challenges.

The relay can cache the fact that the challenge was successful. In fact, if it is not cached, we will have to perform PoW many times if the network connection is unstable (this is common in mobile devices).

Furthermore, if the cache is retained for a sufficiently long period of time, users may be able to pre-process PoW on a PC with plenty of computing resources. It would be possible to control the difficulty of PoW so that it decreases for a certain period of time after a difficult PoW is passed.

I’m not sure how effective this will be as a spam prevention mechanism, but the idea is quite simple and seems interesting, so I’ll just share it. Any thoughts?