How do you propose we implement this reliably with rate limits on joins and new connections?
There’s a severe lack of proper error messages provided by the server for every rate limiting event.
Connecting too quickly? → Disconnected
Joining too quickly? → Disconnected
Chatting too frequently? → Disconnected
Temporary connection interruption (not long enough to cause a ping timeout) → Disconnected
How do you possibly distinguish all of these errors from the client side?
For example, I can only assume from my perspective that the last disconnection listed above was the cause of the server-side 20 message buffer filling up during the connection interruption. There’s no way to know for sure on the client side why any errors occurred.
Even if rate limits are published knowledge, there’s no guarantee that following them will warrant an uninterrupted access to IRC. This can be easily witnessed from past experience, as when TMI was so severely overloaded in the past the servers started to see bursts of activity from the clients rather than steady flow of data. Without a steady flow of data, it became all too easy to break these limits.
Preferably, it would be nice if disconnections only occurred when necessary. Perhaps the system could be modified to warn first, and then disconnect for habitual offenders.
For example:
Client breaks rate limit → Error message sent to client
Client breaks same limit within a certain timeframe → Error message sent to client → Disconnects client
In an ideal setup for me:
Client breaks rate limit → Error message sent to client → Client handles error and increases client side rate limit