IRC channel logs
2023-10-23.log
back to list of logs
<ckie>so how does ocapn handle cases where one actor is attesting something to another? <ckie>like does it do anything in terms of signing? like can alice go "here is this actor you can Have It, it's signed by me and has no functions, but you have it now"? is that a thing? <Zarutian_iPad>ckie: I am sorry. Ya need to explain what you mean by actor and attesting <ckie>right i am still very much jiggling around the concepts, i'm coming from spritely so i might be mixing it up <Zarutian_iPad>you talking about 3rd party handoff? (which is actually introduction but the handoff stuck) <ckie>like, let's say a follower referral system in an ActivityPub-like social media <ckie>my friend wants to follow this new person, and asks me if i know "hash(prospect_friend)" <ckie>i say yes, and then I want to give her something that she can use to prove to prospect_friend that she knows me <Zarutian_iPad>oh, I see. That is a bit higher level in the stack if I may abuse the OSI stack model a bit <ckie>but what primitive is used for that referral proof? <ckie>because goblins gives me the impression that the crypto sig is magically abstracted away <Zarutian_iPad>in E (see erights.org) this is called the Trademark or Stamp pattern <ckie>oh wow that's an old mediawiki <ckie>uh vaguely, i haven't actually played around with any of this so it's very floaty <Zarutian_iPad>so, given the eq? primitive or a WeakMap one can make a constructor function that makes two new objects that have access to the same WeakMap. These two objects are the sealer and its corrisponding unsealer <ckie>could you like show the ops alongside the underlying ops and where they're running, if it's not too much trouble? <Zarutian_iPad>now, you give the sealer some thing and it puts it in a box only the unsealer can open <Zarutian_iPad>how does the sealer do it? Well it makes a 'box' object that it uses as a key to store it and the thing in the shared weakmap and returns the 'box' to its invoker. <Zarutian_iPad>the unsealer, given a 'box' just uses that as the key into the same weakmap and just gets the thing from there and returns the thing to its invoker <ckie>so what if I have a bunch an array ({ foo: int, whatever: string, secret: Sealer<T> })[], and I want to unseal all the secrets? <ckie>that's a lot of network I/O <ckie>or even worse, Sealer<Sealer<Sealer<T>>> <ckie>that's 3 roundtrips min! <Zarutian_iPad>how ever one can make a cryptography version of the sealer unsealer pattern easily yet have the same interface <ckie>yes! so this is what made me come here <ckie>it's a problem on the current web too. at work we have this incredibly frustrating thing where we fetch the index.html, the js, a list of categories, the categories, and all the items in them <ckie>somehow it's still fast because cloudflare but oh dear does it hurt to think about <Zarutian_iPad>so, you want to 'name' an object without nescisarily grant access to it <ckie>how so? to GraphQL-like query it? <Zarutian_iPad>CapTP of E has something called the swissBase, the swissNum, and the swissHash <ckie>for the sealer array case, it'd be nice to go "I want *all* of these" <ckie>and generally and for the other case, asymmetric sealer/unsealers? <Zarutian_iPad>basically you want to ask your friend if certain object is known to them and get a signed answer back, no? <ckie>sure but that's not a special case? <Zarutian_iPad>btw I mentioned the sealer unsealer pattern as if someone is Stamping a thing, it just means they hold the sealer close but give the unsealer to anyone who asks <ckie>I want Friend[].map(=> .do_you_know(crypto_hashlike(prospect))).await <ckie>and if they know they can return a referral in the same roundtrip <ckie>i guess that's spritely again because the developer still has to be careful to avoid the net roundtrip, no magic dust there <Zarutian_iPad>sure, but I think you might be on the wrong osi concept level here <Zarutian_iPad>the unsealer can only unseal boxes made by its corrisponding sealer <ckie>oh wait yeah i got confused <ckie>i conceptualized it as the sealer being a one-time thing thats thrown out once the box/unsealer tuple is made <ckie>Zarutian_iPad: could you elaborate? <Zarutian_iPad>you see CapTP and ocapn is about how to streatch the object-/actor-graph between vats. But only eventual sends and not immediate calls will work on references streacthing between vats. <ckie>it feels like there's a missing compiler layer of sorts? <ckie>yes, because like if the server/client are of the same codebase <ckie>the compiled-down protocol can have a single endpoint for "call these things on these things, and then loop over those unsealed boxes and call just those blue things" <ckie>that's be 2 RTs and a pretty large size before, whereas it's just a byte or two after <Zarutian_iPad>I think that you are confusing concepts from ActivityPub and such to what ocapn is about <ckie>but it does give preferential treatment to clients the server is aware of, and that's no good <ckie>by C/S i mean the vat that hsa the stuff i want and me <ckie>motivation: tor is slow as heck. home servers can be pretty slow <ckie>and i feel like performance gets washed away and maybe bolted on later <ckie>i'm trying to figure out where the goblins/ocapn/application-layer separation lies <Zarutian_iPad>something like js`E(sealedBoxesArray.map((box) => E(remoteUnsealer).unseal(box)).map(t => E(t).doBlue()` <ckie>so what does that look like linearized? <ckie>most importantly: 1 or 2 rt? <Zarutian_iPad>one big packet/tcp-segment with the invocations of the unsealer, <ckie>but we don't have t to doBlue on yet? <ckie>and even more, RCE! "arr.map(t => t.doBlue())" what about a loop that doesn't terminate? <Zarutian_iPad>you see, the sealedBoxes array lives on the sending side and gets iterated over at that place <Zarutian_iPad>each iteration is sending the box at that array index to the remoteUnsealer <Zarutian_iPad>then the second 'looping', the second .map() is actually eventually sended to the promise for the resulting array of the first 'looping' which in turn does the .doBlue() eventual send on each item in the results <ckie>not a physical one! but yuuppp <ckie>so we already know we'll get a Promise back? <ckie>that still doesn't explain the remote .map/loop <ckie>this keeps on working even if nested? i.e. if sealedBoxesArray is something this vat doesn't have a copy of yet? <Zarutian_iPad>up to a point because you cant build a whole bridge just of promises so to speak <ckie>why not? if we know the return types <ckie>it'd be amazing if arbitrary queries were possible and we didn't run into the halting problem <ckie>i think there it's because of the gpu arch probably? but like, in glsl iirc loops are limited to fixed sizes and such <ckie>complete sidenote, my new really expensive ssd keeps on flipping a few bits here and there and its quite frustrating <ckie>mostly because everything goes "woomp woomp!! hash wrong!!" <ckie>WD SN850X 2tb, would avoid <Zarutian_iPad>but I think #spritely is more conductive for this discussion as ocapn is rather more lower level protocol focused <ckie>so what does ocapn define? the protocol for these rpc's? <ckie>"12:00.0 Non-Volatile memory controller: Sandisk Corp Western Digital WD Black SN850X NVMe SSD (rev 01)" <ckie>my laptop has a "Sandisk Corp WD Black SN750 / PC SN730 NVMe SSD" that's been perfect <Zarutian_iPad>I would go with Sandisk or Toshiba or such for ssds but WD okay for actual hard drives <ckie>yeah the reported name is interesting though <ckie>heh, string ports in the java RMI Naming.rebind <ckie>Zarutian_iPad: thank you for all the info you poured on me! <ckie>will move there when i've had time to process this & think of some new problems <ckie>or maybe, more refined problems. or maybe spritely just isn't it and it's gonna make slow miserable apps- <ckie>yeah i suppose i have some reading to do (: thanks again!