This needs some frontend polishing for the script timeouts and stuff, but using XMPP for federation is definitely the right way IMO. Or, at the very least, much better than just making up protocols on the way, as Diaspora did. Federation and message routing have been solved…
FWIW, I think XMPP solves problems in a completely horrible way. It's ridiculously over engineered, verbose, needlessly complex, overly extensible to the point of absurdity.
It totally makes sense to create a concise, specific protocol to solve a specific problem when appropriate. Learn from the hundreds of mistakes that were made in the 90s and early 2000s when all this X* came out.
Actually the core of XMPP is fairly small - an XMPP server need not implement every extension ever conceived of. Given that it's widely deployed, solves the presence and federation, and is implemented in a wide variety of languages, I think the GP is right.
The only real nit that I see is with mobile devices - XMPP isn't great for low power low bandwidth situations.
Google keep the chat client open but have an option to hold back all but the most important packets on the server side and then batch send them after a set period of time. This is something along the lines of http://xmpp.org/extensions/xep-0273.html
The current nokia version of buddycloud (http://mobile.buddycloud.com) will run continuously for for about 18 hours. The android version with batch sending of packets even longer.
And if you worry about XMPP's verbosity, just add the DEFLATE option to your TLS socket. That drops the size down to about 10% of the original.
And diaspora solves communicating in a horrible was. No chat (but expect it to be XMPP based), no real time, horrible tunneling of wired stuff over http.
Besides that: Most users already have XMPP accounts with friendlists. I'm eager to see how diaspora will solve that problem.
It solves roster/presence and federation. The core of XMPP is pretty small; the extensions are numerous, but you don't have to implement them (if you're just using XMPP for the federation or as a messaging layer) for the most part. You also get the advantage of tried and true libraries for a lot of languages, which saves you from reinventing the wheel again. There are stable servers and usable clients to help you in development, and the documentation of the protocol is pretty good. Also using things like HTTP-Bind interfaces, you can basically use XMPP without keeping a connection open. All this flexibility has its use.
Unless you need
1. Chat
2. Friendlist (prefilled with your friends)
3. Realtime communication
4. Federation
5. Social (activity streams)
Diaspora fails on 1+2+3 and does a poor job on 4. XMPP needs implementations for 5 (spec and demo implementations exist).
Just like OneSocialWeb, buddycloud started out using XMPP's built in event stream. We found that this quickly ran out of steam for scaling and was too constrained to build a really good social system. So we pivoted and the new channel servers that are being built are all independent from particular XMPP server implementations.
The channel approach runs as a separate server instead of trying to build everything into existing XMPP servers. Decoupling the channel server release cycle (almost daily) from the longer release cycle of XMPP servers speeds development.
This is happening because it's having to pull down all channel posts instead of storing some of them locally. Not so ideal. A better approach will be to have backbone.js throw them into a local store.
It's mandatory I think. It's currently unusable on my netbook and less technically adept people tend to get scared from messages of non resonsive scripts, fearing the page is trying to download and install malicious code
