-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
2 way reliable messaging (VatTP) layer #94
Comments
My 2c: this should not be a separate layer.
|
not separate from what? I propose/expect to build this with vanilla rholang. Also, a new abbreviation such as |
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. |
Sorry. We don't have that right now. I would create one |
@dckc rchain/rchain#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 (rchain/rchip-proposals#35 ) . That way, the Agoric side would be compelled to accept that the RChain side had sent a message. |
progress in office hours today: 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
The text was updated successfully, but these errors were encountered: