ShowHN: buddycloud, a distributed social network
buddycloud is an extensible open source distributed social network. A user’s identity looks like user@domain.com and users share content in "channels".
We started buddycloud because of the growing “closed-ness” of existing social networks. For example Twitter’s increasing API contortions about what one can and can’t do with their API or which quadrant one is supposed to operate in. We also think it’s important to build services against a known protocol that works against any buddycloud instance on any domain (not paid-for APIs). Naturally this called for a completely decentralised design built on open standards like Atom, Activitystrea.ms and XMPP.
Each buddycloud-enabled domain runs a suite of servers. Each buddycloud server uses DNS to find, connect, and sync content in realtime with other buddycloud servers. This content can be any kind of structured data or large files.
Today we are releasing open source implementations of the following buddycloud servers: the buddycloud-channel server (shares your channel / your activity stream with trusted followers), a media server (shares anything from a small avatar to a multi-TB file), a push-server (email and mobile updates), and a taste engine (“channels you might like”). Some of the team are working on more servers that will let you suck content in and out of existing social networks.
Our reference implementations are written in Java and node and use Postgres for storing data. The web-client is built on backbone.js. There’s also a console client written in Python.
Next tasks: client speedup using IndexedDB. Following permissions, Android, iOS and Firefox OS clients and release buddycloud.js.
We really hope that some of this could be useful for your project: - https://github.com/buddycloud - wiki https://buddycloud.org - demo instance at https://demo.buddycloud.org - channel https://demo.buddycloud.org/team@topics.buddycloud.org
40 comments
[ 6.6 ms ] story [ 107 ms ] threadRepos - https://github.com/buddycloud
Wiki - https://buddycloud.org
Demo - https://demo.buddycloud.org
Channel - https://demo.buddycloud.org/team@topics.buddycloud.org
I'm not sure that Diaspora has a defined server-to-server API or a client API (can someone more aware of their progress comment). On buddycloud Each domain runs an HTTP API server (https://buddycloud.org/wiki/Buddycloud_HTTP_API) that clients can connect to on their home domain (eg if you are james@giantpeach.com, you connect to something like http-api.giantpeach.com). And servers use XMPP to exchange between one another.
Then there is Tentd. I like what they are doing. I think their approach is that every user is a server (your id is http://me.domain.com). I'm not quit sure how they federate or resync messages when nodes go down. Can anyone comment on how they federate?
How do you decide who has access to what? Will it be somehow encrypted, so that only a subset of my contact list could get access to a part of it?
Would I be able to move all my data to a different server if I decided it is no longer trustworthy?
Think of the architecture like your email provider: You can always grab your mail spool and find a new provider. buddycloud is not dissimilar - just grab your posts and followers from the API and import them on a new provider. We're make this easier soon but, the data and endpoints are all there to facilitate it.
Good luck!
When asked about whats next for stella, nux was heavily focused on just getting his first dollar in revenue.
translation: Do not be a dick about other peoples stuff, especially when you have built things yourself which are less than noteworthy.
* http://li.nux.ro/stella/
Worrisome facts, yes. Potential problems and helpful strategies, yes. Discouraging opinion with nothing to back it up, no.
Facebook is a huge, ugly blob and we urgently need something to replace it that is not organized from the top down. Yay to buddycloud!
It wasn't entirely clear from a quick look at the wiki: What is postgresql used for? Metadata on media? How is authentication handled?
Apologies if I overlooked some obvious documentation (I confess I haven't looked at the code).
Are there any good comprehensive design overview documents?
I'd be interested in how much would be needed to (re)implement a stand alone version, running on a single technology for easy low-scale deployment (eg: running xmpp, mediaserver and api(?)-server all on top of nodejs, or via simple go-based servers)?
Authentication is handled by the XMPP server - Prosody, ejabberd, OpenFire, etc.
The XMPP protocol is documented on https://buddycloud.org/wiki/XMPP_XEP, and the HTTP API on https://buddycloud.org/wiki/Buddycloud_HTTP_API.
Right now if you want to use a single technology I think the best would be to use nodejs: the channels server and HTTP API are running on it. The problem will be the XMPP server (I don't think node-xmpp can handle that). The media server is written in Java, so a complete rewrite would be needed (but the media server is optional). And I'd love to see all of that in Go, but last time I checked its XMPP libraries were not usable enough for what we'd need.
And I wouldn't be surprised if there is a a large overlap between bitcoin-ers and buddycloud-ers. Encryption (Client to server connections are encrypted. Server to server connections are also encrypted.) And Decentralised. And built around a common protocol.
Is there a site for btc bounties? You (someone, anyone) could put time into that.
tl;dr
* find existing friends on buddycloud using other social networks as pointers
* post out to existing social networks
* give users a way to invite Twitter, FB etc friends in
* build a build a Facebook vacuum-cleaner that helps move a users existing content over (depending on API restrictions).
Whenever a module/feature gets completed, please consider creating short how-to docs/videos. This is a consumer oriented product, so friction to deploy should be minimal.
The java server (https://github.com/buddycloud/buddycloud-server-java) is nearly feature complete and being implemented by a company called Surevine who plan on using it for "enterprise" customers.
I'm sorry, but the only person who could plausibly pull off "magically" in a product description was Jobs. I would strongly suggest rewording this part so not lose people in the first 3 seconds on the site.
If a user can spin-up a hosted buddycloud instance on their domain, that's got to be useful for them.
This post has a more dev focus but we know that the look and feel and functionality for users is really important. To see what we are working on check out our prototypes that are now being incorporated: https://demo.buddycloud.org/prototypes/ and Felix's paperfold effect: https://developer.mozilla.org/en-US/demos/detail/paperfold-c...
o@buddycloud.org ;)