What sorts of property should our computer base recognize?
Here are some that have been done in the past:
- Primitive property (resources) recognized by primitive trusted code (a kernel):
- Rights synthesized by user code
- We assume here that services of user code may be owned.
The code provides the value perhaps with property that it owns, as a farmer owns land and produces food.
- Money
- Keykos does money with user code.
The ideas of DSR are so light weight that doing money in user code would make it many times more expensive I think.
There remains the question of whether an object should name its money or whether each object should have one purse with just one amount in it.
I don’t know which is faster.
I assume a capitalistic framework forthwith.
There will be vendors of primitive resources at each node.
Money is fungible so that the confused deputy objection to ambient authority does not strike.
I think that I will treat money as an unnamed authority of an object.
Money in packets at the lowest level of link multiplexing seems strategic for the same reason.
Node code (Switch Ware, whatever) must be able to make assumptions as to the nature of link services.
Just what can be sent over links.
A given link must be multiplexed, in general, between a variety of users.
It seems clear that link integrity must be assured by strong (un-spoofable) authentication codes such as MD5 or SHA.
The multiplexing software can then assure that data will not be delivered to the wrong client.
It can also assure that money arithmetic is secure.
This implies classic error control that is secure against man-in-the-middle attacks.
Encryption can be provided but there may be cases where the cost of encryption is more than its worth.
Link Services
I think that a link should be divided into channels.
When a link connects nodes X and Y then a channel on that link is accessible to objects at X and Y.
A channel should be able to transmit packets where a packet is a string of bytes and an optional DSR money field.
Some limit on the string size is imposed that is compatible with link efficiency and some global guaranteed size that software can count on.
With the authority to accept data from a channel an object should be able to wait for a packet to arrive.
When the packet arrives the money field, if any, is added to the recipient’s money along with the string and indication of how much money was there.
I think that the multiplexing logic is in privileged code but that is a trade off between performance and security considerations.
Persistence
Most state of a comm application need not persist across bootings of the system.
Resources need to persist for mission critical applications.
The advantages of holding resources via capabilities are numerous and this requires persistent capabilities.