capnproto / go-capnp

Cap'n Proto library and code generator for Go

Home Page:https://capnproto.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Level 3 RPC support

zenhack opened this issue · comments

Some discussion came up on the mailing list about adding Level 3 RPC support:

https://groups.google.com/forum/#!topic/capnproto/iXuK8wjmG8o

Louis was looking to arrange a video call around this; @zombiezen I know you don't have a ton of bandwidth for this project these days, but thought I'd ping to see if you'd be interested in joining us? No pressure.

I don't know Louis's GitHub handle, but I'll cross-link this issue on the mailing list.

If there's someone looking to get ramped up on contributing to the Go package, I'm happy to pass on knowledge, but otherwise I'm going to have to decline due to other commitments.

I don't know Louis's GitHub handle, but I'll cross-link this issue on the mailing list.

@zenhack I'm here 🙂

If there's someone looking to get ramped up on contributing to the Go package, I'm happy to pass on knowledge

@zombiezen I'm quite interested in maintaining this package, and would definitely appreciate a guided tour. Happy to work around your schedule as much as possible.

Excellent! Left a reply on the mailing list so you've got my email address.

@lthibault have you assumed the role of package maintainer yet? I am also interested in helping 🙌
cc @zombiezen

I'd definitely be interested in joining, let's use jitsi again. I have a preference for early afternoon EST, but am flexible.

@zenhack Awesome! In the meantime, I'll add you to our Slack community, as I think some real-time coordination is helpful.

@lthibault Excellent! I am on the west coast, PST. Thanks!

'Morning, @taylorjdawson !

You should have an invitation in the gmail account listed in your GitHub profile 🙂 . I'll re-send it, just in case.

We're finally ready to break ground on this! There are some preliminary things we should think about, and some design questions. In particular:

  • I've already addressed this, but #451 adds support for using vines, which we'll want to ease upgrades.
  • We may want to consider finally addressing #2 first, and maybe add a corresponding API to generate non-answer promises. This would make path shortening much more useful.
  • There are a few parts of the implementation I want to audit & think through the soundness of. In particular:
  • We'll want to define the main logic on top of an abstraction like the VatNetwork described in rpc.capnp, but we also will need to define at least one real implementation for it to be of any use.
    • We may want consider looping Kenton in on the design of that, to get buy-in for compatibility with any future implementation in C++ (and likely others).
    • Since BN is funding the work on this, I'd obviously like to hear from @lthibault what the environment they're using this in is like, and factor in those constraints.
    • I'd like to be able to use both websockets & webrtc at some point so we can have vats in the browser use 3PH. The fact that webrtc doesn't give vats an obvious stable identifier to work with introduces some challenges, and I'd like to think about how these might be solved before we commit to a design that prevents it.
    • It might be nice to design this in a way that different transports can be negotiated (with vats having preferences) within the same VatNetwork. Maybe using a public key as an identifier for the vat and having a signed statement or such that tells other vats how to connect to it.
    • I do want to think a bit about how to make interop with an ocapn bridge work smoothly as we design this. At the last pre-standardization meeting Jessica gave a presentation on how goblins currently does this, which is worth digesting & reviewing: https://share.tube/w/44DhG6pcEyCFgnUHhxnUTn

Probably some of the above should be split out into their own issues.