2 way reliable messaging (VatTP) layer

[dckc]

Currently, https://github.com/rchain-community/rchain-api/blob/master/src/proxy.js only supports calls from off chain to the chain and back, not the other way.

To support CapTP, it should be split into a lower level that just does reliable messaging (with acknowledgements) in both direction. For example, perhaps listenAtDeployId should be used for acknowledgements, not for the results of computation.

A design wrinkle:

• [ ] in Agoric, reliable messaging is done with sequence numbers. listenAtDeployId would support a more concurrent approach. Should we take advantage of that? Or stick to the simpler vat model? I lean toward embedding the simpler approach for now.

cc @Bill-Kunj

[Bill-Kunj]

My 2c: this should not be a separate layer. I like the idea of

new
   outsider(`rho:io:network:some-uri`)
in {
   // code here using outsider
}

[dckc]

not separate from what? I propose/expect to build this with vanilla rholang.

Also, a new abbreviation such as rho:io:network:some-uri needs a change to the rnode scala code. I don't see any need for that. we already have deployerId which suffices to acknowledge client->rnode messages, and polling in the other direction is straightforward.

[dckc]

oh... ideally, we'd have a websocket connection to rnode. Does rnode support that, @zsluedem?

[zsluedem]

oh... ideally, we'd have a websocket connection to rnode. Does rnode support that, @zsluedem?

Well. The rnode got websocket endpoint but provides very limited(useless) function now. The dev wants to refactor that.

[dckc]

@zsluedem is there a github issue about addressing the websocket limitations? I'd like to track it.

[zsluedem]

@zsluedem is there a github issue about addressing the websocket limitations? I'd like to track it.

Sorry. We don't have that right now. I would create one

[zsluedem]

@dckc https://github.com/rchain/rchain/issues/3585 a draft one.

[dckc]

Hm. this simple protocol works if parties trust the bridge. But it would be much more powerful to have an RChain light client (https://github.com/rchain/rchip-proposals/issues/35 ) . That way, the Agoric side would be compelled to accept that the RChain side had sent a message.

[dckc]

progress in office hours today: https://github.com/rchain-community/js2rho/blob/captp/lib/messageQueue.js 331e08d

cc @jimscarver