[klez]

The protocol itself doesn't bar you from implementing image sharing.

Imagine this:

You have a bot in your channel that accepts an "upload-image" command followed by a base64-encoded string representing an image (or a series of these commands if line-lenght is limited, I'm not sure about this part of the IRC protocol). The bot checks that the image is actually an image (to avoid weird injection tricks), saves it on the server and returns a link you can share or sends the link directly to the user/channel of your choosing.

This can be automated with a irc client, of course. Users using old clients will receive an actual link, users of this supposed new client see a clickable preview of the actual image inline.

[dmitriid]

> This can be automated with a irc client, of course.

And of course it was automated. There are any number of such clients. Slack. Facebook Messenger. WeChat. Viber. Dozens of them. Of course they don't use IRC. But they automate file delivery. And media inlining. And dozens, if not hundreds of other things.

Meanwhile the "nothing stops you from implementing" crowd implements nothing and keeps wondering why basically no one uses these wonderful open protocols.

[Leszek]

Sounds like you're describing a new protocol.

[terminalcommand]

IRC protocol is actually really simple, you just have commands and parameters. AFAIK it is not unusual for IRC servers to implement extra functionalities through bots.

For example to provide authentication many servers provide a bot called NickServ. There could also be a mechanism called ProfileServ that implements these functionalities.

The beauty of IRC is that you can open telnet, connect to an IRC server and actually be able to chat by typing raw commands.

The problem with IRC is that there is no standard specification, and there are many many edge cases. Therefore in my experience most IRC clients implement a small subset of the IRC protocol.

I've been trying to write an irc client in Go for quite some time (https://github.com/terminalcommand/irc-v2). It's been a fun experience, but there is still a lot to cover.

[rasengan]

> standard specification

RFC 1459

[tonyg]

Unfortunately RFC 1459 is just the shallow end. It both includes features that no-one uses anymore, and excludes widely-deployed features that everyone relies on. Lots of the de-facto IRC protocol isn't written down anywhere outside various client and server codebases.

The situation is not unlike that of terminal control sequences. The core VT10x functionality is more-or-less mostly in place, ish, in every terminal emulator, but some of the VT10x functionality is no longer implemented, and lots of subsequent useful functionality isn't well documented, so implementors are left to crib from other implementations.

[u801e]

I believe that https://modern.ircdocs.horse/ documents how the IRC protocol is currently used (and I'm not sure why they chose that particular tld).

[terminalcommand]

Ircdocs.horse is an excellent resource but it is unfortunately not complete.

Irc also has a lot of -to me at least- obscure specifications for example involving channel modes. The functionality differs from server to server.

I have the impression that most irc servers are operated by programs with old codebases coded in C. New client implementations are continuing to get written, but I do not see a lot of server implementations around, probably because it is complicated to write.

[klez]

Would you consider adding a new HTML element to be describing a new protocol instead of http? w3m still speaks http but is unable to render the IMG tag (and instead substitutes that with a descriptive text, if available), while, e.g. Firefox shows an actual picture.

I mean, this proposal is to build it on top of IRC, it doesn't need to change how the IRC protocol works. We're speaking a level above that.

[rasengan]

I think the beauty of IRC and the previous way of thinking when we built the internet was just this - we could hack any change or additional layer into the software that we used.

IRC was, with the exception of simple clients, codable, scriptable, extensible.*

Software today is “what you get is all you get.” It’s pretty sad.

* It was a human body script that caused you to look at this “*”. Scripting is powerful.