JSON-IRC - Considerations?

[realJoshByrnes]

So we're working on a JSON based server, and I've taken in a few considerations from the previous threads such as ircv3/ircv3-specifications#57 and ircv3/ircv3-specifications#55

It seems IRCv3 isn't ready / has discarded the idea of JSON based servers (or I've missed something), although I personally feel that other than having a 'standard', it should be outside of the scope of IRCv3 as it's a completely separate protocol.

I'm looking for constructive feedback on this (not complete, but hopefully you'll get the picture)
https://github.com/MSNLD/JSON-IRC/blob/master/README.md

As we're planning to launch a "JSON-IRC first" server, the target right now is to ensure maximum compatibility with existing IRC clients.

Some potential issues:

• Raw numerics where target isn't sent - I've found two (IRC4+ 821/822). This seems to be a bug in the original Microsoft based servers that has followed on. I believe clients will continue to play nicely.
• Any existing parameters starting with a "%" - I couldn't find any of these.
• %#Channel names not playing nicely with some existing IRC Clients (I used mIRC and The Lounge, they both work as expected)

There's still much more to work out, but I'd love to hear some feedback.

As for named parameters, these are on the cards in the future, but I feel like these should be added later. The goal right now is maximum compatibility, whilst not compromising on readability.

Example

{
   "tags":{
      "key1":null,
      "key2":"value"
   },
   "cmd":"USER",
   "args":[
      "Username",
      "*",
      "*",
      "Hello world."
   ]
}

(cmd is the only required object, just like IRC)

Also, not sure if src should be an object, or a string (you're unable to tell if localhost is a user or a server in IRC)

[hhirtz]

Hey!!

As you have said using JSON to format IRC messages is a big (and controversal) protocol change, and thus may not be implemented by "standard" IRC clients. At this point one might think IRC is not meant to have another better format, but I would beg to differ. Let me explain.

Since you're going for such a change, why do things by half? The JSON schema you're offering is still pretty close to what IRC message are, and thus JSON doesn't provide any "worthy" benefit (in a IM sense). On the other hand, you might see that a command in IRC is very close to what a method is in HTTP! This is a simple example of what I mean:

C = client, S = Server

C->S: @label=my-label TOPIC #channel 
S->C: @label=my-label :irc.example.com 392 nick #channel :Welcome to my #channel!

In HTTP, the client request would be

TOPIC #channel IRC/4.0
Label: my-label
Cookie: some-session-id

And the server response...

IRC/4.0 392 RPL_TOPIC
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/plain; charset=ISO-8859-1
Content-Length: 24
Server: oragono/3.0 (Unix) (Red-Hat/Linux)
Accept-Ranges: bytes
Connection: Close
Label: my-label

Welcome to my #channel!

This protocol change makes IRC enjoy the breadth of the Web ecosystem, and the sturdiness of HTTP implementations. It also allows values like topics, away messages, etc. to have any character in it, and not be restricted to a line of text.

What do you think?

[SadieCat]

I'm looking for constructive feedback on this (not complete, but hopefully you'll get the picture)
https://github.com/MSNLD/JSON-IRC/blob/master/README.md

Command (cmd) string | number

There's no benefit from special casing numerics like this. Numerics are normal messages and should be parsed like normal messages.

Raw numerics should be sent as an integer over JSON-IRC, and the first (target) parameter MUST NOT be sent to clients with the exception of the raw numeric 1 ("001" in IRC) as most clients use the target in 001 to determine the initial nickname on registration.

Omitting the first parameter just makes things harder for existing software to handle things n order ito save a trivial amount of bandwidth. What exactly is the reason for this?

As JSON is not a protocol delimited by spaces, it seems appropriate to allow spaces to be used in JSON-IRC. To support backwards compatibility, conversion must be attempted on many clients to determine suitability.

This is a pretty unreliable form of backwards compatibility. Banning the characters, at least in old messages, seems more reliable.

"args": [
   861,
   1981,
   "Current local users 861, max 1981"
]

Again, special casing numbers like this seems like it has no benefit...

It is RECOMMENDED that JSON-IRC SHOULD be delivered using the Websocket Protocol [RFC6455].

This seems like mixing two entirely different things? The message format is independent to the transport layer.

I don't see why this needs to be recommended either. We already have a WebSocket spec with multiple implementations which web clients can use if they want.

Example

The (non public) InspIRCd JSON implementation is almost identical to this proposal other than we always send the command as a string, use "params" for the parameters, always send parameters as strings, and tags without values are encoded as an empty string instead of null.

[realJoshByrnes]

@SadieCat

There's no benefit from special casing numerics like this. Numerics are normal messages and should be parsed like normal messages.

I do agree with you, there's no real benefit to converting the numerics to numbers, and may cause issues with string conversions.

Omitting the first parameter just makes things harder for existing software to handle things n order ito save a trivial amount of bandwidth. What exactly is the reason for this?

According to RFC1459, the first parameter is always the target in raw numerics, which I believe would always be the client in S->C communications. This information seems redundant, and seems to be ignored in most clients (with the exception of 001)

This is a pretty unreliable form of backwards compatibility. Banning the characters, at least in old messages, seems more reliable.

As we're doing JSON-first, I feel that if these characters are allowed (eg, Spaces in nicknames), it's important we are able to display "something" to existing IRC clients. I'm not stuck on the encoding, but something needs to be sent that an IRC client can understand.

This seems like mixing two entirely different things? The message format is independent to the transport layer.

You're right, it is. It should probably say something along the lines of it was developed with Websockets in mind, rather than making a suggestion.

The (non public) InspIRCd JSON implementation is almost identical to this proposal other than we always send the command as a string, use "params" for the parameters, always send parameters as strings, and tags without values are encoded as an empty string instead of null.

Interestingly, I was using params - but someone mentioned they wanted args in the previous threads. I'm neither here nor there on this one, as it makes no real difference (maybe "params" for compatibility). I've chosen null in tag values as it's falsey. if (value)... etc.

[SReject]

My initial thoughts on moving to a JSON based data exchange is that the requests are made with a desire to shoe-horn IRC into applications it wasn't designed to fill. Often times, the implementation hasn't been given due thought.

General Thoughts

Moving to JSON would break backwards compatibility with every piece of IRC related server and client software that currently exists. That's literally millions of units that would need to be updated. With such an update comes dev time overhauling established code bases, migration periods, user inquiries and complaints; essentially adoption pains. If those pains are too sever, client and server devs will forgo transitioning to the new protocol. After all, they've spent the last 2-3 decades building on the original RFCs designs and would be asked to scrap that work.

To avoid such growing pains there would need to be a mechanism in place to opt-in to the JSON-based exchange until the exchange reaches widespread use. This could take decades if it ever happens at all, in that time developers would be maintaining two parsers that serve the same purpose just formatted differently.

WebSockets/Browsers

Even if the data exchange moved to JSON, it would still be unusable by WebSockets/Browsers as the connection handshake of a WebSocket/Browser is an HTTP request. IRC developers would have to write a mock-http server for such clients at which point we have left the realm of IRC protocol and entered HTTP which is beyond the scope of the IRC RFC.

Assuming a WebSocket/Browser can successfully navigate the handshake, why throw away the current data-exchange? If the connection originates from a websocket/browser then the theoretical client is fully capable of parsing received data like every other already realized client today.

If anything, you should be making requests to the Web Standards working group to add a more robust/raw socket standard

[SadieCat]

Moving to JSON would break backwards compatibility with every piece of IRC related server and client software that currently exists.

ALPN exists for doing backwards-compatible protocol negotiation over secure channels.

Even if the data exchange moved to JSON, it would still be unusable by WebSockets/Browsers as the connection handshake of a WebSocket/Browser is an HTTP request.

We already have a WebSocket spec with multiple production-ready implementations.