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!
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.
host: irc.darkscience.net/6697 (SSL required)
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.
Oh and there's also a Matrix script for WeeChat, so you can use matrix from WeeChat (and thus Glowing Bear)!
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 :)
What are you talking about?
> 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.
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.
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.
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  (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.
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...?]
I'm sure when Matrix is the go-to chat protocol you'll get more than that. Until then it is sorta fitting..
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.
> 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!
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.
Or, there's email.
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.
Weechat and it's Android relay client is for you.
I've been using the free version for a while and I'm pretty happy with it.
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.
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).
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.
To soak wisdom from top-tier hackers in the field, you want to go where they hang out. IRC might just be the hacker playground.
That alone makes a convincing case for using IRC.
> 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.
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.
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.
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...
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.
Are there solutions out there that offer something similar but without the community aspect?
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.
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.
(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.
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'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.