When I was in high school I seriously looked forward to 2010 as all of my favourite science fiction authors pegged the next decade as when a lot of action would be happening in space. Sadly it seems that we won’t be seeing any of that (at least not yet) but I still think it will be an interesting decade.

If you had asked me 6 months ago how things were going I probably would have given a mixed *shrug* as I was still in the middle of dealing with my father-in-law and his rapidly declining health and, to be honest, I was glad to 1) have a job and 2) have a house so that we (Elaine and myself) didn’t have even more things to worry about. But then right at the end of summer he passed on and now, after dealing with that event, things are sure looking different.

Two years ago we suddenly found out that most of us at OSAF were out of a job but that turned into a chance to join my first-ever startup – Seesmic. Now as I approach my second year at Seesmic I’m looking forward to see what happens next both personally and professionally.

The work i’ve done with XMPP and Python have really payed off, the rest of the world (well, ok, the web part of it) have really caught on to realtime data flow and XMPP is playing a big role in that and Python remains a good language to code in for both XMPP and other back-end apps.

So yea, big changes have happened and more to come I’m sure, but as long as I’m enjoying what I do (which I am) and as long as I keep my skills fresh, I don’t see any reason to not just keep moving along and enjoying this amazing field I call a career!

My Blackberry has been oddly silent the last day or so (oh I hope I didn’t jinx that just now!) and i’ve been catching up on some podcasts, the most recent being This Week in Google #21 where during one bit they talk about how disruptive to businesses Google has become.

What Google is doing is something I’ve been waiting a long time to happen, for some company to beat back the large corporations who are straddle both sides of the fence in the world of content – they are both producers and delivery agents (and also in some cases control the delivery method.)

We really need companies to become tighter in focus – be a delivery pipe and a good one; be a content producer and a good one; be a receiver or client and a good one but just don’t be all three. I’m looking at you now Comcast and Apple.

When we have multiple choices of pipes and can move our phones, netbooks or computers from one to the other without penalty then we can have a proper marketplace of competition.

Ok, that’s the only non-geek podcast I’ll do for another year :)

According to the archives, i’ve been writing the occasional post since 18 December 2003.

I had to double check that date since it sure doesn’t seem like 6 years have gone by :)

Evidently Jesse Stay and I had similiar thoughts about all of the chatter about the adoption of Twitter’s API by WordPress and Tumblr (among others) and while I spent the day watching and shoveling 2 feet of snow Jesse was way more productive and put forth a group project to think about how the API could become more open and not tied to any specific vendor :)

At first I was thinking that this idea has already been tossed under the bus by many folks who thought about creating open versions of Friend Feed and I even thought that in a way it’s already being proposed by the Laconi.ca (aka Status.net) crew and the OMB protocol but I realized that I was focusing on how I would implement such an animal and not how to enable data transfer, which is after all the core part of what an API offers.

After realizing I was giving the thought some serious short shrift so I sat and chewed on it and came up with an idea and also an immediate concern:

First the idea, it should be a gateway that allows for sending/receiving of items using one of the many existing excellent examples of data APIs

• Activity Streams
• Atom Pub
• RSSCloud
• Open Social  

Any one of the above would make an excellent gateway API interface as they allow for all of the elements that exist in a Twitter item.

The one immediate concern I have is about identity. As a gateway, the system would need to understand how to map identity from/to the incoming and target network so that a proper flow of the conversation can happen.

The good thing is that recently a lot of work has happened recently on just that item :) and I think that the newer Web Finger and the existing OpenID options could work because already quite a few of the larger data silos allow for mapping of OpenID to their internal systems. The protocols above also all, if I remember correctly, have some method of storing enough metadata to allow for the incoming item to maintain it’s integrity even if on delivery some items are lost – the gateway would be able to remember the transaction even if the target mangles some of it.

With the proper storage of metadata then other protocols like Salmon can be used to track the conversation across all of the “jumps”.

I think the important part is to not create yet another data silo that has to be maintained and polled just to allow for all parts of the conversation to maintain itself – rather I would love to see this as something that could be used to enable each unique identity to maintain the information required and become the master of their own conversations. Of course large sites could offer internal proxies to their own user base who don’t wish to implement their own, but it would also allow power users to do so and then the other gateways and exchanges points become secondary backups and the whole thing becomes a lovely distributed system.

Just some quick thoughts that I wanted to get down before I go to sleep

First, it’s not the “Twitter API” if it’s found on WordPress or Tumblr (not to mention that this API compatibility has been in Identi.ca (aka Laconi.ca) for almost a year now) – it’s just an API that is Twitter-compatible.

Second, the endpoints used to access an API are, at most, 1/3 of what makes up an API – the most important part of an API is the data passed to and also from those endpoints to do the tasks that the endpoints enable.

So sure WordPress and Tumblr have a Twitter-compatible API but what happens when Twitter changes how one of the endpoints work, like they did when they recently changed how since_id works or even how re-tweets work. At best the other sites will be able to make similar changes but the worse case scenario is that they won’t or cannot make the changes and then things start to get ugly. Anyone remember RSS 0.93? or even the blog related API’s to make posts from clients – all suffered from fragmentation.

That is not to say I am not excited to see the API pattern used by Twitter is being more widely adopted, it’s a well thought out and functional API – I just think that crowning it the King of micro-blogging APIs is a bit premature until the *whole* API, data formats and all, is documented.