

Diaspora ported to use buddycloud channels and XMPP - imaginator
http://buddycloud.com/cms/node/210

======
moeffju
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…

~~~
axod
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.

~~~
dminor
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.

~~~
imaginator
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.

------
bobds
The announcement on the mailing list has some more narrative:
[http://groups.google.com/group/buddycloud-
dev/browse_thread/...](http://groups.google.com/group/buddycloud-
dev/browse_thread/thread/ee4fae4a143e38ea)

------
treffer
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!

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

~~~
ohyes
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.

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

~~~
imaginator
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.

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

~~~
imaginator
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.

~~~
Fahrertuer
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

------
orangeman
awesome!

