Hacker News Reader

Comment by c3RlcGhlbnI_ | Hacker News Reader

My favourite bit is how they skipped adding length negotiation and it is causing them problems already. See the brief discussion of size limit on http://ircv3.net/specs/core/message-tags-3.2.html

Adding tags forced them to increase message length because of how IRC messages are hilariously limited to 512 bytes in all directions. In the existing protocol you already have to guess how long your messages are allowed to be because the server tacks on a prefix to your message before relaying it, which can require it to truncate characters to fit the modified message into the length limit. Having some amount of tags tacked on as well would have made it impossible to guess how much room you had.

Now if they had started with fixing the actual protocol they wouldn't have had to deal with that. Honestly this feels more like a standard "let's add cool stuff" push than intelligent stewardship of the protocol. I guess that is kind of cool too though.

View on HN

My take is that to some extent the protocol itself is enshrined in a kind of historical gravitas that makes it politically hard to modify.

People assume that IRC as a protocol is not fantastically outdated and it's architecture is inherently distributed and fault tolerant. Even if those things are not really true (at least not at the levels that other moder modern systems would be considered at), people hold onto the belief.

Length negotiation has been discussed for years, but it’s not that easy.

Imagine user A negotiates a length fo 1024 bytes with the server, user B negotiates a length of 2048 bytes.

User B sends a message via the server to user A.

What happens?

No, it isn't easy but that is what makes it the kind of thing that requires great spec work to accomplish. It would require proposing transitional steps and monitoring their adoption over a very long timeline.

However reading their site more carefully I suppose their stated goal technically is to only provide extensions to the protocol.

So the situation you describe already happens, user A has 512 bytes to send to the server, but the server has 512-prefix_length bytes to send to B. This is a flaw in the original protocol and the currently accepted solution is to truncate server-side(what to do is not stated explicitly, though it is implied that you probably shouldn't wrap messages). But fixing it is probably out of scope.

The prefix is discoverable by client A though: it can send a self-message and thereafter knows the maximum length it can send to any given target.

They will only know the prefix for the server they are connected to. On a larger network such as Freenode, client B could be connected to another server with a different prefix length.

The prefix doesn't involve the server. The prefix that's prepended to your messages when another server passes them on to a client is ":nick!user@host " and is the same for all messages that you originate.

(On Freenode and other networks with a similar service, your hostname can be changed by services, but the client is notified of this and can update its knowledge about the prefix).

D'oh, you're right! I looked at a non message command to refresh my memory.

User A gets two messages like SMS that can be joined? Or is that too naive?

What if the message is a configuration message that can’t be split?

And how would it be split?

Or should there be a mechanism for reassembling message frames?

That's what I mean. Like SMS it's a syntax that would allow for smart clients to re-assemble the message but is visible in plain text for backwards compatibility

Why is the config message bigger than the standard minimum?

Because a message can contain message tags, and other config stuff.

Imagine you have a 513 byte tag in a message.

or 511, because C told A that this was a funny number and faster for some reason.

The standard would specify a minimum and then you'd be able to go up from that in multiples of it up to a different maximum. If that doesn't jive with the client the client can go screw itself.

At least negotiating it would make the minimum width en route more knowable. Right now you don't really know. The system can't even perceive this aspect of itself well.

>My favourite bit is how they skipped adding length negotiation and it is causing them problems already.

We are working on it but when you have hundreds of different implementations which are all broken in their own way its not as easy as just adding a way to negotiate the length. Extending the length to add an extra 512 octets for message tags was a temporary fix.

>Now if they had started with fixing the actual protocol they wouldn't have had to deal with that.

We HAVE started with working on fixing the protocol. Almost all of the specifications in IRCv3.1 and most of the specifications in IRCv3.2 fix core protocol issues.

Reply on news.ycombinator.com