You should have a look at just about everything on
http://groups.fsf.org/wiki/Group:GNU_Social/Project_Comparison
There's some good in each of those.
I agree that there are good ideas in each of these. However, I have not seen any in this list which aims at being exhaustive (e.g. facebook use cases). They all focus on very specific goals (e.g. OStatus on public microblogging). Did I miss any ? Could you say today that there is a decentralized alternative to Facebook ?
| Our approach supports both a hub&spoke model (intelligence and data at
| the server) and a P2P one (the end resource is where the stuff is),
But XMPP does not hide who is talking to whom. That is something
GAP and other F2F technologies do better.
But at which cost for the user experience ? It will be a key challenge to balance security and simplicity and will require tradeoffs. You can have E2E in XMPP if you want to, but it comes at a price. Most users today are happy with email on unsecure server and non TLS connections... the good thing is the one who needs PGP can do it.
| We also recognize the need for a lightweight HTTP based API and as
| soon as someone proposes a good HTTP based flow (and we are looking
| forward to the future Buzz API), we'll implement. So feel free to get
| in touch if you have ideas/feedback.
That's interesting how a file transfer protocol (HTTP) is seen as being
lightweight - even more lightweight than a protocol that was supposed
to be a messaging protocol (XMPP), a lightweighter job than obtaining files.
Both protocols have become over the top for what they were supposed to do
and neither of them is indeed lightweight.
Depends on your definition I guess. XMPP is statefull, and relies on a XML parser. Not straighforward to build your own server on raw sockets or to write in a language that does not support threading (e.g. PHP). This can still be done for HTTP.
Lightweight is when you can drop some data into a text template
and throw it into a UDP packet or an existing TCP stream.
Not much preprocessing. No unnecessary packet round-trips.
Lightweight isn't when you have a simple API. It's when the
protocols underneath actually do efficient things.
An identity and security framework is still required. If it is not part of the transport, you simply move the complexity to another layer.
And when it comes to true privacy, GAP is a most interestingly
architected protocol: http://gnunet.org/download/aff.pdf
It's not lightweight either, but it provides actual privacy, not
just encryption.
Will definitively have a look. As you said, there is a lot of good things to be learned from a lot of good projects !