Feature: 3-party handoff

[michaelfig]

From @erights:

It'll also be fun figuring out 3-party handoff. In E it was mostly layered on top of 2-party object-to-object messages.
The hard part is abstracting the naming and creation of transports, i.e., abstracting from the old notion of VatID

Along with this should be a library providing a SturdyRef abstraction (i.e. persistent object references as strings) rather than just a bootstrap object for a given anonymous connection.

[zarutian]

If you do not mind then I am going to butt in a bit with hopefully illuminating insights.

VatID in CapTP of E is the public key (or cryptographic has thereof) of the vat it names.
Provided a way for a connecting vat to verify the identity of the remote vat is indeed the one it intended to connect to.
It is also usefull for talking about the named vat in third person, in
cases such as Locator.provideFor/3 and Locator.acceptFrom/3 which is used in CapTP of E.
This is now generalized in Agoric into two parts:
one on how to send messages to the vat and one on how to get and verify messages from that vat.
Do not know how well that fits with 3rd person usage.

Now, SturdyRefs are a bit trickier. In CapTP of E they are a tuple of two parts, a VatID and a swissNum.
The later is an secret name that allows any connecting vat that knows access to the object it names.
Does not work on unveiled vats like those running on top of blockchain.
Thinking about this has spawned quite a lot of musings on my behalf on how to do it with certs or other such constructs.

I can expand on any of above if there is interest.

[erights]

I can expand on any of above if there is interest.

Please!

The first problem, for us, is live 3-party handoff that can include multiple open chains connected over IBC as out VatTP-like layer. The core, as you say, is rethinking the VatID. Some of my thoughts on that:
https://www.youtube.com/watch?v=a0Wr2BvIixk&list=PLKr-mvz8uvUg70w0yKGfytaDqxiIBNo_L

Bootstrapping initial connectivity isn't what E SturdyRefs did. It is what E captp uris did -- out of band data capability. In E, the two were closely related. Here I think you mean the data capability problem.

On the data capability problem, I think you invented the best starting point in your contributions to CapCert. The key insight is that, unlike the captp uri, it cannot be a bearer instrument. It must be minted specific to the one entity that can redeem it.

[zarutian]

Please!

Which part should I expand on?

If I recall correctly the handoff tables in CapTP of E were indexed by VatID of donor, VatID of recipiant, and a nonce. In such entry there were eather the gift (in a FinalSlot box) or the resolver of a promise for the gift. (Depended on which message arrived first).
Easy to do due to the fact VatIDs in E are in an universal namespace, making them in this use essentialy zero dimensional Schiling points. I do not know how to do such with the relative vatIDs you described in the linked video.

I understand that Agoric is doing captp on top of a store and forward messaging layer. I suspect that messages between VatA and VatC that carry the equiv of Locator.provideFor/3 invocation could be duplicated and given to VatB to ensure that VatC does get such invocations.

[erights]

Start with absolute. If possible structure the absolute as a degenerate case of relative, as the video suggests. Once you get things working with absolute, we can then explore relative again, to see whether we can make it work in concrete deployments. I am hopeful but far from certain.

[zarutian]

Alright, after having this problem shimmering for a long while I think I can narrow the vatId part down a bit.

For exposition purposes lets say a vatId is of the form { sendMessageTo(msg :JSON) :Void, verifyMessageFrom(msg :JSON) :bool }. For 3rd person usage we only seems to need to be able to compare the verifyMessage part of two vatIds.

Lets call such a comparator vatIdEq(operandA :Any, operandB :Any) :bool. That comparator absorbs the question of absolute vs relative vatIds.

Having half-solved this vatId part we can the use something quite similar to http://wiki.erights.org/wiki/NonceLocator using the provideFor and acceptFrom methods. That solves the 3-vat handoff.

For out of band, off-chain, introduction we can use a trick by Alan Karp.
This trick works provided that a subset of vatIds can be public keys.
An off-chain party that already has some spefic reference to an
object in an on-chain vat, generates a public key private key pair.
Then in a provideFor message such as in the 3-vat intro above names the aforesaid reference to the object as the gift and the public key as the recipiant vatId. The party can then give that message and the private key to anyone they would have given captp uri were we using CapTP of E.