I noticed a new web service today called a Dead man’s switch, which dispatches email in the event that you don’t respond to periodic ‘pings’ that prove you’re still alive. But it occurred to me that I might outlive the person or organization that pays the bills for the service, making the service useless.
There are other kinds of services that we could be reluctant to use simply because the value is so high we don’t trust it to an inventor who could lose interest, or an organization that could go insolvent. Like data repositories that could be used in many different programs and devices, but that would break them all if someone forgot to pay the hosting bill.
But say the service ‘owned itself’, and paid its own hosting bills? Like this:
- The host is Amazon EC2 or similar
- The bill is paid by debiting a bank account
- The bank account is replenished by interest returns and advertising revenue
- The bank account is in the name of the service itself, and once seeded is never touched for anything else again
- The creator declares the service ‘finished’ and moves onto the next project
To me, this is an engineering problem similar to those of building Mars rovers, bury-n-forget power generators, The Millenium Clock, and other artifacts that have their own homeostasis mechanisms and can be abandoned by their creators without ceasing to function.
The question is: what are the gotchas? Must the bank account be in a real person’s name? Can you prevent the govt. from considering the account ‘unclaimed’ after n years? How could it recover from crashes? Is there an API for opening new hosting accounts at other companies so it could automatically scale itself and protect itself against the insolvency of any one host?
You can’t make a service robust in this way – if the bank account is a single point of failure then when (not if) it fails, you lose. A bank account can’t exist without a legal entity to own it, but that’s just a detail here – other failures are that Amazon might pull SC2, or raise the price, or make an incompatible API change, or be bribed by your rival or ordered by a court to remove your app.
Ross Anderson has published an initial description of the requirements for an ‘eternity service’ for data storage. The broad principle is to distribute it across as many people as possible, and ensure that they all have solid incentives to keep the service running, and to keep specific data live. It has to be resilient against as many as possible participants dropping out, and against as many as possible participants ‘going rogue’ and trying to subvert it.
He only gives broad outlines in the paper I read, and a few specific techniques that might be useful, but that was over 10 years ago. You might find further research if you look.
http://www.cl.cam.ac.uk/~rja14/eternity/eternity.html