IRC channel logs

<tsyesika>just catching up on IRC. Awesome you're working on an implementation SignalWalker, really exciting to hear!

<tsyesika>I hope we see you at the OCapN monthly meetings if you can make it :)

<Zarutian_iPad>which is next tuesday for january iirc

<Zarutian_iPad>cwebber: 3ph as topic here

<Zarutian_iPad>as vats in the current goblins implementation do not have a single vatid but multiple based on session spefic public keys, I have been wondering about gift nonce collisions

<Zarutian_iPad>ACTION could be mistaken

<Zarutian_iPad>E circumvents that by venn diagramming into existence subnamespaces

<tsyesika>Zarutian_iPad: there shouldn't ever be gift ID collisions

<tsyesika>vats aren't part of the CapTP draft spec but each implementation is responsible for ensuring gift IDs are unique

<tsyesika>(goblins does this by having an incrementing integer)

<Zarutian_iPad>which end of an connection increases the integer?

<tsyesika>it's the gifter which comes up with unique gift IDs

<Zarutian_iPad>a bit of definitions, we have host (where gift lives), giver, and recipiant

<tsyesika>the gifter in this case is defined in this section: https://github.com/ocapn/ocapn/blob/main/draft-specifications/CapTP%20Specification.md#third-party-handoffs

<Zarutian_iPad>and the unique gift ids are namespaced to the host? that is the recipiant asks the host for gift nr x which gifter picked, no?

<cwebber>Zarutian_iPad: collisions shouldn't happen any more than they do with import/export tables :P

<cwebber>they're namespaced to a pairwise unique name for the session between two parties

<cwebber>and if there's a new session, a new name is made

<tsyesika>Zarutian_iPad: the gift IDs are specific to the gifter <-> exporter session

<Zarutian_iPad>aah, okay

<tsyesika>the gift ID only applies between gifts given by the gifter to the exporter in that specific session

<cwebber>Zarutian_iPad: jump ahead to 0:21 of https://dustycloud.org/tmp/ocapn-handoff-wip1.mp4

<cwebber>A<=>B, A<=>C, B<=>C

<cwebber>but really those are unique to each *session* between A and B, etc

<Zarutian_iPad>so instead of E's way of having the gift id namespaced to gifter and recipiant, it is namespaced to gifter and exporter (host from earlier)

<cwebber>yes.

<tsyesika>yeah

<cwebber>when an ocapn session starts, each side makes a unique key *just for that session*, and shares their public key. a-of-a2b and b-of-a2b we might call them

<tsyesika>It's because the gift lives on the exporter

<Zarutian_iPad>the spec murkily implied exporter global gift ids

<cwebber>then both sides sort those keys and hash them

<cwebber>and then that's a unique name for a<=>b

<cwebber>and remember, we are using certificates

<cwebber>not nonces.

<cwebber>so now jump to 0:42 of https://dustycloud.org/tmp/ocapn-handoff-wip1.mp4

<cwebber>Gift certificate: Give A<=>C:5

<cwebber>and we actually say we're giving it specifically to B's key

<cwebber>it's like zcap-ld certs

<Zarutian_iPad>indeed, CapTP of E relies on the proof of the vatid whilist goblin uses the certs

<tsyesika>there's also the explainer video I did last feb which should help explain this: https://ocapn.org/news/spritely-goblins-third-party-handoffs-implementation-presentation.html

<cwebber>which is then handed to B, and then jump to 0:55

<cwebber>now B makes a receive cert which points at the give cert and proves that it was their key (from a<=>b) that was authorized to pick it up

<cwebber>Zarutian_iPad: everyone seems to keep thinking we implemented things the E way... we didn't!

<Zarutian_iPad>yeah, perhaps I am just a bit too steeped in the way E did things

<cwebber>I designed OCapN's handoffs around the recent presentation MarkM gave about "gift tables", and then added the ceritificate approach similar to zcap-ld

<cwebber>we did this so that this could even work with Agoric's use case of needing to interop with blockchains

<cwebber>it should be robust enough to support that since no shared secrets are required

<cwebber>Zarutian_iPad: it's not just you, it's a problem we keep running into

<cwebber>tsyesika gave that lovely presentation to the ocapn group, and everyone asked good questions

<Zarutian_iPad>now I am trying to figgure out how to change how ActiveCapCert uses these gift tables

<cwebber>and yet still people who were there on that call keep assuming we did things E style

<cwebber>multiple Agoric folks have multiple times have said "well you're relying on shared secrets, so that's a problem"... we're not!

<tsyesika>I donno if it's worth giving another presentation (we do have the recording so maybe not)

<Zarutian_iPad>hmm... it might not be that goblins captp use shared secrets but it does use public key cryptography where the signing private keys are kept secret/private

<tsyesika>btw re: the spec being unclear on this, it does say "gift-id This is the gift ID that is generated by the Gifter that the desc:export will be deposited at. This gift-id MUST be unique for gifts deposited on the exporter by the gifter (i.e. per session)."

<tsyesika>maybe that language could be made more clear, not sure

<Zarutian_iPad>and blockchain vats are only fortifed but not veiled afaik

<Zarutian_iPad>(you can watch all of it but not touch kind of thing)

<tsyesika>not sure what that means but yes it uses per-session public key crypto so you do need to keep your private key secret but all messages put on the wire can be public

<Zarutian_iPad>aha, it is not just the wire to/from a vat on blockchain that is public but the entire vat state itself

<tsyesika>are you using vat to mean captp capable node?

<tsyesika>ACTION is assuming so

<Zarutian_iPad>in the sense of E where you have object heap+event loop

<cwebber>Zarutian_iPad: I think I see what you mean

<Zarutian_iPad>which, the vats, in this case are connected via captp.

<cwebber>Zarutian_iPad: you're saying that the blockchain, as a vat itself, should be able to exchange ocaps

<Zarutian_iPad>yebb

<cwebber>hm

<cwebber>there still may be a way to do this with certificates.

<cwebber>with ocapn's design

<cwebber>but that's a good point

<cwebber>the way to do it would be to take ChristopherA's observation that "proofs" are more general than "signatures"

<Zarutian_iPad>in E's use of gift tables where you namespace gift ids/nonces/nyms you only need the vatid or endpoints name

<Zarutian_iPad>"my name is how you know it is me, (when I speak and how to address me)"

<cwebber>Zarutian_iPad: let's put it this way

<cwebber>OCapN's current mechanism is robust enough to work in an environment where eg a public ledger was used as a *message medium*

<cwebber>ie, all the messages were visible to the public

<Zarutian_iPad>sure, public wires

<cwebber>we haven't shown yet (it may be true that it's possible, but not yet demonstrated, I need to think about it) that the blockchain itself can yet *be* a vat which can perform handoffs

<cwebber>Zarutian_iPad: it probably can though, in the sense that with the ChristopherA version of proofs as more general than signatures (and similar to)

<cwebber>you can eg see consensus as a "proof" that an agreement was made

<cwebber>and that the blockchain has achieved a current state

<cwebber>it could be that the signature verification step could be similar

<cwebber>but this is something to come back to later

<Zarutian_iPad>btw, an idea I saw in the SmartMessages paper and I am thinking implementing in ACC is that you can name an code brick (SM) or an ACC by its hash without naming a public key or such

<Zarutian_iPad>which supports ChristopherA's point nicely

<Zarutian_iPad>hmm... something that goblins captp seem to support: giving the same gift twice to two different recipiants

<cwebber>Zarutian_iPad: nope

<cwebber>oh

<cwebber>wait you mean at the same number?

<cwebber>same gift id number

<Zarutian_iPad>we have Alice, Bob, Carol, and Dave

<cwebber>yes you could do that probably. there's one problem that we have left it under-defined whether or not a gift is "removed on retrieval"

<Zarutian_iPad>on a<=>b Bob tells Alice to put gift under nr x

<Zarutian_iPad>Bob tells Carol and Dave, via desc:handoff-give that there is an gift awaiting them under x at Alice signed by Bobs public key of a<=>b

<cwebber>yes you can reuse an id in that way, per the certificate logic

<cwebber>in practice, the design is slightly hedge'y in goblins' implementation

<Zarutian_iPad>now, there is a race iff the gift table entry gets used up at retrival

<cwebber> [(pull-out-gift id)

<cwebber> (when destroy-on-fetch?

<cwebber> ($C gifts 'remove id))

<cwebber>cutting out some code

<cwebber>but right now

<cwebber>it always sets destroy-on-fetch to #t

<cwebber>so it will always destroy it on fetch.

<Zarutian_iPad>we are in the spec biz here on this chan and I like to preclude these kind of issues

<Zarutian_iPad>ACTION watches that presentation recording

<Zarutian_iPad>a meta-note: I had not seen clipart in years. I wonder why it fell out of fashion

IRC channel logs

2024-01-02.log