Try to ensure websocket IRC connections end up relatively standard

[DanielOaks]

Insp has a websocket implementation in testing as far as I know, Chary has one as well, and other software/daemons are interested in adding them.

Landing on some roughly-standard way of implementing websocket IRC connections (in terms of connection, line protocol, etc) would be very good, and help people develop general web clients that could use them.

[realJoshByrnes]

I'd be interested in this. Currently using the Primus node.js library to do this, but if a standard is decided upon, it would be great to enable support.

[syzop]

We added Websocket support in UnrealIRCd 4.0.10 in January 2017. Along with the release announcement back then was also an example URL https://www.unrealircd.org/files/dev/ws/websocket_unrealircd.html showing a very crude client implementation which can be used for testing.

One thing we did change recently (UnrealIRCd 4.0.13, 15 Aug 2017) is that on websocket connections you no longer need to send (CR)LF in input and the server will no longer send (CR)LF after each line in output. It is now simply 1 websocket message = 1 IRC message. This was on the request of a KiwiIRC developer (who also said he talked to InspIRCd) and it made sense.

UnrealIRCd accepts both BINARY and TEXT frames incoming. Outgoing messages are sent as BINARY. Due to the way IRC works a message may contain characters that would be considered invalid UTF8. If sent as TEXT frame, this could cause the client to abort the connection whenever someone in a channel speaks "malformed utf-8". Hence, BINARY is used which does not have this limitation.

[realJoshByrnes]

@syzop I'm guessing that a binary message ending in a CRLF combination would also work as expected in your implementation?

[syzop]

I'm guessing that a binary message ending in a CRLF combination would also work as expected in your implementation?

@ozjd Yup, exactly ("be liberal in what you accept")

[SadieCat]

Are Libera still objecting to text frames?

[jesopo]

uncertain; pending a discussion on potentially quantifying how much non-utf8 data we deal with. the only feasible outcome i can see is dropping nonutf8 at ingress, and that depends on how many users it would disrupt

[slingamn]

From my point of view, the current proposal is still a draft and I'm totally open to going back to a text-only version. In that case I would tentatively propose:

1. Keep subprotocol negotiation (it might be useful in future)
2. Clients SHOULD request text.ircv3.net, but if they don't, that's the assumed default
3. Servers MUST accept text.ircv3.net if it is present
4. binary.ircv3.net is no longer mentioned

I don't think this would create significant incompatibilities with any implementations that currently exist.

[SadieCat]

Can we please not relitigate this stupid pointless debate please @slingamn. The only thing the compromise is blocked on currently is Libera determining how much traffic is non UTF-8.

[slingamn]

I'm clearly misunderstanding something because I don't see why that would block the proposed compromise, which AIUI was merged as a draft with approval from Libera's representatives?