Sunday, May 19, 2013

Confused about Google and their XMPP advocacy

At Google I/O 2013 (15-16'th of May), Google announced that the new Hangouts are not based on XMPP as a messaging backend. 

The story was brought shortly after this announcement on theverge (http://www.theverge.com/2013/5/15/4318830/inside-hangouts-googles-big-fix-for-its-messaging-mess). At first I was a bit shocked, so I tried to dig a bit further down to what it means and what had happened.

Apparently it seems that Google did it to be able to control the protocol them self and to make all of their product interoperable and not the other way around???
Their claim of ditching XMPP for Hangouts, was also because they found their messaging landscape too fragmented and too messy.  They wanted to be in front of the development and have bigger market shares compared to IMessage (Messages), WhatsApp, Facebook Messagener etc. Ironically many of these services run on XMPP services (even though not federated one, which google did).

Google also claims that they tried to use XMPP to open up their infrastructure and federate with other XMPP implementation vendors, but that the other entities seems to be reluctant to do the other way around.. 
I would say that this deeply is a BIG claim - most vendors and big entities I know of, participates in the making of the core protocol and the XEP (extensions) - I haven't seen Google in a while involving them self in these discussions in the XSF (XMPP Standard Foundation) and the makings of the standards. We have an excellent XMPP community and a really open and friendly XSF, with a lot of meetings and discussions.

What I have seen of participation from Google, is twist in some of the extensions in their own little fuzzy way and not giving the changes back to the standards - which mean they claimed to use the standards, but where really not 100% compliant in some of the cases. Some things they added "secretly" to the protocol was good and some were bad. 


It's an open standard protocol, so participate Google!  And contribute not only to open source, but also to open standards which are becoming more and more important.


Back to the current issue. So what does it mean to the end users and other services? From a reliable source, Google is not making S2S support and limited client to server C2S, which means supporting by only doing ordinary chat and not group chat, file transfers etc. This basically means no federation from/to Google hangouts, which is a bummer!

For the end-users the coming years will bring an even more split market, confusion and walled gardens!
Google have drawn a line in the sand and you can either be on their side or on some other silo...
This will split many of the users. Some will be on Facebook, some on Google, some on whatsapps and what not. Each of their users will be locked in, into their according silos..

So what will be next, Google? SMTP/IMAP, HTTP or other open standard protocols? 
As an example; if google e.g. closed the IMAP access because they wanted me to use their gmail UI, I would be frustrated!. I have a lot of different mail accounts and I want my mail messages to be gathered in my own native client with IMAP. Even worse if the closed down SMTP I would not be able to route my mail around to other user outside of google - which is quite a good analogue to XMPP federation issue we got here!

So what can/shall we do about it? Well its not easy to come with a simple solution. For example what do we do with a "couple" of millions users coming from google chat? Do we get them on one single XMPP domain, e.g. jabber.org, FSF (Free Software Foundation) ? or do we encourage them to put up their own federated XMPP service at home?

The answer is not easy - I definitely think that we need some kind of bigger XMPP service provider(s) where all starters of XMPP can go and just fetch a new account. Setup a group chat (MUC), and do what ever they want. Not all newcomers knows how to setup their own domain and XMPP service - even though it is quite easy (I'll write a blog about that later!).
But setting up this service also comes with a price! Maintaining and keeping an XMPP server operational at a large scale for a long period of time is NOT easy! - you have to deal with spammers, black hats, 99.9999% uptime, strange client behaviours and patterns etc.
Even though we can blame Google for a lot of stuff, they still maintain(ed) the largest XMPP service on the Internet, and they do/did a good job for uptime and maintaining it. Even though I've had some problems with subscriptions and black listing form google - breaking the XMPP core protocol and specifications, but thats another issue. :-)

After reading a blogpost from Mickael (@mickael) : http://blog.process-one.net/google-cloud-messaging-update-boosted-by-xmpp/, I found some thing more funny and confusing.

Google announced their new backend for Google Cloud Messaging (GCM) which is based on XMPP..

So Googles claim about streamlining their infrastructure and interoperability really is confusing!.  
Reading up further on GCM (see http://developer.android.com/google/gcm/ccs.html), it sure looks like that it uses XMPP for persistent connections towards the client - sending JSON as a payload inside a message stanza.

"The GCM Cloud Connection Server (CCS) allows third party servers to communicate with Android devices by establishing a persistent TCP connection with Google servers using the XMPP protocol."

So besides hangout (which does not use XMPP anymore), their messaging backend infrastructure for Android, Chrome etc. is using XMPP for server push.

Hmmm confused about Google and their XMPP advocacy?.. I sure am!

Because this blogpost is written on blogger.com (google domain) I sure hope that you dear viewer, are able to view this post on HTTP and not only SPDY..