Track Built on Open Specifications

The Google Buzz team just rolled out the Track feature, which lets you subscribe to real time updates for search terms via PubSubHubbub.   It's pretty awesome, and builds on top of the work we've done for the Buzz Firehose.  A search query is just like any other URL -- say, https://www.googleapis.com/buzz/v1/activities/track?q=coffee+OR+tea -- and you can subscribe to it with PubSubHubbub using existing code.  In fact that URL will work in any PubSubHubbub-enabled client (like Google Reader).

Experimental Magic Signatures Draft

picture via oskay

This morning, I put up an experimental Magic Signatures draft for comment.  This is a fairly extensive reorganization of the spec, so it would eventually become an -01 version of the Magic Signatures specification.  It is still provisional and changing and it really needs feedback (including implementation feedback).  It adds two optional pieces, and solves a bunch of unspecified things, and is organized so as to make it easier to use as a building block in specifications other than Salmon.

The major additions are:

• HMAC private key signatures
• Ability for signer URLs to provide signer keys on GET directly
• A JSON based format for signer keys 

The major (possibly breaking) change from the prior version is that public keys retrieved via XRD are retrieved via XRD Property elements rather than Link (since all current applications are using inline keys in any case, and this is more parallel to the new JSON format).

Looking forward to feedback on this experiment.  If it's successful, we'll rev both Magic Signatures and tweak Salmon to incorporate it.

We Built this Firehose on Open Specs

photo CC joevans

Last week, we launched the Buzz Firehose feed.  You can see it in action at the sample Buzz Mood app (code).  One thing which we didn't highlight too much (though DeWitt did) is that this is completely built on non-proprietary protocols and formats: Atom, PubSubHubbub, and Activity Streams are able to deliver real time push updates easily and quickly.

We did do some special things on the supply side for efficiency.  If you GET the firehose feed you'll see that it never contains any updates, just feed metadata and the hub link.  Conceptually, it contains the last 0 seconds of updates.  This is primarily because it doesn't make sense to poll this feed, so it exists only to provide a subscription mechanism.  Internally, for efficiency we're pushing new updates to the hub with full data rather than pinging the hub and waiting for it to poll the feed.  But, we're using the standard Atom format to push the data. The hub is doing coalescing of updates so when a bunch come in over a small period of time, as with the firehose, it will send them in batch every few hundred msecs to each subscriber.  So the POSTs you get for the firehose will almost always contain a feed with multiple entries in it -- whatever has come in since the last time you've received an update.  There are also some tweaks to the hub retry configuration; if your server doesn't keep up with the firehose the hub will back off fairly quickly and won't attempt many retries.

XAuth is a Lot Like Democracy

XAuth is a lot like democracy:  The worst form of user identity prefs, except for all those others that have been tried (apologies to Churchill).  I've just read Eran's rather overblown "XAuth - a Terrible, Horrible, No Good, Very Bad Idea", and I see that the same objections are being tossed around; I'm going to rebut them here to save time in the future.

Let's take this from the top.  XAuth is a proposal to let browsers remember that sites have registered themselves as a user's identity provider and let other sites know if the user has a session at that site.  In other words, it has the same information as proprietary solutions that already exist, except that it works across multiple identity providers.  It means that when you go to a new website, it doesn't have to ask you what your preferred services are, it can just look them up.  Note that this only tells the site that you have an account with Google or Yahoo or Facebook or Twitter, not what the account is or any private information.

Some objections to all of this are natural; I had them too.  Below are my answers (note: I'm not speaking for Google here, just myself, but I believe these answers are consistent with what people like Chris Messina and Joseph Smarr are thinking).

1. Objection:  The implementation relies on a single domain.  Answer:  The current implementation does this due to restrictions in browser security models.  There is no essential reason for that single domain to exist, there is no data stored on the domain's servers and no web services accessed from it.  It just stores the JS used to implement the API today.  In theory one could write a browser extension that maps "xauth.org" to "127.0.0.1", make sure to serve up the JS from a local web server, and XAuth would work fine.  A better use of time is to convince the browser vendors to support XAuth natively.  Which leads to objection #2...
2. Objection:  This should be done by the browsers, not by a back door via a JS API.  Answer:  Yes, it absolutely should, and the best and fastest way to make that happen is to get a deployed solution and user experience supported by many sites as quickly as possible, then swap out the implementation.  It is trivial to replace the XAuth JS core with calls to a browser solution.  In fact it'd be great to figure out a good way to make this happen automatically with feature sniffing, though for that we'd need a very stable JS interface.  And for that we need... field deployment experience!  XAuth is a great bootstrap to a browser centric future solution.
3. Objection: But the central domain name should not be managed by a single party, even in the interim:  Answer: Yes, that's true, and the parties involved are working to get it managed by a neutral third party who can be trusted not to do something bad.  Note that we can know fairly easily if some domain owner starts to do bad things as they'd have to mess around with the publicly visible JS to get information to go anywhere but the users' local computer.
4. Objection: It should be opt-in per browser, not opt-out.  Answer:  Note that XAuth doesn't prevent opt-in semantics on the part of identity providers, it just doesn't enforce it.  All other things being equal, yes, it would be better to force the default to "off" and ensure users understand what they're doing when they turn it "on".  The last bit is hard; a choice that users don't understand is even worse; it doesn't really solve anything but hurts adoption -- and gives proprietary alternatives, which don't require opt-in, a big advantage.   Again, a browser-native alternative may be able to solve this.  An XAuth ecosystem, already in place, ready for browsers to use, is a powerful incentive for them to do this.

Eran writes: "This is a misguided attempt to solve a problem browser vendors have failed to address. It is true that getting browser vendors to care about identity and innovate in the space is a huge challenge, but solving it with a server-hosted, centralized solution goes against everything the distributed identity movement has tried to accomplish over the past few years."  (Emphasis mine.)  It is precisely my hope that XAuth will help bootstrap the ultimate goals of the distributed identity movement, and that it will actually accomplish things in a short time frame while setting the environment up for a better solution in the future.

[Updated:  You may want to refer to the original announcement of XAuth back in April, where many of these objections have already been answered.]