IRC channel logs
2023-02-23.log
back to list of logs
<elplatt>tsyesika, i'm here to scribe! note: power/network is out in much of ann arbor right now. i'm at a public library and should be good, but there's a small chance my connection could drop <tsyesika>okay, thanks for scribing despite the issues, I'm sure someone else can take over if you do loose connecting <cwebber>################ BEGIN MEETING ################ <elplatt>tsyesika: github issue #12 on third party handoff contain links to presentation and slides <elplatt>tsyesika: 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 <elplatt>tsyesika: first on agenda: voting to approve minutes from last meeting <elplatt>there has been discussion on having these reviews being done out of band on the pull request. we can vote on that too <elplatt>ian clarifies we are voting in irc. cwebber can copy from big blue button to irc if necessary <cwebber>PROPOSED: Review meeting minutes out of band on PRs <cwebber>APPROVED: Review meeting minutes out of band on PRs <elplatt>next agenda item: issue #27, appointing new chair <elplatt>tsyesika: has been acting as chair, but we haven't had an election <elplatt>cwebber: has recommended Jonathan Rees for chair <elplatt>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 <elplatt>cwebber: jonathan hasn't implemented a version of ocapn which might lend a level of neutrality <elplatt>cwebber: also recognizes the excellent work tsyesika has done so far! <elplatt>jonathan: 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 <elplatt>cwebber: is jonathan open to it? jonathan: yes <cwebber>PROPOSED: Make Jonathan Rees chair of the OCapN group <cwebber>APPROVED: Make Jonathan Rees chair of the OCapN group <elplatt>tsyesika: big issue for today to discuse is ocapn uri stream format <elplatt>cwebber: proposes tsyesika continues to chair for this meeting. general agreement <elplatt>tsyesika: 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 <elplatt>tsyesika: 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" <elplatt>cwebber: summarizing github thread. uris for two things: ocap sturdyrefs and locations in general <elplatt>cwebber: structured representations are preferred to stringy. gui apps should encapsulate ocaps rather than relying on string representations <elplatt>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 <elplatt>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 <elplatt>cwebber: open question about how to signify netlayer <elplatt>cwebber: open question about multiple uris referring to same object <elplatt>mark miller: 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. <elplatt>mark: 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. <elplatt>mark: 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 <elplatt>cwebber: address needs to include authentication component, but that may be all the information you need, as in tor onion <elplatt>mark: so you always have machine self-identification, you may or may not have routing hint information <elplatt>mark: 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 <elplatt>cwebber: early spritely used hints in query string, not currently used <elplatt>tsyesika: caused issue with addresses that had multiple parts separated by dots <elplatt>cwebber: caused issue with uri parsing <elplatt>mark: 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 <elplatt>cwebber: early versions of ocapn includes uri type that includes certificates as part of the uri <elplatt>tsyesika (goblin hat): which types of sturdyrefs are helpful? <elplatt>ian: 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 <elplatt>ian: 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? <elplatt>alan: would like to see something indicating sturdyrefs should only be sent over a secure channel <elplatt>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 <elplatt>cwebber: started thinking about how these should be structured. machines have transport, address, hints. sturdyrefs composes those with swiss num <elplatt>cwebber: having the structure more important than settling the string format <elplatt>jonathan: 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 <elplatt>mark: 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 <elplatt>addres, etc. not argument for uris specifically, but argument for prefixing with a scheme and colon <elplatt>ian: 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 <elplatt>ethan: if there's an opaque syntax, what prevents creating a uri scheme later? <elplatt>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 <elplatt>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 <elplatt>jonathan: 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 <elplatt>having these on the data paths you'd find uris on? <elplatt>ian: 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 <elplatt>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 <elplatt>jonathan: 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 <elplatt>ian: we could use some other kind of separator <elplatt>jonathan: that would satisfy the idea <elplatt>mark: 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 <elplatt>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 <cwebber>BTW the design of netlayers in Spritely's OCapN work were done specifically to encompass the ideas you are advocating, Mark :) <cwebber>didn't use the prhase "theories of legitimacy" but the idea is that the netlayer has opinions on that <elplatt>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 <elplatt>cwebber: thank you to jessica tallon for excellent service! applause <elplatt>tsyesika: March 24 at same time confirmed <elplatt>#################### END MEETING ############################ <tsyesika>I forgot to say but I'll get these minutes up tomorrow :) <elplatt>happy to help! and it's a great way to learn from all of y'all <ocdtrekkie>sorry I had to duck out, just caught up with the notes in here <tsyesika>jar286: would you like to open the issue for the next meeting as the new chair? :) I can merge the PR with the minutes we just approved and also update the website with the next meeting time <tsyesika>I've merged the minutes jan 2023 minutes <tsyesika>so to slightly complicate matters relating to the next meeting, the clocks will have changed to summer time over in the US, but will not have done so over here in europe (I'm not sure about other areas in the world) <tsyesika>I believe in the US they change on the 12nd of march and in europe they change on the 26th of march <tsyesika>ACTION isn't sure where everyone's located