DistOS-2011W Diaspora

cha0sPod

cha0sPod is currently offline, as I am setting a pod up on a remote server rather than a home server to improve performance. Link will be posted in this section upon it going live.

Introduction

For my implementation report, I will be setting up and using a server running Diaspora. Diaspora is a distributed social network meant to directly compete with centralized social networks such as Facebook and Twitter. My report will focus on my personal experience with Diaspora, both as an administrator as well as a client. Due to time constraints, most of the administrator reporting will involve setting up the pod, while the client portion will focus on the interactions of two test user accounts.

Section 2 describes the specifics of Diaspora, particularly how it functions from the client's perspective, Section 3 covers my experience in setting up a Diaspora pod, Section 4 includes additional details in regards to the management of the cha0sPod, Section 5 covers my experience in using Diaspora as a client, Section 6 contains my conclusion, and Section 7 includes all references made in the document.

What Is Diaspora?

Diaspora: Distributed Social Networking

Diaspora is designed to decentralize social networks, so that privacy can more easily be managed by the individual user. With a centralized social network, all information, messages, and pictures posted are effectively owned by the corporation hosting the network. The idea of sacrificing all of your privacy in exchange for a service is exactly what Diaspora hopes to prevent [1].

How it accomplishes this is the utilization of user-owned servers, called "pods". Pods are used to host content, such as status updates and pictures, and communicate with other pods so that the content is available across the network. Users may either create a pod, join an associate's, or sign up in a pod open to the public. In any case, Diaspora prioritizes user privacy using a number of methods, which are described below [2].

Aspects

Aspects are used to maintain multiple identities in the social network. By default, every user starts with the "Home", "Family", and "Work" aspects. When the user posts, they can specify which aspects to post to. For example, if the user posts to the home aspect, only friends associated with the home aspect will see the post. When a friend is added, the user specifies which aspects the friend should be associated with [3].

New aspects can be created at any time, so that users can customize the privacy of their content on a per-update basis. This means that a user may have "Employees" and "Supervisors" aspects, so that messages can be sent to a manager's employees based on the level of privacy the message needs.

Content Ownership

Users maintain ownership of all content posted, including pictures. This means that the user has control over how photos are distributed. Again, this is done through the aspect system, so that photos are only seen by the people you want them to.

Setting Up Diaspora

Preparation

For the purposes of evaluating a Diaspora implementation, I have opted to set up a home server. The home server in question is an old Dell Dimension 3000 running Ubuntu 10.04 and an Apache server. After registering the domain cha0sNet.com and configuring my router, my server was online.

Steps used in setting up cha0sPod can be found at Diaspora's main site.[4]

The next step is installing some additional software. This section is pretty straight forward, it's just installing packages from command line. These instructions can be found on the wiki setup page for Diaspora, linked above.

With all the prep work completed, my system is ready to host a new Diaspora pod. The details of that are outlined in the next section.

Setting up the Pod

The first obvious step is to actually download Diaspora from the git repository, which can be done with the following command:

            git clone http://github.com/diaspora/diaspora.git

Next, change directories so that you are in the diaspora root directory. The diaspora directory is located wherever you ran the git command, unless specified otherwise. Not realizing this, I ended up installing it in my home directory, before eventually moving it to /var. Successfully switching to the diaspora directory (tricky I know), running the command:

            bundle install

will install Diaspora’s gem dependencies.

The next step is starting MySQL, which I had previously set up while configuring my Apache server. It says to run

            sudo service mysql start

to get the database started, but for me it started automatically on installation.

With all this out of the way, it’s time to configure Diaspora so that it actually works (An important feature).

Configuring cha0sPod

Up to this point, everything was going fine. I followed each step outlined by the main site, and more or less it all went smoothly. This is the moment where it stopped going smoothly.

The first bout with configuration comes in the app_config file. To create it, run the code:

            cp config/app_config.yml.example config/app_config.yml

and then change certain values within the file. The only field I changed during my initial configuration was:

            pod_url: http://www.cha0sNet.com

though, I’m not really sure if that was necessary. So, everything fine here.

Configuring the database comes next, a process similar to the above configuration. Run the code:

            cp config/database.yml.example config/database.yml

The values in this file are more important, since this is where you configure the user/password Diaspora uses to access your MySQL database. Just enter username/password used for the test, development, and production databases. I used the same account for each one, because I’m risky I guess. Obviously the user account needs to be created before or at this stage, unless you just used root. But that’s probably I bad idea, which is why I went ahead and created a new user account for Diaspora purposes.

With the database information all properly configured, it’s time to create the databases and tables. Luckily Diaspora automates this, and initializes the databases with the following code:

            bundle exec rake db:create
            bundle exec rake db:migrate

Of course, this is all works theoretically and there must not be many people struggling with this step, otherwise there would be some sort of warning. Despite that, this is the first instance of something going wrong.

Diaspora uses three databases, one for each stage of development. For whatever reason, the diaspora_production table was never created. I didn’t discover this until much later, as prior to my launching my pod into the internet, Diaspora used the first two databases.

The fix was simple enough; I simply copied diaspora_test and named the copy diaspora_production. Overall, this was the easiest obstacle to overcome.

Running cha0sPod (First Attempt)

Now, prior to deciding to run it on my Apache server, I attempted to run the server using the default configuration using thin. To do this, run the code:

            ./script/server

while I was able to access my local instance, I was unable to access it neither through the local area network nor over the internet. Eventually I figured out that it was because I wasn’t running it as root [5]. The command to get it running is thus:

            sudo ./script/server

And it appeared to work. At least, the command line showed no errors. However, accessing through the LAN and WAN resulted in a blank page being rendered client-side, and an error I couldn’t really find much documentation on. In search of a solution, I ventured beyond the basic setup page, and found one detailing how a Diaspora instance can be run through Apache[6]. Since I already had a server set up, I decided to try this option out.

Attaching Pod to Apache

As I already have an Apache server set up, the first step to attaching my Diaspora instance to my Apache server is to install the passenger module. The passenger module allows Apache to serve Ruby on Rails applications, such as Diaspora. The code to install passenger is as follows:

            gem install passenger
            passenger-install-apache2-module

The guide says to load the module into Apache Config, but it did this automatically for me, so I just skipped that step.

All that’s left to do is create a new virtual host for the Diaspora instance, which is fairly simple. I simply used the default Apache virtual host file and changed it to reflect this:

            <VirtualHost *:80>
            ServerAdmin webmaster@localhost
            DocumentRoot "/var/diaspora/public"
            <Directory "/var/diaspora/public">
            Allow from all
            AllowOverride None
            Options -MultiViews 
            </Directory>

And then ran the following code:

            sudo a2dissite 000-default
            sudo a2ensite default
            sudo /etc/init.d/apache2 reload

To activate my Diaspora server. This is of course when the fact that diaspora_production didn’t actually exist came to light, but the problem was solved easily using the method described earlier. And thus, cha0sPod was online.

Managing The Pod

After setting up the pod, there are additional options available to the administrator. Much of Diaspora is automated, so this section is mostly about managing the pod as a stand-alone server.

Customizing The Pod

An interesting part of Diaspora is that each pod is an independent system, and so a user's experience may differ greatly from one pod to another. For instance, cha0sPod does not currently support certain features that the major pods do, such as finding friends and posting to a Facebook account.

Besides services, each page (referred to as a view) may be customized visually using the HAML markup language. I had never heard of this mark-up language before this point, and so opted not to mess with the website pages, with the exception of my welcome page.

Managing Sign Ups

There are two distinct classes of pods: public and private. Public pods allow anyone to go to their website and sign up for an account, while private pods requires an invitation. This can be set in the "config/app_config.yml" file, which of course would require a server restart afterwards. cha0sPod is a private pod, and will remain in this state as it is mainly for personal use.

Using Diaspora As A Client

Diaspora is still in it's early stages of testing, being in an open "Alpha" stage currently, so it's understandable that things aren't going to work perfectly. I created two user accounts to test the capabilities of Diaspora as a sort of messenger between two contacts. These two accounts are:

• cha0s: Thomas McMahon
• adm1n: Aurora Rhys

It's important to note that user accounts are local to a pod, so the same username can be used across multiple pods. A global username is created by appending the domain name to the username (i.e. cha0s@cha0sNet.com).

My testing of the Diaspora service involved four stages:

Stage One: Communication Within Established Pod

As a sort of control test, I registered cha0s and adm1n as users on an already established server: Poddery [7]. The purpose of this test was to observe the communication between two users within the same pod, which has a reputation for being reliable. The sequence of events were as follows:

1. cha0s searches for "Aurora Rhys" and finds her profile page.
2. cha0s adds Aurora to his "Work" aspect.
3. adm1n receives a notification that "Thomas McMahon" has requested to add her. adm1n adds Thomas to her "Work" aspect.
4. cha0s posts "Hello." to his "Work" aspect.
5. adm1n sees salutation, and responds.
6. cha0s receives response.

As expected, there were no problems communicating within the same pod. The next test was to determine if cha0sPod is capable of the same interaction.

Stage Two: Communication Within cha0sPod

This test more or less mirrored the first test, except executed on the cha0sPod server. The purpose of this test was to ensure cha0sPod behaved normally with internal communication when compared to an established server. The results of the test were the same as above, showing that cha0sPod could achieve internal communication between two users.

Stage Three: Communication Between Two Established Pods

To test how well pods are able to communicate with each other, I registered adm1n on a different pod: Diasperse [8]. By testing the communication between two established pods, I would be able to compare how well my pod is able to communicate in contrast. The sequence of events were as follows:

1. cha0s searches for "Aurora Rhys", but cannot find the one on diasperse.com
2. adm1n logs out of diasperse.com, and logs back in.
3. cha0s is now able to see Aurora Rhys, and adds her to his "Family" aspect.
4. adm1n receives a notification that "Thomas McMahon" has requested to add her. adm1n adds Thomas to her "Family" aspect.
5. cha0s posts "Hello." to his "Family" aspect.
6. adm1n does not receive message.
7. adm1n posts "Hello?" to her "Family" aspect.
8. cha0s does not receive message.

As you can see from above, there was a failure to communicate between the two pods. The strange part is that cha0s was able to find adm1n, but unable to receive messages from her. Even after logging in and out, there were no messages. Obviously, this didn't bode well for cha0sPod.

Stage Four: Communication Between cha0sPod and Established Pod

The final test I ran was to see if cha0sPod would be able to communicate with an established pod. To do this, I had cha0s (logged in to the cha0sPod) search for adm1n (logged in to the poddery pod). cha0s was able to find adm1n, but like above, was unable to do anything more than that.

Results

As far as communication goes, it appears as though Diaspora may be in a temporary rough patch. However, there are many reports of successful pod-to-pod communications online, so it's possibly just a recent bug that needs to be fixed, or else an issue with pods running different versions.

I will continue testing once the official cha0sPod is established on a remote server, and hopefully the communication issue is solved by then. But right now I would recommend waiting before switching from Facebook to Diaspora, unless you enjoy submitting bug reports.

Conclusion

Personal Review

Diaspora aims to create a social network that prioritizes privacy, and it does just that. Through the usage of servers owned by the clients, and the concept of aspects, information posted can only be accessed by the users it's intended for. As of right now, setting up a personal pod can be fairly tricky, as there are a few odd bugs that will hinder your progress unless you figure out what is going wrong. I myself had to manually create one of the datbases, along with opting to use a different server package than the default. The Diaspora interface abstracts the individual pods so as to appear as a single system successfully, though there are major bugs that prevent Diaspora from being used as a legitimate social network at this point in time. Specifically, there appears to be an issue with communication between pods at this moment. These results are hardly surprising, given that Diaspora is still in its "Alpha" stage of testing.

Diaspora has shown a lot of promise from my usage of it, and will only get better as more services are integrated into it. Overall, this experience has been a positive one, even though there were a few difficulties trying to get the server to run, and I plan on creating a legitimate pod on a remote server for my personal usage.

Future Work

As far as future plans go, the wiki suggests that the main changes that are occurring at the moment involve securing messages sent between pods [9]. Beyond that, launching Diaspora as a full-fledged social network competitor would be the ultimate goal.

References

[1] Jim Dwyer (May 11, 2010). Four Nerds and a Cry to Arms Against Facebook. February 26, 2011, http://www.nytimes.com/2010/05/12/nyregion/12about.html?_r=1

[2] Diaspora Home Page. January 31, 2011, https://joindiaspora.com/

[3] Aspect FAQ. February 16, 2011, https://github.com/diaspora/diaspora/wiki/Aspects-FAQ

[4] Installing an Running Diaspora. February 16, 2011, https://github.com/diaspora/diaspora/wiki/Installing-and-Running-Diaspora

[5] Randall Munroe. xkcd: Sandwich. February 28, 2011, http://xkcd.com/149/

[6] Installing on Ubuntu Apache. February 22, 2011, https://github.com/diaspora/diaspora/wiki/Installing-on-Ubuntu-Apache

[7] Diaspora: Poddery. February 25, 2011, https://poddery.com/

[8] Diaspora: Diasperse. February 25, 2011, https://the.diasperse.com/

[9] Diaspora Security Architecture Proposal. February 28, 2011, https://github.com/diaspora/diaspora/wiki/Security-Architecture-Proposal