Many IRC servers have a rate limiting mechanism, where clients are only allowed to send a given amount of messages for a given time window. Sometimes there are different restrictions depending on the type of message, the state of the connection, etc. Usually the server behavior when the limit is reached is pretty punitive: the server disconnects the client.

For this reason many clients implement a rate limiter for their outgoing message. Because they don't know better, they have to pick a pretty conservative default limit. For instance, soju allows bursts of 10 messages, then waits 2 seconds between each message. However, this limit is unnecessarily restrictive on some less strict networks.

It is possible to add knobs to let users configure the limits on a per-network basis, however it would be much nicer if users wouldn't need to concern themselves with such issues and things just worked by default. In other words, I'm interested in a solution to gracefully handle rate limiting without risking disconnection.

Possible solutions I can think of:

• Add a new cap to indicate that a server won't disconnect a client because of rate limits. The server would still be free to slowly process message bursts, this would result in writes blocking on the client-side.
• Advertise a simple burst+delay setting from the servers. This won't cover all peculiarities but will still significantly improve the status quo.
• Add a standard response for servers to indicate that they didn't process a message and that the client needs to slow down. The server doesn't disconnect the client, it discards the incoming message and sends a non-fatal error. The client can slow down its outgoing message rate and retry. This is similar to HTTP's 429 Too Many Requests.