[kuschku]

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?

[c3RlcGhlbnI_]

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.

[caf]

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.

[lfowles]

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.

[caf]

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).

[lfowles]

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

[lstamour]

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

[kuschku]

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?

[lstamour]

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

[st3v3r]

Why is the config message bigger than the standard minimum?

[kuschku]

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

Imagine you have a 513 byte tag in a message.

[y4mi]

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

[Senji]

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.

[KirinDave]

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.