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.
What direction? Building music distribution and ai agents? Or building a social network that literally relies on trusted servers (that you're even expected to pay for) to function?
I agree this is a problem. However, there is at least one protocol addition (that doesn't involve cryptocurrency per se, although it shares some ideas) that tries to address this: proof-of-work requirements.
The idea is basically this: message IDs are SHA256 hashes of message contents. If you add a nonce to the message metadata, then each time you change the nonce, you'll get a different SHA256. Relays can then choose to ignore messages without a particular number of leading zeroes in the event ID. This means a client will have to do a non-trivial amount of computation to generate an event ID that a particular relay will accept.
> None of this is uncharted territory. Uncharted for Nostr, maybe. But time and again anything that comes out of crypto shows that people building this stuff have literally zero knowledge of what has been there in the real world before them.
I mean, I think it's a direction for social media that hasn't been tried yet on a wide scale. Personally, I look at it as a cool idea- I don't know if it'll actually pan out in the long run, but I think it addresses a bunch of problems with both centralized and federated social media, so it's worth seeing what can be done.