I'd like to see a distributed implementation of social graphs.

But meanwhile, let's try something simple and practical.

First identity. If you have a place on the Net to call home, then it has a URL. URLs are memorable (by comparison to UUIDs), and we already track them and exchange them. So let's use that as the first point of identity.

Second links. Graphs emerge from links, so we need a way to find who you're linked to. What about blogrolls? Many people use blogrolls to link to their friends. WordPress has a fairly simple UI for managing blogrolls that anyone can use.

Third, semantics. WordPress uses XFN, so if you crawl the blogs by just looking at the front page, you can determine all the friend/colleague/spouse/etc links. I can't think of simpler way to extract all that information.

Fourth, search. Who says it has to be distributed? Why can't you just aggregate that information into a centralized server, do all the graph calculations there, and have people use that service to find other people?

Fifth, layering. But say you want to layer "you know X through ..." on X's blog. You can let people embed a script tag that pulls that information into their page, or come up with a FireFox extension that displays it on the currently viewed page. The possibilities are endless.

There's not a lot of graph theory, or RDF semantics, or Web service APIs behind this approach, so it may disappoint if you're looking for new technologies to hack out. I think it's more fun though, since you can pull if off in one weekend and spend the rest of the time focusing on useability.

At the center of this is the identity service. This service contains all the information about an entity within the space. For simplicity's sake I'll limit my comments to how they pertain to people, but as far as I'm concerned they can refer to any discrete object, real or virtual, that can be referred to in the web universe. think X.500 with a webservice front end. This web service would provide the following features:

- Contain, present and modify public, private and semi-private information to accessors that appropriately authenticate. So a webservice call that requests a user's profile will only get read-only access to public information, unless that call provides proper credentials to view or modify that information

- Manage subscription callbacks to parts of that information. Within a security context, allow external entities to subscribe to portions of a profile, and receive notifications when those portions change.

- Allow for objects to move freely between services, and provide seamless forwarding for objects that have moved. The internal core identifier for each object needs to be universally, permanently unique and not tied to whatever service is containing it at the moment. In the event that a former containing service cannot or will not manage forwarding, a secondary forwarding registry service could be created to facilitate this. Backwards propegation of this object movement would clean up the links in the background over time, so if a service gets a redirect on an object it's looking up, it would pass on the redirection as well as update its own internal links. So if I rehomed my profile, every time someone followed a link to my old service, their service would update the link as well as pass on the new reference.

This service would contain all the profile information relevent to that particular person; all the information that we're used to supplying about ourselves on tribe or other services. The FOAF schema is an OK start to this, although it looks pretty clunky to me at this point.

Once we have that service running, then by layering a set of web pages atop it (or heck, maybe just some XSL) and you've got friendster 1.0, but without the vender lockin. Anyone could layer their own presentation mechanisms (HTML, XML, etc) atop the web service to work with or display data in a manner appropriate to their use.

Other services could then be created to work with this service. A message collection service would satisfy the concepts of "tribes", but would again be federated. my profile that I host at Profiling Service A could state that I belong to Forum B at Message Service C as well as Forum D at Message Service E. By abstracting everything using "friendly names", you would never know that you're bouncing all over the net gathering up this information. Once again, vender lockin is prevented; if Some Random Message Service decides that a certain type of discussion is inappropriate, then the owner(s) would just migrate the XML that describes the forum to a new service, set up the required redirects, and be back in business.

Other services could include binary object storage (Photo album ++), listings services, and all the other things we've come to expect from places like tribe, plus more as we dream them up.

As Brian mentioned, the connectivity graph is a particularly hard problem. My understanding is that tribe has one machine devoted to creating this graph and holding it in memory, and that's for a relatively small, self contained service. Something that's internet scale will probably need to have the problem distributed. I'm not sure if the problem is NP-Complete or NP-Hard, or merely Collosally Annoying, but the solution will probably be an approximation rather than an exact graph. Perhaps individual nodes would compute their own chunks, and would constantly be swapping data. Perhaps some graph-crawling service that does for identity what google does for searches will develop a graph service that presentation services would subscribe to.

I babble. I should go back to work. :)

-m