Potential new hooks

[phyro]

Not really an issue, just a writeup on which data might come in handy for various custom implementations:

1. ws connection that sent the event - This could be a parameter to AcceptEvent. Why have this information? Some people believing banning IPs or rate-limiting them is better than adding PoW cost or LN invoices. If you want to rate-limit users, you probably want to do it through the connection identifier.
2. ws connections receiving an event - Event going into the system (wsIn) has storage+bandwidth cost, even going out (wsOut) has only bandwidth. But if someone wants to put a rate limit on bandwidth, they'd not only need to rate limit the input, but also the output. For the latter, you need to have the ability to view who's receiving how much data.

Both of these could also be used to send metrics to observe the system in live conditions i.e. how many different connections do we have, average number of events per connection, how many events we send to subscriptions on average, what are the outliers etc.

[barkyq]

Could make a RateLimiter interface which relays could implement. Perhaps with a signature:

type RateLimiter interface {
     AcceptMessage(ws *WebSocket, message []byte) error
     BeforeSendEvent(ws *WebSocket, event nostr.Event) error
}

There are fairly natural places to place these hooks in handlers.go. Alternatively to AcceptMessage, the option of changing the AcceptEvent signature, as you suggest.

[barkyq]

Although on second thought, AcceptMessage would not really help with bandwidth, since it would only fire after the message was received. Although in combination with maxMessageSize, perhaps some rate limiting is possible.

[qustavo]

IP is easy to spoof, I can see someone flooding data from different IPs. Also banning one IP could potentially prevent honest users to send traffic. I think it's better to use the existing AcceptEvent method to implement a rate limiter per pubkey. Network traffic can be controlled (regardless of the protocol) via iptables or some user-space based traffic shaper tool

[pbennett]

What prevents users from just spamming with newly generated pubkeys? That's far easier than sophisticated IP switching methods using different NATs or IP pools. Since we're not talking about UDP, traffic still has to be route back to complete a connection in the first place. They still have to be real routable IPs. pubkeys are effectively infinite in comparison.
Obviously significant DDOS attacks need third-party help (ie: cloudflare and the like), but for the common case, an additional event at early in the handleWebsocket code might be nice (to kick connections entirely) and pre-message.

I'm super early looking at the relayer code but on the surface this doesn't seem a bad idea and I could see possibly making use of it myself.