Aehso’s Output

It’s almost incredible to believe that Facebook application developers have put up with using discussion forums to report, discuss and track bugs in the Facebook Platform while it is in constant use by 40million+ users but Facebook have finally launched a Bugzilla based bug tracking site.

One might be forgiven for thinking they survived this long because the platform API is rock solid but their tendency to roll out nightly updates that break very visible platform APIs every few days contradicts that slightly. We scratched our head for few hours a while back when the mock Ajax APIs that our application profile boxes were using suddenly started presenting the user with misleading error dialog boxes, only to find out that the platform API had accidentally been busted the previous night. I’d imagine there’s been a lot of time wasted by a lot of application developers over the past year while tracking down similar incidents but they have been incredibly patient in waiting this long.

One thing I would love Facebook to add is a FBML tag that gives the application developers extra debug/trace info while running/debugging their application but until now I’ve had no decent way to know if something like this isn’t already in the works. Something like a fb:is-app-developer, or a magic debug/trace div beneath the application div might be nice. Or they could just open source their FBML->HTML rendering engine and then 3rd parties could go about developing decent tools to aid debugging (I suspect this is already being reverse engineered though anyway…)

Better later than never though I suppose.

aehso api, facebook, scm

Ronan pointed me to an interesting Wired blog entry on Brad Fitzpatrick’s social graph problem. The social graph problem requires many of solutions that Dion’s Dream River needs so I was going to just comment that it will take a long time for any of this to happen (thankfully Brads essay openly calls this out).

Then I read that Brad might be joining Google. So I’ve changed my comment to “it might happen just a little bit sooner”.  This is just the type of problem that the folks at Google love to try solve…

aehso api, facebook, internet, openid, social, web2.0

Now that I’ve been using Facebook, LinkedIn and Twitter for a while I’m beginning to notice fragmentation of my contact network and event streams.  The problem goes a little deeper than “should I twitter this or/and update my FB status?” or “should I add her as a friend in Facebook or LinkedIn?”. 

Then there is also network replication to deal with – I’m getting multiple friend invites for the same people, many of whom are already in my (private) contacts list.  Don’t get me wrong, I like connecting with people!  I’m just finding myself wishing that there was a better mechanism through which all this stuff can be synchronized though.  It turns out Dion Almer is finding himself dreaming up a solution he calls The River:

In the dream I developed an application called “The River” that was a filthy rich UI that showed your one main river of events, and various rivers that would run into the main one. The river would contain: Incoming email, Status events from fb, twitter, pownce, Cool.Next, Event invites, Blog entries via rss, Photos uploaded, etc.

Dion adds a nice kicker when he suggests the following feature:

When a user signs up, they are asked for their FB/gmail/linkedin id to find people / invite them. Most services do that right now. However, there is an extra check box which states “if you see me connected on another network, automatically connect me here”. This means that you don’t have to keep accepting friend invites from the same people again and again. You should virally, quite quickly, get all of your contacts sync’d up.

I think this is an excellent suggestion but I’d take it one step further.  The River needs to do this continuously, effectively acting as an intelligent agent.  Unfortunately there are two major barriers to this ever happening:

• The agent needs to be able to verify user identities.  For example it needs to be sure that the John O’Shea in your network is me, not the footballer, the filmmaker or the humanitarian.  I can and do play football, shoot home movies and donate to charities but I’m not those people.  One problem here is none of the major social networks support associating an OpenID with a user profile so by consequence none have the required APIs.  A second problem is not many people have OpenIDs yet (that reminds me…)
• The agent needs read/write  to the users contacts and event streams within each social network.  Read can be done via RSS feeds, but write needs HTTP API access.  Of the networks I mentioned above, Facebook(api) and Twitter(api) provide this LinkedIn doesn’t (yet – they are working on APIs though).  The walled garden social network sites like MySpace and Bebo really won’t want to ever provide this.

If OpenID gains more momentum then I think all of the above is do-able.  I am of course ignoring the walled garden networks but over time they will seem more and more antiquated to their users and their influence will diminish.

This is, of course, all an extension of the older problem of synchronizing contact information between multiple email accounts and mobile phones and that nut still isn’t completely cracked.  iSync solved this to an extent but it (still) doesn’t have any decent Google mail/calendar integration. (I’ve tried ABGMerge but it created a mess to the extent that I had to revert to backups. This is becoming a real pain for me as I ditched my .mac subscription last year and I’m mainly using gmail now – suggestions welcome!)

Meanwhile something is going to have to give, and I think the first service I’ll drop is Twitter…

aehso api, facebook, mac, openid, social, web2.0