[E-Lang] Promises, equality and trust

[Mark S. Miller]

At 03:19 PM Saturday 7/28/01, Mark Seaborn wrote:
>"Mark S. Miller" <markm@caplet.com> writes:
>> At 02:54 PM Thursday 7/26/01, Mark Seaborn wrote:
>> >(Incidentally, what is the origin of the term `Miranda method'?
>> In the U.S., one's Miranda rights include "If you cannot afford a 
>> lawyer, one will be provided for you".  They're named after this case:
>> http://www.thecapras.org/mcapra/miranda/rights.html .
>Ah!  I wasn't expecting the origin to be an area like that!  (I should
>have guessed, after the Granovetter operator.  

Much as I'd like to take credit for being this quirkily interdisciplinary, I 
actually got the idea for this kind of use of "Miranda" from the ANSI C 
standard.


>Incidentally, I did a
>search in Researchindex.org for Miranda methods and found nothing.  I
>did a search for `rights amplification' there too and didn't get much.
>The literature has some progress to make. :-) )

Yes, "rights amplification" is a fundamental idea, and goes back at least to 
Hydra if not earlier.  Kind of makes you wonder what all those computer 
scientists have been doing in all the years since then.


>> >Does a holder of a promise always get told about the promise's
>> >resolution, or does this information only come through the call to an
>> >observer passed to a whenResolved message, with the local proxy for
>> >the promise wrapping the observer passed in whenResolved so that it
>> >detects the resolution too?  (Giving whenResolved special treatment in
>> >this way does not seem very elegant.)
>> 
>> The latter.  The holder of a promise never gets told simply by virtue of 
>> holding. Rather, the holder of a promise can arrange to find out by means of 
>> the various "when..." constructs you already know about.  The holder of a 
>> promise can also check (ie, poll) by use of "Ref isResolved(expr)".
>
>A minor thing:  I presume you mean the holder never gets told by virtue
>of holding in terms of the inter-vat protocol (so polling would not
>work unless a `when...' message had also been sent).  (Also, does the
>`Ref' object replace the `E' object?)

We were misunderstanding each other.  I assumed you were speaking at the 
object level, and by "holder of a promise" you were speaking of object Alice 
holding promise (unresolved reference) P in a variable.

 From your response, I now think you're speaking at the inter-vat level, so 
I'll try answering again.  Refer to 
http://www.erights.org/elib/distrib/captp/resolving.html .

If VatA holds a remote promise (unresolved reference, triangle on the 
diagram) to an object on VatB, then VatA *will* get told simply by virtue of 
holding.  The implementation of this property is by virtue of the automatic 
generation by VatB of a whenMoreResolved message (small blue-green message 
arrows) to be sent towards the arrow head of the reference (presumably on 
VatB as well, so it's actually only VatB's business how it implements this), 
and the automatic generation on VatA of a DelayedRedirector (diamond) as a 
facet of the remote promise.  The DelayedRedirector is itself a PassByProxy 
object, and a remote far (ie, resolved) reference to this DelayedRedirector 
is used by VatB in the automatically generated whenMoreResolved message.

There are two circumstances that result in VatA holding a remote promise to 
VatB.

* The result of a remote send is a "promise for the result".  The protocol 
operation for a remote send is a DeliverOp 
http://www.erights.org/elib/distrib/captp/DeliverOp.html .  step2 of the 
animation on that page shows VatA generating the remote promise (x') as a 
"question", and generating and exporting the DelayedRedirector which will 
resolve that question.  step3 shows VatB both sending to Bob the explicitly 
encoded message, and autogenerating and sending toward the result the 
whenMoreResolved message, with a remote far reference (rdr') which will 
resolve VatA's remote promise (x').  The remainder of the animation shows 
the steps that typically follow.

* If VatA sends a local promise as an argument of a remote message, then the 
promise is exported.  Refer to the fifth column of the diagram at the top 
of http://www.erights.org/elib/distrib/captp/4tables.html .  An exported 
promise is encoded as a NewRemoteVowDesc 
http://www.erights.org/elib/distrib/captp/NewRemoteVowDesc.html .  On 
exporting a promise, VatA sends to this very promise a whenMoreResolved 
message (the small blue green arrow in the fifth column of the diagram) 
containing as argument a far reference (in the questions table) to the 
redirector (yet to be created) for the remote promise on VatB (yet to be 
created) that corresponds to this local promise in VatA.  VatB, in decoding 
the NewRemoteVowDesc, not only makes the imported remote promise that points 
at VatA's local promise, VatB also creates the redirector for this promise, 
and enters it as an answer to be pointed at by the already created far 
reference to it in VatA.

I think this is sufficiently different than the impression I gave of what I 
was doing, and sufficiently similar to what you were suggesting (cool!) that I 
should wait for you to re-ask your remaining questions before proceeding.


>(I saw a reference on the Web site to `CryptoBrandMakers' --
>does E implement crypto sealer/unsealer pairs yet?)

Not yet.  Probably not till sometime after 1.0, unless a pressing need pops up.


>I can't think of any specific cases in which this would be a problem,
>but in the general case it does mean that Alice can't send an
>unresolved promise P to Bob and then expect the answer received to
>have anything to do with the X Alice later finds P has resolved to,
>since Bob may think P resolved to Y.  Maybe the answer Bob sends to
>Alice should be marked as based on the assumption that P resolved to Y
>(a hash of Y could be presented to avoid revealing Y itself).

Yes, this is the unsolvable problem from the previous email.  Your 
suggestion seems like a theoretically valid suggestion for ameliorating the 
problem somewhat.  But it makes my head hurt ;).  My off-the-cuff, 
top-of-the-head tentative gut reaction is that the minor increase in safety 
is not worth the complexity.


>> I still think default shortening is the right engineering decision, because 
>> the price of not shortening is too high, and the above price of shortening 
>> will IMO usually not be a practical issue.
>
>Isn't there an initial cost of shortening, though?  The vats being
>introduced must wait for a few round trips to complete to set up a
>connection.  Might it be worth sending messages through a proxy until
>a connection is set up?

It might be, but experience to date doesn't show a crying need for it, and 
it would be more complicated, so I'm happy to postpone it until a need for 
it become clear.


>Shortening as a default is fine, though there will always be people
>out there who are hostile to delegation, and it might be worthwhile
>making this risk stark by providing capabilities for finding out where
>a request comes from (not given out by default, of course).

Interesting.  I like this form of rationale a lot.


        Cheers,
        --MarkM