Open dckc opened 2 years ago
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
}
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.
oh... ideally, we'd have a websocket connection to rnode. Does rnode support that, @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.
@zsluedem is there a github issue about addressing the websocket limitations? I'd like to track it.
@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
@dckc https://github.com/rchain/rchain/issues/3585 a draft one.
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.
progress in office hours today: https://github.com/rchain-community/js2rho/blob/captp/lib/messageQueue.js 331e08d
cc @jimscarver
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:
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