Let me make some points on various applications of Keykos (or Eros).
First a meta comment.
While it seems necessary to find the “killer application” for Keykos, any simple application can better be done without a new operating system.
It is the interaction of a community of interests, needing to interact in high volume, that a capability based operating system can uniquely support.
With that in mind, how can we begin? There are two general beginnings
that seem promising to me:
These are highly synergistic for whenever a person is the direct user of metered data, a browser is a fairly natural tool for the user.
But before we confuse the two lets think about them separately.
- A toll road to data (and services)
- A web server.
(toll road, gateway, data meter, whatever)
See this for a concrete idea.
A capability system can enforce clear limits on information flow and
meter allowed flow.
The general plan is to make the raw data available via a capability or perhaps several capabilities, and to then write capability style code to administer a large variety of data deals.
I assume that these data capabilities provide both read and write access.
Capability style code is good at subdividing such rights.
There are, in simple cases, two parties that may provide code to be so contained: the data seller and the data buyer.
See insulation for a more technical description of the kinds of signal control that capability systems can provide.
- Why would the data owner’s code be limited?
- The data owner’s code may be privy to a confidential question of the data buyer.
This makes sense if the data buyer trusts the operator of the gateway, more than he trusts the data owner.
- Why is the data buyer’s code limited?
- That code may have had access to more data than the buyer can pay for.
The deal may be that the bill depends on the size of the message from the buyer’s code to the buyer.
More Grandiose Directions
Just as manufacturing of physical goods has gradually stratified into layers of industries that add value, so will information commerce.
I imagine someone needing to know how many families live at an elevation of more than 1300 feet and have an annual income of greater than $75,000.
Demographic data would not typically include elevation but would include information that can be converted to elevation with the help of topographical service.
The buyer writes a program that will create a confined version of the altitude oracle.
The program runs in a confined compartment, passes over the entire data set that he could not possibly buy, passes the latitude and longitude of each family (or a sample thereof) to the oracle, forms a histogram of the elevations, and passes the resulting histogram thru a meter that measures its size.
The size os reported to the data owner or perhaps the gateway collects from the buyer and pays both of the data owners.
The oracle is confined because the demographic data owner does not, and need not, trust the owner of the topographic service.
The buyer’s program is somewhat more confined than the current factory design provides.
The current design does not limit