Today we’re releasing a dev-preview of buddycloud and would love your feedback.<p>buddycloud is an extensible open source distributed social network. A user’s identity looks like user@domain.com and users share content in "channels".<p>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.<p>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.<p>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.<p>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.<p>Next tasks: client speedup using IndexedDB. Following permissions, Android, iOS and Firefox OS clients and release buddycloud.js.<p>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
Simon (<a href="https://demo.buddycloud.org/simon@buddycloud.org" rel="nofollow">https://demo.buddycloud.org/simon@buddycloud.org</a>) from the buddycloud team here. Happy to answer any questions about the bc architecture or our approach.
Very nice, from a quick look this looks closer to my design sketches for an open social network than the earlier contenders.<p>It wasn't entirely clear from a quick look at the wiki: What is postgresql used for? Metadata on media? How is authentication handled?<p>Apologies if I overlooked some obvious documentation (I confess I haven't looked at the code).<p>Are there any good comprehensive design overview documents?<p>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)?
Great idea. Wish the project much success. Once it is further along, my startup will give this product a shot -- in particular the java server integration is of interest to me.<p>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 one luring problem with these distributed social network sites are the transparency with the target audience and its creators, most of your most potential audience is not going to care much of how the backend is constructed, rather your users will focus on the design of the app and what they can see, the field of distributed networks is an interesting one and wrangling with apis and libraries is where I feel web programming will be heading for a long time, good luck in your distributed/startup endeavors!
With secushare security is one of the starting points. Simply having a distributed network doesn't mean it would be secure. If authentication and access management isn't done correctly, distributed network could be real security nightmare.
See: <a href="http://secushare.org/" rel="nofollow">http://secushare.org/</a>
> ... <i>a magically simple way.</i><p>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.