See (p3,eggintro) for a partly obsolete introduction and motivation to the factory.

Absolute Discretion {as in the yield of FACTORYC}

It was proposed that instead of FACTORYC we provide a call on a factory to produce a new factory. The new factory would inherit only the discretion of the old factory. This would make the idea of discretion entirely relative {whereas we seem now to say that the yield of FACTORYC is absolutely discreet.} Such an approach would be safe but would sacrifice the otherwise neat idea that the indiscreetness of a factory was a lattice function of the components of the factory. This implies that a factory with all components of DK(0) is, in fact, absolutely discreet.

It seems nearly possible to provide for temporary indiscreetness. It would be as if the requestor could open a window so that the creator {but not the requestor} could see into the object's state and then close the window after a time. Subsequent to the closing of the window the user would be free to introduce new data to the object without danger of the creator seeing the data subsequent to the closing.

This can be carried out if a DDT is built within the object and the creator communicates with DDT without passing keys.

This seems to falter on the issue of broken objects within broken objects. The debugger of the outer object may need to call upon the inner object's creator to fix the inner object. The outer object debugger, however, has only the authority of the outer object which is insufficient to connect the inner object with its creator. This is because the requestor's factory key that created the inner object will be without fix rights.

We conclude that for now the fix operation leaves the object permanently potentially structurally indiscreet {sic}.

Speculations on how to solve the general problem:

During a debugging session the creator communicates with a proxy which is a program running with only the authority available within the object plus the authority to communicate data to the creator. The limitation that the proxy not communicate keys is to prevent communications subsequent to the termination of the debugging session by the requestor. This would be possible if the creator exported keys to parts of the object during the session.

Suppose that the “fix” operation on the requestor's key returned a protected viewport to the object's state.

Suppose that this viewport were really a start key to a domain with the brand of the object and no code.

One must trust the creator of a one hole factory {about the nature of the hole} but the holder of the builder's key to complete one hole factories need not be trusted.

An alternative design would have allowed the .hole to be replaced by the holder of a builder's key. Since the factory creator and the builder's key holder are usually the same, this may be an unimportant distinction.

We know of no reason the domain creator of a factory can't be specified like any other component.

This has certain advantages. Getting a new factory with a preexisting brand is simplified - you don't have to use the copy key. Initialization of OS domains would be conceptually simpler - there could be an “OS domain” object and there would not be the problem of the domain having {and misusing} the real domain key to itself or having to invoke the OS simulator. You could just install an “OS domain creator”.

The destroy and identify functions of the domain creator can be more efficiently implemented as calls {kt+4 and ?} on the virtual domain key.

Specifying the factory's domain creator might seem dangerous for the purposes of the factory.

There are two kinds of information within an object to protect; the nature of the algorithm and the data being processed. We argue here that both are protected.

No one needs to hold the builder's key but the owner of the algorithm. Thus the result of opening the object cannot compromise that information.

The start key {or other object handle} represents the authority to access at least some portion of the coded information. The opener of the object must hold this handle. If the owner of the object decides to reveal his secrets to the builder he gives an object handle to the builder.

If, within the object, there are information barriers, the creator is responsible for their logic. This means that the object owner already must trust the creator's code to enforce that barrier. He may then trust the creator.

These notes were written just prior to the current (18-Aug-81) factory design.

The attempts to refine the EGG architecture enough to implement it as part of the standard system have become dependent upon the ability to describe how discreet an object must be, particularly if it is a compound object, built out of other discreet objects.

It appears that many objects will not be absolutely discreet according to the current (7/22/81) definition used in building objects via eggs. As examples of the kind of problems, it may be necessary to trust the system administrator of a database, or to trust an admittedly indiscreet key which is part of an object.

Dilemmas about discretion

dilemma 1: Gnosis was designed to hide things, but - in order to build a domain which is not structurally discreet, the indiscreet components must be explicitly known to the creator, and thus cannot be hidden.

dilemma 2: EGG's are intended to make things discreet - but the current design requires that anything which is indiscrete is known to the creator, which is exactly the opposite of what is intended.

Questions to explore in understanding discretion
question 1: Is it possible to have creators which build both discreet and indiscreet objects.

question 2: Many objects (such as a mail union) are inherently indiscreet. Is there a large enough mass of objects which still make sense if they are required to be structurally discreet.

question 3: How do you build objects which you can trust if the objects are structurally discreet.

question 4: How do you build objects which are structurally indiscreet, but for which you trust all of the indiscreet components.

question 5: How do you build objects out of components which are indiscreet, but which you still trust?

question 6: Is it necessary to develop a language to describe discretion.

question 7: Is it possible for a single egg to serve varying levels of discretion.

All is not lost. There are some things we think we know.
Answer 1: We know how to build and service structurally discreet objects.

answer 2: We think we know how to build relatively discreet objects from a few primordial constructs which we have defined (in the egg) to be discreet.

The following statement is also recorded.
In order to build compound, relatively discreet objects, it is necessary to either pass each indiscreet component explicitly through each level, or to pass a dictionary of components which might be needed at lower levels. The latter proposal isolates the intermediate domains from changes in the specifications of the lower domains.

This key supports VCSK wherein VCSK needs to disassemble other VCSK segments and this requires that the keepers be produced by the same DC. Now all VCSK keepers would be from the same DC.

Trusting the Factory

Some of the function of the code in the factory need not be trusted. This is because the only domain that executes that code is structurally discreet {unlike the factory domain itself}. In particular the evaluation of the G function and the dissolving of .program and .keeper is executed by the domain created in response to the original invocation of the requestor's key. That domain is always structurally discreet even when it is executing the special factory code.

There is a problem with the promptness of factories. If a .program is a requestor's key and the .program therein loops the original factory remains busy.

Except for this fluke, requestor's keys would be manifestly prompt. I suppose that a “relative discretion” query could also report whether the .program and .keeper were either requestor's keys.

This problem is about to be fixed. The new domain will call any necessary factories. If they aren't prompt, the original factory is still available.

Factories were designed to manage discretion. They also seem to be the natural way to manage integrity.

As with discretion, the integrity of an object is limited by the integrity of its components.

The sense key provides read access to the segment aspect of an arbitrary object. Holding such a sense key is not an obstacle to discretion.

The integrity of an object, on the other hand, seems to require attention at all stages of construction.

How shall we demonstrate the solidity of an object built by FSC or VCSK? Each of these come from factories, but they come in contact with programs which might pass them destruct keys so as to become un-solid. Two ways come to mind:

1. A friend of a space bank is available that will accept a node key to a segment connected with node keys and sever each node and page of that segment and return a segment key to a kept segment. The offered segment may include similar solid segments. This segment keeper knows the bank and is known by the bank's friend. Its discretion may now be vouched for by the bank's friend who is, in turn, known to the bank.
2. New sorts of start and resume keys are invented. These gates cannot pass key arguments. The segment keeper is started in a factory with only a suitably durable bank.

The section at (price) speaks of some fancy methods of pricing and billing. Such schemes require an otherwise confined domain to hold a key which is not a value key {(p2,vo)}. Those schemes thus seem incompatible with factories. We present some near solutions here. None of them quite work. The inherent dilemma is that a program author cannot be indefinitely unaware of being rewarded for his work.

The Sub-Contractor Problem

A problem realized late in the generation of these ideas concerns the paying of sub-contractors. Here the sub-contractors are the yields of factories held as components of the main factory. The main program (yield of the main factory) is in no position to negotiate with the owner of the sub-system over price. Such negotiation could only occur via a major hole. We must therefore adopt a more rigid payment strategy.

There are these basic kinds of method that I know of here:

Purchase of an object good for some definite amount of service {(ppc)},

Payment per service: either accounts {(p2,account)} or assets {(asset)}.

The service meter allows the program owner to know to whom his program is providing service. This is not always appropriate. In particular it may be contrary to discretion requirements.

The limited service object seems to require some advanced planning so as not to run out in mid job. Programs are not good at such planning.

I think that we are left with some sort of loose change scheme such as described in (asset-fact).

The Loose Change Solution {best so far}
I think that the slow channel idea {(sdc)} and loose change idea {(asset)} can be combined with some factory specification modification to allow for “coin slots” available to factory yields that sends money to program authors and yet limits information as to exactly how much, when and to whom the service is provided.

Unfortunately this requires institutionalizing within the factory slow data channels and the loose change system. It decrees that there is just one sort of money and that the slow channel reporting periods are standard. Even with these limitations these scheme seems the best so far.

See (p2,purse) for an elaboration of this idea.

A variant of the above:
It is possible to produce a standard hole through which coins may be passed along with a notation indicating to whose account the coins belong. See (p2,col).

This has the advantage that no factory spec change is required. It has the disadvantage that the account specification is left to the application logic; an un-Gnosis like solution. The net effect is that untraceable deposits could be made in accounts.

This is like the 940's “stream accounting” except for the anonymity of the depositors.

Limited Factories
The design of the egg (a precursor to the factory idea) called for the production of just one object. When we noticed that the egg could produce many identical objects we though of the earlier limitation as merely a design oversight. We also changed the name to “factory”. I now notice that the old design had the advantage that the program owner could limit the degree to which he disseminated the use of his program. This could, in turn, be used to support charging strategies.

The most obvious proposal for factory design modification would be to institute a counter in the complete factory that would be decremented for each object produced. The factory would be dissolved upon exhaustion of the counter. The counter could be set or incremented by the builder's key and read by the requestor's key.

Requestor's keys to such factories would, alas, not be value keys and would thus be ineligible for inclusion as components in other factories except as holes.

Since the invocation of a requestor's key must convey no signal to the builder and the builder could read a meter that he supplied upon factory creation, the factory creator requires no meter to produce a factory. It is on the house.

The design at (p2,col) perhaps demonstrates a weakness in factory design. We are required to name accounts with bit strings instead of keys.

It seems that one should be able to install a private coin receiver which would obey an trusted algorithm but which would lead to the particular author's coffer. It is true that such the private collector would have a hole but the fact that the private object's algorithm is trusted should some warrant the inclusion upon some categorical basis.

An approach to a solution to this problem might be a modification to factory design. Here goes.

Imagine a “categorical hole”. Along with the current three circumstances under which a component can be added to a factory there would be a new circumstance. The factory would know some creator {factory or domain creator} which would vouch for the trustworthiness of objects created thereby.

These are some thoughts that need to be integrated with the rest of this section. I enter them now (unintegrated) before I forget them.

When we speak of what keys there are on one side of a fence {or within an envelope} perhaps we must include within that set the keys producible therein. In particular we would include of the fetcher key producible by a factory creator's key with “recall fetcher rights”.