Shared publicly  - 
 
Some insightful comments on Google dropping XMPP for Hangouts.
 
Google defends dropping chat federation with inaccurate and misinformed comments on the underlying protocol (XMPP) and blaming others for not joining.

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.
20
4
Ivan Averintsev's profile photoTorsten Kleinz's profile photoAlexander Terczka's profile photoAndreas Proschofsky's profile photo
10 comments
 
Es mögen zwar nicht die Schwergewichte der IM-Branche XMPP eingebaut haben. Aber dafür haben viele, die vorher keinen IM-Dienst hatten, plötzlich XMPP. Sogar GMX und Web.de. Mit denen zusammen kann man AIM, ICQ und Co obsolet machen. 
Translate
 
BTW: Wird XMPP nur in der Client-Software oder auch auf den Google-Servern deaktiviert? Können Google-Nutzer sich auch weiterhin mit einem XMPP-Client einloggen?
Translate
 
+Torsten Kleinz Wird nur im Client deaktiviert, am Server soll es aber weiter laufen. Hab gerade einen Test von Hangouts in den Startlöchern, wo ich näher auf das Thema eingehe, ist nämlich leider alles nicht so einfach, wie es klingt. Insofern nur kurz: Derzeit heißt die Wahl realistisch entweder Hangouts ODER Drittclient mit klassischem Jabber, beides nutzen zu wollen führt zu jeder Menge unerfreulicher Nebenwirkungen.
Translate
 
+Andreas Proschofsky Die Wahl ist für mich einfach - XMPP. Hangouts mögen für viele Zwecke supertoll sein. Aber ich will in den meisten Fällen grenzüberschreitende Textkommunikation, die nicht die Aufmerksamkeitskanäle mit nur einem Gesprächspartner verstopft. :-)
Translate
 
+Andreas Proschofsky der google Talk (XMPP) Server funktioniert noch und der Talk-Server kann auch noch "federations", aber die Funktionalität leidet bereits. z.B. Gruppenchats funktionieren nicht mehr zwischen Talk und Hangout-Usern.
Als Android User kann man noch durch "deinstall update" den hangout client entfernen und talk zurückholen. Aber wie lange noch? 
Man sollte herausstreichen, dass durch das entfernen von XMPP die Anzahl der möglichen Gesprächspartner stark gesunken ist. Hangout ist für mich zu Talk wie "Facetime" zu Telefonie.
Translate
 
+Alexander Terczka Aber eben nur für Power user. Alle anderen waren schon immer auf Talk beschränkt. Ich habe mal versucht, Talk und GMX zu verbinden. Das Ergebnis war sehr bescheiden. Nachrichten kamen gar nicht oder verzögert an.
Translate
 
+Daniel Rose interessant; gmx hab ich nicht; ich habe talk zu @derstandard.at, @mail.at, etc benutzt und das war schneller als SMS. Ich hab damit z.B. Fehlerbenachrichtigungen und eine "Alarmanlage" implementiert.
Translate
 
+Alexander Terczka Ich weiß ;) Das Hauptproblem seh ich im Alltag eigentlich daran, dass Hangouts ein "Always-On"-konzept hat - und dieser Status mit dem XMPP-Server verknüpft ist. Die unangenehmste Auswirkung davon: Wer bei Hangouts auch nur irgendwo eingeloggt ist, wird allen anderen Jabber-Kontakten dauerhaft als online angezeigt. Kontakte lässt Hangouts aber nur von Google-Kontakten zu, versucht wer externer eineN zu kontaktieren gehen diese Nachrichten (so nicht noch wo ein Dritt-Client läuft) schlicht ins Leere. Das ist schon ziemlich massiver Fuckup.
Translate
Translate
 
Ihr habt ja recht, aber das betrifft einen für Google offensichtlich vernachlässigbar kleinen Benutzerkreis. Von daher nicht: epic fail. Genauso wenig, wie es Otto Normalverbraucher interessiert, welche Android-Version er hat.
Translate
Add a comment...