One of the problems with most substitutes for email is that they fail to implement a concept that Marc Stiegler of HP writes about in his technical report Rich Sharing for the Web. Narc outlines six features of rich sharing that are captured in this short scenario:

Alice, in a race to her next meeting, turns thunder-struck to Bob and says, “Bob, I just remembered I need to get my daughter Carol’s car to Dave’s repair shop. I’ve got to go to this meeting. Can you take Carol’s car over there?”

Marc's thesis is that email has held on so long because it's one of the few systems that supports all six features of rich sharing. But that's not really what this post is about, so I won't describe that further. You can read Marc's excellent white paper from the link above if that interests you.

As I was contemplating this scenario this morning, I was thinking that part of what makes this work is the idea of bearer tokens. A car key is essentially a bearer token. Anyone who has the key can open, start, and drive the car. Hence Carol's daughter can delegate to Carol by giving her the key, as can Carol to Bob, and then Bob to the mechanic.

The problem with bearer tokens is that they can be easily copied. If I give you the "key" to my account at Dropbox in the form of the OAuth2 bearer token that authorizes access, we both have a copy. In fact you could put it on a web site and everyone would be able to get a copy. OAuth2 bearer tokens don't work like car keys.

The key difference is that car keys are fermions, not dataions. That is, they can be in exactly one place at one time whereas bearer tokens can be in multiple places at the same time. Sure we can make a copy of the car key, but that takes work. Exchanging keys (Carol giving it to Bob) takes work. They have to arrange to meet or something else. The concept of work is critical.

One of the key features of the bitcoin blockchain is that it prevents double spending. That is, even though the data representing a coin can be in many places, only one person can spend it. And, importantly, can only spend it once. This seems like a property we'd want bearer tokens to have.

The simple concept is to put bearer tokens in a distributed ledger like the blockchain so that we only allow the current holder of the token to use it. Checking if someone is the current holder of the token is easy since everyone can have a copy of the ledger. But transferring takes work in the same way that transferring a bitcoin takes work (that's what all the "bitcoin mining" is really accomplishing).

In fact we could probably just use bitcoins as tokens. When Alice authorizes Bob to access her account on my system, I'll send a small amount of bitcoin to Bob. When Bob accesses the system, he presents the coin (note, he just has to show it to my system, not spend it or transfer it) and I can check that it's the right coin and that Bob is the current holder. If Carla presents the token (coin), I can check that she doesn't own it and refuse service.

A few thoughts:

• There's nothing in this system to prevent Bob from transferring the coin to Carla. That is, after Alice gives the token to Bob, she has no control who he transfers it to.
• This system costs real money. That is, bitcoins, no matter how small, have value. But that's a feature, not a bug, as the saying goes. The cost makes bearer tokens behave more like physical keys.

This is open loop thinking, but I'd appreciate your thoughts and feedback on how a system like this might work better and what problems it might solve or create.