IRC channel logs
2023-11-16.log
back to list of logs
<Zarutian_iPad>which reminds me, I been wanting to make an uTP+libsodium netlayer for ocapn. Why? Because then it can piggyback on Bittorrents DHT swarm, specially if 'fake' infohashes are used to name the nodes in those ocapn_locators. <Zarutian_iPad>as uTP connections for bittorrent get identified with the string "bittorrent" before the rest then I propose we identify uTP connections for ocapn with the string "ocapn" <Zarutian_iPad>ACTION notes s/and permits assertions that two objects same the same live reference identity./and permits assertation that two objects that have same object identity do have the same live reference identity./ <Zarutian_iPad>ACTION reads line 254 of that document and finally now understands what the wants-partial? boolean is about <Zarutian_iPad>tsyesika: I have made a first pass review on the implementation guide you wrote <Zarutian_iPad>been looking at the differences betwixt spritely goblins bootstrap object and the NonceLocator object in E <Zarutian_iPad>`deposit-gift` has only two arguments whilist `provideFor` has three. Similiar situation with `withdraw-gift` having only one argument whilist `acceptFrom` has two. (Lets put the vine stuff aside for now) <Zarutian_iPad>what is the extra argument in an invocation of `provideFor` or `acceptFrom`? in the former it is the vatid/name of the recepiant node whilist in the latter it is the vatid/name of the gifter node <Zarutian_iPad>I hold forth that these node names need not be one to one to vats.(That is a vat can have many names.) <Zarutian_iPad>But these names can be the public keys generated at each session start. <Zarutian_iPad>this simplifies the stuff around the <'desc:handoff> as no certificates are needed there, only something like <'desc:3ph ExporterName ExporterOcapnLocator giftnonce>. <Zarutian_iPad>but this requires netlayer authentication, integrity, and confidentiality or credibility. Which is something we want anyway