ShowHN: buddycloud, a distributed social network | Hacker News Reader

ShowHN: buddycloud, a distributed social network

73 pointsimaginator38 comments

Today we’re releasing a dev-preview of buddycloud and would love your feedback.

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

Clickable links to save you keystrokes:

Repos - https://github.com/buddycloud

Wiki - https://buddycloud.org

Demo - https://demo.buddycloud.org

Channel - https://demo.buddycloud.org/team@topics.buddycloud.org

Simon (https://demo.buddycloud.org/simon@buddycloud.org) from the buddycloud team here. Happy to answer any questions about the bc architecture or our approach.

Obvious question maybe but how does BuddyCloud compare to (and perhaps integrate with) Diaspora?

I remember another effort in distributed social networking, from some months ago. Forgot the name though.

http://tent.io ?

There's two three things that count when building a distributed social network: easy to use client APIs, Server APIs (how do servers find and connect, catch up, etc) and a reference implementation.

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 would my data (say status updates) be stored? On a single server of my own choice?

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?

The unit of sharing is the channel. You start with a personal channel user@domain.com and can create any number of new channels (holiday-photos@domain.com). Each channel has followers, moderator etc that you can control access to (or just set it as public): https://buddycloud.org/wiki/Channels_Explained

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.

Your profile page behaves weirdly when viewed on iPad. The scrolling is jerky and clicking the title bar doesn't scroll to the top like it should.

We know there are problems on the 1st gen iPad. Is that what you are using?

no, 3rd

Very nice, from a quick look this looks closer to my design sketches for an open social network than the earlier contenders.

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)?

PostgreSQL is used for storing channels (users posts, subscriptions, etc.) and metadata on media.

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.

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.

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.

Good idea. Thanks. We're also working to solve the problems by keeping the design as intuitive as possible. Media sharing should be just a question of dragging and dropping the file in to the channel posting box (we're going to work on this frontend bit next).

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.

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!

Agreed: we have to focus on two levels - users and devs:

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...

I've seen the paperfold effect a while ago, very nice , count me in as an early adopter, the non-distributed model works though and I dont understand why it is so frown upon among the hackernews circles. I for one care more about the frontend than the backend, in which both for buddycloud is nice, the team is talented

o@buddycloud.org ;)

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: http://secushare.org/

Excellent news, good luck and good progress. Good to see such rapid progress to this release !

Are any of my friends on it ?

So we have to solve three big problems: build a distributed architecture, build great reference clients, get massive adoption. We've almost solved two of those and have a team working on the third problem: https://buddycloud.org/wiki/K-Factor_Project

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).

Simon, great news! Things have moved along since our last talk at FOSDEM. :-)

> ... a magically simple way.

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.

I had been meaning to change that. Thanks https://github.com/buddycloud/webclient/commit/d7cc1f43103dd...

Any way you can make it more appealing to bitcoiners?

I like bitcoin: it started out as a protocol and reference implementation. That's what we are trying to do today.

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.

If you can add more encryption protocols in the future like OTR for chats, and so on, please do. But of course don't let this distract you right now. Your #1 goal now is actually get people moving away from the closed networks like Facebook, and I guess you can add more encryption/anonymity stuff later on. But it could be important to keep this in mind while you build the service up, so you don't need a major overhaul later to add them.

The difficult part is always key management: making a service that my mom can understand and manage and "just works". Our federation layer is built on XMPP. That gives us a pretty solid layer to extend chat and interoperate with gtalk and other chat services including video via Jingle.

Yeah, nice work. My own thoughts: you want to have people coming together to engage in commerce on buddycloud with btc as the preferred currency, like what paypal is to ebay. Maybe make the server appealing to install on bitcoin servers and have the network as the preferred way to discuss transactions and record a list of transactions and interactions.

Who is "you"? You, adrianwaj could make it more appealing to bitcoiners by offering some cool features. I programmed a bitcoin wallet for facebook (and never put it live as I fear handling other people's money) but of course, that's a cool feature. The users within one server could transfer coins outside the block chain at no transaction costs. Do it yourself or make a bounty for it.

It's not going to be me, haha. But they should put up a btc donations address.

Is there a site for btc bounties? You (someone, anyone) could put time into that.

How will you generate revenue?

Wordpress is free and open source - and help users that don't want to host their own blog with a simple way to host a blog on wordpress.com.

If a user can spin-up a hosted buddycloud instance on their domain, that's got to be useful for them.

Yet another thing nobody will use, but I guess at least it's a nice learning experience for the devs.

Good luck!

"Yet another thing nobody will use" said a active member of the incredibly popular centos remix, stella.

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/

First, calling someone a dick while being a dick yourself is not very funny at all. Second, it may be hard to believe, but I was not actually being malicious. I _really_ want one of these projects to succeed, but I've learned to hold my horses ever since Diaspora. Third, leave my Stella alone.

I second this. Negative opinion has no place here.

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!

Reply on news.ycombinator.com