IRC channel logs
2025-01-22.log
back to list of logs
<jfred>oh whoa I hadn't noticed that there was a Python netlayer implementation in the test suite <tsyesika>jfred: yeah just the tor onion netlayer and then a very basic TCP one for testing. While not my aim when I wrote it, the OCapN test suite in python technically implements all of OCapN and so it probably wouldn't take too too long to adapt it to be a general OCapN library <jfred>and one of my friends that I've talked with about ocap stuff a bit is way more of a Python guy than a Scheme guy, so this might end up being a useful reference later on <tsyesika>that'd be cool :) if they end up getting interested and working on it, they're more than welcome to join the channel and/or group. We're always looking for more folks to implement, use it and help us improve the spec <Zarutian_iPad>I am a bit puzzled about the gift mechanism used via the two methods on the bootstrap object <Zarutian_iPad>that in the 'deposit-gift method the recipiant or their public key (or hash there of) isnt meantioned <Zarutian_iPad>I do know that goblins doesnt use vat identity public keys or otherwise but session keys <Zarutian_iPad>as I understand it, the 3ph mechanism in goblins relies mostly on the nested certs of desc:handoff-receive and, inside that, desc:handoff-give <tsyesika>right. The public key is per-session so in the typical alice, bob and carol situation where alice is giving a a reference of carol to bob. Alice doesn't know the key pair bob and carol will use <Zarutian_iPad>Alice does know two keys, Bob public key he is using on the Alice-Bob connection and the one Carol is using on the Alice-Carol connection, yes? <tsyesika>and alice helpfully uses both things when creating the desc:handoff-give <Zarutian_iPad>which bob needs to sign over when he makes desc:handoff-recieve, no? <tsyesika>she puts bob's public key in the alice <-> bob session in the desc:handoff-give and then signs the desc:handoff-give with her private key in the alice <-> carol session <tsyesika>well when bob makes the handoff-recieve it includes verbatim the desc:handoff-give, with its signature so carol can check it and verify that it is in fact alice who made it. Once carol is sure of that, she can then trust the key alice left inside the handoff-give for bob. Bob signs the desc:handoff-recieve with the key he uses between alice <-> bob <Zarutian_iPad>so, why doesnt alice inform carol of bobs public key in the 'deposit-gift deliver-only message? <tsyesika>she doesn't need to, she includes it in the desc:handoff-give <tsyesika>carol already has that info from bob and has a mechanism to verify it's trustworthy <Zarutian_iPad>the thing is, that the 'name-/nonce-space usage of gift-id betwixt alice and carol could leak, no? <tsyesika>the gift ID can leak and it doesn't matter, because you need the desc:handoff-give from alice and you need bob's private key in the alice <-> bob session <tsyesika>having just the gift ID alone doesn't actually help you <Zarutian_iPad>authority wise it doesnt matter but info leakage wise it does <tsyesika>maybe you can explain the problem a bit more, I'm not seeing the issue <tsyesika>Imagine mallet looks at the traffic between alice and carol, see's the gift ID. How can mallet use this to his advantage? <Zarutian_iPad>plus, how E did it makes it easy-ish for me to interface/integrate my ActiveCapCert stuff seamlessly as I could use the 'naming' of the recipiant pub key. <Zarutian_iPad>Mallet doesnt need to see that traffic, just the handoff certs <tsyesika>the desc:handoff-recieve includes a handoff-count though which makes it so it can only be used once. <tsyesika>so if mallet saw the desc:handoff-recieve and tried to reply it, it'd not work <Zarutian_iPad>as I said it doesnt matter authority granting wise but info leakwise as mallet can infer how much of gifting is happening between alice and carol for other parties <Zarutian_iPad>another puzzlement of mine is that there doesnt seem to be a return value of 'deposit-gift, which Mark M called a vine (something to hold onto so the gc system doesnt prematurely collect the gift, yet allow it to be gc'ed later) <tsyesika>I'm not seeing how alice leaving bob's key when depositing the gift prevents people who can see the desc:handoff-give and desc:handoff-receive on the wire from knowing how many gifts are happening... <Zarutian_iPad>and also how does alice know that the gift got deposited if not for such a vine? <Zarutian_iPad>it allows for ?sub-?namespaceing of alice gift-?space? on carol, so to speak <Zarutian_iPad>then the gift id only need to be unique per gifter-recipiant on the gift hosting vat, no? <tsyesika>well part of the assumption is that messages are delivered not dropped so if alice sends a message to deposit a gift to the bootstrap object she can be fairly confident alice will get that message delivered. As for how carol knows when to GC the object, she can immediately remove it from the gift table since bob can't re-use the desc:handoff-receive, but she obviously can't immediately GC the object. GC happens through the usual <tsyesika>the gift ID is unique only between the giver (alice) and exporter (carol) <tsyesika>you can think of each session having their own gift table <tsyesika>i.e. gift ID is per-session unique, not per peer unique <Zarutian_iPad>that only applies to gcing the alice-carol ?stub? (the thing that holds onto the gift on alice-carol connection behalf) <tsyesika>not super familiar with vines, but the purpose of this is so carol knows when she can drop the entry in the gift table? <tsyesika>(by not super familiar with, I mean I've never heard of them :)) <Zarutian_iPad>that only applies to gcing the alice-carol ?stub? (the thing that holds onto the gift on alice-carol connection behalf) <Zarutian_iPad>the vagaries of the 'net could delay bob-carol messages, particular the one of 'withdraw-gift <Zarutian_iPad>so alice-carol gc:export message can show up before bob retrieves the gift, no? <tsyesika>I'm going to head to bed in a second so if you have more questions someone else will have to answer or I can another day :) Alice doesn't decide when her gift gets GC/cleaned up in the gift table. That either happens when alice <-> carol's session ends, or when bob collects it <tsyesika>alice doesn't actually do any GC for the deposit gift <tsyesika>okay, hope I helped explain it a bit more, g'night! <Zarutian_iPad>so, there isnt a way for alice to tell carol that she is giving a spefic giftto bob, tell bob about the gift, get netlayer ack from both and her then turning off her wifi?