> > | You should have a look at http://onesocialweb.org (fully XMPP based). > > 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 !
