Ralph Meijer - Google+ - Google defends dropping chat federation with inaccurate and…

Apparently, all the of the (good) sentiments behind the reasons for choosing XMPP as the protocol for Google Talk (https://developers.google.com/talk/open_communications) are no longer the driving force behind the decision making regarding its replacement Google Hangouts. All that talk about Client Choice, Service Choice and Platform Choice has been replaced with "if the other big players don't play, why should we?". So all those "thousands of other ISPs, universities, corporations and individual users" Google Talk used to federate with are no longer important.

On top of that, XMPP is blamed for not keeping up with the times:

"When XMPP was designed, smartphones and social networks didn't exist. Yet both trends essentially transformed communication but the standard remains unchanged. For example, mobile has several requirements around bandwidth and battery that are simply not part of the standard. And audio and video integration are not well defined," [a Google spokesperson] said.

This glances over the the fact that the X in XMPP stands for eXtensible, which still results in proposals for new protocol extensions every month. The XMPP Council, which I am currently serving on, watches over XMPP extensions in the XEP series (http://xmpp.org/xmpp-protocols/xmpp-extensions/) of the XMPP Standards Foundation. However, as XMPP is built on distributed technologies, everyone can invent their own protocol extensions in private, too. Something that Google should be fully aware of, as they have created a bunch of their own protocol additions, of which some are documented here: https://developers.google.com/talk/jep_extensions/extensions.

To go into even more depth, at various times, battery and bandwidth constraints for mobile use, have been discussed within the XMPP community at several times, since at least in 2008 and possibly before, with protocol proposals like Roster Versioning (XEP-0273, now part of RFC 6121), SIFT (XEP-0273) and background information on XMPP on Mobile Devices (XEP-0286).

Meanwhile, Google never participated in any of these discussions (https://plus.google.com/116276248303121270590/posts/V7LzUzj8R4D). Instead, they invented their own protocol (google:queue) for delayed presence delivery, much like but slightly simpler than what SIFT proposes. Had Google just participated, that protocol had likely been remade into a true XEP, for broader use in the community. This would have prevented, for example, Facebook, from also creating its own protocol for the same thing (https://bugs.freedesktop.org/show_bug.cgi?id=38943).

Of course none of these concerns for mobile are applicable for server federation. As far as I know, the Google Talk client on Android doesn't even use XMPP as the client-to-server protocol.

Google did cooperate with the XMPP community on standardizing Jingle (http://xmpp.org/extensions/xep-0166.html), a suite of protocol extensions for initiating and managing peer-to-peer media sessions between two XMPP entities. Ironically, this includes *audio and video integration", the very thing Google now says is not well defined, where Google was by far the largest driver behind it. And then Google Talk also never fully implemented the standardized protocol, causing other implementations to add custom, non-standard, workarounds.

Likewise, there are several proposals and even IETF drafts (for enhancing network security, including spam prevention, that Google didn't bother to implement. As an example, whereas as many other server operators would have wanted to start verifying X509 certificates on the TLS encrypted connections between servers, Google still doesn't check certificates or serve up properly signed ones themselves, allowing rogue servers to come in play.

The XMPP community even tried to accommodate some of the harder issues with serving up proper certificates for large numbers of hosted domains, explicitly including Google Talk, resulting in this IETF draft: http://tools.ietf.org/html/draft-saintandre-xmpp-dna-02.

From personal experience with building federated social networks on top of XMPP at Mediamatic Lab, I can name several other protocols that would benefit some of the newer features in Google Hangouts, including Publish-Subscribe (XEP-0060) and the related Personal Eventing Protocol (XEP-0163), that Google just ignored.

How didn't the standard (XMPP) change again?

As +Peter Saint-Andre was quoted in the TechHive article, we will just move forward.