IRC channel logs
2023-01-16.log
back to list of logs
<fr33domlover>o/ Do personas/contact-lists/petnames require to use crypto keypairs to identify people? Or do they work by comparing ocap uris/swissnums? Or some other form of token? When I add someone/something to my contact list, which is sort of a key-value map, I suppose the type of key is text (the name) - what would the type of the value be? <fr33domlover>(Asking because I want to implement petnames on top of CapnProto and hoping to maintain some compatibility, at least on the concept level) <tsyesika>the way they work in spritely's implementation is comparing the sturdyref of the "persona" object (it assums if you can control that URI, you're the real person, which is true in the case of onion netlayers which is what we currently support). I don't think this needs to be the case, it could be done with other mechanims <Zarutian_iPad>fr33domlover: you can also look into how brands from ERTP from Agoric are used <fr33domlover>isd, does object reference equality work in CapnProto? IIRC it's level-2 and CapnProto has implemented only level-1? <tsyesika>okay np, I'm going to head off for the evening <tsyesika>fr33domlover: when you've implemented can you ping me with the details, I'd love to take a look <fr33domlover>Might take a while, but likely sometime in 2023 because hoping to put this on my MoU with NLNet ^_^ <isd>fr33domlover: reference equality works in haskell-capnp, though note that the references really do have to be the same; if one is a proxy they are not equal. I actually think the "level" language is confusing and not really useful. <isd>go-capnp is probably going to implement "level 3" before "level 2," for example. <isd>and reference equality is supposedly "level 4..." <isd>I think it would be better to think of these things as independent features <isd>Note that you'll want to use waitClient before comparing, to make sure you're not comparing promises, which will be unequal to their targets. <isd>But once you've done that, you can just use ==. <isd>(I think one thing that's a little confusing is that there's hypothetically some extra machinery that might be needed for reference equality on some netlayers but not others. And it isn't needed on simple point-to-point connections, so it's easy to have it work there without much effort) <isd>(And as I implement 3PH, I plan on trying to design it in such a way that it is unnecessary there as well...) <isd>Note though, that without 3PH implemented objects from different connections will always be unequal. So that may make it a bit annoying to use currently. <isd>Once I add 3PH to the go implementation, I plan to write a proxy that other implementations can use to get 3PH "for free" <isd>So that's in the pipeline. <ocdtrekkie>And if I try to explain what that entails I will get it wrong, so I will let someone else do that. <isd>Lets you hand a capability from one connection to another, and have the provider & recipient form a direct connection. <jfred>Which does feel like the most error-prone part if multiple netlayers are supported... because both the provider and recipient need to support (and be directly reachable via) the same netlayer <isd>You can fall back to just proxying if you're unable to establish a direct connection.