Over a year ago I'd written up a preliminary specification for the REST design of a distributed social network. The rationale should be obvious to anyone who's paid attention to internet technology in the last decade: freedom from "walled gardens". Because of work though, I never was able to devote much time for the project. Recently several discussions with Scott have led to interest re-sparked.

The first step is to identify what Facebook/MySpace et. al. offer that can't be offered simply by adding XFN style links to a blogroll. As I see it, closed communities offer the following features.

1. Information exposure
   Information is granular, and non-standard (i.e. The information exposed by Facebook is not the same as that exposed by LinkedIn, but there is generally some overlap)
2. Privacy controls (though some users of Facebook might argue this...)
3. Web real-estate.
4. "Secure" bi-directional relationship mappings. You can't say someone's your friend on MySpace unless they also agree that you're their friend.
5. Searching (in a generic sense, not a textbox, type in a name sense). Network construction might be a better term.
6. Defined (closed) communication protocol. When Alice friends Bob, both sides know what to do (well, duh--they're both on the same system).

Of these problems the most difficult to solve is search. There are two approaches:

1. Push architecture. When a client changes data, it makes an RPC call to all of it's peers informing them that it has changed.
2. Pull architecture. When a client changes data, it modifies a feed (RSS/Atom is the natural choice) which are periodically polled by peers looking for changes.

Coupled with a strong client-side caching mechanism and search becomes a more approachable problem.

Bi-directional relations are actually not as analogous to real-world interactions as uni-directional. There's no reason why Mallory can't consider Eve a friend and she doesn't reciprocate.

Communication protocol is another major hurdle. I think there are two options:

1. All web applications that function as a social node have a well defined REST hierarchy underneath them.
2. All URLs that function as social nodes have some meta data attached to them which tells clients where their accessors/methods can be found.

For the time being I've decided to stick with the former. The advantage of the later is that it's possibly easier to integrate with legacy systems (MovableType, WordPress, etc.)

I've started working on a proof of concept in Rails, though there's no reason it has to remain there. I've placed a bzr branch here. (yes, it's still infantile).

I haven't forgotten privacy is a complicated issue. I wish to return to it as some point, once I have a better solution mentally hashed out.

There is at least one project (DiSo) out there that is doing something similar to this. [details]