[mhink]

Hmm. I hadn't considered that. In my defense, I'm actually not a crypto guy at all, and so I hadn't given much thought to the actual dynamics. And now that I think about it, I don't think I've seen many relays actually implement that particular protocol extension, and this is probably why.

On the other hand, I think it's reasonable to note that individual relays could very well change their proof-of-work requirement over time to deal with network conditions. Because clients are expected to send events to as many relays as possible, it's not unreasonable to suppose that a client's message might very well make it through _somewhere_, even if a particular relay won't accept their message at a particular moment. Clients can always try again later.

I think it's also worth treating PoW as part of a "swiss cheese model" for managing abuse. There are layers in front of it (since the protocol uses WebSockets, all your standard DDOS protections can sit in front) as well as behind it (blacklisting or throttling pubkeys you don't know very well.)

One example that comes to mind is another protocol extension which provides a mechanism for client authentication, where a server can send a challenge string, in which case the client is expected to respond with a special event type which includes that same challenge string. Requiring a much higher proof-of-work requirement for this message type (and then accepting a lower PoW for messages sent afterwards on the same connection) is at least one idea of a scheme for mitigating spam.

---

For what it's worth, I wouldn't say I'm a True Believer at this stage of the game, but I find the whole thing pretty compelling, and at the very least it's something fun to hack on and experiment with.