4 ms·

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

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.

michaelchisari 16y ago
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/_documentation/quicksocial.txt 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.
- imaginator 16y ago
  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.
  - michaelchisari 16y ago
    Right now, all requests require a callback with a token. user a@a.com sends a request to b@b.com with a generated token. b@b.com then sends a verification request back with that token to a@a.com, and a@a.com sends back true, and b@b.com 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.

michaelchisari 16y ago

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/_documentation/quicksocial.txt 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.

imaginator 16y ago
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.
- michaelchisari 16y ago
  Right now, all requests require a callback with a token. user a@a.com sends a request to b@b.com with a generated token. b@b.com then sends a verification request back with that token to a@a.com, and a@a.com sends back true, and b@b.com 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.