Because IRC works. It's open, battle tested and has huge support by an endless amount of tools and documentation. There is not much reason to not use if all you wanna do is chat.
> I like being able to paste code into chat and have it syntax highlighted
> I like being able to ping people so that they get a notification on their phone
> Occasionally, I like to send a GIF.
That's the job of your client, not the communication-protocol.
That's not what I want. I want modern features like text formatting, links, images, file sharing (don't mention DCC), threads, linking to messages, persistent history, and even emoji reactions.
And when I say "modern" I mean "modern relative 1995 which is where IRC proponents are still stuck".
It allows you to disable threads in your UI but that's useless since then you can't reply to people by posting after them since for them it goes to main chat instead of the thread (instead of, y'know, just being the next message).
Also IRC definitely supports links, haha.
Why though?
> Also IRC definitely supports links, haha.
Oh how do you set the text of a link? Do IRC clients support markdown syntax these days?
How about encryption?
for everything else there are plugins in your client for OMEMO (what signal is based on) and OTR (which is purely session based).
Handling this as a third-party implementation for E2EE is probably the only true way to gain trust anyway. If your provider provides the infrastructure and the client then how can you really trust it?
I believe it is hard to get right, and only worthwhile on 1:1 communication, it doesn't work well at all on large chat rooms, which is what IRC is.
Regardless, if you don't want E2EE to be handled by a plugin- it is possible to make a client with it baked in.
There is no company that will stop you creating a third-party client unlike slack/discord which are extremely hostile to those endeavors by comparison.
EDIT: If you downvote without replying I'm just going to assume you're ideologically opposed to open standards, because I'm not sure what else I can take from it.
You can't downvote direct replies.
---
Speaking about standards; have you looked at IRCv3? Is there anything specific that you feel is not being addressed?
Encryption (to my mind) is better handled outside of the spec itself, just like HTTP vs TLS wrapped HTTP (HTTPS) where the "TLS" has no bearing at all on how HTTP is implemented.
IRCv3 is attempting to address the persistence issues, though many people like the lack of persistence in general.
I don't want to guess at what your concerns are, but more generally; have you looked at the spec?
My network forces TLS: https://darkscience.net
Forcing people to "do what you want" is against the spirit of open standards.
It's fucking slow.
Then you use private messages as a way to talk to someone without disturbing, or away from the noise, of the channel - still not for really private conversations ; for this you don't need encryption, you need end-to-end encryption, but at this point you'd rather use a messaging platform rather than a chat platform.
I even learned today that irssi has an OTR module by default! On Debian systems you have to install irssi-plugin-otr but once you have that and irssi you can just `/load otr` and `/otr init` in a query and that's it, you have E2EE.
This is handled client side though, so I suppose if your clients cannot agree on a protocol you'll be left with nothing. I'm not sure that's really the responsibility of the server though, since we're talking E2E after all.