IRC channel logs
2023-06-24.log
back to list of logs
<Zarutian_iPad>been thinking about how to support multi named vats/principals <Zarutian_iPad>in the case of an ActiveCapCert, Macaroon, or heck a bare source_stringed function, one should be able to name the principal by the content cryptographic hash of the source string of the thing <Zarutian_iPad>KrisKowal[m]: re the video: regarding captp over udp that Dave is thinking about doing: maybe start with BitTorrent uTP? <KrisKowal[m]><Zarutian_iPad> "nothing good on the telly so I..." <- I’m sorry that your television is broken. <KrisKowal[m]>I jest. Thank you for the notes. That makes sense. Might make even more sense if the way to identify a vat is correlated to how the connections are authenticated. <KrisKowal[m]>But that wouldn’t really require cryptography per se to be mentioned in the wire protocol. <KrisKowal[m]>I hesitate to judge the ocapn proposal as stands since I haven’t given it a close read yet. <Zarutian_iPad>it can be as simple as two twires of an serial link at a spefic port or pins <KrisKowal[m]>I have lots of questions that I’m sure would be answered by a cursory read of the spec :-) <KrisKowal[m]>But they’re of the nature: does ocapn as proposed already effectively express the 3PH protocol on top of the data and message passing layer? I’ve seen a hint of that already since there’s a conventional bootstrap object with methods to support 3PH. <KrisKowal[m]>My observation is that there’s actually a great deal of need for flexibility in the transport layer. For Endo, I’ve already found that I need 3 different message framing layers: WebSocket, Chrome Native Message Host’s framing protocol, and our own implementation of Netstring, which we use over file descriptors, UNIX domain sockets, and Windows named pipes. <KrisKowal[m]>We also observed on that call that “transport protocol” hints have to exist somewhere. So, my question is, where are they currently? <KrisKowal[m]>As well as Chrome extension ports, which are different, presumably for reasons related to hubris. <KrisKowal[m]>And desc:handoff records are layered on top of message passing, right? They’re in a message? <KrisKowal[m]>I just feel really irresponsible for asking these questions without first doing a lot of reading. <KrisKowal[m]>This immediately answers one question: there must be something akin to a `WeakMap<object, Exporter>` that is shared by multiple connections. <KrisKowal[m]>That is, all connections across which a hand-off might occur. <Zarutian_iPad>I think so but I am not sure. Have not scrutenized the goblins implementation <Zarutian_iPad>in the gist ai linked earlier, there is three level map so to speak <KrisKowal[m]>A grannovetter with the labels “gifter”, “receiver”, and “exporter” would be handy. <KrisKowal[m]>The descriptions of the principles are forward-referential. <KrisKowal[m]>I think I grasp the design now. In the connection between the sender and receiver of a gift, the handoff record is written inline, and some interactions occur out-of-band with the various parties’ bootstrap objects. So, it would seem the crux of the debate on layering is how much information should be communicated in-band vs out-of-band. <KrisKowal[m]>Like, conceivably, the handoff record could just contain a nonce, which would be reified as a promise, and resolved thru low-level ocapn messages between bootstraps. <KrisKowal[m]>But there must be some placeholder in band. Whether the cryptographic material needs to be there is under debate. <Zarutian_iPad>you need to have the exporter vat id and connection hints in it too <Zarutian_iPad>in CapTP of E the Promise3Desc (which serves same purpose as desc:handoft-give) it has three things in it: the vatid of the exporter, the connection hints, and the giver, recipiant spefic gift-id <Zarutian_iPad>but it is not signed as the recipiant just has to establish a connection to the exporter and on that connection invoke the .acceptFrom() (`fetch` in goblins ocapn) method naming the gifter vat id and giving the gift-id <KrisKowal[m]>Is there debate over whether the exporter vat id and connections hints must be inline? <Zarutian_iPad>not that I know of, just a debate on if the desc:handoff-give needs to be signed or not <KrisKowal[m]>Do we have agreement that the connection hints must be something like a buffet of routes and protocol options, like IPFS addresses? <KrisKowal[m]>So the “no sign” camp presumes that the connections are pre-authenticated? <Zarutian_iPad>the thing is the recipiant vat might have never heard of the exporter vat until the Promis3Desc / desc:handoff-give <Zarutian_iPad>pre authenticated, credible, and integrity-checked but not nescisarily confidential <Zarutian_iPad>re the list of connection hints buffet: sure, it might even something that the exporter vat told the gifter vat when they established a connection <KrisKowal[m]>right, email, telephone, slack, smoke signals, carrier pidgeons… <KrisKowal[m]>sings: all you need is nand. all you need is na-a-a-and.