Hacker News new | past | comments | ask | show | jobs | submit login
The Sad State of Mobile XMPP in 2014 (op-co.de)
102 points by ge0rg on Jan 30, 2014 | hide | past | favorite | 76 comments

The state of instant messaging is sad overall. There was a steady evolution to my own IM usage: from a proprietary, walled-garden IM solution (ICQ) via a reverse engineered multi-network client (a la Trillian) to a federated, free protocol, XMPP. I figured everybody would be using XMPP of some sorts and we'd be on our merry way to solve more interesting problems on that basis.

Instead, everybody is back to walled gardens that can't interoperate, and I'm using 5 or more services to talk to acquaintances -- SMS, Jabber, Google Talk, Skype, the list goes on -- and fall back to good old email for people where I don't have access to their IM of choice (such as Facebook chat or Whatsapp). It's such a pain in the ass.

It's 2014, I expect it to be matter of course to be able to chat with everyone I know with all the bells and whistles -- OTR-support, offline messages, synced history where desired, file transfer. It's an odd twist of technical history that we're not there yet.

It doesn't feel like we've moved backwards. It feels as if we just remained in the stone age of instant messaging. Even Google who pretended to be the "white knight" of IM, betrayed everyone by dropping XMPP federation in Hangouts and by not opening the Hangouts protocol.

I personally just use XMPP. I don't care about 5+ walled garden services and I'm not interested in proliferating them any further by participating. If my contacts aren't on XMPP - I simply don't communicate with them through IM. There is always e-mail for such cases.

If any other open and better successor to XMPP will come along - I'll consider switching or using it in addition. But so far there is simply nothing else out there.

Even with xmpp a helluva lot of those networks just aren't secure.

Security issues come on top. But interoperability comes even before, hindering basic ability to communicate.

Can you elaborate/point me to a resource?

I think this may be related to how it has proven difficult to be able to maintain a persistent, decentralized identity online.

The centralized "make an account with us" approach lends itself towards monopoly centralization of every service - once a critical mass is on-board with a single service, they get led into path dependency with the others. That's how Google, Facebook, et al. have been able to creep into every aspect of identity.

The only protocol I can think of that has bucked this trend is IRC, which has moved from a "few big networks" model to a bevy of smaller ones since the mid-2000s. Identity persistence there is secondary to community persistence, which may account for the difference. All the centralized services rely on being acommunal - a single giant network on which anyone may reach anyone. And with acommunal spaces, there is a strong "free for all" aspect that puts trade and monetization in the dominant position - which, besides the monopolistic aspects, leads to spam, identity theft, sockpuppeting, et al.

There is, perhaps, a model for reversing the overall trend through the community-persistence method; an entire community is harder to fake, thus it produces much stronger guarantees about identity.

For the first few years, IRC was one big network. In those days anyone who wanted to and had the resources could link their own server to IRC, so it was essentially a federated model.

If Apple had kept their promise to "open" FaceTime, I wonder if things would be different. Imagine being able to open a Hangouts session with anyone in your contacts who has an iPhone (without them installing Hangouts for iOS). Imagine if the Hangouts protocol had been released, then I could keep my strange bitlbee setups and have my messages anywhere.

I think it's probably time to move on from XMPP, but you really need Google, Apple, Microsoft and WhatsApp in a room together thrashing out something that'll work for everyone. I can dream, right?

Apple couldn't open up Facetime due to Patent threats.

I've seen this explanation in a few places and while I don't discount it entirely, I find it difficult to believe it's the sole factor at play; primarily because of the dearth of other third-party accessible services that build on AppleID (CalDAV and IMAP/SMTP are the only ones that come to mind).

What is he benefit or point in Facebook or Google doing interop with other IM systems? Interop seems like a desperate last-chance measure when you realise you're losing users.

I don't think there's anything technical involved. Unless spam is considered a technical problem, but denying federation seems to solve that problem considerably,

This is a purely business perspective, completely dropping the interests of the user.

All older communication companies (providing e.g. phone calls, fax, SMS) have working, interoperable systems that work on a global scale for _any customer of one company to any customer of another company_. By using a globally unique number.

It is, quite frankly, a disgrace that we now run around and find excuses for companies to re-introduce closed networks on a medium that provides working low-level routing on a global scale for almost all connected parties already. We're talking short messages here. I went back to SMS because of all this bull. Not even iMessage. It works. With everyone. Everywhere. Without installing something.

From a users perspective, the current situation is horrible and a huge step back.

I couldn't care less about what the benefit for Google or Facebook is.

>This is a purely business perspective

Yep, pretty much. Do you expect multi-billion dollar companies to do something just because it sounded nice? Acting like that only works if they can get enough users onboard to commoditize the service. IM is far from that point (see the rise of new messenger apps/networks, decades after the first ones). These companies want their users inside their apps as much as possible.

Not to mention, allowing federation doesn't help the vast majority of their users, who are on other closed networks. So for it to be relevant, two networks need to interconnect. Without any solid reason or threat, why would they do that?

SMS BTW is a rather crappy example; I don't think I've ever used any other service that was so unreliable, slow, and expensive. And the only reason you have competition in many companies is due to the government coming in and breaking things up or allowing competition. Even today on phones, various companies are still doing their best to create lock-in or jam users, by, say, charging ridiculously high prices to call into their networks.

If SMS is crappy for you, just take phone calls. There is still jam-in, yes, but you can mostly find a cheap phone connection from any place in the world to any other. I regularly call cross-continent and with some googling, you get a decent rate.

The point being: the system is there and there is competition that drives the prices down.

Also, I don't believe that for a "vast majority of users", federation doesn't matter. Everyone I know uses multiple messenger apps on their phone _or just use SMS_. SMS is the base line.

This is a failure of a model. Sure, Google has no interest of federating with Facebook. What this leads to is the aforementioned silos of peoples communications. "How do I contact this person? WhatsApp, Facebook, Twitter DM, Jabber, Google Talk, jadajadajada?

The only thing that comes close is email.

No, I don't expect multi-billion dollar companies to do something that sounds nice. Which still makes the model as a whole a failure. Obviously, multi-billion dollar companies cannot be trusted with providing reliable and easy reach-ability on a global scale.

>The point being: the system is there and there is competition that drives the prices down.

Eh, not really. Many countries still use the state-run monopoly. Connecting to them has a specific price. The demand for calls into their country is more-or-less fixed, and will remain so no matter the price. If you're seeing a price much below the actual price, then it's due to someone doing some illegal maneuver, such as sticking their cell phone on a VoIP system. (Despite it being illegal, I applaud such efforts.) Even for countries that aren't run like that (Europe?), prices can be well in excess of $0.20 a minute. The price to the receiver of the call is $0.00 so perhaps that limits competition. Some places even put an international tax on all calls, so that calls from outside the area are forced to pay more. Some places do the inverse.

Do you have info on people that use SMS across countries? For many countries I've seen, the price-per-message makes it a true last resort. (Inside the US or inside EU, this may not be an issue.) This makes WhatsApp so useful.

Do you have a real proposal, or is this a "it'd be nice if our government helped some companies build and run an IM infrastructure for very low cost for us"?

When telephone started it was like that.

until regulation... which allowed Bell to buy everyone else and integrate everything.

So? pick your poison?

Sure, pick your poison. (although I couldn't care less about Bell, being from Europe and all)

But be aware that said regulation allows us to make emergency calls reliably in the case of an accident and then quickly talk to loved ones on the other side of the globe by hitting 10 buttons on a device everyone understands.

Also, the same regulation enables TCP to work on a global scale, allowing me to post this very message on a message board hosted somewhere on another continent, probably passing through the infrastructure of more than 3 multi-million dollar companies actually being in the business of compatibility.

Given the choice between all instant messaging services closing shop or the a breakdown of the phone system, I know which one I would pick.

TCP is a good point... anyone have more information on how that worked? I always assumed it was free market.

ARPA used TCP and the whole thing got build from that. Non-TCP for local network was quite usual for a while (eg. IPX). But to connect to the existing internet, you had to speak TCP. After the internet "won", switching to TCP for local networks as well just made things easier.

Goodwill? I don't think it's really a "desperate last-chance measure", so much as a tool. FB and Google both offer a lot of other services beyond just chat. FB offers photo sharing, the newsfeed, potential for correct address books (at least with people that share that info with their friends), event organizing, games. I'm not that into it, but I know a lot of people that are. Then Google offers Google Mail, Docs, Hangouts, Calendar, Drive. I think they have their own image sharing system (I don't take many photos, so those features are nearly useless to me). Their chat protocols are more of a side-effect of having something already associated with your identity. Opening them up to federation likely won't cost them many users (and those users it does cost them will likely be as inactive on all their other services as I am), but has the potential to gain goodwill and endorsement from other circles (particularly those people that others -- family, friends -- go to for tech advice).

What's the benefit of gmail interop with other email systems?

Email has too much momentum to ignore? See Facebook's messaging - they're happy to ignore and cut off email. If they get away with it, it's a huge win. If it looks like they're not gonna get away with it, then they reverse decision and talk about opening up or whatnot.

I don't believe that it's clear at all that Google, FB, or Skype would win by opening up their systems. The best we're likely to see is alliances, like FB+Skype. Unless a service is in a losing position (like BBM), what do they gain?

I don't think you should be downvoted. You raised a valid point and people are downvoting you because they are disagreeing with you. I think pg should clean up downvote abilities for people who do this often via moderation. Like moderators should see a list of people who downvoted what and just one click nuke their downvote privileges.

Obviously I don't think I should be downvoted either since it's an accurate comment. :) But I am quite fine with moderation working the way it does - it'd be better than arbitrary moderation "nuking" privileges.

A model where certain threads are curated and used to measure how valuable someone's voting is might be helpful in weighting votes. But that sounds like a lot of work for probably little reward.

I'm OK with less downvote privileges in general, the community would benefit if there were less downvotes all around.

Meta-moderation on /. was like this. Moderate the moderation, if it was deemed fair/appropriate then you were more likely to get to moderate again later. If it was deemed unfair/inappropriate you were less likely to receive mod privileges.

The mobile industry body GSMA's Rich Communications Services (RCS) initiative seems relevant in this context.

"joyn services enable customers to chat and enrich messaging or voice calls by exchanging images or video simultaneously during calls, in a private and secure manner, with any member of their contact list that has joyn, regardless of the user’s network or mobile device. Additional services such as voice over IP (VoIP) or IP-video call will be introduced in the near future. These services may be used on both the operators’ mobile networks and on Wi-Fi networks." (Source: http://www.gsma.com/newsroom/spanish-mobile-operators-launch...)

http://www.gsma.com/futurecommunications/rcs/ http://www.joynus.com

on text IM, google did an old microsoft bait and switch. Everyone moves to gtalk, it is open XMPP, except that it is not anymore. sorry.

then came video and skype got everyone back to square one. but they were more worried about being bought by microsoft so they lost the mobile integration with phone numbers, and a bunch of others and made the "facebook deal" with their users. give us access to your phone number and contact list and we cross that. privacy for convenience. And everyone loved.

> a bunch of others apps

damn mobile typing.

It does feel like we have moved backwards. To go off topic a bit I think the social interaction aspect of net has become quite central atleast in my computer usage and it feels strange that it's hard to express across applications that this person is the same pseudonym and I am very interested in contacting him but don't really care via which protocol it happens. Now we have systems build around files and maybe pipes, but there should be global metaphors for the 'who'. Who are you trying to reach, who did this file, who could read this.

I would add webRTC to that list. powerful in desktop environments, poorly supported on mobile. at least as far as I have seen.

What is the state of power saving related XEPs which are critical for battery life on mobile? Looks like nothing is moving anywhere. For example XEP-0273 is still deferred:


I'd worry about this even before anything else when it comes to XMPP on mobile, since otherwise your client can be a hungry monster eating up your battery in no time.

The main problem with energy saving are short-living NAT session in the "carrier grade" NAT systems deployed by mobile ISPs.

You need to ping the server aggressively to prevent a NAT timeout from killing your connection. On most networks, ping intervals of 15 minutes are sufficient, but some ISPs seem to be brain-dead enough to kill TCP connections even earlier, enforcing additional load on their own networks.

However, it is hard to make a proper guessing algorithm to estimate the time between ping messages, so most apps hard-code it. yaxim is using 15mins and hoping for the best. Xabber is working with 1min (or 30s, not sure), Google's cloud connection is using a similarly low interval.

How is IPv6 deployment going in the mobile networks? That could solve all these NAT problems.

Zero deployment on the networks I have access to. Also I would not be surprised if the carriers manage to break permanent connectivity there with stateful firewalls.

T-Mobile deploys IPv6 exclusively to Android devices with 4.4 (Kitkat): http://www.dslreports.com/shownews/TMobile-Goes-IPv6-Only-on...

I'm on the edge of my knowledge here, but your might look at the MQTT protocol [1]. Facebook uses this for Facebook Messenger [2].

MQTT, I believe can solve part of the power issue, as well others. However, I do not know how easy it is run XMPP over MQTT.

I've been evaluating this internally at my company as we explore M2M (machine to machine) communications in mobile.

[1] - http://mqtt.org [2] - http://mqtt.org/2011/08/mqtt-used-by-facebook-messenger

Interesting, but it requires an overhead of routing one high end protocol (XMPP) over another one. Not sure if it's the best approach. XMPP itself can offer mobile optimizations (like the XEP I brought above), but for some reason the whole thing seems stalled.

XMPP is XML, which is most probably sent over TCP. I think if you had a XMPP to MQTT gateway this might solve the "last mile" for XMPP and power.

It still looks more like a workaround rather than a straight solution. I.e. chatty nature of XMPP is masked / mitigated with MQTT. A proper way is really to reduce the chattiness of XMPP itself in cases when it's needed.

Why would anybody want to use XMPP with mobile anyways? The protocol is very noisy and as a result it will keep turning your radio on/off in the background, effectively killing your battery.

Why would anybody want to use XMPP with mobile anyways?

Anyone with an Android-device is already using it. Android's push-notification depends on XMPP to work, and Gtalk/Hangouts is already piggybacking on that, making it a free ride.

So, unless you are on the patent-troll side of mobile, you have no reason not to use it.

Are you sure about that?

http://developer.android.com/google/gcm/index.html talks about using XMPP upstream but I thought the protocol to talk to the device was a lightweight proprietary thing.

It is. I talked to one of the devs a few years back, and he explained how they used [Protocol Buffers][1] internally, because XMPP just didn't work at their scale.

XMPP is a protocol that Google uses in some instances to talk to the rest of the world. But inside their ecosystem, they have no reason to stick to it.

[1]: https://developers.google.com/protocol-buffers/

>Android's push-notification depends on XMPP to work

Do you have a source for this info?

In the early Android versions (pre 1.0), the Android API actually included XMPP methods. I also remember reading debug messages containing "XMPP" in the function names related to GCM. These are just hints, and the protocol might have been changed since then, but the GCM uplink feature also indicates that it still at least relates to XMPP.

Not any hard reference-data, but whenever I am on a network where Android-push notification doesn't work, it seems to be because the device cannot connect to talk.google.com on the regular XMPP port, or at least so I seem to remember my logcat telling me.

Note: I've observed this without being signed into Google Talk or Hangouts.

The point is precisely to make XMPP work with mobile. There's no fundamental reason why this is impossible, it just doesn't work very well now. Of course if it is tweaked to work on mobile, well, it will work on mobile after that.

WhatsApp is using a customized version of XMPP: http://en.wikipedia.org/wiki/WhatsApp

a good client is not really noticeable in battery life for me. have you even tried it or are you just spreading FUD?

I don't deal in the iOS ecosystem, but the fact that the only way to get data to the device using push is insecure is just pathetic.

In a perfect world, the public would care. Instead, we scream into our own echo chamber.

The public cares that their battery lasts longer since there's only a single persistent network connection.

The public doesn't know. In a perfect world the public would had make choices which would lead everyone to open platforms, away from walled gardens, but as we don't know how to pick up leaders, most of us don't understand how and why privacy works.

iOS 7 supports background wake-up-and-do-things for apps, so this problem is actually solved now.

Would you care to elaborate? The only thing I found in the apple docs is that calling your app callback is a "best effort" service not guaranteed to do anything if your app is not running already.

An interesting thing is the Push Notification system used by Firefox OS which does not maintain a connection with the server like Android or iOS, instead the carrier has a notification server so that when you send a push notification, the carrier sends a signal to the phone and awakes the app.

Making IM apps that don't need to keep a connection open is a great way to reduce battery. This way whenever you receive any message the carrier pings the phone, the app awakes and open the connection to retrieve the messages.

More info at https://developer.mozilla.org/en-US/docs/WebAPI/Simple_Push

I am sure that this can be used to make a XMPP client that makes good use of the battery by only keeping the connection open while people are talking and effectively closing it once the chat goes idle.

As I wrote, it is hard to keep the conversation private in such an offline+push context. On the other hand, the additional battery load induced by a properly implemented XMPP connection is low. Apple's main fear is probably badly designed apps which really drain the battery.

iOS user here. I have Colloquy Mobile, with a backend of ZNC/Bitlbee, which bounces IRC and various IM protocols to my phone.

But it's by no means a layman's solution...

I'd be interested in hearing a bit more how this works... I currently just use tmux on my server instead of an IRC bouncer. And this is the first time I have heard about Bitlbee...

Does that require your mac to bounce the messages to you?

Nope, ZNC has a colloquy mobile bouncer: http://wiki.znc.in/Colloquy

no, you can do push notifications from linux.

(my friend wrote some push stuff for ZNC to his iOS irc client - which I use.)

I suspect some companies don't implement XMPP because it's too complex for simple messaging with very little upside. For a startup why worry about potential future interoperability with Google services(?), which would add months of engineering to get things right? YAGNI.

Layer (http://layer.com) is building a successor to XMPP that's optimized for mobile and solves device coordination problems. The inventor of XMPP, Jeremy Miller, works there.

This looks interesting. I looked at their site and documentation for implementing a client (once they are up and running). Do they provide any other information about their goals? Do you know if they have a goal to let anyone run a Layer server with interopability like xmpp does?

For me the worst thing was the way it handles multiple devices -- AFAIK when there are few clients with the same priority connected, the server delivers messages completely arbitrarily, usually only to a one of them and based on some crazy criterion like the last connection time; not to mention that the context is always lost. I ended up using SSH client and irssi :(

My experience has been:

* Google: Delivers incoming messages to whichever client most recently talked; occasionally 'resets' and delivers messages everywhere until a client talks again.

* Facebook: Delivers incoming and outgoing messages to web client; incoming messages only to XMPP clients (i.e. no outgoing message sync); occasionally outgoing XMPP messages are never sent or recorded at Facebook (this seems to happen and then stay a problem forever), resulting in your messages being silently lost.

I don't like that most of the XMPP client on Android are presenting the roster of contacts instead of my conversations I'm currently having. Those are important to me. That is why I prefer systems like Hangouts or WhatsApp.

So most XMPP clients looks odd for me, they try to look like desktop clients. Which doesn't work on Android I think.

Maybe someday I'll be able to use my iMessage-to-XMPP scripts to communicate with several devices instead of just my Android phone.

And maybe someday I can build a bridge between FaceTime and XMPP once all the media protocols get sorted out.

It may currently be a sad state, but it's exciting to see the direction things are/can be going.

As we move to mobile platform, privacy becomes more and more exotic.

When we were developing a messaging system for our app, we looked at XMPP, and it wasn't a hard choice to not use it.

As it's meant to be a constant-connected protocol, it's a poor choice for mobile. But beyond that, the various plug-ins are overly complicated, difficult to configure and most of the existing servers are "black boxes" that tend to not be easily hackable.

It was easier to make a chat protocol over HTTP from scratch than scale XMPP. YMMV.

I remember a post mortem for XMPP/jabber from 5 or 7 years ago. The author described what went wrong and the title was something like "the state of xmpp and why it's dead" or something.

Does anyone here remember that ? I have been looking over the internet but my google-fu failed me and I really wished I could read it again.

"If we can manage that, we can also convince all the users of WhatsApp, Facebook and Google Hangouts to switch to an open protocol that is ready for the challenges of 2014."

Not sure if serious. Let's hope not.

It was tongue-in-cheek, though my agenda is to make mobile xmpp as reliable and user-friendly as the proprietary apps.

Can you elaborate your reasons for hoping I'm not serious?

IIRC, Facebook Chat was using XMPP but switched to MQTT. Not sure if it has changed since.

Disclaimer: I could be completely wrong.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact