Ascription is an Anathema to any Enthusiasm

Here’s a fun idea, a generalization of MIME types.

As a prolog let’s look as details of one of two one-click subscription solutions mentioned in the prior posting. The one that avoids a central hub/server but instead requires that we do some rework on all the clients. That cost got me thinking about how to pack more value into the rework.

In the blog subscription scenario the blog offers a “subscribe now!” button. Clicking it sends to their browser/reader a document which the browser/reader reacts to by creating a subscription. That action is triggered by the MIME type of the document. In Tim’s scenario MIME type is application/atom+xml.

If your managing your blog feeds using a local news reader as I am (e.g. NetNewsWire) then it’s an easy matter for the reader to register as the handler for that MIME type. Things are a bit harder if your new’s reader a web site, for example BlogLines. In that case you need to install something that catches incoming documents of this MIME type and turns around and hands them off to the web site.

Can we generalize this idea? Certainly. How much value can we pack in this subscription offer MIME type?

A simple step up in the idea is to create a MIME type document bouncer. An application you install on your machine and when a document of a given mime type is received or opened it turns around and redirects that document off to helpful website. For example such a beast could help users view documents that aren’t widely supported. There are plenty of these! This would useful.

A nice improvement on that would be to provide a way that helpful websites could plug into this easily. For example. Bob implement a service that can convert documents of MIME type ‘application/powerpoint’ into other formats - for example SVG, Open Office, etc. Bob’s website is a pain to use. Bob needs a way to tell the document bouncing application about his service. So he adds “Add Converter” button his site. Should the user click that a document sent to the user’s reader/browser (might have the type application/dispatch-offer). That gets handed off to the document bouncer which update’s it’s dispatch-tables/pattern-matchers and next time a document of type application/powerpoint come over the threshold it can offer our happy user the option of the document to Bob’s conversion service.

In my fantasy this can get even cooler. Going back to the blog example. The blogs provide a ‘Subscribe!’ button, the document that returns can describe a number a means of subscribing - email, rss, atom, whatever. The new reader(s) can place a number of patterns into the dispatch negotiation program. After hitting the subscribe button the user is presented with a menu of choices. He that allows him to route the subscription offer to the handler that is appropriate for the blog in question. He can redirect the subscribe offer to BlogLines, NetNewsWire, depending on what fits the situation.

One last step. The data feeds from blogs are just the tip of the iceberg. For example all my financial institutions have data that I pull down from them in service of keeping my financial house in order. Each one of these ought to, but doesn’t, have a “get data feed” button. Stitching up the links, for example passing those links thru to my accountant, is a huge plumbing problem.

It’s a fun idea that we might be able to create a very general scheme that allows data providers to describe what they have to offer - a set of choices - in a single document. It’s also a fun idea that data consumers could describe what they offer to handle. Giving the the offer to provide, and offer to handle a MIME type and a manager that the user controls we can keep the user control of making these linkages, where he belongs, while making the user’s experience tractable.

In my father’s day every scientist and engineer paid a regular tax to CRC for access to his table of logarithms, etc. His copy of that book which he gave me when I went off to engineering school is so worn that he rebound it in a piece of cordoroy. These days many pay a tax to Wolfram for something analogous. So that CRC considers Wolfram a very threatening competitor shouldn’t surprise anybody.

What a sad story! It’s really amazing how common this pattern is; a public good emerges. A private entity finds a means to gain ownership of it. Private entity then proceeds to destroy the public good. It’s enough to make you adopt the GNU license.

By now we all have come to understand that links are a unit of currency. The number of inbound links you have, the number of customer accounts, the number of subscribers to your site’s feeds are all metrics that denote something about how successful your doing. In turn we know that links create graphs and graphs of links often have power-law distributions with amazing class distinctions betwix the parties in the graph. We know those class distinctions are not a consequence of the merit or value created by the links but instead of how fast the graph is grown or how the nodes merge as market share is rolled up thru mergers. So we know a lot about links as elements in the process of creating wealth. Every scheme for creating links will become the target of bad actors.

We also know that links play a role in the identity problem. That the more you know about a persons links the more accurate your model of him can be. We know that accurate models of users are fungible. A better handle on who the user is enables targeted advertising and more highly discriminated pricing. A better handle on who the user is enables transaction costs to be reduced. Single sign on, one-click purchasing, automated form filling are not the only examples of that.

It surprises me that we need to be reminded of this each time we encounter another effort to create a means to creating a large quantity of links.

This month’s contribution to the let me help establish a mess of links party is one-click-subscription. The puzzle in this case is how to lower the barriers to subscribing to a blog. Solving this problem requires moving three hard to move objects - all the blogs, all the readers, and sticking something in the middle between them. Both suggested solutions need to move all three; but they vary in where they put their emphasis. The blog hosts are probably the easiest of the three to move - they have an incentive to move and the market is already very concentrated.

One plan is the classic big server in the sky plan. Everybody rendezvous around the hub server. Requests to subscribe are posted to the hub. The user’s reader keeps it’s subscription set in synch with the hub. The business model suggested is a consortium organized by the common cause of a stick - fear of somebody else owning this hub - and a carrot - the bloom of increased linking it would encourage. Since early and fast movers will capture power-law elite rewards in such linking build outs there are some interesting drivers to build the consortium. Large existing players should find it advantageous to get on board. The principle problem with this plan is it’s a bit naive. A consortium of this kind is likely to become player in any number of similar hub problems, for example identity. This hub will have account relationship with everybody. It would know a lot about everybody’s interests. To say the least, that’s very hotly disputed territory. This plan has triggered more discussion than the following plan.

The second plan that’s been floated is to introduce into the middle a standard which blogs can adopt and readers can then leverage. This implies changing the behavior of most of the installed base of blog readers. The structure of that installed base is less easily shifted. The idea is to have the subscribe button return a document to the client’s browser (or blog aggregator/reader) which describes how to subscribe. Automation on the reader side can then respond to that information. This means introducing and driving the adoption of a new type of document, a new MIME type. It probably means installing a new bit of client software on everybody’s machines. The browser market leader would have some advantages in making this happen; and could there for very likely coopt any success in this plan to drive users to use his aggregator. But then that may only point out that the only reason we have a vibrant market of blog reading solutions is because the dominate browser has been dormant for a few years.

These are hard problems, and this is only one of many we currently face.

I’m not sure why this paper is called ‘Viral Communications” (pdf) but it’s fun and two things leapt out at me.

Future Proof: “Upon installation, the purchaser will have the expectation that they should work for the expected lifetime of the device itself independent of any other changes in the … environment.”

“… a commons where each new cow adds grass.”

I need to go back and add “future proof” to the reasons why people standardize; it’s a varation on what I call there “prevent stranding.” The cow line is a nice way of framing the club-good boundary maintenance problem.

My problem with the term ‘viral communications’ is that it’s so similar to ‘viral marketing.’ I know what viral marketing it; it’s marketing communication that manages to parasite on somebody else’s communication and there by captures some legitimacy which it can use to get past the recipient’s defenses against marketing. The paper is about systems of collaborating devices that use a modicum of coordination to create scalable distributed networks with lots of bandwidth. The vision is to use standards (the ones that guide that collaboration) as a substitute for the lawyers at the FCC.

Following up on something Clay mentioned the following chart plots the distribution of tags for four popular URI at del.icio.us. Each line is the tags assigned to one URI. Each point is one tag, the vertical axis is how many times that tag was used to label that URI. The more popular tag for a URI is on the left; the least on the right. Note the power-law distributions.

I’m extremely surprised that the slopes are so similar. Of course a sample of four isn’t very large. If tags were drawn at random from the english language the slope would be slightly larger than -1. I’d assume that as the page becomes more focused the slope becomes more extreme. So that is, I guess, a hypothisis that if you find all the pages with more than 500 tags and extract for each of them a score, i.e. the negative of their slope. The high scoring ones are very focused while the less focused ones are more generic; i.e. scattered over the space of all things tag-able in english.

The audience of del.icio.us readers presumably is also critical in determining the slope. If they are all java programming, web site hacking, 20-30 year old geeks then that certainly imposes a high degree of focus. Or if you like message discipline.

Sadly I don’t see a trivial way to find a random set of pages with more that 500 tags.

Update: More here.