WIP: sketch out interfaces for working with vat networks #452
Conversation
Similar to the VatNetwork interfaces described at the bottom of rpc.capnp; this patch introduces a sketch of what these interfaces might look like in Go, plus the beginning an in-memory implementation to use in tests. Needs testing & docs, and of course isn't actually used by anything.
|
Note this is using the term "Peer" instead of "Vat" in the API, because the latter is really a unit of concurrency, not a node in the network. See ocapn/ocapn#18 |
|
I like this. I've stared at that spec a few times, and have often wanted an implementation to play around with. One thing I'm still not clear about, though, is what bearing this has (if any) on how applications interact with the capnp library. Are application developers going to need to provide their own implementation of these interfaces in order to support 3PH? If so, I would appreciate a quick sketch of how this interacts with the existing |
|
Quoting Louis Thibault (2023-02-15 14:11:27)
Are application developers going to need to provide their own
implementation of these interfaces in order to support 3PH?
We'll probably want to define and implement at least one that people can
use out of the box. See my comments about this on the 3PH issue.
I would appreciate a quick sketch of how this interacts with the
existing rpc.Conn API. I'm sure it's simple enough, but it just hasn't
clicked yet.
Basically, instead of supplying a Transport to NewConn, you'd
construct a Network spawn a goroutine calling Accept() in a loop,
and optionally call Dial to connect to some other peer and get its
bootstrap interface.
This bit should be documented (hence this is WIP) but: the idea
with the Network and PeerId fields on on rpc.Options is that
the logic inside Conn would use these when dealing with third
party caps and Provide/Accept message types. Dial() and Accept()
on Network would fill these fields in themselves; app code wouldn't
generally deal with them directly.
|
|
(update, went ahead and documented those fields). |
|
Quoting Louis Thibault (2023-02-15 15:25:03)
Is it reasonable to remove this and make the interfaces accept a
type parameter instead? It would be quite elegant to be able to
reuse libp2p's peer.ID type, and I think it would also make sense
for the type system to distinguish between, say, Network[peer.ID]
and Network[uuid.UUID].
I considered that, but we're going to want to store these inside a Conn,
so we're going to end up needing to hide the type anyway. I suppose we
could make the PeerId wrapper private though? But then it's still going
to propagate into Options, so you'd have to specify a type for that even
when doing point-to-point connections...
|
Since we've renamed PeerId -> RemotePeerId in Options, we need to do it here as well.
...to match the one for Dial()
|
Added a bunch of docs. |
Many of these are copied from rpc.capnp, possibly slightly modified.
Ah ok, that makes sense. Partly as an intellectual exercise, and partly in case there's something there: the options type is consumed internally by If that is indeed the case, it seems like we could get away with defining I have a hunch that it will be helpful to enforce separation of vat-networks based on type. Maybe I'm overthinking this, though. |
|
#348, re-running. |
Now I see why the sketch in rpc.capnp had the analogues of DialIntroduce/AcceptIntrocued as methods on the connection. This probably still isn't right; still fussing with it.
|
That feels overly complex. I kindof suspect applications that use more than one Network will be relatively rare, and also I see various problems with things like importClient which hold a pointer to the connection; you'd have to again propagate the type parameter... it just doesn't seem worth it to head off mixing up peer IDs. I'm not 100% happy with this; I think there are tweaks I'll want to make to the interface, but it's at the point where it's getting hard to predict exactly what they will be before diving in and actually trying to implement the logic this is supposed to support -- what do you say to merging this as-is with the understanding that it will probably be revised a few times? |
Similar to the VatNetwork interfaces described at the bottom of rpc.capnp; this patch introduces a sketch of what these interfaces might look like in Go, plus the beginning an in-memory implementation to use in tests. Needs testing & docs, and of course isn't actually used by anything.