Ascription is an Anathema to any Enthusiasm

Rainer Joswig has released a 44 Meg Quicktime video showing some of the features of the Lisp machine. I found this extremely nostalgic. The Lisp Machines did all this in the middle 80s; and large portions of it in the late 70s.

The announcement in his blog implies that this is one of a series so he may have already said some of the following.

One thing to note is the integration of four interface styles. One style is a classic editor development loop. The second style is a rich graphic user interface; you need to wait till the little demo of the drawing editor to see that kind of UI. The third is an semi-english language like interface; you can see that in some of the commands he types.

The fourth, and this one is waiting for somebody to rediscover it, is that everything that is rendered into the output typescript retains knowledge of what type it is. That allows the mouse to move over the transcripts and everything that was output is “alive.” For example when his mouse moves over a symbol the system knows that it’s a symbol and the menus offered are appropriate for a symbol. This is, no surprisingly, true for small small types and large types. So when his mouse moves over the print out of, say, a system definition the menus then offer up operations like patching that system.

All four UI stand on a single foundation; a bridge between the dynamic type of the objects in the system and various “presentations” of those objects into the UI. Interaction is then intermediated by the nature of those presentations. That allowed you to write commands that would be offered up to the user when a given gesture was made on an object of a given type that appears in a given style of presentation.

You can see some of the notation for that in the simple examples he goes thru. The first few examples differ only in the kind of UI the interaction takes place within.

The demo ends with an example of the integration of source control the mechanisms for patching running systems. These are the kinds of systems that we are now having to rediscover to be able to respond quickly when hackers find security flaws in our running systems.

Tim Oren writes a nice little Eulogy for HyperCard.

A few things stick out in my mind about Hypercard.

It was incredibly fast. Software today rarely seems as fast. It could do a page turn faster than my G4 seems to be able to type a single character. It did could do these sweet builds from one page to the next that continue to this day in presentation software. You never saved data. That reminded me of APL workspaces.

It was one of the first applications to take seriously the idea that behavior might be inherited not in via the type/subtype hierarchy but via the document enclosure topology. So a button that when a button invoked the function F hypercard would search for the implementation of F first in the button, then the page, then document.

Tim points out that Hypercard wasn’t broken into client and server as we would likely do today. More important to me at the time and still today was that there was nothing you could do in the UI that you couldn’t do in the scripting language. That made it possible to do all kinds of very sweet animation on top of the amazing painting engine. This design pattern of a strong deep data type with a scripting engine laid over it is very powerful. You see it in Autocad, Emacs, and Excel. A lot of software these days the only deep data structure is - tada: the database. That gets dull pretty quickly.

When the Mac first came over the wall in 1984 I was fascinated by how it empowered a huge population of people to use computers. For the first time you really could bring one home and get to work writing that novel. A lot of people complained that the machine wasn’t friendly to programmers, which struck me as totally missing the point.

So I got curious about how you might empower a large population of people to program. Could you create the same event over again, this time enabling people to write software. The only example of even coming close at that point was the spreadsheet.

Hypercard did exactly that. It never competed with the installed base of developers. Instead it generated this amazing bloom of new tiny little applications. Instead it illustrated what happens when you manage to hand a useful tool over to a large unserved population of amateurs. The tail of the power-law curve.

I wonder, if flash is the closest modern equivalent; maybe so.

Adverse Selection is a term used in the insurance industry for a particular kind of market breakdown. The breakdown proceeds in a cycle where the distribution of customers shifts toward higher and higher risk buyers while the insurance company keeps raising prices to compensate until the only buyers who buy are truely horrible risks.

In all markets buyers and sellers have differing amounts of information about the goods being exchanged. For traditional manufactured goods sellers tend to know a lot about the costs of production while buyers tend to be better informed about the benefits they can capture after purchase. I.e. buyers tend to know more about the future and sellers more about the past.

Transactions are more likely to take place in the presense of these information asymmetries. If the buyer and seller have different models of worth then after the transaction has closed both parties can be happy with the outcome. If they have identical models then the best they can do is close the transaction with both parties meerly satisfied that they didn’t get taken. To an optimist this means that markets make everybody happier; to a pessimist it means that any transaction leaves money on the table.

The adverse selection senario given above is interesting because both buyer and seller are attempting to predict the future. A successful insurance company manages, thru the magic of statistics, to gain an upper hand in the information in balance.

One of the definitions linked to above gives this very concise definition of adverse selection: “A situation in which market participation is a negative signal.” Anytime a buyer or seller enter a market and begin to participate they reveal some information about the hand they have been dealt. When a market begins to fall apart via the process of adverse selection the market becomes structurally flawed so that only customers who are truely lousy risks will still enter the market. Once this happens then entering the market tends to signal that your a lousy customer.

Market structure creates selections pressures on both the buyers and the sellers. A market maker strives to maintain markets were these selection presures don’t drive the market in any of many the wrong directions. So while a “adverse selection” is a term used in the insurance industry it certainly would seem to be equally applicable to any number of other markets and in all cases it would seem to apply to both buyers and sellers. If the market is poorly structures then as tranactions clear the buyers and the sellers are both happy; but as the future unfolds one or both of them become unhappy.

I love this quote.

Part of the problem was how arrogant we were. We believed that we could spend a couple of days watching trained lawyers perform a highly-skilled job, talk briefly to them, and then make their jobs completely obsolete.
- here

It resonates nicely with the fun that Clay’s been is having tearing into the social software dudes; even if I don’t entirely agree with him.

When I young I used to go to parties with lots of artists and theater people. They would ask what I did and upon replying that I wrote software a painful silence would follow. I’d sometimes indulge myself by inserting toward the end of that silence the assertion. “My dream is to put an entire city of people out of work!”

In reality my dream is to create new cities of people. Don’t tell anybody; but a lot of that arrogant social software seems to be doing just that. Who’d a thought, weird huh?

Back to the Internet identity problem; or how we solve to solve the problem of letting users safely and easily reveal personal information, as well as the problem of how that interacts with various authoritative entities.

In the real world we reveal substantial amounts of information casually – hair color, language, approximate age, various fashion statements. We adjust that revealing dynamically. We wear different clothing in different contexts. For better or worse the folks around us use this revealed information to assemble a model of who we are. They create a model of our identity. The revealing is feeds into a dialog about their model of us. That model then feeds into our relationship the one between us.

In a commercial context we might call those relationships “accounts.” In the marketing literature they even talk about relationship marketing. Doc. Searls makes the point that as the Internet shifts the balance between them and us markets become conversations. Solving the identity problem is all about finding a way to enable that conversation to proceed in a practical, useful, and safe manner.

In the Internet no standard methods exist to help users begin the conversation. When I walk into Amazon, or eBay, or a mailing list I am naked. Actually it’s worse than that. I’m actually so thin a presence that I don’t even have a place to hang a few rags that might help me to project a persona.

That didn’t happen by chance. Fixing the identity problem demands that we tackle two very hard problems (revealing and authorities). These are so hard we have kept pushing the problem outward. At each round in the design game it has been easier to just minimize the revealing and push the authority problem out to the network’s edges. That approach has its benefits. Nobody knows you’re a dog, America is all about second chances, etc. etc..

But I want to be wearing clothes when I go out. So today’s puzzle is to look at what a revealing mechanism might look like, from 40 thousand feet.

I find it amusing to say that what’s needed is a “self-server.” A place we can refer others to. Want to learn about me, go here. This place enables them to have a dialog about who I am.

Let’s look at a scenario.

I visit a Wiki. I want to contribute some fresh content. The server running the Wiki wants to check out my reputation before it lets that happen without moderation. So it turns around and via some Rube Goldberg device it manages to get access to my self-server and using that it asks about my reputation as a contributor of reasonable content. Since Mr. Wiki doesn’t trust me, of course, it’s pleased when the self-server recommends an authority that the Mr. Wiki can trust. Ask them Mr. Trusty says. Of course when asked Mr. Trusty (a reputation authority) says very nice things about me! Happy day, Wiki server let’s me post.

Clearly a lot of details are getting glossed over here. But notice that at no point was anything revealed about me except my reputation as a contributor of open content. The Wiki didn’t learn my name, or my social security number, or the name of my dog. Presumably before I’d allow my self-server to do that I’d have to grant permission.

If this were 1980s the self-server would be documented with an RFC and a simple protocol. In the 90s we might have used a web page, and if we wanted to encourage a dialog it would have included a CGI script. These days we call it a web services listener. “Whatevvver.” We modern guys so we can assume lots of encryption and opaque identity tokens etc. etc.

In the Liberty Alliance design this thing I’ve called a “self-server” is a set of web services spread out all over the Internet. That allows, in our example, lots of posting reputation services. It allows many many authorities of varying kinds and seriousness. Your bank, your house, your hairdresser, your clubs can all play a role. That’s as it should be. We certainly don’t want to create one grand central authority.

The only “central authority” they need to rendezvous with is the standard protocols. Those protocols break out into two layers. One is generalized glue that helps you find various kinds of services. The second is a suite of services. Once you get the first layer right then any number of members can pile onto the suite of services. If you want to have service that helps users reveal their fashion preferences then have at it.

Well actually there are three layers of protocols because we also need to design the Rube Goldberg device that helps you find the self-server-directory starting from what ever is available in the legacy protocols.