I think there's two issues with this, though. One, it's somewhat dangerous to have an incompatible fork so early on. Of course, the code is so immature that this may not be as big of a deal at this point.

The other is that I'm not sold on XMPP as the best protocol for distributed social networking. I think it can be overly verbose, and a simple protocol over HTTP/HTTPS makes more sense to me, and I've had good luck with that so far. That said, I'm not completely sold against XMPP, either.

There's two things here:

Protocol and the architecture. Protocol-wise I have no problem with http - it's well understood and any RoR dev can pick it up an use it. And indeed you could even, with a lot of work, build a federated network off http(s).

But http is not a a federation architecture. XMPP provides this out the box and makes bootstrapping a secure federated social network much easier.

I'm not talking about extending HTTP, though, I'm talking about a protocol over HTTP. My project uses a custom protocol called QuickSocial:

https://github.com/appleseedproj/appleseed/blob/master/_docu...

Although the software is protocol-agnostic, and hooks could be written to support XMPP, as well.

I think my biggest issue with XMPP (beyond it's verboseness) is that it requires a whole separate XMPP server. This is less of an issue for Diaspora, which already requires a series of services running, but for my project, Appleseed, the goal is to get everything running under a LAMP stack which can be run on any shared host.

Don't worry about the verboseness of XMPP - TLS with the deflate option drops that down to 10% of the original size. Or you can do what google did on Android and write your own binary protocol representation.

If I setup a new appleseed node and how do you really know it is me/example.com? I've yet to see that done well in http and would love to be proven wrong.

Right now, all requests require a callback with a token. user [email protected] sends a request to [email protected] with a generated token. [email protected] then sends a verification request back with that token to [email protected], and [email protected] sends back true, and [email protected] completes the request.

Which, if I'm not mistaken, is very similar to how XMPP does it.

The protocol also tries and minimizes the amount of actions that a third party node can take. You only trust your own node to take actions on your behalf.