Fun thing is: It's 512 bytes for everything, not just the part you typed. So this includes the command and channel, the trailing CRLF and I think when routing through different servers the server name gets stuck in there somewhere, too. Which means that a client has no idea how long the actual message is that it's going to be able to send.
Worse, because the server doesn't bounce back your own messages, most clients provide no indication that your message was cut off - it appears whole to you, but doesn't arrive in full at others' clients.
Most clients that do attempt to split long texts into multiple messages get one of these wrong:
- They miscalculate the number of bytes available for payload, because they don't check with the server's idea of their hostmask (which can change during the session e.g. due to authentication) to calculate the length of the preamble as seen on the receiving end.
- They count characters and ignore the number of bytes they actually encode to (either in the message or the preamble, or both: there are some networks like the Korean Ozinger that allow Utf-8 nicknames).
KDE's Konversation does both correctly (it also has some other nice visualizations of server/protocol-imposed limits, e.g. when you try to change the channel topic it'll color text past the server limit in red, again taking into account character and formatting code encoding).
With ircv3 the actual limit is 1024 characters, but it is has to be enabled with the capabilities negotiation extension.
Though it's 512 characters for tags, and 512 for the message.
