Connecting over WebSockets?

[xyzshantaram]

I'm just wondering if it'd be worth our while to support connecting over WebSockets. AIUI the protocol is the same, the only difference being the transport. This would mean we could even eventually branch out to our code also running in the browser (which should be helped along by Deno emulating a browser environment as far as APIs etc go.

[xyzshantaram]

Extrapolating from the same thought, are there any plans to support other/more IRCv3 stuff?

[jeromeludmann]

Using IRC through WebSockets would clearly be worth it.

We could probably add it and specify it as an option?

new Client({
  transport: "ws" // "tcp" by default
})

From what I understand, we should only abstract socket functions (like connect, read, send and close), right?

[aronson]

I read over the IRCv3 specification. A couple things to note:

• The WebSocket spec is a work in progress and may change. Targeting it now may not make sense, but I agree that the enhancement is quite valuable.
• I'm not sure implementing only part of the IRCv3 spec will work, but it seems like the components are pluggable given the link below. We may find that enabling WebSockets requires additional features to be useful.

I found a list of server software one can test against. Looks like three implementations support the WebSocket spec. I'm going to get one running and take a stab at WebSocket support now. I think a number of these IRCv3 features are low-hanging fruit, but others are quite involved.

[xyzshantaram]

From what I understand, we should only abstract socket functions (like connect, read, send and close), right?

This seems to be my understanding as well. Seems like it wouldn't be that difficult under the current architecture.

The WebSocket spec is a work in progress and may change. Targeting it now may not make sense, but I agree that the enhancement is quite valuable.

This is an excellent point, we might have to do a lot of backwards compatibility work in the future to preserve functionality of code that might be written at the moment. However, the WebSockets spec as it stands currently has not been updated for two years judging by the copyright notice, and the spec does acknowledge a variety of implementations based on it (admittedly while urging us to "strive for maximum compatibility").

I'm not sure implementing only part of the IRCv3 spec will work, but it seems like the components are pluggable given the link below. We may find that enabling WebSockets requires additional features to be useful.

As I understand it, most clients/IRCds are at varying levels of IRCv3 adoption. Like you say, it's quite pluggable - you request the cap and then if the server has it you can use it. We can probably knock out the low-hanging fruits and not worry too much about the bigger ones unless there's a huge demand from users or there's a particularly interesting feature.

We'd probably have to CAP LS during the registration phase and then turn on/off plugins based on the server's response. (We got lucky with SASL and WebSockets since they both don't really deal with sending messages over the connection, just are inherent qualities of the registration/connection respectively).