Thoughts on the Social Graph
Jamie found an excellent story about the trouble with social graphs. The author discusses the proliferation of social networking websites, the annoying problems this creates, and proposes an open solution to much of the problem. Essentially he is talking about an API for all those relationship systems not under the control of any single commercial entity, coupled with a shared login system. Had things like this been popularized a half a decade ago, we'd be looking at a different internet.
The people I communicate with on Facebook are not the people I interact with on Linux forums or on Slashdot. The meaning of a "friend" (or whatever) on each site is totally different. Not only do I not want these connections treated identically... I don't want those separate accounts to be related to one another!
Frankly the downsides to having my online social activity interconnected are numerous: spamming, ease of monitoring me, etc. The end result is that I will either reveal personal information I didn't intend to, or conversely I will use the sites less freely because I'll be worried about revealing information (e.g. if I know potential employers will easily find the information).
Considering the numerous downsides, I have trouble seeing the benefit, to the end-user, of having a comprehensive, widely-accessible 'social graph.'
Facebook has made it possible for people to build the applications that people want and tie them into Facebook. A Web 2.0 site could accept log-ins, or allow Facebook users to simply add the application, adding them as users. Conceivably, Myspace will add a similar feature before going bust. The article's author gives a lot of non-sense about developers not wanting to be slaves to facebook, but they have it backwards.
I subscribe to Netflix. I added a Netflix app to Facebook, it let's my friend's see my queue... yawn... It also let's my Facebook friends, if they get Netflix, quickly add me as a Netflix friend (subject to my approval). The Netflix app mirrors some of Netflix's UI, but not everything. I still go to Netflix to manage Queue's and add movies, but I can see what's going on quickly on Facebook.
The problem is that most Web Developers suck. If your data store for your web-app is good, then you can EASILY create a Facebook front end. If your front-end has all your database calls (no stored procedures in the database, not even a DB functions file in Perl/PHP/whatever you coded in), then you see it as "be a Facebook App OR a website."
The promise of HAVi in the AV world was that we would connect our equipment via Firewire, and they would export a front-end in Java that our TV or Receiver would render for us. The data in MPEG-2 with fixed compression caused content producers to go ape-shit, but the idea is valid on the web.
If you want to process information, you need to collect it and do something with it. The days of a "single HTML interface" are now over. You need a mobile version, an iPhone version (possibly, we'll see adoption rates), and now a Facebook version.
I collect my photos in iPhoto on my Mac. I upload them to Facebook via an iPhoto plug-in to show my friends. I upload them to Shutterfly via an Export Plugin (well, did until they haven't supported iPhoto '08 yet), so my extended relatives can buy pictures.
I have other friends that are into photography, they use Flickr. However, there is a Flickr "interface" for Facebook, so their Flickr Albums are viewable on Facebook. Sure, if they have pictures that they want the Facebook features (tag a friend), they need to upload to Facebook, but if they want Flickr sharing (tags, etc.), they upload to Flickr and put it on the Flickr App on Facebook.
Open APIs will let US aggregate OUR data, not have one site steal it from others.