rchain-api icon indicating copy to clipboard operation
rchain-api copied to clipboard

2 way reliable messaging (VatTP) layer

Open dckc opened this issue 4 years ago • 9 comments

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

dckc avatar Jan 11 '22 15:01 dckc

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
}

Bill-Kunj avatar Jan 19 '22 09:01 Bill-Kunj

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 avatar Jan 19 '22 16:01 dckc

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

dckc avatar Jan 19 '22 16:01 dckc

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.

zsluedem avatar Jan 20 '22 01:01 zsluedem

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

dckc avatar Jan 20 '22 01:01 dckc

@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 avatar Jan 20 '22 03:01 zsluedem

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

zsluedem avatar Jan 21 '22 02:01 zsluedem

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 avatar Mar 05 '22 15:03 dckc

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

cc @jimscarver

dckc avatar Mar 12 '22 19:03 dckc