<nettime> The disruptive Web

["Michael Gurstein" <mgurst@vcn.bc.ca>]

Jon Udell's library experiment is here
http://staging.infoworld.com/articles/ap/xml/03/01/06/030106apapps.xml?Templ
ate=/storypages/printfriendly.html

Copyright Infoworld.

January 3, 2003 01:01 PM PST

The disruptive Web
Jon Udell

I DID AN EXPERIMENT last week that nicely demonstrates the disruptive
potential of Weblogs, Web services, and digital identity. My experiment
began with two observations.

First, I noticed myself buying books from Amazon.com not on the basis of
Amazon's recommendations but on the book-related blog postings gathered by a
clever service called All Consuming (www.allconsuming.net). Like Blogdex
(http://blogdex.media.mit.edu), Daypop (www.daypop.com), and Technorati
(www.technorati.com), All Consuming measures the diffusion of links
throughout a large network of blogs. But while the others measure the
fluctuating interest in blogs themselves, All Consuming makes books the
organizing principle.

All Consuming displays books mentioned on blogs in the last hour or week,
summarizes and links to the citing blogs, and, using Amazon, Google, and
other APIs, wraps book details, price comparison, and purchase apparatus
around the discussion. Finally, it exports an RSS (Rich Site Summary) feed,
an XML news-syndication format. As a subscriber to that feed, I'm reminded
daily of the books being discussed on blogs. The reminders and the
discussions they link to have raised my awareness of books and prompted me
to buy them more often than usual.

The second observation followed directly: This was getting expensive. Could
the local library help meet my surging demand for books? Its online catalog
knew whether a book was locally available, but that information didn't
appear in the right context. To switch from Amazon or All Consuming to the
library's site for a requery doesn't take much effort. Once we establish a
context, though, we are loath to abandon it. The question became how to
avoid that context switch.

There was never any doubt that integration was possible. All these systems
use ISBNs (International Standard Book Numbers) to identify books. When All
Consuming scans blogs, it looks for ISBNs to find postings that mention
books. All Consuming also uses ISBNs to create the SOAP calls that pull
Amazon information into its Web pages and to form the URLs that send users
to Amazon pages about those books.

Unlike Amazon, the library systems don't offer XML APIs. They appear to be
merely form-driven Web sites. But hidden within those forms are the URLs
that make every form-driven Web site a protoservice. And embedded within the
search URL is the magic ISBN number.

I knew that manually copying the ISBN from one browser to another wouldn't
satisfy most people. But I blogged that solution anyway because it was an
interesting partial result that would provoke the blog hive mind to suggest
how to take the next step. And it promptly did. Jenny Levine
(http://theshiftedlibrarian.com) noted that my local library uses the same
system as hers and that the system's vendor serves more than a thousand
libraries. Another blogger, Scott Reynan, reminded me that bookmarklets,
which are JavaScript snippets embedded in HTML links, can be installed in
browsers' toolbars. A bookmarklet, when clicked, could inspect the current
page's URL (say, at Amazon.com), capture the ISBN, form a library search URL
incorporating the ISBN, and invoke that search in a new window.

One problem remained: How would I configure the bookmarklet for a given
library? Reynan suggested a geographical method: Request (or discover) the
user's postal code and map from it to the nearest library on the vendor's
list. That was plausible, but the mapping wasn't readily available. Then a
laughably simple solution presented itself: Generate a list of bookmarklets,
one per library, and blog it. A user who visits that blog page and finds a
local library there can drag its link to the toolbar to install the
bookmarklet.

Thus a new service, potentially useful to millions of people, was deployed
by blogging a Web page containing 900 links. The meme spread quickly in the
petri dish that is the interconnected blog network. My published RSS feed
spread the news to my subscribers, who passed it along to their subscribers,
and soon the blog indexes picked it up and spread it even more widely. By
the end of the day, the technique was verified to work with many libraries
in the United States. What's more, it had mutated. Reports came in from
around the world about adaptations that worked with library systems from
other vendors. These mutations, packaged as HTML links, propagated through
the blog network. People from Syracuse, N.Y., to Sweden found links in their
RSS readers that could be installed and used immediately.

The vendor of the library lookup system that our bookmarklets were invoking,
never having imagined or intended this disruptive outcome, hastily yanked
its listing of the 900 libraries. The following day, the listing was just a
ghost in the machine, manifesting itself in Google's cache and the Wayback
Machine. What seemed to be an informational Web page turned out, to the
vendor's surprise, to be a Web services directory. Moreover, the software
that made it easy for people to tap into those services had a special
property. Hyperlinks are the currency of the blog network. Packaged as
hyperlinks, these scripts merged seamlessly into that currency flow. The
medium for the exchange of ideas and the medium for the exchange of software
became one.

These are the ideal conditions for what economist Hal Varian calls
"recombinant growth." When it's viral, of course, such growth can also
become cancerous. Malicious e-mail is the famous example, and it raises an
interesting question. Most of us have learned by now to never click on
executable e-mail attachments, even when they appear to come from friends or
colleagues. Why then were users of these bookmarklets willing to ignore the
warning (in some browsers) that the links contained possibly unsafe code?
Here's the difference: digital identity. Although we can bind digital
identity to e-mail messages by signing them, almost nobody does. The
cumbersome mechanics of the PKI (public key infrastructure) certificate have
made it a mainstream nonstarter. As a result, we can trust no one. That
policy is formalized in the emerging white-list-style e-mail services, which
classify all messages as spam unless the sender has registered with the
recipient.

Blogs work differently. Instead of n-way authentication, there is only
one-way authentication. Each author authenticates to a hosting service to
post there. Each blog is bound to and emblematic of its author's identity.
The popularity rankings that the blog indexers incessantly churn out are
also measures of trust. As a longtime blogger, I've built trust that comes
partly from speaking consistently over time with a credible voice and partly
from peer validation expressed in the currency of links. Everyone can see
that to violate that trust by spreading malicious code would be a
self-destructive act.

If you're creating a Web service that you hope will have a disruptive
impact, the lessons are clear. Support HTTP GET-style URLs. Design them
carefully, matching de facto standards where they exist. Keep the URLs
short, so people can easily understand, modify, and trade them. Establish a
blog reputation. Use the blog network to promote the service and enable
users of the service to self-organize. It all adds up to a recipe for
recombinant growth.

#  distributed via <nettime>: no commercial use without permission
#  <nettime> is a moderated mailing list for net criticism,
#  collaborative text filtering and cultural politics of the nets
#  more info: majordomo@bbs.thing.net and "info nettime-l" in the msg body
#  archive: http://www.nettime.org contact: nettime@bbs.thing.net