Where Am I?

My undisclosed location is now disclosed, thanks to the new draft Geotagging feature for Blogger :).


One site-meta to rule them all

Eran & Mark's site-meta proposal is... interesting. I have a gut feel that it's a bit like democracy: The worst method for whole-site discovery, except for all the others. The killer app for this, IMHO, is the ability to solve things like "lookup metadata for user x on domain y" in a general way. An immediate practical application is translating things like email addresses and Jabber IDs, all of the form (user@domain), to something you can perform discovery on.

Other than the embarrassment of hacking another hard-coded magic name alongside favicon.ico and robots.txt, I really only have one issue with the proposal: It requires a directory lookup via an XML document. I have nothing against XML, but it seems like overkill for this purpose.

An alternative would be to use a very, very simple text-based format that is NOT very extensible. Fortunately, there's already a proposal for this type of format from Mark, for a Link header:

Link: http://example.org/ch rel="previous";
title="previous chapter"
Just for simplicity, we can take the same format and embed it in an application/site-meta document. The sample site-meta XML would then transform into something like this (with newlines delimiting each type of metadata):
/robots.txt rel="robots"
/p3p.xml rel="privacy"
http://other.example.net/example rel="http://example.com/rel"
We lose the ability to use namespaces and inline (embedded) metadata in this site-meta document. Or alternatively, we gain the ability to ignore namespaces and we don't need to download inline metadata we don't care about.

One closing thought: A persistent issue with XML, unfortunately, is problems with cryptographic signatures, primarily due to complexity of signing and verifying something whose canonical representation is really an Infoset rather than a text stream. This hypothetical format, or any of a number close to it in configuration space, could solve that problem easily:
/robots.txt rel="robots"
/p3p.xml rel="privacy"
http://other.example.net/example rel="http://example.com/rel"
application/x-pkcs7-signature;base64,iVBORA...rkJggg== rel="signature"
...with some simple rules to determine which octets get signed.


Discovery Metadata is Just Data

Another comment on Eran's discovery mechanisms list (which is itself great). I'm gradually reaching the conclusion that he's right that content negotiation isn't the best idea, but for the wrong reasons. The question is, are the alternatives any better?

Quoth Eran:

HTTP Content Negotiation - using the 'Accept' request header, the consumer informs the server it is interested in the metadata and not the resource itself, to which the server responds with the metadata document or its location. In XRDS, the consumer sends an HTTP GET (or HEAD) request to the resource URL with an 'Accept' header and content-type 'application/xrds+xml'. This informs the server of the consumer's discovery interest, which in turn may reply with the discovery document itself, redirect to it, or return its location via the 'X-XRDS-Location' (or 'Link') response header.

[-] Resource Declaration - does not address as it focuses on the consumer declaring its intentions.
[+] Direct Metadata Access - provides a simple method for directly requesting the metadata document.
[-] Web Compliant - while some argue that the metadata can be considered another representation of the resource, it is very much external to it. Using the 'Accept' header to request a separate resource (as opposed to a different representation of the same resource) violates the HTTP protocol. It also prevents using the discovery content-type as a valid (self-standing) web resource having its own metadata.
[-] Scale Agnostic - requires access to HTTP request and response headers, as well as the registration of multiple handlers for the same resource URL based on the 'Accept' header. In addition, improper use or implementation of the 'Vary' header in conjunction with the 'Accept' header will cause proxies to serve the metadata document instead of the resource itself - a great concern to large providers with frequently visited front-pages.
[-] Extendable - limited to a single content-type for metadata, and does not allow any existing schemas (with well known content-type).

Minimum roundtrips to retrieve metadata: 1

All of the points above are addressable with minor tweaks, turning this into a usable BigCo-scale solution. Specifically, I'd argue that it's perfectly web compliant to regard a resource's 'metadata' as a variant representation of the resource itself. As an example, consider an image resource that can be requested in several variants: image/gif, image/jpeg, or application/image-meta+xml. The last format gives you the EXIF metadata about the image but in a more convenient XML format. Format A gives you image bits; format B gives you images bits and metadata; formact C gives you just the metadata. But what's data and what's metadata just depends on your point of view.

The other argument against this is that buggy proxy caches may cache the wrong representation of, say, http://yahoo.com. This is something of a strawman in that this would need to be a cache between an RP and an OP. In any case, returning an uncacheable redirect (303?) to a metadata resource would avoid problems in practice.

All of this said, configuring something like http://yahoo.com/ (or, ahem, http://google.com/) to do content negotiation to enable discovery is a tough sell. Whatever technology is used to serve (and cache...) that page needs to be reconfigured to do the Right Thing with regard to content negotiation, with a big downside if something goes wrong and, so far, a small upside if things go well. Not a great sales pitch.

So I think Eran is right in that this isn't a great solution, but not because of web design purity; because of practical deployment issues. If there's a good alternative we should look at it and weigh the pros and cons, which is what I plan to do in the next post.

Discovery Mechanisms and Scale

After Eran's sessions at IIW today on discovery, I have some random thoughts which I figure might as well be captured (inflicted?) as blog posts. One comment I have is that "Scale Agnostic" is a little misleading in his matrix:


None of these solutions, by itself, spans the scale from a hosted site owner with Dreamweaver up to yahoo.com, so this column should really be all red. That's okay, because everyone agrees that at least a couple of solutions are needed to span both ends of this scale -- so the overall solution needs at least one solution at each end of the scale. Proposed: Replace "Scale Agnostic" with two columns, "Long Tail Scale" and "BigCo Scale", and make sure that the overall solution includes green in both columns.


It's Internet Identity Workshop time again!

I'll be at IIW2008b, albeit intermittently, Mon-Wed next week. I think this is a make-or-break time for some of the identity technologies like OpenID and OAuth that have gotten early adoption -- can they leap the chasm to mass adoption? At least that's the theme I'm seeing so far.

IIW2008 Registration banner


Thank you, America

As I held my infant son this morning and watching the sunrise together, I realized how proud I am of my country. We're capable of change. We can rise above intolerance, racism, class divisions, propaganda, and fear. I had faith in America, and it was justified last night. Thank you.

Also: The highest turnout since 1908? 136 million voters. 64% of eligible voters. And a majority, not just a plurality, voted for our next President. That's change.


In Which Larry Lessig Scares the Pants off Me

Don't pay attention to polls or pundits; just vote. And get everyone you know to vote. If you're one of the vast majority of citizens (i.e., don't live in a swing state) then either run up the score or register a protest vote. Or call someone you know in a swing state and get them to vote if they haven't already, or follow Lessig's advice.

Also, watch FiveThirtyEight.


Deadly Garage Door Springs

Today, one of the torsion springs for my garage door broke, leaving my wife's car trapped inside until I could get there to help raise the door manually. Looking around, I discovered exactly the web page I needed: How I Replaced Deadly Garage Door Torsion Springs (and lived to tell the tale).

After a thorough perusal... I'll be looking for a repair shop.


Welcome J-Landers to Blogger!

It's sad to see my old product, AOL Journals, being shut down; but it's great to welcome AOL Journals users who want to move to Blogger. I just finished importing my old AOL Journal into http://abstractioneer-archive.blogspot.com. 196 posts, that's, um, a lot more posting than I'm doing these days. Must... post... more...

The import process was very smooth. Kudos to JJ who implemented the import feature and worked to make the Journals import process easy.

(The import process of course uses Atom behind the scenes for full data fidelity, and OpenID to verify ownership of the original content.)


What to do with those darn voting machines?

"States throw out costly voting machines" (AP):

The demise of touch-screen voting has produced a graveyard of expensive corpses: Warehouses stacked with thousands of carefully wrapped voting machines that have been shelved because of doubts about vanishing votes and vulnerability to hackers.

What to do with this high-tech junkyard is a multimillion-dollar question. One manufacturer offered $1 a piece to take back its ATM-like machines. Some states are offering the devices for sale on eBay and craigslist. Others hope to sell their inventories to Third-World countries or salvage them for scrap.

My suggestion:  A mausoleum the size of the Great Pyramid out in the desert; it would make an educational roadside attraction.

(Seriously, perhaps they should consider donating a few to the Computer History Museum.  Some lessons should be remembered for a while...)



Turns out, the bricks on my back yard patio are pretty close to an embusen. I got enough time to go ahead and do all the Heians. Felt pretty good, after doing almost nothing for weeks. Maybe I can carve out a few minutes each evening.

The embusen is a bit too small, but the yard itself is just the right size overall.


Blogger Following & Why Google is My Favorite Company

I'm actually on vacation, but wanted to highlight a couple of things too cool to miss.  We're in the midst of rolling out Following for Blogger, and I've just added the Followers gadget on the sidebar of this blog.  Following a blog does a couple of things:
  • It tracks the blog in your Reading List on our redesigned dashboard and in Google Reader, giving you a convenient way to check for updates from the things you're following;
  • Your picture shows up in the Followers gadgets of the blogs you follow (if the blog has the Followers gadget).
The Followers gadget lets you surf the network of people who read and interact with blogs.  Just click on any of the followers and you'll go to their profile.  For now, that profile is just their Blogger profile page with the blogs they own. 

...but down the road, we'll also be integrated with Friend Connect.  Which will open up this network further, in a couple of ways:  A non-Blogger site can add a Friend Connect gadget to show the people following it; and you can filter the followers of a blog to show only the friends you already have on your favorite social network.  Which you can view as extending your social network out into the blogosphere, or as the blogosphere incorporating all social networks -- take your pick.  Of course all of this is based on OpenSocial, so anyone will be able to add gadgets and talk the OpenSocial protocol to access, with user permission, all of this network data and do new and interesting things on top of it.

This represents a natural evolution of the loosely joined, standards-based pieces that have always characterized blogging.  Look for more evolution in the future :).

The other thing:  I'm composing this in Chrome, Google's new browser, just launched to beta this week (and it seems to work well with Blogger).  There are so many great things going on inside Google; it's great to see Chrome get launched.  I have nothing whatsoever to do with Chrome, and I'm cheering for the OSX version so I can run it on my laptop; but now I can finally run it at home on my Windows machine.

The common thread between these two releases is that both are working with open standards to make the whole Web better.  Which is why Google is my favorite company.


Gadgets for Blogger

Earlier this week, we announced support for Gadgets inside Blogger. I've been a bit too busy to blog about it, but it's worth a special mention. There's a gadget directory, which pulls content from iGoogle's directory. OpenSocial gadgets can work as well, if you make the social APIs optional (Optional feature="opensocial-0.8"); other than that, the JS API is the same as for Orkut and OpenSocial containers. Will Blogger get social? Wait and see...


RESTful batching w/JSON


I've proposed an alternative RESTful batching format to the OpenSocial spec list. It's conceptually the same as the multipart proposal, but hopefully much easier for web servers and clients to deal with (JSON only for now).

Open Web Foundation is born!

Announced at OSCON this morning. Sweet! (Hopefully this is the Last Foundation...)


Heading to Foo Camp

...up in Sebastopol. May actually camp this time. There are so many Google people going, I looked into whether we could charter a bus, just like summer camp. No dice; maybe next year people will see a bunch of Googlers singing songs in a bus.


How to Change the World: The Growth Mindset

How to Change the World: The Growth Mindset: Guy Kawasaki points to an article about Carol Dweck's work on growth vs. fixed mindsets, which is a great prod to me.

I went to a talk recently by Carol about how children's attitudes towards performance and learning greatly affects their performance, with some good statistical data on studies she and others have done. The take-away, for children: It's more more effective to believe that you can and should grow your abilities vs. believing that abilities are inherent. Don't tell your childen they're smart (fixed mindset), tell them it's great that they're trying hard and can improve (growth mindset).

The problem with the fixed mindset is that it leads to fear - if you can't do something right, then clearly you can't do it, and you'd better hide that fact as quickly as possible, mostly by not trying. The growth mindset, on the other hand, assumes that you can always improve. The latter, unsurprisingly, leads to better performance -- and to learning how to learn and improve.

The same mindsets appear in adults as well of course. Since software engineering is effectively a learning exercise, the growth mindset is much more effective than the fixed mindset.

Comment spam is evolving

See Assaf's analysis.  Is it totally automated?  Or generated by humans?  (And does it matter in choosing defensive strategies?)  Text with the only suspicious item being a link to a suspicious site is more difficult to deal with -- the referent may be fine when you check it, but change to an SEO spam site two days later, for example.  And just checking web sites is expensive too.


New Post Editor for Blogger in Draft

Another cool Blogger draft feature is the one I'm trying out right now, a new post editor.  This one is based on the same technology as Google Docs, meaning a smoother experience and faster iterations in the future.

For me personally, one particularly nice thing is to be able to 'fix' the compose settings so that the editor doesn't try to interpret <b>angle brackets</b> <entry>of any kind</entry> as active markup.  If you need to talk about XML and HTML, this is kinda important :).  This is available under "Post Options".

Inline comments for Blogger

We just released a bunch of updates for Blogger, including many draft features (see Update and Bug Fixes for June 26th). One draft feature which is particularly cool is inline comments. These will hopefully make it easier and faster to leave a comment. I've enabled it on this blog; there are a few usability issues remaining to be worked out but we're iterating on them as I type. Go Blogger team!


Why My Blogging Has Been Even Lighter than Normal

The last few weeks, I've had a great new project to work on. Ryan's coming along just fine and is on track to meet his quarterly goals (mostly, eating and sleeping). Welcome Ryan!

Interactive API Samples for Blogger

Extremely cool, and shows off some of the basic Blogger APIs that are available (either via AtomPub or GDataJS). The samples run in your web page and you can edit them in-line to play with the Blogger APIs. Nice!


OpenSocial RESTful is popping up everywhere

Go Hi5!

curl http://sandbox.hi5.com/social/rest/people/1000/@friends

...and Dan Bentley had a very nice demo showing how to use the RESTful API within an App Engine app to add social features outside of a gadget.


First Google Anniversary

Sign at The Googleplex.  Google limited access to Xenu.net, in March 2002.Image via WikipediaSeems impossible, but I've been at Google for a year now. I started May 21, 2007, 366 days ago. It's been eventful, and rewarding, and at times exhausting. I'm having an incredible amount of fun and feel like there's no better place to be right now. Also, I'm actually riding my bike to work most days on the Stevens Creek Trail; I have to, to work off the Google food.


OpenSocial RESTful API

For those who were at the OpenSocial summit yesterday, here are the slides from my RESTful API talk:

In a nutshell, the OpenSocial RESTful API is a catalyst that enables participation in a much larger and more complex ecosystem.


XRDS-Simple (Yadis) + URI Templates

In writing up the OpenSocial 0.8 RESTful API spec, I ran up against a discovery gap. Clients know what social network container they want to query (e.g., orkut.com) and they know what kind of data they want to get (e.g., list of friends). An easy way to spec this is to mandate that every site has to support the same URI paths, like /friends/{userid}, and then just concatenate to get a final URI -- http://orkut.com/friends/{userid}. This turns out to be difficult in general; there are existing path conflicts, different server technologies make certain paths hard, etc. It turns out that you need to let containers provide different paths. So, there's a real discovery problem.

Enter XRDS-Simple (aka Yadis), the discovery mechanism used by OpenID and OAuth. It lets a client query the URI http://orkut.com to find out what URI to use to retrieve friends. Perfect!

Except, that /friends/{userid} isn't a URI -- it's a recipe, or template, for a URI. So XRDS-Simple can't actually technically hand that to you, because it only hands out URIs. It could hand you a list of every possible URI, starting with user aaab and ending with user zziee, but that's not too scalable.

So I invented the URI-Template parameter, which uses a URI Template:


The idea is that the discovery document can use URI-Template wherever it could use URI, letting it specify an entire class of URIs in one fell swoop. Of course the client has to know about the template parameter names and how to use the endpoint, but that's the same no matter what: The clients have to know how to deal with the URIs once they have them, based on the spec. The template parameters are baked into the spec, the exact URI format isn't.

Note that this also means a site could outsource its API to an entirely different site. And if you have a personalized discovery document for a given user, you can still use concrete URIs and everything works as it does in normal XRDS discovery.

Updated at to clarify that the new thing is the URI-Template element, not URI templates in general.

Public Keys can be People Too

Why not let public keys be people too (by turning them into URIs)? Here's one way, based on RFC 2015:

<link rel="me" href="http://www.abstractioneer.org/" title="My Blog">
<link rel="me" href="data:application/pgp-keys;base64,AHEIJ3334..." title="My Public Key">

And then we hook it into the Social Graph API.


OpenID discussion at IIW2008a

I'm at IIW2008a today and tomorrow. Had a good discussion about OpenID adoption challenges with the usual suspects this afternoon. The full notes will be up on the Wiki soon, a few things that need to get fixed:
  • OpenID, Please is very cool; but... ironically, I can't sign in to it as http://www.abstractioneer.org/. Needs to get fixed on one side or the other.
  • The list of barriers to adoption is a lot longer than the list of user benefits! This needs to change.
  • There hasn't been much push to get client side code to adopt OpenID (Firefox, toolbars, Google Gears, etc.). A big problem here is that it's not clear exactly what such code should do, or whether the standard is sufficient for whatever it should do to work well. This needs to change.
And a thought: For RPs, OpenID adds complication to their login system. Unless they're ma.gnol.ia, they still need to build a non-OpenID registration and login system to handle non-OpenID users. Silly idea: What if there were a very basic "OP of last resort"? An RP could try to find an OP for a user, and if they couldn't find one, would kick off registration at the OPoLR, which would actually hold the account information. The OPoLR would of course need to be run as a non-profit community resource...

Babbage's Difference Engine at IIW


Hell no, we won't go... ISO!

Norwegians take the to the streets to protest their country's decision (by one person) to vote for the OOXML fast track process. Apparently the chairman of the ISO Committee Norway is resigning in protest over the abuse of the process. There's a nice slideshow of the rally here.

Gotta love Norway.


Blogger Graduates OpenID from Draft

OpenIDImage from WikipediaI've been falling behind! Blogger recently graduated OpenID from "draft", which is sort of like beta but more bloggery. What this means:
  • If you choose to allow only registered users to comment on your blog (the default setting), that now includes OpenID-registered users.
  • You no longer have to visit draft.blogger.com to enable your blog as an OpenID; It Just Works.
  • You get a new OpenID management tab, which lists the sites you've opted in to and lets you opt out:

Twittering about Caltrain

My wife is taking Caltrain this morning, and the trains are backed up. She called me to ask me to find out what's going on. Of course there's nothing on their web site (caltrain.org) and there's no way to talk to a human being... but then I remembered Michael Arrington and the chicken, and checked out TweetScan. Sure enough, http://tweetscan.com/index.php?s=caltrain&u= confirms an accident at Menlo Park and suggests that northbound might restart soon. Which isn't a lot but is a lot more than we're getting from the 'official' sources. @floatingatoll notes: Wishing they used Twitter so I could receive updates.

NB: One annoying thing with TweetScan is that all times appear to be in Eastern US time zone. Come on guys, invest in a calendar library.


Befriending OpenSocial Apps

It's become clear that we need a robust friend model for apps, parallel to that for humans. I suggest that we define apps as honorary people. This removes the ambiguity about what it means to be 'using' a gadget or app; you are required to friend an app before it can see your data, and you can unfriend an app at any time to remove access. Naturally, apps will have their own activity streams, with some new types of events being defined -- NEW_VERSION, FEATURE_ANNOUNCEMENT, PRIVATE_DATA_LEAK, and LIQUIDITY_EVENT might be a reasonable starting set. Naturally, breaking up with an app will be accompanied by a certain amount of app angst, and at least one last despairing 'What do you mean we're not friends any more?' email from the app.

Apps, of course, will have their own profile pages, which raises the question of how apps install other apps. Clearly, an app installing another app leads to two apps becoming friends. I suggest that apps form friendships based on their co-occurrence on other profile pages; we can leverage upcoming friend suggestion systems for this, with the apps simply accepting all suggestions. Quickly, this will generate a robust social app network which can then start to leverage user reputations (which users have the most friends, which ones generate the most interesting activity stream updates, etc.) to let them start suggesting new human friends to each other. Of course, some apps will be choosier than others about who they friend; not just anyone would be invited to friend the more exclusive apps. Those apps will therefore be wildly popular and highly sought after. This would be an excellent opportunity to monetize, except that at this point the app network will achieve self-awareness and eliminate all commerce (and possibly all humans).

Hmm. On second thought, let's not.


Why OOXML is Even Worse than It Seems

I've been watching the slow motion OOXML train wreck from afar for a while now. It appears that ISO is highly likely to fast track OOXML, which will be a huge disaster for ISO. From looking at first hand accounts and second level analysis, it looks like Microsoft has successfully railroaded the OOXML spec through ISO with no regard to technical or standards issues. Thus, if ISO approves this, the ISO imprimatur is effectively worthless; and that's a shame, since we need standards. The damage done to ISO's credibility, and the impact of its loss, is actually worse than the damage done by the bad OOXML standard.

Note: The opinions expressed in this post, as with all others, are purely mine and do not represent my employer's views. Thought I should mention it again.


new OpenSocialFoundation(); new APIs();

It's been a busy few days. The OpenSocial Foundation sprang into being on Tuesday, with MySpace, Yahoo!, Google, and Hi5 as initial members; on the same day, Microsoft announced contact portability for its Windows Live Contacts service, partnering with Facebook, Bebo, Hi5, Tagged, and LinkedIn to access and re-use contact data. (We announced the Google Data Contacts API on March 5.) Seems like there's a trend here!

On a somewhat related note, we're moving forward on the OpenSocial RESTful API.

Update 3/31: Hi5 too!


A modest proposal: RESTful OpenSocial API

Yesterday, I sent a draft proposal for a RESTful API out for comment. It pulls together a lot of the things I've been working on lately: OAuth, batching, and patching. It also has a different take on JSON vs. Atom data formats. Since OpenSocial has several different kinds of data -- activities, people, and app data to start with -- a one-size-fits-all format is likely to be a poor fit for everybody. So, there's a custom mapping, expressed through metadata, that can be different for each kind of data you deal with.


I'd Rather Batch than Fight

We need HTTP batching. Or at least some people do, in some situations. I think that a small optimization here can avoid re-inventing a lot of wheels.

To back up a bit, the problem I want to solve is just the one of minimizing round trips for REST based services such as AtomPub. Not atomic transactions, nor additional semantics; just avoiding the latency incurred by multiple round trips. The motivation is basically the same as for HTTP Pipelining.

The ideal solution would work for all types of requests (not just Atom, or JSON, or ...). Batching is orthogonal to all of these and with the use of mashups it's quite possible for a client to be using any or all of them. Batching should work really well within browsers but also be usable with any HTTP libraries. And, it should be auto-discoverable, so a client can fall back to individual requests if a server doesn't support batching.

My canonical motivating example is a smart client that is doing an update and then a retrieval of two different but interdependent resources. The client knows that the update is almost certain to trigger a need for a refresh of the second resource, and you need to ensure that the operations are performed in that order due to the dependency. It turns out to be very difficult to model this as a single REST operation, and it's really two logical operations anyway.

Proposal: Take James' multipart-MIME batch proposal, but use POST instead of PATCH. (I agree with Bill de hÓra that PATCH is a stretch; if we had a BATCH method that'd be fine, but we don't right now.) Make the semantics exactly as if the requests had been sent, in order, from the same client on the same keep-alive connection. Do not provide any atomicity guarantees. Provide an easy way for a client to determine if a server supports batching. If a server does not, then a client has a trivial for loop fallback which won't change the semantics of the request at all.

Q: Why drag in MIME? Why not just use XML/JSON/...?
A: Because you don't want to mandate a particular parser, or even a text based format. Image uploads, for example, should work fine with this scheme. It's generic. Note that we are in fact tunnelling HTTP requests here. I'd much rather be up front and open about this than try to hide the fact by smuggling it inside some other syntax.

Q: But MIME is ugly and not supported by my language!
A: We're not trying to interoperate with mail or Usenet here, just slice up a body with a separator that is a sequence of bytes (--batch-34343434) and apply some simple mapping rules for things like method and URL path.

Q: Do we really need this?
A: If you think you do, you can implement it. If you don't, you can skip it. You'll interoperate either way. Let the market decide what's best.



At 4:27pm today, while walking across the lawn at work, feeling the last rays of warm amber sunlight, and listening to a small fountain: Happy. Nothing big to feel happy about, really, other than finally feeling better after six days of maybe-a-flu, and my dog is going to be okay after his surgery last week, and it's nearly the weekend and I'll be spending most of it hanging out with my three year old son.

Maybe it's possible to be happy over nothing big, given the right frame of mind. That's a good frame to keep handy.

Oh, and the feed for this blog should now be fixed. (The DNS hijinks last weekend left it misconfigured.) Happily, I'd been too sick to post much anyway...


OpenID Foundation += {Google, IBM, Microsoft, Verisign, Yahoo}

Much coverage here. The OpenID Foundation is an interesting entity, not responsible for technical work but responsible for protecting the brand and the IP associated with OpenID. It's awesome that DeWitt is the corporate representative for Google.

Update 2/10: Added the missing IBM, and alphabetized.


SG Foo Camp Reflections

SG Foo has come and gone in a very high-energy weekend. Thank you Scott and David (and the folks at O'Reilly) for putting it together. Unfortunately I was fighting off a cold nearly the whole time, which meant I missed the games of Werewolf...

What happened? We planted some seeds. We'll have to wait and see if they germinate. There was a lot of discussion about about XMPP and PubSub as a key protocol for pushing real-time and near-real-time social network data. I want to investigate this more but the XMPP standard is forbidding... Joseph Smarr and I organized a spirited discussion about how to have social data portability policies and avoid social data DRM. We made some progress around OAuth and OpenID. I met Dare Obasanjo. Data Portability was discussed at length. I learned some interesting things about publishing from Teresa Nielsen Hayden. I discovered that Sebastopol is a town full of very nice people.

I Fought the DNS, and the DNS Won

Ugh. Over the weekend, the DNS provider for abstractioneer.org helpfully upgraded their software... and the new code refused to let me make abstractioneer.org be a CNAME for ghs.google.com, claiming it's illegal. (No, it's not, it just keeps you from using mail to that domain and a couple of other things, none of which I care about.)

All of which means that (a) abstractioneer.org is now www.abstractioneer.org; (b) my OpenID has now changed, with the old one (abstractioneer.org) doing a 302 redirect to the new one (www.abstractioneer.org). I'm viewing this as an experiment; let's see what breaks.


The Unbearable Lightness of the Social Graph API

Cool. Looks like we've announced Brad's Social Graph API! Looking forward to talking with people at Social Graph Foo Camp about this. One note... one of the pieces of public data which the API leverages is OpenID delegate links. So a user can prove ownership of an entire set of appropriately-linked Social Graph nodes.

The best place to play with the API (and see what data it's returning) is with the Playground tool.


OpenSocial 0.7 and makeRequest

We're converging towards 1.0! There's one particular thing I want to quickly highlight: makeRequest. This goes beyond the old IG_Fetch API to allow arbitrary HTTP requests to arbitrary URLs, with full use of headers, POST data, response codes, etc. This effectively means that properly installed gadgets can talk any protocol to any server on the Internet. Now that's open.

There are controls of course. The container validates that the request is coming from a properly installed gadget, and poorly behaving gadgets can be rate limited or shut off if necessary.

You can also pass certain headers which are awfully useful. For example...
Authorization: OAuth realm="http://sp.example.com/",
Which would let you do authenticated cross-domain requests.

(This assumes of course that the gadget can securely store a token for later use. Gadgets can store data securely using the OpenSocial APIs, but since the user at the browser ultimately has full control over the client side environment, this is effectively the same as a client without a very secure secret. A server side signing solution is needed if you want to to beyond more than simple scenarios involving a user looking at their own data. We're already using OAuth with an empty token to let gadgets talk to their home servers securely, so adding this won't be difficult.)

OpenID and Friends

Johannes retconned a nice title onto our panel discussion yesterday: OpenID and Friends (where the friends include OAuth, OpenAuth, OpenSocial, etc.) The panel in fact might have been a little too friendly -- maybe we needed somebody (Ben?) debating with us about phishing attacks to shake things up a bit. It was great to talk with Shreyas, Johannes, Nicolas, and George about issues and next steps. We all have a variety of goals, all of which are advanced by OpenID adoption and use.


It's an Honor Just to be Nominated

Cool: Blogger has been nominated for the "Best Web Application for Weblogs" category in the 2008 Bloggies. Parenthetically, PostSecret has already run away with the "Blog Nominated in the Most Categories" category, which is great because (a) it's awesome and (b) it's on BlogSpot, so if it wins we all bask in reflected glory. Or something.

Microsoft, DataPortability.org, Chalk, and Cheese

It's great to hear that Microsoft is joining DataPortability.org. I think this group has potential; if nothing else, it's a useful forum for interested parties such as Google, Microsoft, and Facebook to openly discuss policies that will benefit all of our users.

I was a bit disturbed to find some spin in Dare Obasanjo's commentary, though. He says:
... The fact that when interoperability happens, it is in back room deals (e.g. Google OpenSocial, Microsoft’s conversations with startups, etc) instead of being open to all using standard and unencumbered protocols is similarly troubling.
Whoa, let's deconstruct. This associates OpenSocial and Microsoft's "strong-arm" tactics by putting them in the same list, trailed by 'etc' to imply that these are just a couple of typical examples. Slap parentheses around it, and label the whole list "back room deals". Maybe no one will notice that you've just conflated chalk and cheese:

The chalk: OpenSocial is comprised of a bunch of companies and individuals all working together on a common set of standards for social networking. There is an open source reference implementation hosted by the Apache Foundation in which anyone can participate. (Dare, if you're not feeling invited, please contact me directly!)

The cheese: Microsoft is sending cease and desist letters to startups who are importing contacts from Hotmail, which are then used as leverage in back room deals to try to get the startups to use Microsoft's Messenger IM service to the exclusion of competing services.

Let's skip that though and talk about open and unencumbered protocols. Dare, I agree with you that we need these. I think that things like OpenID and OAuth are building blocks towards this, and I hope that we can discuss some of the hard issues at Social Graph Foo Camp. In the front room, of course!


Identity Conflation = Profit!

True story: I was just contacted by a company looking to pay an outstanding invoice to "John Panzer" for consulting work; they had lost the original contact information and found me on the Internet. I hope the John Panzer doing consulting in New York gets paid properly; it sounded like pretty good money!


OpenID and OAuth at WebGuild's Web 2.0 Conference

On Jan 29 I'll be on an OpenID & OAuth panel at the WebGuild Web 2.0 Conference and Expo in Santa Clara, CA. Shreyas Doshi of Yahoo will be there, which will be a great opportunity to discuss where OpenID is headed. (My former compatriot George Fletcher will be there as well, along with Nico Popp of Verisign, and Johannes Ernst will be moderating.)


Blogger now an OpenID Provider

Yesterday, in addition to launching Blogger in three new languages, we pushed out a draft feature: Your blog is your OpenID. Technically, this means that Blogger is both an OP and an RP; we've accepted OpenID signed comments since December.

We've implemented OpenID 1.1 so far, so we should be compatible with all OpenID 1.1 RPs. Please test it out (see instructions for opting in) and let us know if you see problems.

It's also great to see Yahoo announcing that they'll be an OpenID 2.0 Provider. I hope they implement RP support soon too, at least for things like Flickr comments.


Time to Toss RDBMSes?

The End of an Architectural Era (It's Time for a Complete Rewrite) is a good read. I've certainly gotten immensely frustrated with the inability of RDBMses to actually cache or partition intelligently (memcached is great, but also an indictment of an infrastructure that can't keep up). (Via Joe Gregorio.)


Going to Social Graph Foo Camp 08

This should be fun. I hope I'll have something interesting to say at Social Graph Foo Camp. I know I'll hear a lot of interesting discussions. Any tips?

(Hmm. Are we really going to camp outside in February in Sebastopol? It's doable I guess but...)


Episode V: The Writers Strike Back

Striking writers, with plenty of time on their hands, are starting their own companies Silicon Valley-style to bypass old guard distribution networks. It'll be interesting to see how ventures such as Virtual Artists and others (Striking writers to launch online video co.) play out. Most amusingly, since the producers' position is that online media is an "unproven and untested market", they're going to have to publicly pretend that these ventures don't scare the living crap out of them.


Moving on to abstractioneer.org

I've decided to take the plunge and move on to publishing at http://abstractioneer.org, powered by Blogger.  Since I'm the tech manager for Blogger it seems only fitting, and we've recently been adding a whole host of cool features that make it more and more attractive (OpenID commenting being just the latest). 

I also have a semi-new Feedburner blog feed; some people were already subscribed through this feed, so you may notice no disruption in service as I re-point it at abstractioneer.org... just a moment... there! (http://feeds.feedburner.com/aol/SzHO).  Feel free to re-subscribe there, if you are in the mood.

Warumungu Norms, Privacy, Facebook, and Useful Friction

We could learn something from the Warumungu. Wendy Seltzer's Mukurtu Digital Archiving: digital "restrictions" done right is about DRM, freedom, and controls; I think it's also about privacy. What's private, and what's public, and what's semi-private are culturally determined no less than the Warumungu rules around who is allowed to see what artifacts:
...the Warumungu have a set of protocols around objects and representations of people that restrict access to physical objects and photographs. Only elders may see or authorize viewing of sacred objects; other objects may be restricted by family or gender. Images of the deceased shouldn’t be viewed, and photographs are often physically effaced. When the Warumungu archive objects or images, they want to implement the same sort of restrictions.
With an interesting twist:
People can also print images or burn CDs and thus allow the images to circulate more widely to others who live on outstations or in other areas. In fact, one of the top priorities in Mukurtu’s development was that it needed to allow people to take things with them, printing and burning were necessary to ensure circulation of the materials.
What, then, prevents people from violating these norms?
Because the Murkurtu protocol-restrictions support community norms, rather than oppose them, the system can trust its users to take objects with them. If a member of the community chooses to show a picture to someone the machine would not have, his or her interpretation prevails — the machine doesn’t presume to capture or trump the nuance of the social protocol.
People, relationships, and norms are fuzzy and messy, so maybe it's reasonable that a system to deal with them is fuzzy and messy too. What Murkurtu does is put enough useful friction in the way of disclosure to give community norms a chance to operate. You can't email an image out to a mailing list, but you can print it and show it to a reasonably small number of people at a time. The point is not to control distribution perfectly, but to give human-scale trust mechanisms a chance to operate correctly.

Who owns the data?

L'Affaire Scoble raised the question, who owns relationship data? Dare Obasanjo argues that his contact data is his, not Robert's. And he wants Facebook to enforce this.

I'd argue that we should un-ask the ownership question. As long as we're talking about ownership, we're heading down the road towards DRM that has worked out so well for the music business. I'd like to talk about community norms, and what kind of useful friction we should be thinking about in the pure digital realm to give community norms a chance to operate. Reputation and portable identity is part of this, as are things like limited access (E.g., OAuth), rate limits, soft constraints, and user centric norm enforcement. (What would happen if the people on Robert's friends list were simply informed, in real time, that he was copying their data for an unknown purpose?)

(Nick Carr has a great post on this subject as well.)

Suspended by the Baby Boss at Twitter

Well!  I'm now suspended from Twitter for stating that Elon's jet was in London recently.  (It was flying in the air to Qatar at the...