There's a lot of neat stuff in IRCv3 to bring IRC up to date, but most importantly it is standardising a lot of the existing protocol and patching up some of the existing warts that make pushing IRC difficult - all while being backwards compatible.
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.
I use KiwiIRC each and everyday. It's one of the nicest looking and easiest to setup web frontend for my hybrid-ircd setup. Sadly it's just a small group of friends and an OLD eggdrop bot that runs a crusty old megahal.mod as entertainment. I haven't found anything that runs as well and can create humerous replies since then. Hopefully the old code will continue to compile for awhile.
Anyway, I strayed off topic. I too am excited for IRCv3 and the future of IRC. I love the protocol, and despite it's drawbacks it serves my purpose well.
And thank you for all your work on KiwiIRC. I love the project :)
Bit off-topic, but Eggdrop was the very first thing I ever compiled from source WAY back in the later 1990's. I figured out how to hack together a (absolutely terrible) TCL script to monitor #fatefiles on EFNet for messages by certain nicks (a few XDCC bots) and echo them to another private channel. It was trash but it worked. One of my earliest experiences that I can remember with any sort of real code. Ahhhh, the good 'ol days.... great times. :-)
Me too! Eggdrop with TCL/TK on Undernet, with fbsql as mysql client. Rudimentary chatting with the bot and getting it to answer preset commands, looking up records in the database. It was frustrating, but when it worked it felt glorious.
I have been running https://github.com/pteichman/cobe for a number of years and once in a lucky while it approaches the sentience of a drunk howler monkey.
I've been running this in a Telegram bot while simultaneously building a corpus library from the Simple English Wikipedia and the results have pretty pretty amusing thus far.
Thank you so much for developing such a great IRC client. Question:
>IRC is getting interesting again and IRCv3 is up there making a lot of this possible.
Could you elaborate? What are the most promising things about IRC today? I personally am a huge fan and have been a user for over a decade now. But I do see a lot of underutilized potential.
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.
Well, yeah. When I was a teenager my group of friends used to use a QNet IRC chat for communications. Most on mIRC and such clients. Today it's pretty much all nerds. I do enjoy IRC, and pretty much live inside my tmux session, but I don't think I can recommend it to anyone who isn't already probably using it.
Probably says more about your social circle than IRC. There's a lot of channels and if hookers and blow are more your speed than say, gentoo, you can certainly find a channel primarily discussing them.
First off, I don't believe there's anything even remotely wrong with being a nerd. Quite the opposite. I do hang around in channels focussing on a diverse range of topics, from various freenode foss-channels to torrent trackers to radical politics and also, yes, shadier communities.
I just believe that even the most benign, non-techy use of IRC poses demands that are incompatible with the vast majority of users today. But that's a strength to me. IRC is filled to the brim with some of the smartest, most creative, exciting people I could think of.
> but I don't think I can recommend it to anyone who isn't already probably using it
I wouldn't recommend it to my friends, who were hard enough to get off WhatsApp and into Telegram at least. To my parents, who have trouble enough running Skype. To the girlfriend, who's happy with Snapchat. IRC, even at the very basic level with a GUI or Web client, demands things from users I don't consider realistic to expect from them.
I'm very happy with it the way it is though. Just saying that I won't waste time recommending Arch Linux as a desktop OS to friends who have trouble keeping a Windows install useable for six months.
Absolutely not. It's got a bit of an edge without seeming like something an angry teenager came up with - murder.im or so, "Riot" doesn't have only inherently negative associations -, it's short, easy to remember... it would've been a great name for many software projects, but especially for collaborative, communicative software I find it to be a stellar choice.
I actually wrote a reply explaining why it was a great name and vector somehow fell flat before understanding that you were being genuine. I agree. Riot has that edge but a Riot is always a group activity. And it's something anyone can join. They only need jump into the riot.
> "Riot" doesn't have only inherently negative associations
???
Could you provide some, I can't think of any.
Also Vector seemed fairly decent (with the small plus of the matrix/vector association). Riot isn't much shorter then Vector, it has violent/negative association, and changing names (unless its a major improvement) seems like a bad idea for a piece of software relying on network effects and trying to become popular.
Riots often occur when groups feel they have no other recourse. There is sometimes a positive fallout from the riot but at such an extended time that it isn't clear the riot had anything to do with it. It's a group activity that shows a group of people all feel similarly about a subject. An expression of which is usually considered positive except for the presence of destruction and violence during a riot.
irccloud keeps going down every time freenode netsplits. It got so bad lately I actually canceled my subscription and instead set up weechat+glowing bear, which is not as polished, but it works fairly well on both desktop and mobile. (And cheaper)
It's also free software and easy to set up so I encourage everybody to check it out.
Does it still work if you've got WeeChat customised or does it need to be vanilla? I'd like to keep using it from a shell while on a decent machine, but would absolutely not mind the option to connect from mobile clients.
Dev here. It's completely independent of your config. Indeed many things carry over to Glowing Bear automatically, such as scripts that modify the lines (colorize_nicks.py) or create new text buffers (like highmon or grep.py), filters, triggers, etc.
Did check it out. Absolutely amazing project and if anyone still reads through this chat, absolutely what a modern IRC experience should be like in my view. Effortlessly does a lot of the things people on here like about Slack.
I like WeeChat as a client, it's fast and lean and works inside the tmux session that pretty governs my digital life both private and professionally. Alas, it's not always accessible. Getting Putty to reliably work with tmuxed ncurses apps is a nightmare for example, imho.
Glowing Bear solves this brilliantly. It looks great, you get features like inline display of media and is easily secured with certificates from Let's Encrypt.
Thank you, devs. This'll make my "newly discovered FOSS projects of the year" list for sure.
Honestly, if I need to use a third party service like irccloud, isn't the benefit of IRC lost at that point? Why use irccloud when I can just use Matrix or Slack?
Because you could swap off irccloud at any time, to another IRC services provider or self-hosting, and not lose touch with the people you're chatting with, because the network layer is independent from your interface (irccloud).
By contrast, if you want to switch off Slack, can you still talk to people who stay on Slack, or do you have to get them to switch too?
I like IRC over Slack for the same reason I like email over Slack: I can just use my client with the interface I like, and the network takes care of getting my message to someone using a different interface, that they like. It doesn't require we compromise on a shared, fixed interface, a la Slack.
Adding tags forced them to increase message length because of how IRC messages are hilariously limited to 512 bytes in all directions. In the existing protocol you already have to guess how long your messages are allowed to be because the server tacks on a prefix to your message before relaying it, which can require it to truncate characters to fit the modified message into the length limit. Having some amount of tags tacked on as well would have made it impossible to guess how much room you had.
Now if they had started with fixing the actual protocol they wouldn't have had to deal with that. Honestly this feels more like a standard "let's add cool stuff" push than intelligent stewardship of the protocol. I guess that is kind of cool too though.
My take is that to some extent the protocol itself is enshrined in a kind of historical gravitas that makes it politically hard to modify.
People assume that IRC as a protocol is not fantastically outdated and it's architecture is inherently distributed and fault tolerant. Even if those things are not really true (at least not at the levels that other moder modern systems would be considered at), people hold onto the belief.
No, it isn't easy but that is what makes it the kind of thing that requires great spec work to accomplish. It would require proposing transitional steps and monitoring their adoption over a very long timeline.
However reading their site more carefully I suppose their stated goal technically is to only provide extensions to the protocol.
So the situation you describe already happens, user A has 512 bytes to send to the server, but the server has 512-prefix_length bytes to send to B. This is a flaw in the original protocol and the currently accepted solution is to truncate server-side(what to do is not stated explicitly, though it is implied that you probably shouldn't wrap messages). But fixing it is probably out of scope.
They will only know the prefix for the server they are connected to. On a larger network such as Freenode, client B could be connected to another server with a different prefix length.
The prefix doesn't involve the server. The prefix that's prepended to your messages when another server passes them on to a client is ":nick!user@host " and is the same for all messages that you originate.
(On Freenode and other networks with a similar service, your hostname can be changed by services, but the client is notified of this and can update its knowledge about the prefix).
That's what I mean. Like SMS it's a syntax that would allow for smart clients to re-assemble the message but is visible in plain text for backwards compatibility
The standard would specify a minimum and then you'd be able to go up from that in multiples of it up to a different maximum. If that doesn't jive with the client the client can go screw itself.
At least negotiating it would make the minimum width en route more knowable. Right now you don't really know. The system can't even perceive this aspect of itself well.
>My favourite bit is how they skipped adding length negotiation and it is causing them problems already.
We are working on it but when you have hundreds of different implementations which are all broken in their own way its not as easy as just adding a way to negotiate the length. Extending the length to add an extra 512 octets for message tags was a temporary fix.
>Now if they had started with fixing the actual protocol they wouldn't have had to deal with that.
We HAVE started with working on fixing the protocol. Almost all of the specifications in IRCv3.1 and most of the specifications in IRCv3.2 fix core protocol issues.
Slack isn't an IRC replacement. It's business trying to embrace, extend, and extinguish the IRC protocol so they can capture the business market that uses IRC and collect rent.
I think it's Slack's business to allow for realtime communication and file exchange between people that don't know how to operate a terminal, which is like 99% of everyone. If their only clients would be 'business market that uses IRC' they would have a hard time making money.
That's why I use Mattermost, which Slack Without the Suck™. It's free, fast, easy to use, visually appealing, supports PostgreSQL — what more could I ask for?
Well, a native Android client. But other than that, what more could I ask for?
The "real protocol" sucks on ice nowadays. No conversation history, no offline message storing, no push notifications, absolutely none of the niceties we've learned since 1990.
The whole reason the Slacks and Hipchats and Discords of the world exist is that IRC is a terribly limited protocol that many people have tried to hang enhanced functionality on top of and none have succeeded.
Personally, I'm in favor of letting the better product win. IRC has been objectively superseded in nearly every way that matters.
I don't know about you but I have all of those things simply by leaving my bog standard IRC client connected to the networks.
IRC is not a limited protocol. What is happening is that people are using limited computers and networks (smart phones) that aren't capable of the same thing a 1990s computer was.
Which only means the use case for the average user changed and the protocol failed to keep up. And you speak as if the few things I mentioned were the only things that IRC can't do that literally all of its competitors can, rather than a small sample of missing features.
Let's see, in addition to what's above, off the top of my head:
* Video chat / screen sharing
* Audio chat
* First class support for connectors to external services (i.e. not a fake client connected to each room)
* First class support for permissions, registration, etc (rather than a fake god-client service package)
* REST API
Compared to IRC, Slack is more beautiful, more usable, more flexible.
It's a great microcosm of the free-vs-proprietary debate that's been raging so long. Slack is winning the fight because it wins in ways that are visible to everyday users, while not being philosophically better.
You know what else IRC can't do? Be a version control system. And it can't be a webserver, or do GPU accelerated machine learning, or act as a spreadsheet.
As for "First class support" I'd argue that those kind of things make for a less flexible chat system. It's like having a strongly typed classes instead of everything as strings; like Powershell vs a unix shell.
REST API? Ah yes, in 2016 everything needs to be HTTP, I forgot.
Your snarky strawmen address none of my points and will not be responded to.
I'm very curious how you think user registration and an API make for a less flexible system. What exactly are you wanting to do with Slack that the existence of an API and a registration system prevent you from doing or get in your way of doing?
And considering that Slack is generally accessed via HTTP, it kind of makes sense for it to have a sane HTTP interface, something for which every language has decent tooling for...
I'll add I also did these things with 200MHz CPU's, 64MB of RAM, scarce space on HD, a crappy kernel, and a 24Kbps Internet connection that was down most of the time. I'm sure these GHz machines with Nix cores and sporadic 3-4G can handle it. If average developer really tried. ;)
A good part of this discussion is how IRC is completely outdated. If anything, that makes those still stuck on IRC those that need to move on to "real protocols"
WeeChat + relay clients can do it as well, you only run weechat in a tmux/screen somwhere and connect to it with a relay client (Glowing Bear or WeeChat-Android). Works nicely, with synced state and arbitrary history scrollback
I honestly just run a raspberry pi that has Weechat running all the time in a tmux session. So I just SSH whenever I need from wherever, pretty much (with obvious security settings configured).
I am very glad this is happening. IRC was one of the first applications I started using on the internet. These days it nearly disappeared because of closed silos like Facebook, Twitter and Slack. This effort could help bring back a decentralized service that is not under the control of any single company.
That's the sad thing about decentralized services, they follow a standard that doesn't get updated. Facebook and slack can add new features every month, but adding a new feature to email or IRC is so difficult.
Okay... I agree adding features to email and IRC are probably not the easiest things in the world. There are a number of useful features that have been added to email over time though, and I don't think decentralized control of the protocol is the bottleneck. Wave might or might not be a good example.
I'm a huge fan of the IRC protocol, and I think I've set up IRC channels at nearly every company I've worked for.
Freenode and Weechat seem to support the changes, but I honestly worry that the protocol ends up more complicated than it needs to be, or possibly more complicated than people can use. Diaspora already provides a lot of what IRCv3 looks like it's trying to do. I guess I'm just not sure what the difference is.
I'm not sure if this is the best approach. Matrix might be a better way to go, at least for some things. If you really want persistent history and persistent identity, I'm not sure why you bother with IRC at this point: both will always be second class there. Try XMPP, Matrix, Psyc, or whatever. Just so long as you can convince your friends to use it...
On IRC, your "persistent identity" was your user@hostname (and your nick is ephemeral). That's why the user@hostname is shown when a client joins a channel, or in WHO or WHOIS - and why bans match on nick!user@host.
This worked great when people were typically using IRC from their login on a server at their university (and this is also originally why IRC servers used the 'ident' protocol when you connect - to stop you spoofing other users on the same shared system).
It stopped being a viable persistent identity for all users when the @hostname part stopped being persistent - when people started gettting dynamically assigned addresses on internet connections at home.
In many ways, the idea of IRC chat has grown significantly beyond the conventional client. From the ubiquity of chat for productivity in applications like HipChat to the hugely successful Twitch.tv platform, IRC has proven to be a viable backbone in these scenarios. It's quite nice then to see a concerted standardization effort. Hopefully, many of the proprietary features we might recognize today will be widespread and freely available in the future.
I run an XMPP server for myself and a few friend and have had no end to the trouble with it getting OTR or any level of encryption working reliably before friends lose their interest.
Please, someone, just offer us an open source slack clone that runs off on a R-pi and has a walk through wizard to enable the 99% of typical install requirements.
Even as someone who works in the industry, I dont have time to learn the bells and whistles that running a chat server requires.
Which problems did you run into? I use Prosody as the server (which is brain-dead simple to set up) and Conversations as the client on my friends' Android phones. We just add each others as buddies and set "OTR only" with two taps, and these problems are solved forever.
I do agree though that the user experience for my OTR-enabled messengers is shit (especially the "first message not encrypted" problem).
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.
> like edition of messages (with a flag marking it as edited)
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.
How on earth do you expert messaging editing to work. Are irc clients supposed to magically redraw the buffer and edit logs??!
You can already tell if a link is an image, because they're posted a link to an image..... Some irc clients already inline images posted....
So logs are no longer append-only? This seems like a uselessly complex thing for all servers and client logs to support. Seems like it would break many things. What situation needs an edit feature? I can think of none, since a quick follow-up correction is simple.
Also, edits would ruin many of the funny situations encountered on bash.org. :)
Logs can be append-only, while clients can still show edits. These aren't in conflict.
It wouldn't have to be complex, either, and it certainly isn't useless (says me and a few other people already!).
Quick example: I recently typed out about 10 long lines of business development chatter in Slack, the first of which contained a list of prospects. I realized I left a few out in my list, and edited the message to add them in. Without editing, I'd have to have either posted the complete list again or added them in as a second comment. Editing the original message is simply a lot less confusing.
Personally, I would treat the chat like a forum post and take more time to confirm that what I was posting was accurate. I have never used chat as for business purposes though, so thanks for the insight.
I do wonder though, should IRC evolve to be like Slack or should it evolve idependently? I feel that the new features should be more vital, rather than "neat"... like maybe more focus on privacy and/or anonymity. Undoubtedly, I am just resisting change...
I think we're at the vi/emacs point of this discussion. Editing messages works well for me and my team, and we're glad of the feature. You don't have to like it, and I wouldn't force you to edit messages. The world supports both and we both win. :)
We use Slack heavily in our organization and editing happens all the time - whether it's to fix a typo, or insert a missing word, or cross out something we wrote earlier and put in the corrected version. Once you can do it you'll learn the value of it.
Same here except for cosmetic changes. It's the only way to be certain that people have read your corrected version, and not just the pre-corrected original.
I used to work at Bloomberg, where the terminal's MSG function supports editing and outright retraction of any message that hasn't yet been read (and thus, it also supports universal unfakeable read/unread status indicators on sent mail).
I know I'll be dowvoted to oblivion but I'll say it anyway...
You advocate for privacy,
You advocate for openness,
You advocate for transparency,
You advocate for interoperability,
You advocate for host-it-yourself,
You advocate for customisability,
You advocate for scriptability
...
But then all of a sudden "oh no IRC, not enough colours, geez, running a bouncer, who wants to do it?"
-------
I'd design irc-v3 to be bouncer-friendly, and maybe to integrate some bouncer-y features into IRC servers as well (most IRC servers keep logs anyway)
IRCd developer and network staff member here. Dead wrong. I don't think I've seen a single IRCd that keeps logs, and doing so would make it much more expensive to run an IRC network. Additionally, it would be a huge violation of privacy, and we value our users' privacy. The IRCd only logs server events (e.g. network-wide bans, server connection/disconnection, use of administrative tools) and user connections/disconnections (for anti-abuse purposes).
If network staff have logs of something, it was either because their IRC client was present in the channel or because someone else gave them logs.
Most of my network's servers hang around 2-3% CPU usage and <5GB disk usage, and we'd like to keep it that way because we don't want it to cost a lot to host. We have an average of 1000-2000 users per server.
They've been working on this for years and I'm seeing very little of it. And beyond that, it's missing everything we take for granted nowadays: scrollback, keeping note of where you were and media sharing.
Yeah media sharing can be done with, what's it called, CTCP? That's just piping stuff through a short message service, like Twitter or DNS. It doesn't properly display media either, but it allows for small file transfers.
And of course scrollback can be done with bouncers. But it's not something I see my mother using. Facebook Messenger is what I see my mother using.
Is there anything new on the website, or it it just being linked again?
I ran an IRCnet server for 15 years or so and when the PSU crapped out I decided 15 years would be enough.
If I were to give one piece of advice: forget IRC. If you want to make a free, large scale chat system, just forget you ever saw IRC. There are no solutions in that neighborhood.
For you. What about the millions of nontechnical people that need an open communication platform? We use IRC at my employer, and the complexity of getting a bouncer set up means that for cross time zone teams, most people miss any conversations that don't happen in their business hours. This has huge effects on collaboration.
Suddenly it's my job to bring everyone else up to speed on what happened in their off hours? I have a job to do. Slack and Rocket.Chat (and matrix and ...) both solve that problem and a lot of others without the legacy bullshit that IRC slops down the road. I'm sick of spending time working around what is an outdated and inadequate protocol because of momentum in my office.
You realize logging IRC and distributing said logs can be completely automatic, right? Anyone can set that up. It's honestly kind of humorous that you find this to be such a mountain to climb.
I support open protocols and not proprietary products that make you pay to simply keep chat history (Slack deletes messages after +10,000 messages). To be against IRC is to be against e-mail. IRC has been around at least since the 80s.
I am more than well aware what the IETF is and what it has done. However, your response providers absolutely no answer to my question and is quite frankly patronising and rude.
I asked why this should be done under the IETF? What are the benefits, specific to the IRC protocol, of doing this under the banner of the IETF versus not? What do you believe will be gained by doing this under the IETF?
There's plenty of protocols and technologies that we use today that don't fall under the IETF banner and are plenty successful. The W3C is an organisation that comes to mind for example.
It is simpler for us to work on stuff by ourselves rather than getting the bureaucratic nightmare which is the IETF involved. IRC has never followed the RFCs strictly (even RFC 1459 describes a specific protocol which has never existed) so it is not too much of a problem.
There are plans to contribute an updated base RFC to the IETF in due course though.
"IRCv3 exists and is addressing some of these issues; this is great news and we wish them well. It’s almost a contradiction in terms to get competitive between openly interoperable communication projects - we look forward to increasing the richness of Matrix<->IRC bridges as the project progresses."
Why not merge the two projects or just focus on one? WebRTC seems to be a better protocol right now.
We, small gaming community were using IRC as matchmaking "service" where we would all add to a queue, and the bot would then create teams based on players ranking.
That worked quite nice, for ~15 years, and whole community was created, things worked quite nice, diehard users used BNC and terminals, but lately everyone is switching to Discord.
Main matchmaking is still on IRC, but other sub-groups migrated to discord long ago, and that scares me, because no one at the moment knows what will happen with Discord year or two from now.
Essentially, as I understand it, if multiple people submit the same exact URL in a short period of time, they count as votes on the first submission (this may well be completely wrong, but that is how I believe it works).
After a period of time, new submissions are their own post, to allow submissions that did not get visibility have a chance at being seen. This is also sometimes done manually by the mods if they see something particularly interesting that was missed (not sure about the last point though again, I believe it to be true).
I've had the same thing happen with a few of my submissions. On the one hand: cool, the story I liked is now being seen. But OTOH: not so cool, I like the HN metagame too.
Interesting development. Apart from the original IRC specification published in 1993 and revised in 2000 (supposedly the namesake of "IRC v3") there has been quite little real standardisation work in IRC protocol, with various clients, servers and platforms each implementing their custom extensions.
Standardisation is weird in IRC. From what I've seen, most of it that has happened has been the result of one group implementing their custom command/extension and then a bunch of other vendors implementing it in the same way (as well as all the interesting politics behind it all). There's a surprising amount that's been mostly-standardised over time, and not just from formal standards groups like the IETF or IRCv3.
Still, it's been really interesting to get into. It's nice seeing how things have gone so far and how they're going forward (and digging into the archives is always fun).
Unrealircd is imcredible, as far as irc servers go. I ran it with 300 concurrent users at a local LAN and was able to do a lot of excitimg things like load balancing between servers other cool things, already back in 2001.
Do a substantial number of IRC users actually care that the current version of IRC lacks the features that IRCv3 proposes, or are we just modernizing because we want to make writing IRC bots more complicated?
IRCv3 makes writing software easier not more complicated.
Take the "away-notify" extension for example. Without it you would have to repeatedly poll a channel with WHO to see if all users in that channel have marked themselves as away.
An irc network can have several servers. If one goes down if the others are online you can connect to any one of them and still be ok. A net split will happen but they tend to resolve fast.
I don't feel like typing much because it's nap time but IRCv3 is an almost closed group of friends, mostly znc core developers, who have decided they can choose what the future of IRC looks like.
They have put lots of pressure on and harassed other developers of clients and networks, sending them patches and infiltrating their devs if necessary, so their ideas are actually implemented.
If you complain about those ideas and specs, they'll tell you to refer to their github issue tracker, but they mostly ignore those who are not part of that core group I mentioned.
While a number of people in the group are friends, I definitely wouldn't call it a closed group of friends. These are people that have been developing different IRC projects for many years, all discussing the protocol and making sure clients + servers actually work together. Friendships will come from this over years.
A lot of the core group all work on different competing projects, servers and clients, and do frequently discuss any proposal made by anyone if it makes sense.
Historically the IRCv3 project originated at Atheme as a project to bring some extensions to IRC in order to make it more modernized, such as the SASL binding (IRC Authentication Layer). ZNC guys and Atheme guys did not get along because political reasons, so they threatened to fork the project. Atheme decided to spin off the IRCv3 project at that time as it was no longer really interesting to Atheme anyway (IAL was adopted in basically every IRCd and most mainstream clients).
While I cannot really comment on the current managerial processes of the project (as I do not know what internal discussions the technical board has anymore, if any), the technical board allows people to submit things that they know will never ever be ratified, without saying what the outcome will be when it is already known to them, in order to give the appearance that they are an open project. In fact, advising people to not work on specifications that mainstream vendors will not adopt is actively discouraged by the working group, as the image of being open and the appearance of being non-offensive is more important than discouraging people from wasting their time.
As for charybdis (a widely deployed IRC server): we keep an eye on the IRCv3 group and implement things that we find interesting. There is no commitment from us to implement future IRCv3 work just because it is an IRCv3 specification.
As for IRC itself: IRC is a wonderful thing, but honestly in 2016 we can do much better. The backwards compatibility requirement of IRCv3 (which exists because they do not feel they have enough influence yet) is a serious crutch that prevents a lot of potential work for fixing design problems with IRC. The lack of unique identifiers at the client level (other than nickname) makes a lot of things like nickname ownership painful. The overall concept of IRC is a powerful one, but the technical foundation is crap. This is why Slack, gitter.im, etc are kicking IRC's ass right now, and IRCv3 is honestly too little too late for that fight. These services offer easy integration with any type of website and the IRCv3 group is too busy talking about bringing HSTS to IRC. This is a total and complete inversion of priorities verses where they should be.
>ZNC guys and Atheme guys did not get along because political reasons, so they threatened to fork the project.
I do not wish to start an argument over things which are long dead. However, I think it is important to note that the "political reasons" were that you were constantly derailing discussions and threatening people.
I can publish all of my IRC logs if anyone wants evidence of this.
Almost everything you have said is false. Please cease this defamation.
>IRCv3 is an almost closed group of friends, mostly znc core developers
There is only one ZNC developer actively involved with IRCv3 (DarthGandalf) and even they have not been particularly active in the last few months.
>who have decided they can choose what the future of IRC looks like.
We accept any reasonable proposals providing you are willing to provide a strong rationale for it.
>They have put lots of pressure on and harassed other developers of clients and networks, sending them patches and infiltrating their devs if necessary, so their ideas are actually implemented.
No IRCv3 technical board member has ever forced a developer to accept patches. Some people have contributed patches to various IRC implementations in order to improve IRCv3 compliance but those patches have been accepted out of the free will of the maintainer.
>If you complain about those ideas and specs, they'll tell you to refer to their github issue tracker,
We prefer that discussions happen on the tracker rather than IRC as it is persistent and can be referred to in the future.
>they mostly ignore those who are not part of that core group I mentioned.
This is completely false. Please provide evidence of this happening.
A few of the people in that group (but none on the technical board) have been contributing to projects and then disappear once the IRCv3 bits are included. Thusly it appears from a broad glance that they had no interest in the project itself as much as getting another client onboarded with IRCv3 support.
This in combination with the marketing efforts of the IRCv3 group places large amounts of pressure to just accept and maintain the patch in order to ensure that you wind up on their list of recommended software to use, instead of their advocacy of using a different software which has added the patches.
I fail to see the issue. They fixed your project to stay compatible with the spec. They didn't stay, but isn't this the behavior of anyone who just fixes an issue they had in a project?
> I don't feel like typing much because it's nap time but IRCv3 is an almost closed group of friends, mostly znc core developers, who have decided they can choose what the future of IRC looks like.
This is how standards get built now. See also: systemd, R6RS.
Protocols don't go bankrupt and close up shop. They'll still be around in 10 years.
Protocols don't magically pull the rug out from under you, dictate how you use them, or suddenly change features you want and need without you having any ability to remain on the old system. They don't suddenly up the system requirements or discontinue support for old clients. I can still email from any device I ever could, palm pilot, powermac, whatever. Meanwhile your favorite app is dropping support for Android 4 or whatever 24months after release. Or app xyz no longer works on a 2 year old iOS.
Protocols are something I can rely on. Businesses fly by night. I'm not going to start using Discord now and have it be gone this time next year, I've been using IRC for decades, and I'm going to keep using it. It works perfectly, everywhere. Especially if I have mosh and a server running my irc client somewhere else.
I'm not the person you asked, but I share their opinion because JS and websockets do not appear to have any obvious relationship or applicability to IRC.
A reason to do it is because most internet users >99.9% have a web browser. <0.01% have an irc client. You could argue that Twitter or Slack has sort of filled this niche for people who want to do #topic based chat but if the goal is to do it in an open protocol, then that's imo why it would be applicable to irc.
Okay, but in which way is JS and WebSockets relevant to the IRC core protocol, if you usually have a proxy (such as KiwiIRC) which speaks IRC in the backend and HTTP/JS/websockets/whatever in the frontend.
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.
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?
Hmm, I didn't see the 3.3 spec which is still being developed, it looks like they are doing strict transport security as a base extension. So that would address most of my concerns I think. I would still prefer to see TLS required no matter what.
The 'tls' extension is not actually TLS support. It is a method of upgrading plaintext connections to TLS via the STARTTLS command. It has some design problems and is going to be replaced with something that works similar to HTTP Strict Transport Security in the upcoming IRCv3.3 release which will be a base standard.
We strongly believe that the future of IRC is TLS-only.
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 read IRC v3 and assumed they were making major changes to the wire by bumping the major version, which is why I said what I said. I've been using IRC for 24 years but haven't implemented it before, maybe I'll do that now so I can have a better idea of what I'm talking about.
I agree. Even if it's as simple as having a way to exchange public keys baked into the protocol and allowing cyphertext in messages. Even better would be if certain channels could have their own encryption key (exchanged securely between people allowed to join the channel, and changed if someone leaves/joins).
This is like the email situation where encryption options exist, but it's too hard for mere mortals to use. If it's built into the base protocol then there's a chance that clients would implement the standard and actually use it.
Indeed, but there is something to be said for sane defaults--look at the thread on HN a few weeks ago about SSH cipher defaults. Yes, TLS and the CA ecosystem has its faults, but my stance is that any chat protocol should be using auth and encryption, especially group chat protocols like IRC. I'm less upset now after seeing that the proposed spec for IRC 3.3 includes something similar to HSTS.
Hooray for centralised, proprietary tools controlled by a single corporation! /s
Seriously though, I think this is exactly what is needed for IRC: a facelift. IRC is hugely superior to centralised tools like Slack for obvious reasons. But if people are moving to Slack it's not enough to say they should not do that, but try to actually offer a competitive user experience.
I can't say it's bad to update the IRC protocol, but I don't think it would make much difference either. What people don't realize with "decentralized" services is that they don't have a good ecosystem anymore. The web stack, which favors centralization, ships with usable encryption, user interface, distribution etc. To achieve similar end results with "conventional" stacks you will spend far more effort with far less developers to choose from.
People tend to dismiss web application development for being careless, but at the same time forget that this is what made these clear text fairly rudimentary protocols popular. Until we get encryption built-in, more robust programming languages and figure out distribution on the desktop it's unlikely that the ecosystem will come back.
It's sad to me that open source projects so quickly reach for proprietary workflow tools like github and slack. There was a time when you would be laughed out of the room for suggesting that open source developers hinge a project on proprietary stuff.
Even though open source is "cool" now, I can't help but feel it's mostly people working for companies that just want to export their technical debt for free and use open source as a marketing tool.
> Even though open source is "cool" now, I can't help but feel it's mostly people working for companies
> that just want to export their technical debt for free and use open source as a marketing tool.
I think it's more that originally FOSS developers/users were hard-core's who were into the tech and the ideology of 'Free Software'. The user-base now has many people who are into 'open source' for the collaborative (group motivation) and perceived technical benefits at an infrastructure level. It's a benefit because there's more 'free' code flowing around, but the downside is that as soon as a proprietary thing is better the user-base moves to it - they have no link with ideology, they're linked to utility.
I don't get this. Slack was made for small to medium teams. There's so many Slack chats are that unbearably slow (or expensive) because it can't handle that many users.
Also, I have to get invited, check my email, sign up, and skip the tutorial every time?
I hadn't heard of this. I just spent the last hour setting up my own federated server and playing with some clients. This is pretty great! A lot like Slack in terms of UX, but without the corporate walled garden.
To answer that question for yourself just requires reflecting on the benefits of open source vs. proprietary software.
Also, in this particular case, Matrix also appears to be a well thought out platform for decentralised communication, one that is likely to be flexible enough to meet the needs of multiple different forms of communication.
Looking at homepages of various IRC clients, I feel like I am back to 5 years ago when jQuery UI is still a thing: http://ircv3.net/software/clients.html
Equally out-of-date are the screenshots of the clients on the homepages. I don't think I will ever see an IRC desktop or web client that has decent UI according to today's standard. Then again probably I am too young to be their target audience.
Edit: Okay there are some IRC clients that actually look good, such as Riot, but not on the list of IRCv3 client.
If you're a designer yourself we could do with some design help on the Kiwi IRC project!
It's one of the largest web based IRC clients and currently getting a rewrite at the moment, but we've always had a lack of design input unfortunately.
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.