I've been an IRC user since 1996 and still going strong. There have been many chat networks that have come and gone, but IRC, by virtue of being a protocol rather than a commercial venture, lives on.
These days, I use Textual on OS X which has a very clean interface and things like in-line images and videos combined with ZNC for logging messages while I'm away. I log in and they all come up, if I want older ones I use the backlog module with /bl #chan <num lines to go back>. Granted it's not as elegant as scrolling up in Slack but I don't tend to need it often. I'm even connected to my friend group's Slack via IRC so I never have to open Slack itself!
I find the idea of piping in various things into IRC intriguing and something I've been meaning to implement. It's trivial to get a Python/Perl/etc script to connect to an IRC server and spit out some information.
+1 for IRC, the interface is clunky and the protocol hasn't aged particularly well (especially for mobile devices who may not be able to hold a connection forever). But the social aspect of easily accessible chatrooms and the plethora of clients/tools surrounding IRC is really second to none.
You can put a pretty skin on it (slack,discord) but at the end of the day it's going to take years to bring up the level of tooling and at the end you wind up in a closed loop on someone elses platform.
FWIW; I dream of electric sheep so I'm completely biased. I run an IRC network if anyone is interested in joining.
IRC is great for a world where people have one account on one computer that's permanently switched on, but it inherently fails to handle use from multiple devices. All "solutions" to this end up involving running your own server (or, more likely, having someone else do it) and talking to that via a probably-proprietary (or at least nonstandard) protocol at which point you no longer have the benefit you're talking about. (That protocol is often layered over an open protocol, but commands-over-ssh is very hard to interoperate with if not standardized)
Good UI is not just "pretty", it's also about having commands be discoverable. Traditional IRC clients are terrible in this regard.
There's no reason the platform has to be closed - I'm friends with the people working on http://matrix.org/ (though not involved in it myself) and hope they succeed.
I'm a huge fan of IRC but it's true the IRC protocol has many issues (I talked about them before on HN; can't find the link now). IRCCloud may be (slightly) proprietary but at least it still only talks to IRC, and it's a good alternative to Slack&Friends (which are 100% proprietary) and webchat (which have the same issues as desktop clients and are generally atrociously ugly).
Free IRCCloud accounts stay online 2 hours when shut off. I pay for mine, which stays online forever. It's a fairly similar experience to slack except I can still use the same open protocol as everyone else.
Matrix is extremely promising but IMO not there yet.
I run WeeChat in a tmux and connect to it with Glowing Bear. It's a similar experience, and it's all free software. It also leverages the whole power of WeeChat in a nice interface (triggers, scripts, etc), so it can do some nice tricks that IRCcloud can't.
Oh and there's also a Matrix script for WeeChat, so you can use matrix from WeeChat (and thus Glowing Bear)!
Wow I just tried this setup (tried using WeeChat directly from the terminal a while back but somehow it didn't feel comfortable) and it's pretty darn good. Thanks!
Got some examples? I never tried WeeChat. I used to use Quassel (I liked the client a lot), but after my server died I figured it wasn't worth the trouble of maintaining it.
Examples for what? There are some screenshots of Glowing Bear on the GitHub page (https://github.com/glowing-bear/glowing-bear) and in a blog post I once wrote (https://4z2.de/2014/04/10/glowing-bear, probably outdated). I use it with a sans-serif font on the Desktop, too. The UI is quite hackable, you can add custom CSS rules to override things to your liking in the settings (simply changing the font doesn't require that, though).
Some useful scripts include colorize_nicks.py (colourises nicks in messages, to make them stand out over the text) and grep.py (easily and efficiently search logs). Matrix.lua (https://github.com/torhve/weechat-matrix-protocol-script) allows you to use the Matrix protocol with WeeChat, and by extension Glowing Bear.
Trigger-wise, I have triggers that remove colour from status messages (most of them are just noise) or replace (lenny) with ( ͡° ͜ʖ ͡°) when I send a message, mostly because I can ;)
Getting push notifications requires a bit of setup, but there are scripts for Pushbullet/Pushover/..., or irssi-notifier (which also works with WeeChat) to do that. It's a bit complicated because we don't run any servers (Glowing Bear is just a bunch of static files, everything happens in your browser or your WeeChat), so we can't provide push notifications out of the box. Disclosure: I'm one of the Glowing Bear devs, so I may be biased :)
Slack has an IRC gateway, so I think it's about as open as IRCCloud in practice. And the free version of IRCCloud has gradually got worse and worse - I think you're not allowed to connect to external servers any more, only to their one.
It certainly was more restricted than 2 non-irccloud networks at one point. More generally you can't assume the free version will continue to have the same functionality, because they've reduced it before and could easily do so again.
How many times do you get nickserv alerts from IRCCloud (indicating that "your" client has reconnected). I use IRC enough that it's worth the money (I also support their work on IRCv3), but this is getting silly.
Seldom to never? I've seen a couple messages from chanserv when IRCCloud servers have problem, but no annoyance. Keep in mind though I pay for a premium account and I only connect to freenode.
I'm also on a premium account and get disconnected and reconnected at least once a week from OFTC - I thought I also got disconnected from Freenode, but now I'm not sure.
IRC originates from a time where nobody was thinking about multiple devices, or e.g. not encoding in ASCII. Speaking of nonstandard: There seems to be no canonical specification of IRC itself. Nevertheless it's really not that bad in practice if you use a bouncer or something similar like Quassel.
> There's no reason the platform has to be closed - I'm friends with the people working on http://matrix.org/ (though not involved in it myself) and hope they succeed.
There is also XMPP (and has been for years) which does not suffer from many of IRCs shortcomings.
> There seems to be no canonical specification of IRC itself.
Is this a joke? Did you think all this stuff just accidentally worked? I'm not sure how seriously to take your entire message because of this bizarre idea.
Sure it's standardized enough to generally work but to my knowledge only RFC1459 is widely seen as authoritative. The protocol evolved quite a bit over the years but a lot of the extensions covered (and maybe not covered) by those later RFCs are handled to some extent differently between IRCd implementations.
There at least seems to be some effort [1] now to fix some of IRCs issues and bring the whole mess more in line again. As IRC is still widely used and probably there to stay I hope it will work out.
> There is also XMPP (and has been for years) which does not suffer from many of IRCs shortcomings.
In return, it suffers from its own shortcomings, mainly XML and second-system effect (leading to too much complexity & too many options).
What we really need, I think, is exactly what Slack, Mattermost &c. give: persistent, multi-device, multi-group chat. I think that solving that problem in a nice, small, secure protocol (one that doesn't imply a browser-first way of doing things — and indeed, 'secure' probably prevents using a browser in the first place) is more than enough of a problem for someone to solve.
Heck, even just the multi-device shared-identity problem is surprisingly difficult.
IIRC the original standard specifies a particular 8-bit character set (not ASCII), though the broader point stands.
> There is also XMPP (and has been for years) which does not suffer from many of IRCs shortcomings.
XMPP is useless for multiple devices: there's no way to receive messages on both (some servers will deliberately violate the spec here because the spec is stupid), and the federated history spec has been under development for about a decade now. Groupchats don't work properly with federation and have terrible UX in every client I've tried. Everyone assumes XMPP must be good because it's open-source (which is usually a pretty good heuristic) but I've come to the conclusion it's actually a really bad standard.
> XMPP is useless for multiple devices: there's no way to receive messages on both (some servers will deliberately violate the spec here because the spec is stupid)
XEP-0280: Message Carbons and there was that priority thing before. It somehow worked in the past and now it's definitely solved.
> Groupchats don't work properly with federation
The only annoying problem i can think of is when the server hosting the MUC restarts clients seemingly don't notice that they have to rejoin.
> and have terrible UX in every client I've tried.
Maybe you tried terrible clients? Unfortunately are few now which aren't terribly behind regarding protocol support.
> and the federated history spec has been under development for about a decade now.
I think thats the real problem. "Nobody" implements newer XEPs, especially if they are not finalized yet but how should they finalize if nobody puts them to trial? Everybody seems to have settled in screaming out what does not work so well but instead of helping to fix it they halfway reinvent the wheel or switch to centralized proprietary
solutions which may have nicer looking clients but often don't even try to solve harder problems like multi client support. I didn't have a look at Matrix yet, maybe it's worth it but there is always the danger of creating yet another standard [1] (which may not even be as perfect as originally thought in the end either).
> but I've come to the conclusion it's actually a really bad standard.
But is it really that bad (especially at the basic fundaments) to justify something completely new? XMPP at least provides a lot of ability to evolve without breaking everything that was.
hopefully Matrix avoids falling into the cliché of xkcd 927 by focusing on defragmenting the existing silos - building a metanetwork between IRC, Slack, XMPP, etc etc. So rather than saying "hey everyone, throw away your current stuff", we say "hey everyone, build a bridge into Matrix - it's fun and easy (100 LOC for the slack bridge: https://github.com/matrix-org/matrix-appservice-bridge/blob/....
If you want to use Matrix natively via weechat or whatever then so much the better, but the intention is to be useful as way more than just another msging protocol. It's meant to more be a big open decentralised database for conversations and other realtime data - more in common with IPFS or even the Web itself.
[disclaimer: I work on Matrix]
[p.s: can someone work out how to send Matrix $5 every time someone quotes xkcd 927 at us...?]
sigh no, the point is that it doesn't fit because Matrix does not try to be "yet another chat protocol that fits everyone's use cases". It aspires to be a bridging protocol that links other chat protocols together rather than replacing them.
I'll be honest I've not scoured your entire site but I'm just not seeing that description (and didn't at all earlier, I've since looked further).
From what I gathered you want to be the email of chat protocols. The only mention of wanting to bridge other protocols is a quick mention half way down your FAQ page.
Guess this reflects that the FAQ is stale and needs some love. The second item there is:
> What is Matrix’s Mission?
Matrix’s initial goal is to fix the problem of fragmented IP communications: letting users message and call each other without having to care what app the other user is on - making it as easy as sending an email.
The whole point is that the defragmentation is done by bridges. The analogy to email is not in terms of having One True Protocol that everyone uses like SMTP, but that it's possible for a user on app A to communicate with another user without caring what app they use.
Thanks for highlighting that we need to fix the FAQ!
I agree about the discoverability of commands, but that's inherently a client issue and not one against IRC itself.
You're right that there's not much in the way of offline messaging without running something like znc (which you can run at home on anything), but there is also Memoserv on most networks- if you absolutely have to notify someone.
I use znc to fix the multiple devices issue. Admittedly, it does involve running a server, but I've got that handled. As far as the protocol, it's just irc... I connect to znc via irc, and it connects to freenode or wherever. No extra protocols.
IRC is a very ill-suited protocol for device <-> znc though. E.g. IIRC it sends you a constant 200 lines of history (whether you've read that history already or not), because that's all it can do.
The reason I prefer IRC after all these years is that the interfaces available have not been beaten by any other product so far. Sure, IRC has an unfair advantage in being 20 years old so there's 20 years of development behind the current interfaces, but still.
Yes, I have a set of particular requirements which aren't in line with what a "regular customer" would want in their communication app, but so? IRC gives me the freedom to get my interface while someone else can get a different interface.
> +1 for IRC, the interface is clunky and the protocol hasn't aged particularly well (especially for mobile devices who may not be able to hold a connection forever).
I agree with the author on many points, but he's wrong about mobile support. WeeChat has a relay plugin (built-in) that allows mobile clients to connect to your existing WeeChat session. There are even some options to choose from: WeeChat-Android has recently gotten some love again (I hear it works nicely), and Glowing Bear works on every device that has a modern browser and has a nice responsive UI, along with some neat features like embeds and direct imgur upload.
Both connect to your WeeChat instance directly, so there's no cloud provider you have to trust, as the relay works as a socket and websocket. This allows Glowing Bear to work in the browser (Disclosure: I'm one of the devs)
Oh and the point about long URLs being unclickable has been addressed by bare mode, which is bound to meta-L by default. This is not a concern for the mobile clients obviously, as they don't run in a terminal.
Thanks! A few months after writing this article I actually discovered glowing-bear and have been using that now too! It's now the primary way I access weechat, both on my laptop and on my phone.
I'm a long-time IRC user (back to 2004---wait, it might not qualify as "long-time") as well, but I feel that the current reputation of IRC is simply built around communities that still conglomerate on IRC. IRC is a horrible protocol in the modern standard, lacking every bit of the modernism you define. I still don't like a recent trend of using something like the Slack instance for public discussion, but that trend clearly shows that the continued "success" of IRC is simply an illusion or at best depending on an external factor.
It's a fantastic protocol because of how simple it is. It doesn't try to bake-in features beyond the most fundamental of getting a message from one person to others. If you want want support for multiple clients you can have it, you just need to connect through a bouncer. I think some people see this as a cludge: if you can't use a piece of software effectively without additional software that's a sign that the original software is lacking. This is simply not true: what matters is how usable and reliable the end result is. It's not an argument to say that a setup being composed of multiple components makes it hard to set up, because there are ready-made solutions like IRCCloud around for people who aren't interested in doing it themselves. The fact that the setup is comprised of multiple pieces is only a testament to its versatility. You probably want a bouncer for your own usage so that you can use multiple devices and receive messages offline, but you don't need any of that for your bot running on your server, and because none of the multi-device functionality is baked into the protocol, your bot never has to worry about it.
IRC lacks comprehensive presence signaling, and to the extent that this makes read receipts impossible it's a good thing. It has /away which is almost good enough, but lacks good support for being set automatically by clients.
End-to-end ecnryption is becoming fashionable even on proprietary chat networks, and IRC lacks it, and that is a missing feature. The other main missing feature is federated identity, which no major network has.
But apart from that IRC's only problems are where it has the same feature twice, or whan lack of cross-network standardization prevent clients from offering higher-level interfaces. Most networks support both SASL and NickServ, which have overlapping functionality. I don't think ChanServ is standardized, so clients are stuck with showing things like flags on channels and users, rather than presenting a "channel settings" menu. If ChanServ were standardized, clients could automatically configure private channels.
For these few things that IRC (currently) lacks, it gives unparalleled customizability, compatability (I can connect to basically any other chat service like Facebook Messenger or Slack through IRC, but not the other way around), and respect for users' freedom (XMPP and others offer this too, but are smaller).
IRC is a community. The application layer has its own grammar, the way the web does. The IRC community is simply made up of different kinds of users of this community application, separated by servers and channels. The way the web is.
I don't think it lacks modernism, I think it's simply a different dynamic than 'modern' alternatives. (What is "modern", btw? What "new" protocol alternatives are there? XMPP?)
It could be argued the web is a far more archaic, featureless, non-modern protocol... it just has fatter clients and dynamic server-side and client-side applications.
That essay seems so wildly out of date, even though it's only a decade or so old.
> And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.
These days I think Python is every bit as much a corporate language as Java is, and I'm sure huge numbers of people learn it to get jobs at the conventional tech giants like Google as well as small startups.
Python somehow became the default language for data science, which is like the new php+mysql in terms of a high labor-intensive field attracting very new, short-term opportunity, unskilled coders.
>That essay seems so wildly out of date, even though it's only a decade or so old.
Funny how fast tech moves. I think the essay is still completely relevant, though. You just have to find something to replace Python with. Maybe things like Rust, D, Erlang, Haskell, etc. give the same indicators today that Python did 10 years ago.
I like to hang out in IRC channels of things I'm just starting to learn for this reason. I can't answer much of anything in #clojure, for example, and I don't have much to ask. But I like to scroll up through the channel every few hours or even days to see what people are commonly asking about, or seeing if I can work out the solution to someone's question myself and compare my thoughts to the answers in the channel. It's a nice way to passively learn something. Like hanging out with a group of people who are always doing or talking about something.
Mailing lists tend to be nicer for slow or more niche topics. I've seen maybe 10 messages total in all my time idling in ##dsp, but there are several active and friendly mailing lists on the topic. It was surprising to see names of authors of books and research papers just casually responding to questions via email.
I know of others who forward almost everything to email, including custom scrapers/converters (and then of course there's RMS). If your info feed contains more long form resources, that seems like a better end point. But for twitter feeds and notifications, IRC seems mostly sufficient.
Now I do wonder what would be the equivalent for someone heavily into image-based communiciation/updates. Unifying your reddit, snapchat, facebook, imgur etc.
Forward everything to pinterest (or a similar homebrew interface)? Maybe even rendering some text updates to images...
I use IRC over XMPP almost daily, with a transport that connects me to a channel and represents it as multi-user chat, like #maemo%irc.freenode.net@irc.netlab.cz.
The primary reason is that XMPP behaves really nice if the connection is spotty: When I am using IRC in a moving train, I almost never timeout even if the network is not reachable for minutes – and as soon as the client reconnects, I get all the messages from the chatroom.
This was very informative and this "hub" is something that I want to setup for myself. When I started writing down concepts I immediately picked slack because of all the integrations but isn't it a bit 'overkill' to use a community system for me alone to get all my feeds aggregated together?
Are there solutions out there that offer something similar but without the community aspect?
FWIW there's a really good Slack plugin for Weechat called wee-slack [0]. It uses the Slack API (as opposed to their IRC gateway) and so is surprisingly full featured.
Do you know whether, if I run this on an always-on remote WeeChat, it will it interfere with Slack's smart notifications (smart in that it doesn't send them when I'm sitting at my laptop with the Slack client open) either by causing them not to send when they should or to be sent when they shouldn't?
That's awesome, I'll take a look at that. Do you know if it logs to disk the same way weechat logs IRC channels? Right now I'm a little annoyed that I don't have local logs of the Slack channels I'm in.
Yes, it does - filters, logging, etc all work as they do for IRC. Huge +++ for wee-slack, has made Slack much more bearable. Supports many things Slack's own IRC protocol doesn't, like the ability to see edited messages.
IRC user since 1995 and still going strong. Too bad IRCNet is declining, it has been my source of entertainment since the beginning, having these Finnish chat rooms and close circle of friends. I never really got into the english tech-related irc channels, they move too fast and are hard to follow...
My main issue with IRC is channel rot. Every channels I was once a part of died. Most channels that are still "active" are in fact filled with quiet lurkers.
Otherwise IRC is still my favourite. I simply don't visit anymore...
Back in the days it was my go to social software. People were always online there and I even started programming with mIRC. Funny thing, back in the days I built chat-bots for fun and now they are big business, haha. Well, most people there were nerds and this was okay. We also had our own small bulletin board communities.
Later I wanted to meet girls and they just didn't show up often on IRC or BBoards.
So I started using LiveJournal, MSN Messenger and MySpace. Later I switched to Facebook and WhatsApp.
I never could use IRC because it's hard to sift through the noise. I have the same issue with group chats as implemented in Slack, but at least Slack can be accessed with an XMPP client, meaning I can get asynchronous delivery of messages without the need to have a client running 24/7. Do all heavy IRC users have a bouncer and a bot or do they rely on a service like irccloud? Either way, without async messaging, it's hard to use in a distributed team.
As a heavy user of IRC, I would say yes. At least, I wouldn't be able to use it without irssi running inside tmux on some server, and everyone I know does the same.
For a large Free Software project, we use Mattermost (a Slack clone with unlimited history) and it works great. There are a few features missing, but it has been a huge boost for engagement. As someone who has been using IRC for 20 years, I never thought I could get used to using a web-based client, but it's worth it.
Small annoyances, such as having to educate people not to use "@channel" because it will email a notification to 300 people, but it's just a matter of time before it's fixed.
Considering a lot of people use Gmail for email, I would be curious as to why you consider web clients to be unreliable.
(I don't use Gmail, but a ton of tech people do. Something like Mattermost is rather harmless, since less critical than email.)
For what it's worth, Mattermost also package native desktop applications for Linux, Mac, Windows and iOS/Android. The desktop ones are basically a wrapper around a standalone browser. Has better native desktop notifications integration.
I much prefer that I can choose my client, be it pidgin, emacs, mutt, irssi, thunderbird, you name it. Web interfaces are limited in functionality, give me little control how my client works, and I'm at the whim of a server operator. Mutt or Gnus or irssi haven't changed drastically, but a web interface can change without an option for you to restore the previous version. That's a huge problem with the deployment model of web apps, especially for power users.
Like I wrote above, I'm not a real IRC user because it doesn't support async messaging well, and I was curious if there was a viable xmpp-like async mode. I love email and xmpp because they works like git in that I can use it offline as well. Please don't argue that everything is 24/7 connected due to IoT or something like that as an explanation why offline mode has no use today.
Async messaging has other advantages, like drafting a response and pondering about the details over one or more days. That said, realtime chat has its place, but with distributed teams it's most practical to use distributed async messaging for the normal case and fall back to realtime protocols when you need a live conversation. I consider live communication to be the same as calling someone on the phone and disrupting their workflow or failing to reach them due to being unavailable at the moment.
Don't get me wrong, IRC and monitoring chat rooms works for many developers, but that doesn't mean it must work for me as well. We're not all the same after all. When I use live comms, it's on-demand, like a phone call.
I 100% agree. I wasn't sure if you meant reliable as in security, uptime, etc. So reliable as in "stable UI/experience".
I'm also a heavy mutt and irssi user. I think their UI stability is more an issue on how application authors deal with change/improvements, but I agree there's probably a technical factor where libncurses offers less flexibility than HTML/CSS does, so web apps are much more likely to change often.
I don't have a bouncer per se, but my client (WeeChat) is running 24/7 in a tmux. Whenever I want to use IRC, I connect to it with Glowing Bear (browser relay client for WeeChat). This way I have synchronised state (all devices connect to the same WeeChat instance, doesn't matter whether I use my phone, tablet, or laptop) and a nice client.
Thanks for sharing how you use it, seems like there's no real async mode for IRC. So I guess my preference for mailing lists or XMPP isn't just personal taste.
I'd say I'm a heavy IRC user, and I actually tend to either RDP into my Windows setup running hexchat when I'm at another pc/laptop, or just use AndroIRC on my phone with my username plus an underscore or something and skim the chat history when I wasn't connected when I get home if I feel the need to.
That there are no threads to follow per se and you have to come up with filters of your own to create a view of the wall of text is something that failed me anytime I tried to use IRC. With email threads or spontaneous XMPP topic group chats, it works much better for me personally.
I agree it's a personal preference thing for sure. I just really am not compelled by the threaded view of mailing lists. I prefer being able to quickly scan text to "catch up" on things, and I have filters to catch any of the important things I don't want to miss.
Threading is more important today than it was in the past, because there are more and more people who have no idea how to use email or a discussion forum. Gmail and Discourse are partially to blame for when users quote nothing when answering a previous post, assuming everyone has the same view as the author did when writing the reply. So most discourse boards and gmail users' responses on mailing lists have been very hard to fit into the right context. Take even github, where one has to often guess what some comment is referring to. That's why threading with proper message-ids is important. We cope with the bad communication etiquette because we want to be inclusive, but one cannot ignore how much more time is wasted than in the past, due to poor messaging style.
I started learning programming since 2012. I don't like IRC. IRC is not friendly to people like us. Hard to connect, hard to find a free and neat client, hard to talk to the people, hard to start a new thread(also hard since it's in English, but this is somehow good for others). That's why I like talking with people on Twitter and WeChat.
Regarding the long URL issue, since IRC can be easily customised, wouldn't it be possible to create a filter that, for each message, would send the URLs to a URL shortener service and display the result? It could even be a self-hosted service to make sure the URLs remain private.
There are WeeChat scripts that do exactly that (I think urlserver.py is the recommended one, but don't take my word for it). But version 1.0 (iirc) added bare display mode, which does away with the fancy decorations temporarily. This helps the terminal emulator realise that it's a multi-line URL and let you click it. See http://dev.weechat.org/post/2014/02/16/Bare-display
Of course it's easy to do that in a client. Also, on many channels there are bots doing that - every time someone posts a URL, a bot will reply with a shortened version of it.
A bot creates noise for everybody - I think it's nicer to have the client handle this (urlserver.py / bare display in WeeChat, or a non-terminal client). But that creates friction for new users so maybe it's not the holy grail either.
irc since -95. Though I use it just for work these days. I don't think irc will ever go away. It would be nice to have it working in a persistent, distributed way without servers, maybe in the future.
These days, I use Textual on OS X which has a very clean interface and things like in-line images and videos combined with ZNC for logging messages while I'm away. I log in and they all come up, if I want older ones I use the backlog module with /bl #chan <num lines to go back>. Granted it's not as elegant as scrolling up in Slack but I don't tend to need it often. I'm even connected to my friend group's Slack via IRC so I never have to open Slack itself!
I find the idea of piping in various things into IRC intriguing and something I've been meaning to implement. It's trivial to get a Python/Perl/etc script to connect to an IRC server and spit out some information.
Long live IRC!