Its creators claim that Diaspora is a “privacy-aware, personally controlled, do-it-all distributed open-source social network” — and maybe someday it will be. But there are more pieces missing than there are pieces in place, and Diaspora has a long and rocky road ahead if it wants to achieve even half of its stated goals.

To be fair, this is still a very early version of the software, and here and there it does offer insights into how Diaspora is meant to work.

The basic interface for a Diaspora user’s page, which is clearly based on Facebook’s.

The concept behind Diaspora is simple: Instead of interacting with a single, centrally controlled social networking service such as Facebook or Twitter, you set up and work with a “seed” — a copy of the Diaspora code running on a server you control yourself. It’s like hosting a copy of WordPress on your Web space to run your blog, instead of using Blogger or another third-party service.

Users on different seeds can friend each other, automatically exchange data (messages, status updates, pictures, etc.) and enjoy automatic end-to-end encryption of message traffic. They will also have rigorous control over how much information they share with others.

It sounds great in theory, but right now very little of this has been implemented in practice.

Diaspora’s building blocks

Diaspora is written in Ruby and uses a few non-Ruby pieces — the MongoDB database and the ImageMagick image processing library, for instance. The setup instructions favor Ubuntu Linux and Mac OS X, so rather than wrestle with my hosting provider (which doesn’t support MongoDB), I installed a clean copy of Ubuntu 10.04 on a virtual machine and set things up there.

The entire process, including downloading the Diaspora source and the needed support files, took about half an hour. Trying to set up an instance of Diaspora will be rough going unless you’re comfortable working with the command line in Linux and you know your way around Ruby and the Git source code version-control system.

Diaspora’s friend-management page. Friends can be dragged between the aspects you set up, which allows them to see different activity streams.

Once I got my own seed running, I created a few local users and experimented with the user interface. Every user can create and manage multiple “aspects,” which are a little like Facebook’s friend groups. When you assign a friend to one of your aspects, they see only what you post to that aspect. (It’s also possible to post to all aspects at once.) The message streams and conversation threads are blatantly Facebook-like, but that’s not a bad idea: Why reinvent a perfectly good, familiar wheel?

I also ran into a few bugs, which was expected. Some were innocuous, like the error message that you see when you click on your own user profile image. Others were a little more problematic, like the way users on the same node can’t see each other’s updates even when friended to each other.

Right now it’s not possible to do a whole lot with a Diaspora seed. You can post status messages and pictures to aspects, upload images to a gallery, write replies to other people’s messages, manage your own aspects and profile, and make friend requests from other Diaspora seeds.

And that’s about it, since most of the work at this stage is about infrastructure and not end-user features. Some of that laps over into user features, though, like the forthcoming ability to scrape or republish streams from Facebook, Twitter, Flickr and so on. But it’s clearly going to be a long time before the bulk of features added to Diaspora are of direct interest to regular users.

Problems to be solved

Right away, I can see several major problems with Diaspora that need to be addressed before its own creators can even think about promoting it as a social networking solution.

The first, and in my opinion biggest, is the lack of useful documentation. Diaspora’s behaviours and internal protocols need to be documented apart from the source code itself, so that others can create their own implementations — their own clients, their own Android apps, even their own Diaspora-integrated Facebook widgets — without relying wholly on Diaspora’s own code.

If the docs are out there somewhere, I can’t find them. (I had the same problem with Google’s VP8 video codec earlier in the year: the spec consisted of Google’s reference implementation code, which is never a good idea.)

Another potential problem is Diaspora’s component stack. Many hosting providers do support Ruby but few support MongoDB, which would make setting up a public Diaspora instance a lot tougher for your average Web host.

A third issue is that open-source social networking has been around in one form or another for a while now, even if its previous implementations haven’t been getting the same degree of attention as Diaspora. Some examples include BuddyPress (which has been out since May 2009 and which works with WordPress), GNU Social and StatusNet, which is the basis for the micro-blogging site identi.ca.

So although Diaspora is starting from a clean slate and with a slightly different set of goals in mind, it means less re-use of existing work already accomplished by others.

Conclusions

Let’s face it: there’s a romance to the idea of a gang of upstarts sticking it to Facebook by creating a competing platform that’s inherently open, private and decentralized. There’s little argument that Facebook could use competition from different directions, if for no other reason than to pressure it into being less monolithic and cavalier.

But Diaspora won’t make that happen automatically. It already has some degree of competition from elsewhere in the open-source world, too. And it’s a long way from being anything the average user can try out, let alone rely on.

Still, it’s quite early in the development process. The finished product might not resemble this early version in the slightest, either in its architecture or its deployment method. And, again, it’s exciting to see people trying something this radical with nothing more than their own enthusiasm to power them.