Overview
The debate at (p2,keep64) is perhaps resolved by the observation that there is no useful concept of an object that is merely trusted to be immutable. If you can trust an object to have any particular behavior, you can trust it not to delete itself. Integrity logic may bring supplementary confidence that others cannot delete it or interfere by invoking its service key.
The compiler posited there could break and be thenceforth unusable. Banks, Factories and perhaps some segments may come to be trusted as immutable, so long as the banks from which they are built cannot have their guard function invoked.
The most immediate application is an injunction associated with a guarded bank. One should be able to acquire (for some consideration) an injunction against the invocation of the guard key. The holder of the guard key is, indeed, the guarantor of the injunction logic.
The vagueness of the phrase "for some consideration" suggests that the injunction seller should be separate from the injunction creator. One should be confident of the fact that he has an injunction even if he is not entirely sure of how he got it.
State of the Art
A compiler stored on a disk file may be considered, for many purposes, as immutable. Some otherwise immutable compilers have been known to fail when the TOD has reached a certain value in order to enforce agreements in some contract covering the compiler.
I don't know if there is a useful definition of integrity covering such situations. The compiler owner counts on the TOD of his customer's computer being set correctly. The TOD may well be set to thwart the test in the compiler.
The problem of inadvertent dependence on guarded banks seems much greater than the more vague problem of "subsequent hostile actions" on the part of the builder. No current scheme hints at solving the latter problem in general.
Before this scheme can be used we need gates that will not pass keys.
I reject this scheme for now because it is a big task and does not completely solve any clear problem.
Conclusions
Discretion of an object depends on that of the capabilities it holds. The complete integrity issue cannot be settled without resolving the reproducibility issue. The hazards refered to in (noise) are each impediments to reproducibility.
It even seems hard to show that segments without programs inside are solid while hiding the way they are built. The changes seem to pervade the logic of the program that builds them.
The Integrity Issue as a Partial Ordering Problem
Two important questions that may be asked of such an ordering are: What depends on this thing? What does this thing depend on?
The manager of a set of technologies needs to ask both of these questions. The style of Gnosis, so far, has been to abstract these issues. By that I mean that we claim to have solved problems such as discreetness without maintaining central partial ordering information.
We have anticipated a division of responsibilities where X would determine that some set of facilities is sufficiently durable and that Y uses these facilities. How useful is this division? Once spotting a division of functions, we have seldom opted for not dividing them!
The image that we arrived at Tuesday afternoon (15-Feb-83) was to have an ever growing christmas tree of facilities sufficiently durable for some purpose. The concrete representation of the christmas tree might be a directory. This presumes that we want to give equal access to all equally durable things. This is surely not the case. We have always divided the access issue from the attribute issue.
A concept that I have come to feel comfortable with the last few days is a key that represents, in some obscured way, a degree of durability sufficient for some project. This is the key that X provides above to express his definition of "suitably durable". I think that such considerations may be near the heart of the problem of moving projects from one Gnosis to another.
There may be different degrees of durability represented by different APL's.
Such APL's would have to be created by an agency charged with ensuring some attribute of the approved objects. In many cases this would require building the object within guidelines but according to external instructions.
See (formative,club) for just such a tentative design.
This scheme fails some of the more general goals described above for integrity in that the individual service provider cannot produce a manifestly durable service without exposing his secrets to the durability manager. Also the inflation scheme seems just now to be a batch service. Also accountability for space is lacking.