3rd-party handoff design requirements.

[zenhack]

I'd like to explore others' requirements for how 3rd-party handoff works, and find out if there are any unusual requirements. The reason for this is that currently capnp has a sketch of the protocol in rpc.capnp, but none of the implementations actually support it yet, so the design is more flexible there. If there are things that can be done in the design phase to improve compatibility with ocapn, it would be good to know about them while we still have the flexibility.

Things that come to mind:

• Agoric is doing stuff with blockchains, which seems like it might have some implications, since on-chain code can't keep secrets. I'd like to hear about what folks think those implications are.
• I know goblins already supports 3rd-party handoff. I'd be interested in comparing the protocol design there with what's described in rpc.capnp

[zarutian]

Here is how 3rd party handoff works in E as I understand it:

Where we normally speak of Alice giving Bob a reference to Carol, we here speak of the Donor (VatA) giving to the Recipient (VatB) a reference to the Gift (Carol) residing on the Host (VatC). [1]

This happens by Donor telling Host over the captp connection between them to wrap up the Gift into a box for Recipient and tag it with a nonce n. This is done by Donor invoking provideFor(Gift, RecipiantVatId, n) on the NonceLocator at the Hosts end and gets a vine v to hold onto. [2]

Concurrently/simultaniously/meanwhile Donor informs Recipient of aforesaid Gift by putting a Promise3Desc with Host vatid and nonce n, as an invocation argument in an opDeliver or opDeliverOnly message that bears the eventual send to an object on Recipient that is to recieve the Gift.

The Recipient upon comming across that Promise3Desc builds or uses already established captp connection to Host and invokes acceptFrom(DonorVatId, n, v) which gives back a promise to the Gift. [3]

Note that in E, a vatid is the cryptographic hash of that vats public key.

These diagrams might also help understanding the above.

[zarutian]

As you can see in my previous comment the nonces passed around can be from vats trituplewise counters and are not bearer tokens. (Trituple here is Donor, Host, and Recipiant).

As I understand how vatids in E and Agoric work is that, in case of E, the public key of the vat authenticates it at the vattp level (the link layer protocol just underneat captp).
But in Agoric the vatid is not a public key or cryptographic hash thereof (well, maybe for solo vats) but two things: a designator, which tells you how you send messages to the vat, and an authenticator, which tells you how to judge when that vat has uttured a message. Captured in the phrase “my name is how you address me and know it is from me”. For a quorum vat it lists the hosting machines and the quorum threashold. For a blockchain vat it tells you the InterBlockchainConnection (or in case of EthereumVM contract hosted vat, the contract address) port to send to and the consensus rules of that chain (and in the EthereumVM case the log ‘topic’ to watch).

[tsyesika]

Since we discussed this last meeting, I thought I'd add the links to the presentation and discussion we had:

• Peertube recording of the presentation
• Youtube recording of the presentation
• Slides
• Meeting minutes

[dckc]

Just found this while browsing github for capnproto stuff:

• snej/secret-handshake-cpp: SecretHandshake secure connections in C++, with Cap'n Proto support

I wonder to what extent it's relevant here.

SecretHandshake is used in Secure Scuttlebutt.

[zenhack]

For transport security I've had http://noiseprotocol.org/ in mind, and Kenton has mentioned it in the past too.