start on three-party handoff

[warner]

just wanted to capture some thoughts on three-party handoff, based on the new reference types in Agoric/SwingSet#88:

When we get to three-party handoff, we'll define two more reference types that can appear in the remote messages. The first is a "remote ID", which identifies a particular remote machine. These have + and - to indicate whether they're allocated by the sender or receiver of a given message, just like ro+ and ro-. The second is a "Handoff ID" that identifies a particular object that is being shared from one machine to another, again with +/- to indicate the allocator. And I think we'll have three new message types: introduce (to tell one machine about another machine), grant (for A to instruct e.g. C to allow B to access Carol), and handoff (to give e.g. B instructions on how to resolve an incoming Handoff ID).

In our usual "Granovetter diagram" handoff situation (A has a reference to Bob on B and Carol on C, and A sends bob ! foo(carol)), the first time the A->B comms layer sees a reference to Carol, the comms layer will allocate a handoff index (e.g. "10", scoped to the A/B clist). It will then notice that this is the first handoff of something on C, so before it can tell B about the handoff, it must introduce B to the whole machine (C). Therefore A now allocates a remote index (e.g. "20") to represent C.

A creates an introduction string which contains everything B will need to receive and validate messages from C. This might include the public key of a solo machine, or the chain state (validator pubkeys and staking allocations). It may also include a somewhat objective name for the machine (public key or hash of genesis block) which can serve as a hint for merging two introductions of the apparently-same machine (the diamond pattern). Finally it may include network hints to allow a solo machine (or relayer) to deliver messages or subscribe for outbound messages. A sends the introduction message to B just once, and thereafter only references the "remote ID". The remote-ID in an introduce always uses a negative index, because the index is always allocated by the sender of that message:

• A->B: introduce:remote-20;$validationAndNetworkInfo

At the same time, A creates an introduction string for C, to tell them about B. I think this must be included in the A->B: introduce message too, so B can deliver it to C without waiting on A, but I'll have to think more about that.

Now that A knows B is aware of C, A can build the handoff. C must be instructed to grant B access to Carol, by means of a grant message created by A. The grant message says "Dear C: please allow B to access the object that I know as NN. Love, A":

• grant:something..

But A does not actually deliver the grant to C directly, because B doesn't want to get held up waiting on A. So instead A includes the signed/validatable grant message inside the introduce that A sends to B, and B can extract the grant and send it to C themselves.

A then sends a handoff message to B. The handoff will include the previously-introduced remote-20, and the newly-allocated handoff-10 index (which is the A/B name for the object cited by the grant). It includes the grant instructions, plus proof that A actually had the authority to reference the object in the first place (which might be a message signed by C saying "A is allowed to access object XYZ", or a merkle proof that chain C has the A-XYZ mapping in its clist tables).

• handoff:remote-20:handoff-10:$grantMessage:$authorityProof

Now that A knows B is aware of Carol (the handed-off object reference), and has everything it needs to request and obtain access to that object, A can include handoff-10 as a reference in a regular message send or resolution result.

• send:$targetRef:$resultRef:handoff-10:...

(this is still pretty incomplete)

[erights]

Another three party handoff one, along with #40 and #41 . How should we consolidate, or are these really distinct issues?

[michaelfig]

I'm bowing out. These are research and implementation issues beyond what I grasp, and I don't think I should take it on. I'll unassign myself also from the other 3p handoff issues.