Wednesday, June 26, 2013

How Google pulled the plug on the public Jabber Network

I know I'm late but I still can't see this part of the deal showing up...

So, it's no news that Google first disallowed new s2s connections, then started their own protocol, which has no s2s connections at all.

With that, the largest node of the public Jabber network went down, incorporating the largest share of its users. They're pointing to spam:

Chee Chew said that "we haven't seen significant uptake" in federation with Google Talk via server-to-server connections. The majority of the uptake Google did see was from organizations or individuals looking to bombard Google Talk users with chat spam

By assigning
server identity as a hostname, servers are also able to route data
directly to each other and their connected clients, thereby creating
a new, inherently open IM network out of all the individual
installed servers and clients.

There is no open IM network anymore: we have some walled gardens supporting the XMPP c2s protocol for easy access.

For years, I've been dreaming - and trying to get funds - for a mail system competing GMail, but being compatible with it both in e-mail and IM - that's not possible anymore.

I was urging Hungarian e-mail providers - some of them providing their own XMPP implementation - to allow external IM connections between each other and gmail - that's not possible anymore.

The open network of communication won't be brought by XMPP, that's for sure.

Jabber failed to provide good enough spam protection, failed to provide a scalable protocol, failed to provide easy transfer of accounts between providers (if I change e-mail address, I don't have to re-add all my friends, it's enough to set a simple forward or inbox pulling - that's not true for Jabber IDs!)

Besides, no matter what was the dream, it turned out, the complexity is mostly on the client side, and that IM networks are inherently complex. We had a lot of clients able to transfer basically text-only messages. Not even files.

Also, given the fragmentation of the community - it's not a product, it's a protocol community somehow - Jabber failed to gain developer interest it seems - instead of Jingle, the way for A/V communications seems to be WebRTC now.

For message broadcasting and queing, there are a lot of protocols available. XMPP is one of them. For me, XMPP was an open protocol and network for human-to-human communication, and it seems it has failed its mission. It's only used as a fallback protocol for IM clients.

'm sorry, but saying that Jabber/XMPP was somehow technically "insufficient" is utter bollocks, given the inherently extensible (ie the 'X' in XMPP) nature of the protocol.

Many of the deficiencies Google mentioned were Google's fault, as they didn't implement features already defined. Where there was a genuine lacking feature they could have proposed a new one, not unlike what they already did with Jingle (ie the video/voice protocol). Indeed, saying XMPP's video/voice features were lacking is funny given that Google was the original designer of those features.

As for Solomon: The X in XMPP means in practice that you can send arbitrary messages and arbitrary parts in already existing messages and the other side either understands it or it does not. Mostly, its' the latter case.

Just for a quick understanding, basically every messaging protocol which uses any kind of structured data to pass messages (wether it be HTML, or JSON, or even some binary formats) is extensible, provided the parser on the receiving side is not strict so it passess extended messages. It's like saying that you can use arbitrary characters in messages: everything can do that.

I remember when Nokia came to Brussels, begging XSF so that could be a more concise version of the protocol strictly standardized, as in, not part of a XEP, but more like a required protocol, RFC-style. I guess if I grab an XMPP implementation from 2005, it'd still work without modifications...

WebRTC is not a replacement for Jingle as far as I understand. It's not even a protocol - it's an API to enable any kind of protocol to be built and used through JavaScript in browsers (such as SIP over WebRTC, or Jingle over WebRTC and what not).

So WebRTC is a different level framework, and it's not correct to compare it with Jingle I think. Jingle over WebRTC is being worked on. For example:

A scalable, federated IM network with good MUC support has been under our eyes for 25 years. Hundreds (thousands?) of free software projects use IRC daily as a collaboration platform because there's nothing else good enough to replace it.

The protocol is to blame? Bullshit. The problem is and was lack of buy-in from providers (not using XMPP, or not using s2s) - a chicken and egg problem, and lack of sufficiently shiny clients that average users would want to use.