[JoshM33k]

Those types of fragmentation issues never went away, they just changed focus. Whether it is Slack vs. Hipchat vs. Zulip, or WhatsApp vs. iMessage vs. text vs. Hangouts... more options means more (and easier!) ways to contact friends, family, and coworkers, but also means that you have to memorize a "best way to reach me" chart for each individual person.

[shanemhansen]

Every week I have to use a Cisco jabber client, Hipchat, Slack, and Hangouts within the same company.

I know it's got less of a "cool" factor because it wasn't invented last week, but I soooo wish everyone would just use IRC. Use irccloud if you want some nice apps and picture embedding.

[rikkus]

Is it possible to get what Slack provides using IRC? I mean the whole package, not just the text chat. Consider enterprise-friendliness, excellent mobile clients, zero-setup required (no separate keep-you-online relays), really easy integrations, etc.? We are adopting Slack because it's great and I'd have loved to make a case for IRC but I wouldn't know what server to recommend (we don't really want to install it, but we don't want to use a public server), where I can get commercial support, if there's a nice client (like irccloud is) for mobiles - there's a long list, unfortunately.

[inopinatus]

Also in-client searchable archives, media handling, history editing. All require going outside the IRC protocols.

IRC was designed by hackers, for hackers and it shows. Twenty years ago, IRC was my talk destination of choice and I operated a server within a major IRC network; these days my startup uses Slack which I determined to be the "least irritating" of the 21st century options.

I had high hopes for Google Wave but it was sadly stillborn.

[e12e]

Much of that can be had with a IRC bot. That doesn't include media handling, but you could do search via 1-on-1 /msg (query) with a bot. Then it'd truly be "in client" search.

Most would probably prefer a web ui, with search -- but recording chat could still be done via a bot.

I wouldn't say you could get most of the whole slack experience with just IRC, and you'd probably have to do some work (if only configuring channels/bots/find a web ui etc).

[inopinatus]

This doesn't resolve the multifarious issues with identity, reliability, scalability, federation, standardisation &c &c that further rule IRC out from being the universal panacea.

[voltagex_]

It doesn't have to be. Go help with IRCv3 - http://ircv3.net/. Almost everything that's in Slack and Zulip would just be a capability extension.

[e12e]

It depends on the context. You can't federate with Google, Microsoft, Facebook anyway -- and you won't convert the world to use your favourite new protocol (most likely).

So that just leaves you with an easier problem: how can I host conversations etc for my team/org/my friends? And I think a single, isolated irc server should work fine for that use case, and work fine with many different irc clients?

So no, it's not a universial solution -- I just think it's strange when people bring up slack as somehow "better". Sure it's "better" in that it's a product with backing from some fine people -- but if you wanted a solution based on open standard, Free code that you could self-host without worrying about license costs etc ... then a battle-tested IRC server still seems like a half-decent option?

Or put it a different way: if you have 100s of users, could you get many of the features with IRC, and some bots? (Or maybe a slightly tweaked IRC server etc etc)?

[ed: Not that I claim there aren't problems with IRC -- and I've yet to run a personal ircd, so I don't know a) how much work it is to force TLS+SASL[1] and disable plain IRC, or b) if there are other solutions that might be better, that are available right now.

[1] https://freenode.net/sasl/ ]

[ara4n]

Matrix.org is heavily inspired by Wave, albeit using HTTP rather than XMPp, for those searching a more alive option :)

[bjeanes]

> I had high hopes for Google Wave but it was sadly stillborn.

Yeah me too. Google really effed that one up. RIP

[scrollaway]

The closest you can get is a foss slack alternative such as Mattermost, and push for an IRC bridge (Mattermost is working on it it seems: https://github.com/mattermost/platform/issues/650).

But it's not possible to get what you're asking without breaking the IRC protocol - it's not easily extended and the formatting rules are icky mIRC crap.

[voltagex_]

Go help with IRCv3 - you're talking about capabilities, which are part of the v3 protocol.

http://ircv3.net/specs/core/capability-negotiation-3.2.html

[XorNot]

The trick with capabilities is you need them to be reasonably standard. Which means the go to IRCv3 server should ship with them turned on, and the reference client should be capable of using them.

[bjeanes]

Slack's IRC bridge is actually pretty good. I know that's not quite what you're asking, but at least you personally could still interface using IRC.

[jwheare2]

Any reason you rejected IRCCloud? (disclosure: my company). We host private servers for teams and do the majority of what you're asking for.

[rikkus]

I didn't make the decision. Slack started to appear and I didn't know that IRCCloud had apps (which seem to have great reviews). If I had known, I would have suggested it as an alternative. As it was, I just kept quiet as Slack seemed great - even better than HipChat, which I used to use for the same purpose.

Perhaps IRCCloud could be sold as a rebranded Enterprise app as an alternative to Slack? I'd love to see some competition as it looks like only HipChat and Slack are getting talked about.

[hermanradtke]

I don't use it because I want to use my own irc client and not a web interface. I want ZNC as a service.

[bsimpson]

That sounds like a problem with the company. I can understand Slack and Hangouts (at least until Slack adds voice chat), but all that other stuff sounds like poor organization on the company's part.

[voltagex_]

What I posted in another thread still stands - https://news.ycombinator.com/item?id=10256943. Things were better when everything was brought under one client. I know iMessage is almost impossible to reverse-engineer (due to Apple kicking non-iClients off) but I wish there was more effort going into reversing Hangouts. Someone's emulated the JS client from GMail but that's about as far as it's got

[CydeWeys]

IRC's lack of scrollback alone kills it for these considerations, unfortunately. If there's an incident or discussion in progress and you only join the room partway through you have no way of catching up to speed.

[epsylon]

That's what bouncers are for.

[anentropic]

you wish everyone would use the worse option?

[rdtsc]

They were on their way out as some services were federating via XMPP. Then some stopped supporting it.

[scrollaway]

Sad as it may be, it's pretty clear at this point that XMPP won't be the communication protocol of the future. Everyone who ever seriously worked on it seem to have come out of the experience a broken man. Setting it up requires pretty deep knowledge and the promises of compatibility with most XMPP servers break down pretty fast unless you know which extensions to support.

All these problems are fixable but I don't see the tide ever actually changing direction and "hey suddenly XMPP is cool again, we should all use it".

One thing is for certain... humanity needs standard, open and widely-used protocols for communication. And there's a lot of ground to cover: Text, audio, video; single and multiuser; topical (IRC-like); social (invite-based/people I know); Synchronous (IM) and asynchronous (email/offline messaging)...

XMPP tried to do a lot of that. Maybe it tried to do too much. Maybe you just can't do all that in one protocol. I don't know, I just hope we'll get there soon - if nothing else, I'm tired of maintaining those "best way to reach me" charts JoshM33k is talking about.

[catern]

>Setting it up requires pretty deep knowledge

Not even remotely true! Prosody on Debian works out of the box, including federation. You just have to configure the domain name.

It's not hard to set up an XMPP server. It's hard to set up Ejabberd. Ejabberd is not the only XMPP server. Prosody is very easy to set up.

Honestly, people, think before you speak...

[scrollaway]

> Honestly, people, think before you speak...

I didn't just make this up on the spot, I've been dealing with these issues for years. So yes, I've thought about them a lot.

I used to run a prosody server on my home box. It is great software and a fantastic daemon compared to ejabberd (edit: Configuration-wise that is) but fat lot of good that does if you don't know what XEPs to set up when dealing with other servers. I shut it down because it was pretty much useless and I wasn't able to talk to my gtalk buddies from it anymore.

[catern]

> fat lot of good that does if you don't know what XEPs to set up when dealing with other servers.

I have no idea what XEPs to set up when dealing with other servers. I did not have to set up any such thing. Like I said, federation (server to server communication) works out of the box, at least on Debian.

[sanderjd]

Your comment is informative, but the last sentence is unnecessary and inflammatory.

[catern]

You're right. I would delete it, but it's past the edit deadline.

[PhasmaFelis]

> Honestly, people, think before you speak...

Was that really necessary?

[dorfsmay]

I've been using OpenFire, no problem there either.

I had never heard of Prosody, any major difference cons/pros between the two?

[rdtsc]

Yap. Agreed. XMPP looked good on paper, if you read just the mission statement. Thinking back, I tried to dive into it once and nope-d out of it quickly. I guess I just blocked that experience out of my mind for some reason.

[fletchowns]

Who might be the right entity to take on creating a replacement for XMPP?

[scrollaway]

¯\_(ツ)_/¯

One of the best things that could happen today I think is Google open sourcing the Hangouts protocol. It's a reasonable alternative to XMPP and has a massive userbase. The clients are pretty horrible but that might be completely unrelated to how good the protocol is (Note: I have no idea how good it is. Because it's closed source.).

I was hopeful for a while but I don't really see it happening anymore :( Oh well...

Edit: Oh and the worst part: Communication is just one side of that coin. The other side is identity and it's one hell of a side. OpenID was a disaster. Mozilla got it mostly right with Persona but completely botched the marketing and has all but given up on it now. There is no decent foss protocol for identity/authentication today other than Persona, and nobody is working on one. There was a time indeed where I could've pictured Google working on solving this just for the hell of it. Just because it would improve the world. That Google is gone, and there's nobody with the appropriate reach that seems willing to do it now.

[StavrosK]

I will forever mourn and be angered by Mozilla giving up on Persona so easily.

[fletchowns]

Why is Persona dead? Visiting the site doesn't seem to give any indication it's dead...

[lukeh]

Persona was great and it's a bit sad to see it dead after investing a lot of time in it but - one big architectural problem was there was no way to support delegation (the problem OAuth was originally designed to solve).

[e12e]

Has anyone got experience with both XMPP and SIP/H.323? From what I've been able to figure out, H.323 looks like it's one of the better candidates of protocols that exist today and is "reasonably" simple... while SIP... well, SIP smells a lot like it came from big TelCos. And not in a good way.

See eg: https://www.packetizer.com/ipmc/h323_vs_sip/

[jallmann]

> Has anyone got experience with both XMPP and SIP/H.323?

I've worked with all three. The H.323 vs SIP battle was fought a long time ago... for better or worse, SIP won. Any H.323 systems still in the wild can probably be considered "legacy."

That being said, while H.323 has more "batteries included," its call flow is accordingly more complex. SIP is not too bad, there is some subtlety to it, but the main issue is that you have to piece together dozens of RFCs for an interoperable system, not to speak of implementation-specific quirks.

XMPP is the more appropriate protocol in this context -- IM and group chat -- because it has had presence and ad-hoc messaging baked in from the start, including reasonably supported MUC. Ultimately, XMPP's issues are similar to SIP's -- the patchwork of XEPs is too unwieldy to work with. For an example, compare the multimedia bits (eg, Jingle) and the corresponding SIP session setup flow. The stigma of being a XML-based protocol designed in the 90's doesn't help, either.

The biggest reason SIP is sticking around, however, is that it has major buy-in from the telcos with IMS/4G. However, SIP is also a more appropriate protocol for traditional telephony. In that respect, comparing SIP and XMPP is a bit like comparing apples to oranges. With the appropriate extensions, one could behave like the other, but it wouldn't be their strength.

[paulej]

I was the editor of the H.323 spec years ago. Funny you would say that SIP looks like it comes from the telcos, when the whole aim with SIP was to create just the opposite. H.323 has often been accused of being created by telcos, too. Truth is, folks from the traditional enterprise voice equipment makers shaped both.

SIP was adopted by 3GPP in 1999 to be used in the mobile networks. Of course, that trickled throughout the telcos, so it now is widely used in the telco space. H.323 was widely used for PSTN backhauling to reduce tolls. However, SIP is more prevalent there, I'd guess.

Enterprise networks still use both H.323 and SIP, with more desk phones using SIP and videoconferencing equipment split, but moving to SIP.

That said, any move to SIP these days is only because there is nothing better. WebRTC is the next big thing. It borrows SDP from SIP, but no signaling protocol is defined.

Personally, I'd like to realize the vision behind what was intended to be H.325, which was to be a JSON-based signalling protocol that is fully distributed. Each application could implement whatever protocol it wanted, and they would all be associated through H.325, giving the user the feeling that these different applications work closely together. That would be possible, even when applications run on different devices.

Alas, there seems to be no financial motivator for those that control the market to explore that concept, so we're stuck with H.323, SIP, and WebRTC (and various proprietary glue pieces). The trend these days seems to be toward proprietary solutions, providing limited interop with others through SIP. Limited, as in nothing but basic voice and video.

[lstamour]

Identity is a separate problem. So far, https://www.accountchooser.com and OpenID is winning -- if by winning you mean maintaining a list of very popular email providers and using their APIs. ;-)

[ocdtrekkie]

Yeah, I can't see Google ever either open sourcing Hangouts, or making it possible to federate it. Google's opinion seems to be that everything that is a service or protocol should be a Google API.

[vbezhenar]

https://matrix.org is a promising candidate.

[scrollaway]

I remember reading about matrix when they first announced. Was pretty excited about it, haven't heard anything since. I It's just tech though; even if it's mind-blowingly great, won't do much good if no large-scale userbase picks it up somehow.

[ara4n]

We're still alive and going strong - currently supporting glossy client development like Vector.im and building out bridges to as many other networks as possible (IRC, Slack, HipChat etc) using http://github.com/matrix-org/matrix-appservice-bridge and similar. In terms of being picked up by a large user base... yes, we need it if we are to be really relevant. And that means relying on folks like those commenting on this thread to try using it, contributing to it, and help us make it better.

[ara4n]

Whilst we're not trying to replace XMPP, Matrix.org does provide an entirely different architecture (decentralised and evetually-consistent history, high baseline feature set, HTTP-based, etc) that can be used for group chat/VoIP/etc.

[sitkack]

I don't know who will do it, but it will be in-band, meaning inside http and using html5.

[rekoros]

I did some research on XMPP interop and its demise (ignore the title) - https://sameroom.io/blog/announcing-support-for-google-hango...

[hobarrera]

At some point it did fade a bit. About 2-3 years ago enough people were using XMPP/Gtalk so that I could reach about 80% of my acquaintances thought it.

Now, there's no single network that holds over 25% of them. Except facebook, but most of them don't actively use facebook every day, nor pay attention to it's IM.

[tbingmann]

Best ask them first via email.

[TillE]

I don't even know my girlfriend's email address. I'm 30, and she's only a few years younger. The world is strange now.

I miss Google Wave. Not the messy implementation, but the promise of a big influential company throwing its weight behind a modern, open communication protocol.

[inopinatus]

This. This was how I learned that the whole "don't be evil" thing was a load of bovine manure.

Google Wave, as an XMPP-based protocol, held enormous promise as a federated rich discussion standard. Sadly their first implementation was clunky and had a confused approach to standards and integration; it was effectively stillborn.

Then Google killed Google Talk by strongly favouring their closed "Hangouts" product which is practically inaccessible from chat clients. They went further, making it impossible to federate Google Talk to other XMPP services. Facebook and Microsoft followed suit, either ending XMPP support or closing their federation capability.

All three are therefore complicit in the worst abrogation of Internet interoperability since the early days of MSIE. And Google, in a land grab for consumer eyeballs, was the cheerleader.

[CydeWeys]

Weird. I'm 30 too and I know all of my acquaintances' email addresses. How do you not know your girlfriend's email address? You can't even do something as simple as forwarding her your travel tickets so she knows your itinerary, or a receipt for concert tickets so she knows when it is, or send out a group email with details of the time and location of your party, etc.

Email was drifting off for me a handful of years back, but ever since smartphones ascended email has experienced a huge resurgence. I'm likely to use it in preference to SMS for (a) longer messages and (b) messages with multiple recipients (e.g. your standard activity planning emails).

[morganvachon]

It would be nice if the iOS and Android built-in Contacts apps had better support/integration for all the various messaging apps that work on their respective platforms. Rather than trying to remember who uses which services, their contact card could simply contain the entire roster of their services and usernames, and you could initiate a conversation in that service from within the contact card. I know you can do this with the baked in messaging services for each platform (SMS/MMS and iMessage for iOS, SMS/MMS and Hangouts for Android), but I'm talking about a one-stop-contacts-shop for every major messaging platform. Maybe that would require too much cooperation between messaging app authors and the big OS vendors, but I think it would be possible.

An alternative solution would be a cross platform third party Contacts app that offers that kind of integration. I've seen multi-messenger apps (Trillian, IM+) for both platforms, but that's not quite the same thing and it inevitably leaves out important functionality from the official apps.

[andrewaylett]

That they don't on Android is due to the app, not the platform - if the client adds contact integration, it gets listed in the contact's card. Lync, of all things, is a good example of this. I'm pretty sure Skype does too.

[morganvachon]

I wasn't aware of that, thank you. I haven't used an Android phone in a while.