ircv3
Add SAFERATE spec
This is an "implementation" of the rate limiting ircv3-idea, for the first possible solution described in it: "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.".
Implementations
- Bouncer: soju (as client and server) (implemented as
soju.im/SAFERATE) - Server: InspIRCd (implemented as
SAFERATE) - Server: ergo (implemented as
SAFERATE)
cc @slingamn @emersion
I'm not sure this is usable in practice. Even with fakelag users will eventually hit some kind of hard limit on most implementations.
Just as an example: current versions of Ergo in the default/recommended configuration could publish this token. Writes will start to block on the client side (the limiting factor in practice is the TCP buffer size) but there is no "hard limit".
re. usefulness to implementations, I believe it is demonstrably useful to soju and senpai?
I'm not sure another specification that is only usable by Ergo is a good idea. Maybe this should be a vendor extension?
This specification is implemented by Soju-as-a-server as well, but I didn't comment on the implementation details there since I'm not familiar with them.
Someone in #ircv3 was arguing that in principle, the protocol requires every client to maintain two queues, a low-priority queue for ordinary messages and a high-priority queue for sending PONG in a timely fashion. I don't think most implementations worry about this, but it might be worth a note in the "implementation considerations" section that a server publishing this token should relax its expectations around PONG, i.e. tolerate PONG being delayed because it's stuck in the TCP buffer behind fakelag.
the protocol requires every client to maintain two queues
ZNC currently has a single queue, but PONG gets pushed to the front of the queue instead of back
