> 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.
How about encryption?
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.
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.
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.
It's fucking slow.