Diaspora ported to use buddycloud channels and XMPP | Hacker News Reader

Diaspora ported to use buddycloud channels and XMPP

buddycloud.com

64 pointsimaginator19 comments

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.

Holding a socket open on a mobile costs nothing. Sending data through that open socket will quickly jump the phone into DCH state (http://xmpp.org/extensions/xep-0286.html#sect-id115219).

Polling is worse.

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.

The announcement on the mailing list has some more narrative: http://groups.google.com/group/buddycloud-dev/browse_thread/...

keep in mind that this is still early code. pretty much like diaspora. But it's awesome that you start with your xmpp friendlist right away!

XMPP seems like a very bad choice unless you need it for interoperability with other systems.

I'm ignorant to what XMPP is (aside from it being an XML-based messaging protocol). Could you enlighten me as to why this is a terrible idea?

To someone like me of minimal intelligence and experience, it seems to be a reasonable (and kind of clever) choice.

Thanks in advance.

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).

Good for BuddyCloud, but doesn't OneSocialWeb have an XMPP protocol already? Is BuddyCloud the same thing?

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.

It still appears to be very buggy. Many non responsive scripts

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

And trying to log in with Opera doesn't work at all

> Be gentle — it's a work in progress and running on a very small machine.

I'd be surprised if they had anything more than an experimental install right now.

awesome!

Reply on news.ycombinator.com