Laughing Meme

I’ve been terrible about uploading my talks this year. So here are the Advanced OAuth Wrangling slides from my talk today. (even though I really want to spend a couple of hours cleaning them up)

| View | Upload your own

And as its a 85 slides to be given in 45 minutes you can imagine that there is a fair amount of information missing from the slides. Simon made me promise to upload an annotated version, and I’ll try to do that soon.

(and unfortunately the process of saving the slides down to a PDF killed the transparency on the grey backdrops)

I didn’t make it to the keynote to see our new CTO speak (meetings that morning), but it was very strange, bordering on deeply surreal to watch the video of it.

1. Interesting to see my “Flickr is the 2nd largest API ” meme work its way up the tree. I didn’t make that factoid up per se, and I’d probably stand behind it if pushed, but I did reason from very limited data. (also AWS screws up the story, is utility computing an API?)

2. Still haven’t quite adjusted to the transition of OAuth from being a personal project that the “Paranoids” (official title of Yahoo’s internal security experts) were angry at me for working on (against Yahoo policy for Yahoos to work on security related projects), to a the company wide standard, at least on paper.

I’m speaking next Friday at the SF Web2Expo on Casual Privacy. I’m speaking in Dublin Speaking Thursday May 8th (2 weeks later) in Dublin on Advanced OAuth Wrangling. Hope to see you at one or both of those talks.

I’m also excited about a dozen other talks next week, as you can see from my Web2/iCalico schedule.

Congrats to waferbaby, mroth, and ph for totally owning on today’s friend importing feature (aka beehive).

We’re a little late to the game but its awfully nice to be able to launch with zero screenscraping, and zero phishing-creepy-give-us-your-password. This is what data-portability-open-data-delegated-trust future looks like.

update: and yes, we’re cheating, because Yahoo’s addressbook API is still internal+partners only. We’re working on it.

Other folks are talking about and writing about the long germinating, launched in beta, location broker from Yahoo’s Brickhouse, Fire Eagle.

I wanted to call out just a couple of the cool, and non-intuitve decisions they made.

Is NOT a consumer brand

Fire Eagle is a service for building and sharing location data. Its the application built on top of it that you’ll interact with, unless you’re building stuff.

Fire Eagle does NOT manage the social graph

Its a service for sharing your data with friends (or services, or your toaster), but it doesn’t know who your friends are. The social graph has been outsource. Best example of a small piece loosely joined I’ve seen in a long time.

Cares about privacy and ease of use

Ninja privacy is built in. But you don’t have to care. The TOS requires developers to discuss how the data is used. And privacy levels are front and center. And from day one data is delete-able, and in fact data is flushed on a regular basis.

Built on OAuth

Yay!

Mike released HTTP_Request_OAuth today, so I spent a little while this evening coding up Service_Twitter as helper class for making OAuth authorized requests against the Twitter API.

Both are early enough in the dev cycle to be called proof of concepts.

Mostly I wrote it because I had always envisioned there being wrapper libraries around the low level OAuth implementations that wrapped the calls, and constants, and as Mike graciously went out and wrote a low level library I felt compelled to write a wrapper.

Also twittclient, an interactive client for getting an authed access token, essential to bootstrapping development.

And nota bene, HRO currently only supports the MD5 signing algorithm, which is undefined in the core spec, and subject to change. (Just in case you didn’t believe me about the early state of things.)

update 2008/4/18

This code no longer works because Twitter has taken down their (slightly non-compliant) OAuth endpoint. When they add OAuth support back in, I’ll link to it.

I didn’t make it to FOO this year, but I did send software in my stead, and its nice to hear that folks liked it.

We slaved iCalico to Crowdvine to add a social networking layer, a network that was walked, mapped, and color coded by the Pathable folks.

Tony has a nice report back on it, as does Shelly from Pathable (6 weeks aka a couple of late nights). And Scott Berkun (who owes me a copy of “Art of Project Management”!) said super nice things.

Collusion Patterns

So how do you do that — stitch together 3 different sites to provide a unified experience? Visions of APIs, Internet scale SSO, and messaging layers spring to mind. Or more likely hash and slash patches, jury rigged shunts, juggled install directories.

We did the dumb easy thing, and I’m surprised more people don’t do it.

1. Crowdvine.com sets a cookie collusion. This cookie contains the data we needed to display the logged in view of iCalico. (you’re nickname and optional your URL). In addition it contained a md5 hash of the concatted data, plus sekret known only to Tony and myself.

2. If we find the cookie collusion, we load the described user from the database, or create it on the fly behind the scenes.

3. There is no step 3.

Amazingly useful, trivially simple, ultimately flexible. Niche sites are great, but you need techniques for stitching them together before they can realize their potential as pieces of an ecosystem. I don’t necessarily expect to see this kind of integration become more common, but I think it would be great if it did. (and in the name of transparency disposable apps are huge enablers, disposable sites/apps is another pattern I’m puzzled we don’t see more of — its as if we more inclined to converse bits then landfill)

update: Whoops, it was pointed out there was a step 3, or rather a step 1.5: use CNAMEs to point to individual components on sub-domains.