This is incoherent, and not yet ready for the rest of the world to see.
Zooko Identity system.
One of the services an identity may provide is IM equivalent, email equivalent, single sign on service, monetary transfer, and contract formation. If it provides one of these, it normally provides the other three.
Another service an identity provide is https equivalent, only with yurls instead of urls.
At the lowest level, we have multilayer protocol negotiation process in which the layers are integrated so that additional layers do not result in additional round trips.
Excess round tripping is avoided by having compile time layering rather than run time layering. At compile time, a layered description generates a fully integrated protocol, with optimistic protocol negotiation, so that if all goes well, all levels of the protocol are agreed in a single round trip. Layered source code is compiled into integrated and unlayered run time code. According to Google research, we lose two percent of users for every second of delay a web page takes in coming up.
At the lowest level we have an IP equivalent protocol, with network addresses as opaque blobs of variable size. Typically these blobs contain IP addresses, possibly IP addresses plus port number, plus some additional information, with packets typically encapsulated as udp packets, during session establishment, imitations of tpc establishment packets. Possibly we imitate tcp packets. Anyone can write their own IP imitation and drop it in, leaving all other code unchanged, thus if an ISP is playing hardball, as comcast does, one can encapsulate information inside packets that pass ISP inspection as some more politically correct packets. The intent here is that if someon is having trouble with comcast, lots of people will add additional comcast resistent IP layers, and if you compile your server with that layer, and someone under comcast activates that layer in his client, he will talk lie-to-comcast with the server, while the server transparently talks some other IP imitation protocol with other clients.
Layering, however, is compile time, thus to support a new hide-from-the-isp protocol, clients and servers have to be recompiled with the new library, rather than it being put in the OS, and binaries then automatically using it. That is a cost of compile time layering. The cost of run time layering is additional round trips.
Money should support webmoney, also Satoshi Nakamoto’s bitgold coins, if available.
"Satoshi Nakamoto" <satoshi@vistomail.com> has published a transferrable proof of work protocol, http://www.bitcoin.org/bitcoin.pdf, (I have a local copy)
The core concept is that multiple people keep copies of a hash tree saying who owns what coins, and in order to add new coins to the list, you have to have a copy of the tree.
Problem is this makes coins expensive, for to be reasonaly safe against private and public attack, the system needs more than a dozen or so copies.
Bitcoin transactions are cheap enough to compete with bankcards, but we already have a bankcard system that works fine. An alternative system cannot compete directly.
Instead, an alternative system has to provide service in an area where bankcard cannot.
File sharing is an obvious area. At present, file sharing works by barter for bits. This, however requires the double coincidence of wants. People only upload files they are downloading, and once the download is complete, stop seeding. So only active files, files that quite a lot of people want at the same time, are available.
File sharing requires extremely cheap transactions, so to support file sharing on bitcoins, we will need a layer of account money on top of the bitcoins, supporting transactions of a hundred thousandth the size of the smallest coin, and to support anonymity, chaumian money on top of the account money.
Let us call a bitcoin bank a bink. The bitcoins stand in the same relation to account money as gold stood in the days of the gold standard. The binks, not trusting each other to be liquid when liquidity is most needed, settle out any net discrepancies with each other by moving bit coins around once every hundred thousand seconds or so, so bitcoins do not change owners that often, Most transactions cancel out at the account level. The binks demand bitcoins of each other only because they don’t want to hold account money for too long. So a relatively small amount of bitcoins infrequently transacted can support a somewhat larger amount of account money frequently transacted.
But I digress, I ramble. In order to make all this stuff work, we need yurls – but yurls as specified lack some capabilities.
I was thinking of putting up a bink in the cloud, and then thought "and suppose the government steals it." Well obviously, we want all its secrets to have a time out after a while, so the government gets stuff all, and pretty soon the bink pops up somewhere else.
We need each yurl to represent an equivalence class of yurls, so that we can have keys that authorize keys, keys that time out and are replaced by superior master keys, and such like. To implement companies, we need m of signatures – a key is valid if is signed by m of the underlying n keys, and so forth.
To support action in the cloud, we need the process of secret establishment to provide for a new IP – you hit up the permanent IP, and get a secret shared with a transient IP.
We need protocol generation – you specify your messages, you get a generated client server that supports protocol negotiation, and on top of best effort messages provides session establishment, shared secrets, DNS resistance, and within a session, flow control, at least once messages not necessarily in order, at most once messages in order, and once and only once messages in order.
And then we need yurls representing identity, instant messaging from yurl to yurl, therefore yurls representing instant messaging addresses, buddies, yurls representing sums of money, and yurls representing contracts.
When we can do all that, then we have for filesharing by such entities, thus a need for binks, and binks have a need for bitcoins, but first the yurls, for there is lots of stuff we can do with yurls.
These documents are licensed under the Creative Commons Attribution-Share Alike 3.0 License