Yeah, I just don't understand what would relay operator actually do if someone would generate 10k key pairs and post 100k gpt-generated replies to some random posts.
There's actually a NIPS (Nostr's equivalent of RFCs) which introduces a proof-of-work scheme to prevent spamming.
Event IDs are a SHA-256 over the event's payload and metadata, so the idea is that you put some extra metadata saying "I'm doing a bunch of extra work to generate an ID with N leading zeros in the ID", and then a nonce value. You generate the ID, and check to see if it has the number of leading zeroes you wanted. If it doesn't, you increment the nonce and try again. If it does, you're all good- you sign the event and send it along.
Because the ID must be a SHA256 of the rest of the event, you have a fairly good indication of how much work the client would have had to do to generate that nonce. The more zeroes in the ID, the more effort they would have had to expend.
So, as a relay operator, you can define a policy that you won't relay events that don't meet this proof-of-work requirement, and boom, no more spamming.
Of course, there are other ways to handle the spam problem, such as requiring authentication mechanisms or external attestation of messages. But there are multiple tools in the toolbox here.
What does it rate-limit based on? If it's just IP address then I doubt that'll do much good as it won't stop any spammer worth their salt and yet could affect large groups stuck behind a NAT device.
