For those who wish to keep using it, setting up your own server (prosody is pretty good!) isn't too hard these days.

A hearty Fuck You to Google, Facebook, and Apple for tearing apart this open federated standard. Users don't benefit from being forced to use your shitty walled-garden proprietary communication apps.

(Yes, forced; if I want to talk to my friends, it usually has to be via whatever proprietary chat network is in vogue at the moment. There was a brief golden age of IM during which GChat (federated XMPP) was king, but GChat's been in its death throes for years, and the current flavors-of-the-week are AIM and MSN all over again.)

But honestly - they're not trying to appeal to us. Every time I get stressed at the Googlemonster or Facecrook I remember that all I have to do is press delete and use something else.

edit: these apps are built for 1. people who don't / didn't care in the first place 2. noobs 3. my parents 4. advertisers wallets

At least text messaging is still federated with portable identities. Took an act of the Feds to ensure that…

Clearly we cannot play a fair game with the closed whatsapp, but hacking cannot be stopped or forbidden.

After all, it was always like that. If you go back of 10 years al "regular people" had MSN and similar stuff, and we were IRCing. As a hacker, you migth feel sad, and think openness lost the war. IMHO the only difference is that nowadays we have much more "regular people" than before. They were simply sms-ing before they could access whatsapp.

It's actually really sad to see these events... one of my favorite things in the late 90's and early 00's was actually the voice chat rooms in Yahoo messenger, but the bots ruined that platform... it was proprietary, but it was fun.

These days, it's pretty much SMS only for me... I don't need an app that only works on my phone, not my desktop, and actively spies on me, and sucks my battery life. I do have skype which I use sometimes, mostly for those that I talk to overseas on rare occassion.

I had high hopes that XMPP or a decent replacement would evolve that actually worked well... same goes for Diaspora and a bunch of other things though. In the end people like their walled gardens. :-(

Matrix (http://matrix.org/) is getting there. It does work well, though it's still in early (and active) development.

You and me both. I don't have space on my phone for every individual messaging app that my various friends use.

"Have you got whatsapp?" No "Do you use Kik?" No etc.

Do you even need to ask your recipient what carrier they're using or do you just punch in their number and text away? Does it work regardless of what brand of mobile phone they have? Does it work even if their phone is temporarily disconnected from the network?

WeChat has all of those features, but I don't think anyone would regard it as other than proprietary...

Except for when it does not. More often than not carriers don't return the correct status codes, marking messages as delivered when in fact the recipient does not even have SMS enabled in their contract. This gets even worse with international messages that can be routed through multiple carriers' networks until they reach (or don't) their final destination.

I can't even say that XMPP failed to adapt to mobile. It's more that XMPP was a terrible protocol with a gigantic flaw that should not have been there in the first place, and mobile just made the flaw obvious to everyone.

(Yes, I know they're for-profit companies who have every reason not to want to relinquish any control over their network. Doesn't mean I can't hate on them for not even pretending to support consumer choice.)

By my way of thinking, your choice of language (not because of you, the person, but of how the words have become ingrained) is indicative of the problem: "consumer" versus "customer." We consume what the various companies choose to offer to us in the way they offer it. We are not treated as customers, valued or otherwise, in a competitive landscape. There exists a one-way flow, from the company doing the advertising to our eyeballs to consume it.

Look at the businesses people claim to like: local shops, service providers like Fastmail, and the like. In those cases the people giving them money are treated as customers who have other choices and who have made the voluntary choice to continue to associate with that business.

That's what is missing. Customer instead of consumer.

Of the rest, more than half host their own MX. While that's totally reasonable, it means the percentage of people willing to pay just $3/month to be a customer is even smaller than it seems. And $40/year is the cheapest that one could ever hope "being a customer" would cost.

So, lots of people say they want to be customers, but even when doing so is close to free, very few actually do.

(Nothing wrong with using Google because it's free, only while concurrently claiming to want to be a customer. I agree with your point and I'm a happy FastMail customer. I'm amazed FastMail can make a profit at $40 and it's a huge credit to them that they can.)

What is that flaw? Is it the flaw that you mentioned in your opening sentence?

Edit: For the downvoters: This is a serious question. I don't ask non-serious questions. :)

[0] http://xmpp.org/extensions/xep-0280.html

[1] http://xmpp.org/extensions/xep-0313.html

We can speculate all we want, but this just leads to confusion. :)

On the Desktop, Swift and Gajim come to my mind, on Android Conversations is getting really awesome (and yaxim, which I am the author of, supports the basic multi-client/mobile use case you are interested in).

That said, the XMPP protocol is not perfect, and it is lacking some important elements for a 2010+ mobile chat developer, but considering that it was initially developed in 1999, that mobile chat is only one of its many use cases, and that there are extensions covering all you have asked for, the critique is not appropriate.

[0] http://swift.im/swift.html

[1] http://gajim.org/

[2] http://conversations.im/

[3] https://yaxim.org/

And no, I'm not exaggerating, I've done both and decided that writing XMPP clients is not for me a long time ago.

Addendum: I really love XMPP, but I do think the many many extensions have hurt it more than one defined spec. And yes, I know it supports many use cases, but I simply only care for 1:1 and multi user chat.

Sending message to other devices is managed by message carbons which is in last call for being a standard XEP, and support is becoming more and more common.

XMPP is all but deprecated, very active, working well, with a large ecosystem. But is really badly known by most of people(I have by the way started a series of article to explain it: http://www.goffi.org/tag/talk_xmpp).

It's really difficult to be heard these days, but there is a new wave in XMPP world (check our project: http://salut-a-toi.org or movim: http://movim.eu).

At the moment all the MUC room histories vanish if I need to restart ejabberd which is a farce in a cloud world...

And message carbons work, but since ejabberd only seems to support a single auth token meaning that if users connect with multiple devices they can't actually log out of only a single one without pulling the plug on all connected devices.

Are these only ejabberd issues or issues in the XMPP specs?

BTW this is for realtime chat on for an app, nothing federated... I'm open to non-XMPP options too.

Message Archive Management (XEP-0313) is supposed to do that.

> And message carbons work, but since ejabberd only seems to support a single auth token meaning that if users connect with multiple devices they can't actually log out of only a single one without pulling the plug on all connected devices.

Not sure to understand: if you disconnect a device, all the other devices with the same jid are disconnected? If so, it's definitely not normal, and not a spec issue. I'm also surprised to see ejabberd having this behavior, you should talk to the dev team.

Thanks, I'll check that out.

> if you disconnect a device, all the other devices with the same jid are disconnected?

No, not on disconnection - I can't seem to find a way to tie multiple auth tokens to a single user (one per device) to allow them to log out on different devices individually. At the moment logging out one device would disconnect all clients.

Just a short English usage note: "all but" means something like "almost". Judging by the rest of your post, you probably mean "XMPP is far from deprecated" here.

Thanks for the correction :)

1: http://english.stackexchange.com/questions/9967/all-but-idio...

[1] - https://www.process-one.net/en/ejabberd/protocols/

[2] - https://prosody.im/doc/xeplist

[3] - https://github.com/esl/MongooseIM#features-and-supported-sta...

Example:

http://conversations.im/

Let's be honest - we live in times when "federated" email communication would also be abandoned (with Facebook becoming the de facto platform for personal communication) if not the business users.

I guess it just takes time too switch phases.

They do however require your server to be properly set up, with a correct reverse DNS etc. And Hotmail/Live mail does the same.

1: I have little evidence beyond what looks obvious, but that could definitely be wrong. I'm open to new information proving me wrong.

Afaik it didn't happen because of patent issues.

To me it just feels like they just don't care enough.

Also, patents do not have to document everything. You can leave out some trade secrets, as long as the patent itself documents enough to prove it's a novel invention.

And Apple gets pretty much zero kudos from me for client XMPP support. iMessage is a proprietary walled garden; client-only XMPP support is simply their one-way valve to get people into their network and only ever had any worth because Facebook and Google used to support XMPP.

> And Apple gets pretty much zero kudos from me for client XMPP support.

I guess we have different expectations. Apple is a company that sells me client hardware/software. I use Mail to connect to standard IMAP servers, I use Messages to connect to a standard XMPP server and Facebook. You can apparently even buy Apple's XMPP server through the Server app on the App Store: https://en.wikipedia.org/wiki/Messages_Server The one thing they don't offer is a single, centralised XMPP server. That's not really an active attack on the standard, though.

Anyway, I live in a completely different filter bubble than you and your sibling poster - XMPP never had any momentum at all around me, so I can't really speculate on how it died.

Federation is something that is rarely promoted in modern ecosystems. Before Twitter/Facebook, we had RSS/Atom, but these have all failed as companies pour massives investments into "winner take all" approaches to their products. In the short term, it is easy to see why: Why compromise on iteration of features and UX by allowing a competitor to interoperate? Why wait for a new field to be standardized in Atom?

We see it all the time in the consumer space, federation has died, but even look in the infrastructure space, something like Docker: Yes, Docker Hub, is "kinda" open, I mean, anyone can create an account, but it's not a federated scheme where everyone can host their own Images easily. But we use it anyways, because its a better user experience, and its subsidized by a company not directly making revenue on it yet, but wanting to control the user experience.

So we drop support for any federated user experience pretty quickly. And now we are all on Slack, on Facebook, on Twitter.... And it is mostly great. Or we wouldn't still be there.

But I still wish for a federated future, but I doubt it will happen.

See: https://hub.docker.com/_/registry/ https://github.com/docker/distribution https://blog.docker.com/2013/07/how-to-use-your-own-registry...

There are several companies that have implemented alternative container registries. Google (Google Container Registry), CoreOS (Quay) , and JFrog (Artifactory) all come to mind.

One area which hasn't (yet?) succumbed to this is podcasts. The podcast clients I use (Overcast on iOS and Pocket Casts on Android) will accept an RSS URL, and most (all?) podcasts provide such a URL.

However, there's barely a blog out there that doesn't support feeds and I heavily use them in Thunderbird without a problem.

A federated chat that had a good user experience and ideally a feature that appeals to a niche (e.g. easy voice chat for gamers like discord app) could still make headway.

In fact, the proliferation of new niche clients with relatively easy integrations is the kind of situation in which a federation standard could thrive.

Whereas in Facebook, Google etc, the open solution is usually following the walled garden. I yearn for open solutions but they will have to follow open internet access (local grids) and then the economics of sending a packet to SF in order to message my next door neighbour becomes more obvious.

It pretty much works, and that's great, but barely a week goes by when HN doesn't have an article lamenting the lack of useful spam-control or encryption/sender verification and many other things. E-mail is still a very poor medium to facilitate long threads with many participants. E-mail as notifications (push) is lacking. E-mail as an interface to software systems (e.g. ticket tracking systems) is lacking.

These deficiencies are all easy to fix in a technical sense, but practically impossible to address due to the federated nature of the system. The few changes we do end up getting (HTML bodies, and even MIME before then) are long and painful, and are largely resolved by "might is right". Others unilaterally break fundamental features, such as curbing spam by essentially banning decentralised SMTP. If you rely on being able to send out large quantities of email, you either have to pay a gatekeeper, or hire a specialist in the dark arts of actually have your email go through. This dark art consists of keeping track of the many ways in which the large players in the e-mail world systematically break the protocol to combat spam.

We have essentially abandoned the federated nature of email and handed over one-sided control to a small group of companies (Google, Microsoft, Yahoo, perhaps a few other) in order to effectively curb spam. The alternative would have been the end of email.

XMPP fails because it tries to, indeed needs to, boil the ocean. There's an extension, or two or seven, for every conceivable feature and use case, and so you need to choose which set of features in a n-furcated (where n is tragically large) set you want/need, and live with the fact the these aren't perfectly compatible with deployments that has made other choices. And so the federation and standards compatibility is really only theoretical, and then, what's the point? If spam killed truly federated email (and the need for actual working encryption might well finish it off), mobile killed XMPP.

Hopefully, at some point, the IM features of Slack, Twitter, Google Hangouts, iMessage, HipChat, Yammer, Skype, Whatsapp and friends are going to converge enough that an open source application can emerge and define a basic set of features through domination, in much the same way Wordpress ate the blogging world, and that can then lay the foundation for interoperability.

Let me introduce you to IMAP IDLE.

> E-mail as an interface to software systems (e.g. ticket tracking systems) is lacking.

Jira, for example, has a pretty good one.

> We have essentially abandoned the federated nature of email and handed over one-sided control to a small group of companies (Google, Microsoft, Yahoo, perhaps a few other) in order to effectively curb spam. The alternative would have been the end of email.

I've been running my own mail stack for 8+ years. The reason is simple: only I can mess it up. No 3rd party to lock me out from my communication, no 3rd party to decide what I can send. If it fails, it's my fault only. And I'm still using email. I do occasionally get spam, but most of them is already dropped by blacklisting and a few intelligent rule; the rest is catched by dspam.

XMPP is overcomplicated, solving nothing IRC can't solve already ( imho, of course ); that is why it's failing.

What we need for the more open source approach is people to value their communication and not to trust 3rd party because the look/act cool.

> Hopefully, at some point, the IM features of Slack, Twitter, Google Hangouts, iMessage, HipChat, Yammer, Skype, Whatsapp and friends are going to converge enough that an open source application can emerge and define a basic set of features through domination, in much the same way Wordpress ate the blogging world, and that can then lay the foundation for interoperability.

They won't. WordPress was open from the start and the current trends are locking-in APIs, not open standards. There is no profit in openness.

They (the incumbents) won't. But someone will, in the same way that WordPress replaced hosted blog platforms for many. Might be wishful thinking, but this seems like it could happen some day.

It's my understanding that the biggest hurdle in owning your own email stack is that a lot of 3rd parties decide what they'll receive, and hold senders to very strict standards. Have you experienced many issues with recipients on various platforms not receiving your emails?

But I may have chosen the words; the main reasons it that I don't want anyone to let decide or mistakenly delete/close/block me out of my own account.

I often feel the ambivalence to your own mail servers is unfounded. A basic apt-get for Postfix and Dovecot will give you secure defaults. The only thing you need to do then is to set up the certificates, the dns records, and keep up with what happens in the future. It's absolutely comparable to running your own web server, where you also need to change a cert or two over time.

Mostly because some industry giants first moved to support it then yanked the rug out from under it when they realized it reduced the amount of end-user lock-in.

Also: IRC.

It's decentralized, not federated, just like the web.

I think RSS failed because of the bad user experience it provides. Unless you are following hundreds of feeders, it's much easier to just go to their site, than to open a reader, get maybe one line without context - or some text that isn't in the article at all, click there and go to the site.

My comment from that thread:

> I've been running my own XMPP server for years, with federation enabled. A few years ago, it seemed like the logical successor to AIM and MSN and all those other walled garden IM systems. And how easy! My XMPP "name" was the same as my email address. One less thing to put on my business card.

> But since then, I have realised a big problem with it - no-one uses it! Today I communicate with the world by iMessage, SMS, Twitter, and email. "Instant messaging" just seems to have died as a concept entirely, replaced by yet more walled gardens like Snapchat.

> My XMPP server is being turned off for good, next week.

(It has since been turned off.)

What other option is there, really? The other option is no interoperability.

A very relevant post: https://sameroom.io/blog/announcing-support-for-google-hango...

A common use case is federation between two Slack teams (share a channel).

Another common use case is federation between a group in Skype and a channel on Slack.

Or IRC and Telegram, etc.

Making existing systems work together really well is priority one. API only makes sense once that's done.

Of course, I could also just connect to everything through IRC (at least for Slack<->IRC), but the Slack client is a lot nicer on mobile than any IRC client I know of.

The certificate chain for this website contains at least one certificate that was signed using a deprecated signature algorithm based on SHA-1.

What's weird is that Qualys SSL Labs is giving you "A"s, so maybe they don't check for this condition?

Hopefully federated chat will pick up, but it seems business models around social networking pretty much preclude any kind of federated communication between services. If adoption rates for Diaspora, Friendica, Pump.io, GNUSocial etc. are any indication, XMPP looks doomed. :(

Then Google Talk stopped federating properly. Only a bit at first: things like presence notification didn't quite work right, and adding people didn't quite work right. And in the meantime, Hangouts popped up, and offered a more seamless audio/video experience too. Most people I know stopped using Google Talk entirely in favor of Hangouts; the few that remained used it only while the gmail web interface more-or-less supported it. Eventually, federation with Google Talk quite deliberately stopped working.

It didn't take long after that before almost everyone else I talked to on it stopped showing up, even those who didn't use Google Talk. People had "last seen" times in the months, and if I wanted to talk to those people in realtime, I sent them text messages, or Twitter DMs, or Hangout calls.

So when I upgraded my server a couple of months ago, I just didn't bother setting up the XMPP server again. Not because it didn't work, but just because it had nobody to talk to.

  > So when I upgraded my server a couple of months ago, 
  > I just didn't bother setting up the XMPP server again.
  > Not because it didn't work, but just because it had nobody
  > to talk to.

It was very minimalistic compared to MSN Messenger, sadly Google did seem to favor the web version of it, and it received no updates.

From a DIY perspective, what are the options? Are Ignite, Prosody, and ejabberd the only viable options? Are they all being maintained? Is there anything out there that works at a small scale; like a Node server that could run on OpenShift, or something else super lightweight?

http://blog.fastmail.com/2012/09/26/one-step-forward-two-ste...

Honestly Prosody looks the best. We were planning to switch to it when async login support and scalability to thousands of domains was stable... but that was 2 years ago and it never quite materialised - and now DJabberd is so far behind in support for "standard XMPP" and the interoperability of the remaining servers that we just had to give up. I argued strongly against it, having spent so many bloody years on making this thing work - including tons of patches to DJabberd and some EJabberd hacking as well - but the numbers didn't lie.

Better to spend our time on exciting things like the currently-in-testing cross-domain support for Cyrus IMAPd and reverse ACL lookup that will make the LIST command blindingly fast even on big servers. I'm hoping to be able to say two steps forward, one step back this time instead :)

Having said that, for my single-account, single-site needs, ejabberd worked just fine for me for the several years between the time that I learned about the fact that Google Talk federated with XMPP servers and the time that Google stopped federating with other XMPP server operators.

I can't speak to how comprehensive ejabberd is, but for one-on-one chats, and multi-user chats, it worked just fine when I was using it.

[0] https://github.com/processone/ejabberd

I see this keep getting repeated, but AFAIK there was only like a month long time they temporarily suspended federation for adding new contacts due to a spam issue? I've been talking to people on Google Talk from my (FastMail, sadly) XMPP account for the past year without issue? Am I going crazy?

Google might have changed their mind and quietly started federating again. I haven't checked in ages. Guess I have another project to complete this weekend. :)

I shut off my server just recently, because no-one uses XMPP anymore.

Doesn't really change much; just thought that'd be an interesting thing to throw out.

It's missing websockets support though which would be nice.

I found a nice overview of what Matrix.org is doing [2].

[1] - http://matrix.org/docs/spec/#id33

[2] - https://bloggeek.me/matrix-webrtc-interview/

But it doesn't help that XMPP was always awful. It has OpenGL syndrome - too many extensions, described too vaguely, and implemented in too many broken ways to work amongst one another. You get a swarm of mismatched servers and features, and if it did the same thing that would have saved commoner OpenGL adoption, it would probably still be king.

That problem is a blessed default implementation. If the foundations that wrote the specs for these low level pipeline APIs were also burdened to make sure the blessed implementation supported the entire standard perfectly, there would be an out of the box open source permissively licensed base for everyone else to build off, rather than the vague wording of technical documentation.

I'm just hoping Matrix becomes something. In the same way Vulkan can hopefully save universal graphics programming, Matrix might save IM, but we need to support it. I'm working on the Telepathy integration for it myself on weekends in a sketch repo.

I'm super interested in this - do you have the repo posted anywhere?

I love Telepathy and its native clients, but it doesn't support things like remote history retrieval... I feel like that would have to be done before a Matrix CM could work really well.

These services are never going to inter-operate, and I hate it. Imagine if we had to maintain different telephone numbers or different email accounts just to communicate with different groups of people. It's almost unimaginable, but that's what we have now with text and video chat.

This is core communications infrastructure. These segregated private networks have begun to displace the public telephone network in terms of popularity and importance. These are also the platforms over which video communication is being rolled out--not the public telephone network, as most people would have thought twenty-five years ago.

The FCC needs to step in and set some inter-operability rules for the major players here. I have mixed emotions suggesting this, considering that I'm generally opposed to regulation of the Internet. But unless the government steps in, can the situation ever change? Doesn't it need to?

No. That's applying a personal preference - one that I also have - to the rest of the population. Most, and quite possibly almost all, users have chosen features above interoperability.

Yes, the situation could change, but no, it doesn't need to.

Contrast with, say, mobile phone number portability in the US. While one can still argue for or against requiring it, users obviously actually cared and used it. Even when XMPP was popular, very few users left Google.

https://news.ycombinator.com/item?id=10280155

https://news.ycombinator.com/item?id=10486541

I'd highly recommend people read through them, especially if you're interested in fixing the issue.

(By which I mean Google, Facebook, Atlassian, Slack, etc.; all of those companies who have chosen to put a nail in the coffin of the open Internet).

Oh well, guess I won't be doing online chat any more.

I wonder whether the children even believed the last generation of Roman Britons when they spoke of writing, under floor heating, goods from half a world away...

Opera has been doing that a -lot-, the biggest cases being Unite and soon Link.

One thing though:

>Meanwhile, our XMPP service is now somewhat behind the cutting edge, and lacks support for many of the recent XMPP extensions that the dedicated XMPP users are now beginning to request.

Does that mean if they kept silent the service would just run somewhere in the corner, forgotten? ^^

In a multi-device/mobile world XMPP is shit. HN constantly complains about Slack/Hipchat/etc "Reinventing the wheel". "We have IRC and XMPP" they cry without stopping for a second to understand that IRC/XMPP as not trivial to setup correctly, mobile support is complete shit, without things like bouncers or servers to hold all your messages you can lose things and stuff not be in sync, clients can't really add features unless all client can support it, and more.

Does it kind of suck that the dream of federated chat died/is dying? Yes but if it doesn't support what users really want then it's the standards fault. I don't blame any of the major players for pulling support, it wasn't going to move fast enough so they ditched it and built something that would.

In the end, it's quite simple: federation and simplicity work _against_ many business cases. This is why this stuff is being dropped by the big players in favor of proprietary solutions left, right and center.

These are the things I need out of chat and while XMPP had extensions for some of those things finding server software and client that supported it reliably was near impossible.