OCapN Pre-standardization Group

February 2023

Agenda

Minutes

Jessica: github issue #12 on third party handoff contain links to presentation and slides

Jessica: ocapn.org website is up. mostly a landing page for this group's work for anyone interested in participating and for hosting files. source is on ocapn github. small static site

TOPIC: Approval of last meeting's minutes

https://github.com/ocapn/ocapn/pull/33

Jessica: first on agenda: voting to approve minutes from last meeting

Jessica: there has been discussion on having these reviews being done out of band on the pull request. we can vote on that too

cwebber: +1 to approve minutes

jacobweisz: +1

dthompson: +1

elplatt: +1

zenhack: +1

dale: +1

markm: +1

alan: +1

Approved: minutes from last month

PROPOSED: Review meeting minutes out of band on PRs on the github PR, they will be considered approved by the next scheduled meeting provided group members have not provided blocking feedback.

jacobweisz: +1

cwebber: +1

zenhack: +1

dale: +1

dthompson: +1

elplatt: +1

APPROVED: Review meeting minutes out of band on PRs

TOPIC: Appointing a new chair

Jessica: has been acting as chair, but we haven't had an election

cwebber: has recommended Jonathan Rees for chair

cwebber: jonathan has given feedback to group on governance. has been active in w3c governance. dissertation "security kernel in the lambda calculus" helped bring cwebber into ocapn

cwebber: jonathan hasn't implemented a version of ocapn which might lend a level of neutrality

cwebber: also recognizes the excellent work Jessica has done so far!

jar286: sees chair as a way to contribute to an important project. has own opinions but understands the need to set those aside and remember which hat is on at which time

cwebber: is jonathan open to it?

jar286: yes

PROPOSED: Make Jonathan Rees chair of the OCapN group

Jessica: +1

zenhack: +1

cwebber: +1

dthompson: +1

jacobweisz: +1

elplatt: +1

markm: +1

alan: +1

dale: +1

APPROVED: Make Jonathan Rees chair of the OCapN group

TOPIC: OCapN URIs

https://github.com/ocapn/ocapn/issues/29

cwebber: proposes Jessica continues to chair for this meeting. general agreement

Jessica: in spritely, were working on changing URI format in both guile and racket versions of goblins. want input from this group while things are still easy to change. part of the NLnet grant is to address uris, seems like a good place to start

Jessica: some wanted to push topic to later. has put it on agenda as something that would be useful to talk about now, but not "speak now or forever hold your peace"

cwebber: summarizing github thread. uris for two things: ocap sturdyrefs and locations in general

cwebber: structured representations are preferred to stringy. gui apps should encapsulate ocaps rather than relying on string representations

cwebber: providing string reps to use as qr codes and non-ocap apps, use structured when possible. discussion is about how to bootstrap when coming from a non-ocap system

cwebber: should we be calling these "URIs"? Too good a URI rep would imply in-browser compatibility, but that is not something that will be avaialbe for all ocapn uris

cwebber: open question about how to signify netlayer

cwebber: open question about multiple uris referring to same object

markm: distinction between stringy and structure is not the distinction i'm thinking of. in any ocap fabric, connectivity begets connectivity in band. if you only have that mechanism, you can't bootstrap initial connectivity. people who already know each other but aren't already mutually connected in an ocap fabric need a way to connect.

markm: important thing about uri: means of out-of-band introduction. uri is a way of conveying introduction out-of band: paper, qr code, over phone, etc. the authenticity you can count on is no greater than the authenticity of the means of introduction.

markm: the concept of sturdyref in E literature is often confused with uri. sturdyref is an opaque capability, does not reveal its contents. meant to re-establish connectivity

cwebber: address needs to include authentication component, but that may be all the information you need, as in tor onion

markm: so you always have machine self-identification, you may or may not have routing hint information

markm: should think about this because there's an availability vulnerability. if the only places you know about aren't helping you route, you get stuck

cwebber: early spritely used hints in query string, not currently used

Jessica: caused issue with addresses that had multiple parts separated by dots

cwebber: caused issue with uri parsing

markm: is the swiss num the right way to identify the object at the destination? swiss num is shared secret. if the endpoint is a blockchain that can't keep secrets, a shared secret might not be the way to do an authorizing reference

cwebber: early versions of ocapn includes uri type that includes certificates as part of the URI

Jessica (goblin hat): which types of sturdyrefs are helpful?

zenhack: backing up. string refs are useful to do handoffs. doubts about should this be a URI at all, you just need a string not a URI. could just base64 encode the structure

zenhack: less to implement, and maybe desirable to be opaque to user. sees no use case for making the structure legible to end user. if there is one, what is it?

alan: would like to see something indicating sturdyrefs should only be sent over a secure channel

cwebber: one case where this isn't true: if very successful, there may be some cases where it's fine for everyone to have access to these uris

cwebber: started thinking about how these should be structured. machines have transport, address, hints. sturdyrefs composes those with swiss num

cwebber: having the structure more important than settling the string format

jar286: we've had requests for evidence that there's value that these be uris. some are arguing against that. funny to talk about uri syntax before resolving

markm: will make argument for uris. acknowledges that if they are uris, people may try putting them in url bars, but that's not a useful place for them. argument for uris is that before there were urls, there were just different strings that identified different things in different protocols. had to know the protocol before you could parse the string. easy to make the mistake of parsing the wrong format. similar problem with trying to send bitcoin to ethereum

markm: addres, etc. not argument for uris specifically, but argument for prefixing with a scheme and colon

françois-rené: URIs makes APIs more discoverable

zenhack: even if we have someting like "ocapn:" its still not likely to prompt people to paste into browser. type distinction is valid, and discoverability is too. motivates the prefix, but not a full uri structure

markm agrees

ethan: if there's an opaque syntax, what prevents creating a uri scheme later?

cwebber: even if we go with "ocapn:" plus base64, we have two challenges. one is the unaddressed debate is should it be "ocapn:netlayer" or "ocapn+netlayer"? dan connoly would probably advocate for the later

cwebber: other concern is having a clear structure means you can tell the difference between a machine identifier and a sturdyref identifier, even visually. easy to get confused

jar286: argument is a human factor issue, not a technical one. the claim is if it looks like a uri, then programmers will start using it as if it was one, and these things will propagate onto the data paths for uris. second thing is that anything on a uri data path is a security leak. enthusiastic programmers who want to move uris around will put them in server logs and all sorts of other locations. question is more about data paths: what's the use case for

jar286: having these on the data paths you'd find uris on?

zenhack: intuition is if we're going to have two uris for two different things (machine and sturdyref) why are they the same protocol at all. what is the semantic structure of this? what do we or don't we want to be opaque. need to hash out higher level concerns

cwebber: multiple people advocated that ocapn: looks better, but uri parsing libraries don't handle it well. has an advantage: these are not usually clickable. this may address jonathan's issue with the data paths

jar286: doesn't think so. if it's syntactically compatible with uri syntax, then the security risk is there. if you could separate the secret part from the non-secret part that could work, but we probably don't want to do that

zenhack: we could use some other kind of separator

jar286: that would satisfy the idea

markm: want to endorse the idea that there is a discussion of the semantics that is different and more important than syntax, but we have to solve both. in the journey from e days to current work where some machines are blockchains has been a journey in generalizing. before, knowing a machine was to know the key. with blockchains and consensus protocols, these things have a theory of legitimacy: the virtual thing actually sent a message. if a minority of a quorum

markm: sends a message, than the quorum did not send the message. for every theory of legitimacy, there's a logic of a like client that both knows how to speak to the designated thing and how to receive messages that are only sent by the legitimate deisgnated thing and ignore imitations of the designated thing, like a subquorum of replicated machines

mark: that issue that there are multiple theories of legitimacy and there will be multiple theories in the future. on the client side we need to build something that speaks those theories

Jessica: proposing next meeting

Agreed next meeting on: March 24 at same time