One of the outcomes from my trip to Victoria last week is some thinking about the social graph.
More specifically, you may recall that I've been using Flock. As it turns out, I recently upgraded my laptop to Leopard, and made Flock my main browser. This has given me increased exposure to their "people bar" -- a side bar that supports a variety of big community websites, like Facebook, Flickr, Twitter, and so on.
As I've been using this feature, and seeing the way that Flock "detects" features of different websites, I started thinking about how every community website could enable this functionality. Right now, the Flock team has to pre-integrate with the specific website's API to enable this functionality. But, just as they "detect" the presence of site-specific search engines, there is no reason that one couldn't expose a link header that indicates the presence of a social graph.
I know what you're thinking: "But Boris, how many people use Flock? Isn't this just browser specific functionality?" Well, no. First of all, Google has a Social Graph API that is already being crawled -- looking at FOAF and XFN.
Secondly, I got to thinking about all these site-specific applications -- like Twhirl that was bought by Seesmic. So, if we had some basic standards about this stuff, it would be simplistic to have one app that let us monitor / notify / update any of these systems. Yes, there will ALWAYS be websites that have more complex APIs with more features -- that are only accessible by implmenting *their* API to talk to them.
But for thousands of other community websites, built in Drupal, WordPress, Joomla, or what have you -- you suddenly have the same rich access to applications as the big guys. How many websites would encourage their users to install Flock or Twhirl if it supported *their* website?
Oh, and I'm completely skipping the linked data / RDF / Semantic Web factor of having community websites expose some part of their social graph, or at least make it available for querying by people that have the right credentials.
OK, so how does this look to the end user? I'll use Flock as an example, since I've got agreement in principle from them that they'll work with me on this, including help in defining some of the formats.
Now, I know the first thing we're going to have to do is fight a religious war over the format of the socialgraph file. I'm going to suggest some minimal FOAF format, since I'm a born again RDF fan.I don't want to go spraying email addresses all over the place, so perhaps either local unique user GUIDs or OpenID could be used as identifiers for each person. We actually don't need full "person" information -- a username, avatar, status message, and date stamp for last activity sorting should be the minimal set. Even status message could be option for smaller, less complex sites so almost anyone could support this out of the box: just show everyone on the site (yes, that's right...ignore any sort of "friend" connection) sorted by last active -- which could be a post / comment, or (again, simple support by many sites...) just date stamp of last login.
I'd like to think that the choice of OAuth as credentials for acessing this info isn't controversial at all. Feel free to layer OpenID in here somehow, but for the action-at-a-distance on which cool functionality can be built, this kind of a token system looks to be ideal.
What next? Well, surprise, surprise, I'm going to take a crack at getting this implemented in Drupal. Raincity Studios is already working on the OAuth module, which would be one of the main pre-requisites. Once the format of the social graph file is defined (calling Joshua, Arto, and maybe RalphM...), building the next piece shouldn't be too hard.
Ideally, something like the Gnomepal Drupal distribution would ship with this out of the box (for the really ambitious, Drupal 7 core!). And other systems like Marc Canter's People Aggregator could easily expose this social graph info as well.
I'm excited at the continuing growth of every website as a dynamic web application, and also of the exposure of data and APIs by this web of sites. This feels like the right path we're travelling on to get everything a little bit more interconnected.

Flock’s 1.1 Beta Has Arrived! And so I'm testing it (the last time was August 2005). I met my first semi-local Flock'er (Mark Lise) at the last DemoCampVancouver. They came back in force from Victoria to storm the Northern Voice conference (Flock was a sponsor).
At left, that's me watching Clayton Stark, the VP of Engineering, giving Marc Canter a demo, while myself, Rob Scales, and Dickt Hardt look on. Initial impressions (on my desktop PowerMac G5)
If you hadn't heard of Flock the first time around, try it as a replacement (yep, replacement...) for Firefox. If you had gripes/crashes/etc. the first time, erase those memories and know that Canadian engineers are on the job and you should give it another try. With Firefox, you can add a bazillion plugins and do lots of functionality. Flock has it all integrated and smoothed out for lots of the social media services that people use already. Firefox is to Flock, as Drupal is to WordPress?
Works for Mac, Linux, and Windows. Anyone else using it again / for the first time? I have some ideas of other things it COULD do, what do you think?
(slight snafu in posting, but blog posts got autosaved / recovered. yay!)
Disclaimer: my company may end up doing some work with Flock. Of course, we also just helped Spread Firefox recently
Via Dave Winer, I found this post by Mike Arrington talking about the AllPeers Firefox extension:
AllPeers is a simple, persistent buddy list in the browser. Initially, interaction with those buddies will be limited to discovering and sharing files - If you choose to, you can share any file on your network with one or more of your friends. They will be able to see what files you choose to share (even getting an RSS feed of new files you include), and with a single click download it to their own hard drive.
AllPeers is private, P2P file sharing using BitTorrent to do the transfer, implemented as a Firefox extension. It involves buddylists as well, so I left a comment on Mike's site that they should use XMPP to power the buddylist. Buddylists and IM capabilities in the browser (which are proxies for identity and peer-to-peer communication, respectively) are destined to have some sort of representation directly in the browser. This might be something for Flock to think about.
Thanks to everyone that emailed to congratulate me for the quotes in Jeff MacIntyre's piece on Flock in Wired News. Occasionally, messing around with a lot of web technology *does* lead to good things.
Recent comments
5 days 10 hours ago
6 days 4 hours ago
6 days 7 hours ago
6 days 8 hours ago
1 week 16 hours ago
1 week 20 hours ago
1 week 2 days ago
1 week 5 days ago
1 week 5 days ago
2 weeks 19 hours ago