IRC channel logs
2024-08-13.log
back to list of logs
<weary-traveler>cwebber-: i had a question regd vats vs nodes. it's clear that inter-node communication is via captp. how does inter-vat communication happen? does that have to be necessarily via netlayers as well? <cwebber->weary-traveler: it's very efficient in goblins! <cwebber>in goblins every local object reference has information about how to reach its vat <cwebber>typically this is depositing a message over Fibers, so it happens in-process <weary-traveler>hm. what about vats that are in two different processs on the same machine? or is that not permissable in goblins? and separate processes implies that they are separate nodes <dthompson>weary-traveler: separate processes would require captp <dthompson>we don't yet have a netlayer that uses unix domain sockets, though. that is on the roadmap as it's needed for the shepherd + goblins project. <dthompson>cwebber and I have been at dweb camp for the past several days so we're catching up on irc logs now. <dthompson>glad you're checking out goblins weary-traveler! sorry no one was around to answer questions earlier <weary-traveler>dthompson: i see. thanks for confirming that separate processes would require captp. i looked at the testuds layer, but discovered that that the implementation is lacking. essentially, string->uri . ocapn-id->string doesn't give a reasonable answer which makes it difficult for the other process to reify the reference. to the extent i understand, the sturdyref implementation is lacking <weary-traveler>dthompson: is my understanding correct that in goblins there are at least as many nodes as there are processes? i.e., since separate processes seem to require captp that these could necessarily have to be separate nodes <dthompson>weary-traveler: yes, each process would be a captp node, whether on the same machine or not. <dthompson>emphasis on the "test" in "testuds". it's only for internal testing. <dthompson>we've mostly been focused on network communication, so you can use the tcp+tls netlayer for now until we have a real unix domain socket netlayer <dthompson>(which we'll have to implement somewhat soon for shepherd + goblins) <weary-traveler>i look forward to that. thanks for the reference regd tcp+tls layer. it seems the prelay-server example uses it? <dthompson>that's the simplest/best netlayer to use at the moment, since you can keep the networking on localhost. <weary-traveler>dthompson: for a module to implement a netlayer of some sort, what are the base operations that it needs to implement? what are some of the invariants that said implementation needs to adhere to? i wasn't able to find these in the docs, nor in my cursory look through the codebase <dthompson>this is on our todo list to document, and the constraints around these are still coming to consensus in the ocapn group. but basically, a netlayer needs to provide a way to read/write captp messages in a way that a snooping third party cannot decipher the messages. <dthompson>over the network, this means using encryption. <dthompson>and the public key becomes part of the address to the node <weary-traveler>i'm guessing some correctness guarantees are also assumed. i.e, in addition to third party being unable to, the intended party (and only them) ought to be able to receive the message <weary-traveler>perhaps, also, some way to share references (sturdyrefs i think they're called)? or is that not essential <dthompson>not sure if that's true generally, as relays can be involved and that's OK <weary-traveler>i see. yes, this would be quite useful to document. i'm speculating, some of the test cases already check for these conditions? <dthompson>some of this is territory for a professional security audit <dthompson>I don't think unit tests alone are sufficient <dthompson>maybe the official ocapn test suite could help with some of this. not sure. <weary-traveler>didn't mean to imply that they'd be sufficient, sorry. but some combination of model checking of the specification, tests, audit review etc. probably is needed <weary-traveler>i suppose i'm trying to do two things. 1. try and internalize goblins, so i understand if i were to use it for an application what that would look like. 2. identify areas of the API that are more stable/certain, so that i minimize the risk of using something that is drastically changed tomorrow <weary-traveler>(and regd tests i was thinking more property based tests - not sure if guile has something like haskell's smallcheck, but it wouldn't be too hard to code) <dthompson>dckc is using it for a goblins experiment, which is how I learned about it <weary-traveler>ah should be a small change from that then. depending on how it's implemented, it might even work directly. smallcheck simply does exhaustive-checking up to a point <weary-traveler>dthompson: regd 2 (stable parts of the API) above, are there external projects that are using goblins today? you mentioned shepherd+goblins a couple of times. are there any other projects <weary-traveler>dthompson: will be afk. but if you can sneek a response, i'd appreciate it <dckc>" in a way that a snooping third party cannot decipher the messages" <- dthompson is that a netlayer requirement? I thought only integrity was a requirement. Agoric uses captp without encryption. <dthompson>sneek: later tell weary-traveler I think shepherd will be the first external project to use goblins (if it is adopted) as we are only now starting to reach a point where goblins is more generally usable <dthompson>I know this has been a matter of debate/confusion in ocapn so I didn't want to speak too strongly about it <dthompson>but generally speaking if you can encrypt the traffic in your netlayer then you should do so. <dckc>encryption allows you to say "this large random number has only been disclosed to selected parties; whoever has it is authorized" <dckc>but there are other ways to establish integrity such that "whoever refers to object 7 on this channel is authorized"