I don't think it's too late. I know the people working on http://matrix.org/ and I trust them to get the technology right. But as we know, popularity depends on a lot more than the technology.

My only gripe is what took so bloody long. Google Talk debuted 10 years ago and IIRC had an online unified message archive (in gmail) for as long as I remember (2007?). It took 8 years to replicate that feature? "Good enough" ethics at work indeed.

(disclaimer: I work on Matrix)

You don't like the jabber priority based method of dealing with multiple connections. What would be better?

The presumably protocol-level problems are that you can't "upgrade" a two-person conversation to a groupchat, and that a groupchat is an entity in its own right belonging to a particular server, which is something the user really shouldn't have to care about (and also causes reliability issues). And that there's no history.

Beyond that the user experience in every client I've used is terrible: open a dialogue to list available groupchats, manually join one, accept the notification, manually rejoin if you're disconnected. And then you tend to get notifications on every message, rather than just on messages that mention you; purely a client problem, but fundamentally if there are no good clients then it leads me to suspect there's a deeper problem.

Just compare with the groupchat experience in Slack or Skype or heck, AIM.

> You don't like the jabber priority based method of dealing with multiple connections. What would be better?

Send messages to all connected clients for the account, like virtually every other protocol does. And sync history between them. I can accept that that's hard without a centralized server, but it's vital.

Spam, malware and phishing are huge problems with email. I doubt it will exist forever in its current form. I expect more and more restrictions (on sending and receiving) and more and more walled gardens as corporations and people attempt to better defend themselves.

IMO the theoretically best way out of this is the user-owned cooperative, but there's very little traction for that.

I'd trust a small cooperative, but then you still have the problem of federating between those, which brings you back to square one.

This is why I simply love IRC.

I mean there may be some way to do this with IRC where you don't have to piss around with ident and nicks and nets and netsplits and all this other ridiculous stuff, but the proof is in the pudding.

IRC is great, for geeks.

IRC is a very transparent protocol, there are A LOT of chat applications that you see and use every day that are actually implemented using an underlying IRC protocol or variation of it and provide an IRC interface (an example would be Twitch chat).

Furthermore, I've seen IRC being used in a lot of companies internally by most engineers and not.

I would definitely say that IRC has NOT failed, let alone colossally.

EDIT: To reply to everybody and make it easier, I fully understand that IRC isn't universally used (that is the point of the original post) and that is in a steep decline, I'm just saying that claiming it 'failed' (both as front and back end technology) is simply not true. It's old and not as used anymore, that's it. It's like saying the Nokia 3310 phone has failed colossally because not many people use it anymore.

Herein lies the difference between e-mail and IRC - e-mail is fundamentally the same as an underlying technology (we still use IMAP!), but as an end-user product has changed a huge amount over the last twenty years. Things like webmail have progressed a huge amount, and systems like Outlook/Exchange have been built that allow it to be managed in a business centric manner.

With modern e-mail, you sign up for an e-mail, and that's it. You can now go to a website and e-mail people.

With IRC as a product, (aside from the ugly webchats that still expose huge streams of text and NickServ and other things), the end-user experience is still fundamentally the same.

As someone who has spent a non-trivial amount of time in IRC development and as an operator on small and medium sized networks, I've noticed that IRC (especially when services are involved) is pretty counter-intuitive for many users, even otherwise brilliant ones. Modes are obtuse and vary wildly from server to server, the idea of a separate nickname and channel registrations seems unnecessarily complex, channels just disappear when everybody leaves them, and so on. On top of this, the IRC architecture is needlessly limited for the most common IRC network use cases these days. In the past where networks were a federation of autonomous servers, it made sense, but these days a network's servers are partly or entirely controlled by a single entity, and things like netsplits are an unnecessary interruption in user service.

There is a working group to define the next generation of the IRC standard, but the additions tend to be patches for small nigglings in the protocol (such as needing to consistently poll for user away statuses and account names) than aggressive overhauls to the whole architecture, which is okay; there's only so much you can do with an effort like that while still seeing progress, and these are things IRC has needed for a long time anyway.

In my opinion what is needed if IRC is to regain its popularity is an innovative new server implementation that challenges the very workings of IRC from the ground up, maintaining only enough of the protocol to interact with existing clients. If users are to feel comfortable with IRC, they need a server software suite that conforms to their expectations of how a chat service should behave, and no solution currently provides that. The problem is, there is an enormous engineering cost associated with this, and the IRC development community is having a hard enough time as it is finding people who are willing to do more than just basic maintenance tasks.

Whatever the pros and cons of the technology, or the whys and wherefores of the reason for this lack of widespread use, it clearly has not been adopted by the mainstream. If the goal of a protocol is to be used widely, then clearly IRC has failed.

I have a feeling that if DNS had this capability, and "IRC addresses" became standardised in the same way as emails (e.g. nick!irc.example.com), allowing anyone to use it with the same universality as email, the story might be very different today.

Auto-backfill is really nice. And being able to send rich content is something we kind of take for granted these days.

(disclaimer: I work on Matrix.org)

For the same reason as there is a war for your money by big companies. This is how capitalism works. Except with data, it's worse: because people will use free services in preference to paid services, and because network effects are so strong (you can't be the only person you know using your chat service), services have to be "free" and extract value in other, exploitative ways.

Someone has to do the organisation and make it work. IRC makes the users do more of that work. This is true of open systems in general. Proprietary systems end up more convenient but with underhanded ways of paying for it: selling your data, intrusive advertising, etc.

How long does it take you to set up a Jabber client? Can you add a person to Jabber using just their phone number?

It also supports adding a new contact by phone number, and replaces the stock text messaging application, automatically upgrading text messages to OTR XMPP sessions if the other party is on the same network.

It doesn't do federation though, as far as I know.

[1]: https://itunes.apple.com/us/app/signal-private-messenger/id8...

But hey, thank god you're here to be super helpful and point out that we don't have a good chat protocol, but we should darn it. So someone (not you obviously - you have things to do I'm sure) go get it done and report back after you've made a good open source chat protocol.