11–20 of 225 posts
Why isn't encryption baked in by default? It's optional from what I can tell. I don't know how you can design a new protocol and not include encryption.
It's not a new protocol.
IRC (current version) works fine for me. The trick is to front it with ZNC or similar software. Anyway, why isn't this being done through the IETF?
> IRC (current version) works fine for me. The trick is to front it with ZNC or similar software.
But ZNC actually uses a bunch of IRCv3 features.
Why isn't encryption baked in by default? It's optional from what I can tell. I don't know how you can design a new protocol and not include encryption.
> The IRCv3 Working Group is a collection of IRC client and server software authors working to enhance, maintain and standardize the IRC protocol using backwards-compatible extensions. It's not a new protocol.
So I'll reframe my question and ask: Why isn't TLS a base extension?
Why isn't encryption baked in by default? It's optional from what I can tell. I don't know how you can design a new protocol and not include encryption.
There have been lots and lots and lots of discussions about that, but considering it’s just an extension to the existing IRC protocol, it’s not that easy.
But it’s easily possible to enforce SSL over IRC already.
I second a comment made below regarding https://matrix.org/ . I've used IRC for years and still use it almost daily - but come on Mosh + tmux + ec2 just to have permanent chat history? I seriously can't advocate this crap to anyone in 2016. It's too little, too late.
That's a great idea. Maybe also backport some features of Slack, like edition of messages (with a flag marking it as edited), or a common way to have plugins/extensions, or tagging links as images.
This works on Slack but only with their client. Use one of the bridges and you have no clue what's going on and they have a centralised system for this. Syncing that somehow across all servers in an IRC network, across netsplits and everything, is far from simple. You'd also need to do this retroactively somehow if a client received a message, disconnects, the message is updated and the client then reconnects, in order to present an accurate history.
> or a common way to have plugins/extensions
IRC already has a way to allow for extensions. Or do you mean client side?
> or tagging links as images
I'm not sure the IRC protocol should care about that at all. It's more up to the client to detect image links and Glowing Bear for example already does and can display them inline.
That's a great idea. Maybe also backport some features of Slack, like edition of messages (with a flag marking it as edited), or a common way to have plugins/extensions, or tagging links as images.
Earlier quoted context omitted.
> The IRCv3 Working Group is a collection of IRC client and server software authors working to enhance, maintain and standardize the IRC protocol using backwards-compatible extensions. It's not a new protocol.
Fair enough, but I feel you're being a little pedantic since there are base extensions described which are required, and optional extensions which are not required. TLS is one of the optional extensions. So I'll reframe my question and ask: Why isn't TLS a base extension?
Developing kiwiirc.com over the past few years to cover many different IRC servers in all different languages and using many different services/auth services has been a real pain. It won't improve overnight but these IRCv3 extensions making their way into many different IRC server projects are really helping to smooth things out.
There is currently a re-write of the Kiwi IRC project to experiment and make use of the entire IRCv3 extension set, along with some other features to make web based IRC clients just as friendly and modern as people expect from messaging applications today. This will be a huge boost to the millions of people using IRC via Kiwi IRC.
IRC is getting interesting again and IRCv3 is up there making a lot of this possible.