This is a huge endorsement for AtomPub – I’ll bet Bill is delighted (hey, I can even tell him in person at his IWTC talk in an hours time…)

• The People Data API exposes people (viewer, owner, friends) via Atom feed documents and Atom entry documents. However, there is no AtomPub support for this feed so people cannot be created/updated/deleted via API. I suspect this will cause some debate as it means some fairly critical data remains locked into the underlying OpenSocial containers
• The Activities Data API exposes activities (news feeds etc) as a Atom feeds. The Activities data feed can be fully manipulated (CRUD) via Atom/AtomPub requests.
• The Persistence Data API exposes name/value pair data (e.g. configuration params) as a Atom feeds. The persistence data feed can be fully manipulated (CRUD) via Atom/AtomPub requests.

I’m off for a curry but more later today. Here’s a teaser though – authentication is a concern….

1. <wordpress-root-URL>/?feed=atom – Atom 0.3 format feed
2. <wordpress-root-URL>/?feed=rss – RSS 0.92 format feed
3. <wordpress-root-URL>/wp-app.php/service – APP Service
4. <wordpress-root-URL>/wp-app.php/posts – “Wordpress Posts” APP collection feed
5. <wordpress-root-URL>/wp-app.php/categories – “Wordpress Posts” APP category document
6. <wordpress-root-URL>/wp-app.php/attachments – “Wordpress Media” (attachments?) APP Collection

I am a little curious about why the HTML doesn’t contain a <link> for 4 though – its absence makes it kind of difficult to auto discover the collection feed URL. I’m also curious why both 1. and 4. exist. I always assumed that the APP collections would just point to the real Atom feed URL, with APP clients authenticating to send HTTP POST, PUT and DELETE requests. Was this necessary because of bad feed readers/aggregators or was my assumption just plain wrong?

Update: Sam Ruby has some good commentary, doesn’t answer my question though…

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.

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…

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…