What functional improvements are fundamentally incompatible with the "old" protocols? Longer lines could have been supported with a minor protocol revision. Giving customers the freedom to use clients that don't render images, or markup, is actually a positive.
I setup Mattermost for my company. The deciding factor between Mattermost and IRC was effort to get non-technical users a nice GUI. Functionally, IRC would have won.
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.
> 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.
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.
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.
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.
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.
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.
> Additionally not being able to share images as a feature? I guess everyone will do the three step upload to imgur first.
That's a feature for me. If I wanted to be constantly barraged with images, I would have stayed using Facebook and Twitter. People on IRC posting imgur links gives me the opportunity to accept or decline (usually based on their reputation, the channel's response, or my boredom). With other social networks, images are almost always unsolicited and often only waste scroll space (good luck to those still on limited data plans and want to know the context of the latest notification).
Besides, text often can have more substance and precise meaning (even if it's not perfect all the time). After all, we're all communicating with mostly just text right here. Another example of something else that features mostly text are books, so it's certainly not deprecated.
Give me all the text please - in fact, if you give me an image with a caption, I'll read the caption first. I can happily find images through other mediums so IRC without embedded images isn't a problem at all here.
What's the problem? Just setup client to hide images unless you click the link provided - Slack have it, Discord have it. Works exactly the same way, no 3rd party involved. I'm sick when I have to go to imgur to open image and load tons of scripts and see other stuff completely unrelevant. You think imgur doesn't live for profit?
> Additionally not being able to share images as a feature? I guess everyone will do the three step upload to imgur first.
Maybe I'm missing the point here: But IRC does have a file transfer feature, so what would stop people from sharing images just the same way like plenty of "content" has been shared over IRC?
Having open ports directly to the internet (by default) with dial up modems (before routers and NAT) used to be such a common practice. Things have changed, haven't they?
I setup Mattermost for my company. The deciding factor between Mattermost and IRC was effort to get non-technical users a nice GUI. Functionally, IRC would have won.