Pre-postlude:
I wrote the following when I could not understand why some thought that <a href=http://en.wikipedia.org/wiki/Continuation-passing_style>CPS</a> was not the entire answer.
Subsequently I talked with Chip who gave me an iron-clad reason.
It takes a few minutes to sort of understand continuations but at least a day’s hard work to convince yourself that continuations are indeed a valid replacement
for the call-return paradigm.
Chip needs to explain capability propagation rules to those unfamiliar with CPS.
<p>Regarding <a href=http://www.eros-os.org/pipermail/cap-talk/2013-May/015746.html>Chip Morningstar’s observations on the Granovetter Diagram</a> and the common pattern of X calling Y in order to get from Y, a capability to Z.
Chip observes that the initial conditions seem not to match the initial Granovetter pattern, nor any other of the commonly accepted patterns of how capabilities get around.
<p>Prepositions: If is B is a capability to interact with b then in this note we say that “B is a capability <b>for</b> b.”.
This avoids the confusing constructs such as “I send a capability to P to Q.”.
<p>Adopting CPS (Continuation Passing Style), as Chip suggests, here is how I tell the story so as to conform to Granovetter’s insight:
<ol><li>X holds a capability for calling Y who holds a capability for Z.
<li>X sends to Y a message:<ul>Introduce me to your friend Zelda.</ul>
The message includes a continuation to X.
<li>Y receives the message and part of Y’s charter is to hold a few capabilities and hand them to whoever has the authority to send messages to Y.
Selection among those few is made according to details that do not concern us here.
<li>Y sends a message which includes the cap for Z to X via the continuation with the text:<ul>This is the cap for Zelda.</ul>
<li>Upon receipt, X holds a capability for Zelda.
</ol>
I claim that steps 4 and 5 perfectly match the <a href=../Crypto/Granovetter.html>Granovetter Diagram</a>.
X’s first action is to bring forth the situation where the Granovetter introduction can occur.
In step 3 there is some fog about how Y comes to hold the continuation, which is assuredly a capability.
You can’t quite say that X held it before the sending event.
You can say that X performed an atomic operation which did these inseparable actions all at once:<ul>
<li>X created the continuation, a capability to itself.
<li>It sent the message including the capability and divested itself of that cap.
</ul>
<p align=center>Looking Closer</p>
In Keykos Y is most likely a node (capability page) and the code defining its behavior is in the kernel and the call-return events are all one atomic operation; the continuation never actually exists.
Generally X is not in a position to know that Y is a node however, merely that it behaves enough like a node.