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.