IRC channel logs
2023-04-25.log
back to list of logs
<cwebber>hm, bbb is being awfully slow to connect <cwebber>================ MEETING LOGGING STARTS ================ <cwebber>jar286_: main thing today is going through documents <cwebber>cwebber: how are we doing the queue? <cwebber>jar286_: using queueing in the BBB chatroom, because it seems like most somewhat reliable <cwebber>cwebber: I think we should talk about captp but also serialization <cwebber>markm: I advocate whether part of same set to talk about, that they should be part of two different layers <cwebber>jar286_: yes I put something about data layer on the agenda <cwebber>jar286_: but I'm not sure what we have something prepared on that <cwebber>jar286_: cwebber if you think it can be productive I think we should talk about it <cwebber>cwebber: I think yes, tsyesika can talk about it, we did the review isd and markm asked for <cwebber>tsyesika: for an overview of things, I did a PR of the CapTP spec, I am of course working on the work following after <cwebber>tsyesika: I'm not sure how much people have had a chance to look at the captp spec, I wanted to remind folks that the initial draft is based on spritely's implementation, that's not meant to favor spritely, but meant that we can file issues on where we think we *don't* have consensus and can do with working on them <cwebber>tsyesika: and obviously as we come to consensus the document can evolve over time <cwebber>Zarutian_iPad (on bbb chat): drop resolve-desc from op:deliver and only relie on op:listen for that functionallity? <cwebber>tsyesika: I am reviewing and addressing Richard Gibson(?)'s and isd's feeback <cwebber>tsyesika: I propose review it and merge it into the repo and that it be easier to have PRs on parts on the spec <cwebber>tsyesika: eg if we're going to drop the bootstrap object, we can review that language <cwebber>tsyesika: and I think it'd be easier to work with than one big pull request where it's hard to see what we review <cwebber>tsyesika: if the group wants to go a different way that's possible <cwebber>tsyesika: there's a note at the top that says it's a draft spec, we could strengthen it to say that this really will probably change quite drastically, and people will probably not implement it <cwebber>tsyesika: the doc does mention syrup, the intention isn't to not go with that, the intention isn't to go against it, but the first draft is what spritely itself implements <cwebber>tsyesika: my hope is that we can converge on concrete syntax, my hope is tthat we can get more adoption by other implementers, where we can get more implementations with other concrete syntax <cwebber>tsyesika: it could be something else, it could be cbor or msgpack, my preference is we can discuss some kind of syntax <cwebber>tsyesika: other than this spec, I am working on test suite <cwebber>tsyesika: that's more or less the status of my sowrk and to introduce it <cwebber>isd: I'm going to punt to the end of the queue <cwebber>markm: responding to what tsyesika was just saying <cwebber>markm: you've been very good verbally to apply context, this is written from spritely's perspective, as such it's a step towards consensus, but not yet something we can reflect something we can all agree on <cwebber>markm: my concern is that it be more explicitly marked not just a preliminary draft, but rather a perspective from one of the participants, rather than something we can work on towards agreement <cwebber>tsyesika: yes. i can add that, make it more clear that this isn't something the group has converged on, perspective of one of the parties <cwebber>markm: regarding converging on a concrete syntax, thank you very much to look at smallcaps. i've been under the impression that it's hard to... let me ask the spritely people collectively, would you consider smallcaps directly and literally as the syntax <cwebber>tsyesika: I can speak to that. spritely is not tied to syrup, we can switch away from that, am fairly free in what we can change, we think its' reasonable and good, we have possibly two concerns <cwebber>tsyesika: both of them we could technically accept but we think it would be worse than what we currently have in syrup <cwebber>tsyesika: currently we can encode binary data in a very efficient way in a way that we wouldn't have to base64 encode it etc <cwebber>tsyesika: especially if you get store and forward sessions, if chained, you can get a balooning of data, so efficiently the efficiency of binary strings is potentially a concern <cwebber>tsyesika: currently we are using syrup canonicalization for the certificates we're signing, we could have that be a payload of data and sign it, that's certainly possible, to me it seems slightly less elegant than have the message and sign it, but that would be fine, we could do it, could adopt it. something we've been wondering is... if / how it would be possible agoric could change to anything, like msgpack or syrup, or cbor, or <cwebber>something else, something that might mitigate some of these <cwebber>tsyesika: how flexible is it at agoric? <tsyesika>cwebber: I think we are interleaving, but I think this is one of the most cirtical topics of the group. I think this is an important question for how possible interrop is for the group, so I think this is important for the group. <tsyesika>cwebber: Ian a few meetings ago asked us to look at how compatible our technologies are(?) we've done the smallcaps. We've done that, and we think we're quite positive towards smallcaps. One of the things which kept coming up in internal conversations is how possible interop is. This is a rare opertunity, some of the things we've heard from Agoric folks is we already have stuff in production, we might no be able to change. You are hearing from <tsyesika>us we can change, we can change the syntax. So a question to Agoric are you ossified and tied to your implementation, can you address that? <tsyesika>markm: it's expensive for us to change, it's not infeasible <tsyesika>markm: you can commit yourself to data where it's less expensive to live with co-existience <tsyesika>markm: the one we'd like to change to, if we were to change to a binary format. Is one that doesn't exist yet <tsyesika>markm: it's one I designed and implemented except a (?) that Richard Gibson addressed. It's what I refer to as Code Passible <cwebber>markm: the textual representation in json, json does much of the up-front work of converting from textual to structured form, but the binary cost I'll ack as a huge problem. and there's no way to get binary cheaply in a purely textual format, I understand that <cwebber>markm: the reason for binary to binary at least co-exist... the radical perspective of proposing a thing we haven't implemented is it seems to have a magical property without undo cost. order-preserving for certain semantics. semantics not at the AST but as we've architected the set of levels, it's a very nice ordering semantics that I'd like to show to the group at some point <tsyesika>cwebber: I think this is a very positive response, I'm happy to hear it. What you're hearing from Jessica and I is we had syrup because it was simple and we liked it okay, we're not saying it's ideal. What we're happy to hear is that you're saying smallcaps is not ideal. If we are perceeving this as an analysis and I think we should do the analysis and doing the right thing. <tsyesika>cwebber: I think it's worth while for this group to spend time in this design space, if we're saying yes we're going to do this right <cwebber>markm: just temper your optimism a bit, the abstract syntax is something we're tied to <cwebber>cwebber: having done the smallcaps review, I think we felt very optimistic about the abstract, especially given the tagged structure <cwebber>tsyesika: I had put myself on the queue to answer something else, but I will say that I'd be interested to hear more about your proposed solution, I find that very exciting. as I said in my comment, in terms of abstract types, I think we're fairly aligned in terms of what we need to get our captp implementations talking <cwebber>tsyesika: I did take a brief look pre-meeting. so I don't think the abstract syntax is a problem regarding the format <cwebber>tsyesika: I think you did mention a tag type similar to our records, we kind of have it, a pre-defined set of types used in our captp layer, so the rest are tagged as "user records", so I think that'd be okay too <cwebber>isd: my sense of where we are on the data model stuff is that the next thing to do next, someone, I'd be willing to volunteer, is get a proposal for "this will be our abstract syntax", then this would give us something to pick at, critique, etc. we seem pretty aligned, I think we need to start specifying and nailing down the abstract syntax <cwebber>Zarutian_iPad: this is a question to markm about smallcaps. how exactly wedded are you to the json that endo/smallcaps consumes? pure json, or might you say that there's eg a byte array buffer here <cwebber>markm: the key thing about the json as I mentioned is that we get to use the fast native code on all platforms to do the basic json parse and stringify, and everything else we do from structure to structure transformation. that's a nice property, not just for us. but to answer your question, we know we need binary, we're committed to that, and one way to do that is an envelope.. <cwebber>markm: we already have an envelope containing both the json and the slots array <cwebber>markm: the slots array can't have a universal encoding <cwebber>markm: since we already have an envelope that has those two things in it <cwebber>markm: what we have is an index into the slotsarray <cwebber>markm: it would be some pain because we are using json on the envelope as well <cwebber>markm: we do understand it's important <cwebber>markm: in the envelope we can have room for pure binary, and for the part we call the body wich is json encoded smallcaps, what there would be is an index into the binary arrays in the envelope <cwebber>Zarutian_iPad: better solution than what I was just proposing <cwebber>jar286_: amazingly the queue is empty, interested in what tsyesika is doing next <tsyesika>cwebber: We didn't really discuss the write up we did <Zarutian_iPad>ACTION adds a meta-note: look into translate.it or whisper to auto transcribe? <tsyesika>cwebber: I'd like to do it, I'd like to say some things about and the process we went through. Jessica was given not an easy task. The documentation that exists is scattered and is specific to an implementation. She worked very hard (more than I'd have done, if I had done it it's be very opinionaty) on avoding that. I would like to say that she did an increadible job of producing something neutral. It does have lispy kebab style syntax, which <tsyesika>we could change. One thing she did do was stripped out implementation details like tables. All other explinations keep "this table"... and we had a conversation about if that was the right thing, but what I think is interesting about this is... Jessica is going to talk next about an implementation guide and stuff, which will talk about how you might implement it. <tsyesika>cwebber: The effort to go through and translate all the documentation to this spec. <cwebber>tsyesika: so what I'm working on next... obviously as my highest priority is address any feedback that's left on the captp spec that exists, there's still some that we need to get to, with the aim to get it merged, and as convos go on, I will try to keep on top of it <cwebber>tsyesika: most of my time is currently spent on the test suite, which will be in pythohn <cwebber>tsyesika: I wanted to choose a language I was familiar with but which has a wider audience, I wanted something more people knew (not everyone knows scheme)... hope it was a decent choice. going to push it in a few days, still in the earliest stages, hoping by next meeting hoping to have something fairly decent and covering a lot of the spec <cwebber>tsyesika: so that's something I'll be doing, and as cwebber said, on top of that there are two more specs to write, the netlayers spec.... and there's some question about more whether I put in should go into netlayers, we talked internally, certainly open to it... but netlayers as I see it now is mostly opening a channel to the other session and that revolves around certain netlayers. first one is the tor onion netlayer, more is <cwebber>certainly welcome, but with more implementations, maybe people can contribute their own, but at least for now I can document the one spritely is using. <cwebber>tsyesika: and then there's the ocapn uri doc... I changed it to "references" because there was debate about "uris" but we can talk about it... and then there's the implementation guide which is going to be more opinionated about how one might implement this with tons of diagrams and etc (of course spec could have diagrams too)... will have import and export tables and gift tables and that is definitely coming in next few months' work <tsyesika>cwebber: First of all, I want to hear other people's response to what Jessica is working on and what's ahead. I think hopefully it'll be more obvious for why we structured the grant the way we did to get the ground running. Something I want to discuss is what licence we'll use. I would like to suggest Apache v2 for both the document and spec. We could use CC for the document but it's a perfectly fine licence for documents too <cwebber>markm: apache2 is our favorite license at agoric, was our favorite at when some of us worked at google... you've brought up an interesting point that is there reason that documentation can't be under code licenses? <cwebber>jar286_: will there be contributor agreements? <tsyesika>cwebber: regarding contributer agreements, I think that's something we can talk about. I think it's worthwhile and simple enough to have a file of people who've signed off on an agreement that their contributions will be under Apache v2 and that they won't be agressive with their litigation(?) <tsyesika>cwebber: Regarding your opinion on why we have different licences. My impression from when I worked at CC is that it's partially due to historical reasons from where Richard stallman considered these very different things. This really bugged me at CC and something I kicked off before I left was the CC-BY and CC-BY-SA for GPL compatibility. It always troubled me that people made code things and people made non-code things and as someone who <tsyesika>likes video games it always seemed strange to me that people treated these as very different things. Do we treat things differently that are functional vs cultural works <cwebber>tsyesika: I'm happy with apache v2, I'm happy for that to be the license for both the document and the code. I'm interested in feedback people have. I know Ian on the PR talked about organizational stuff. It's something I've been meaning to do, ask you for examples... I'll also remind folks that we might want to set a time for the next meeting before the hour is up <cwebber>isd: I think I can give more detail on the PR <cwebber>tsyesika: also while I'm speaking, I'd like to encourage... if you think there is *not* consensus from reading the doc, and there isn't an issue about it, please file an issue <ocdtrekkie>(not in the meeting, but it sounds very likely the group can agree entirely on apache2) <tsyesika>cwebber: I would like to hear the feelings from four people in specifically: Mark, Jessica, Ian and jar. It's worth doing a vibe check. It feels like a breakthrough moment in the group about being able to move forward <cwebber>tsyesika: I'm very positive, especially after this meeting. there's obviously been a lot of convo on the concrete syntax, I'm very invested in, I did a lot of work in the SocialWG and it didn't necessarily have interop and over the course of the group was difficult to work through. I'm interested in spec work in terms of getting implementations to talk with each other, getting new implementations, creating documentation and <cwebber>technologies that further this space. I'm very excited about that, and certainly excited to work with Mark and everyone at Agoric to work on this. I think we have a good shot of coming to consensus on this <cwebber>markm: I agree with the general positivity. I think it's very interesting how the issues have... as we've broken things into layers that's been clarifying for me too, made my vision sharper. until recently I kept talking about 3 layers, all of which were about data, and the nice thing in tsyesika's document is it's focusing on messaging in terms of capabilities, and that's really nice, we've got our data and slots arrays and things <cwebber>have to be translated from clist context to clist context. I think that's going to be very very challenging, we *need* to have blockchains be able to participate in the fabric, that's of course been central to what Agoric has done. IBC *is* the netlayer for talking to chains, and it's been very designed to meet these needs, and doing 3 party handoffs between combinations of chains and non-chains, we'll likely find it quite <cwebber>challenging, and it's necessary to bite this off. One thing I noticed about the document I read, it's more like old E, making assumptions that endpoints can keep secrets. weird thing about blockchain is that the endpoints can't keep secrets. One final note about data agreement is that we're *really* stuck on the abstract syntax, so things that are still minor issues are gating issues, there's two levels of tagging, distinction <cwebber>between record / string / symbol, and then there's the Tag, and we can't bridge to an encoding that takes some of the things problematic to you like null and just tosses it into the tag, because then it's not "the tag". if we did that it's an extension of the first level tagging, we'd still encode our ? as the top level tagging, because the tag has to be exaclty the tag <tsyesika>Jacob Weisz: we decided on 23rd of may 19:00, does that work for you? <cwebber>isd: also to echo the general positivity, I think... the kind of approach I am taking to this is kind of a one-issue-at-a-time thing. we'd been makign good progress on the data model thing, and I think I'll try to comment, how does everyone like this particular form, because one of the things I found... it's a bit difficult I found to navigate the comments in the agoric source to understand the data model, so I might need to try to <cwebber>rephrase it in a way that makes sense to me, and think about what others might do to work into the tags. in addition to the discussion here I feel like we're getting close on that, and ask "how does everyone feel about this exact spec" <cwebber>isd: from there I'd like to start pinning down the semantics of errors in particular <cwebber>isd: that's something captp has a lot of opinions about, and i might need to bother kenton about, but yeah, that's all I have to say <cwebber>jar286_: I don't have much to add... I guess I admire the recent interchange of taking and kind of forcing the issue of taking what could be a disagreement and instead of talking around it and being nice to try and attack it head on and it seems like it worked really well and I'd like to see it repeated <cwebber>tsyesika: can I propose to markm that you provide info to issue #5 with the *potential* concrete syntax, the one you and Richard Gibson asked about <cwebber>markm: richard gibson can we work on that before next meeting? <cwebber>richard: I think that's possible, not too many obstacles <cwebber>markm: I'll volunteer to next meeting talk about the magic ordering properties, they're really pretty cool, I think you all will be entranced by it <cwebber>Zarutian_iPad: looking forward to it! <cwebber>jar286_: okay, glad for that specific action item, and I guess tsyesika has plenty to do, and if anyone wants to volunteer... <cwebber>tsyesika: I can say I should be able to get test suite published, can you read and comment on spec <cwebber>cwebber: and just to remind this is a starting point spec <cwebber>jar286_: okay I think we're over and done! move to adjourn! <tsyesika>I forgot to mention in the meeting but I'll get the minutes up tomorrow <cwebber>================ MEETING LOGGING ENDS ================ <ocdtrekkie>Jessica: That looks fairly open for me currently, but I never know how things will sort out. <Zarutian_iPad>meta-question: is standards developement always this kind of excruciating even with mostly-agreement in place? <Zarutian_iPad>where the heck does markm and chip get the patience fo tc39? I admire their tenacy there. <ocdtrekkie>Zarutian_iPad: Well, zenhack spent well over a year trying to get one tiny revision to Content Security Policy added to the specification which AFAIK nobody disagreed at all should be there... and zero web browsers have implemented it yet. So yes. <tsyesika>Zarutian_iPad: I have heard the SocialWG that I was involved in was worse than most standards work, it's not something I always found enjoyable. So far in this group I've found it pretty good :) <tsyesika>I'll answer your comments on the spec tomorrow baldur :) <tsyesika>I'm going to chill for the rest of my evening now <tsyesika>the short answer is because you're asking for something where you always want to know about the reply, so instead of making two messages you can construct one which includes all the information required to provide the answer <tsyesika>but I'll write a better answer tomorrow :) <Zarutian_iPad>ah but I counter with that often you do not want to know the result only to give the invocation result an aswer-nr so you can pipeline on it <Zarutian_iPad>plus I excpect the equiv of .then() or (on …) detection on the proxy implementing the promise can emitt an op:listen when a result is expected beyond just the aforesaid pipeling case <Zarutian_iPad>btw really intresting 3ph case is where Bob hands Carol the resolver Alice gave him for an promise Bob is to make in response to an invocation sent to Bob <isd>"excruciating" isn't a word I would use for this or my other experience, but certainly *slow* is fair. Part of this though is that in both cases a lot of the participants (myself included) were not in a rush <Zarutian_iPad>regarding 3ph handoff: given deposit-gift ( NonceLocator.provideFor() in CapTP of E) and withdraw-gift ( NonceLocator.acceptFrom() in CapTP of E) I do not see why desc:handoff-recieve needs to be signed cert. <Zarutian_iPad>isd: this me first time in any kind of standardization work via group <isd>Fwiw, in capnp all of crypto stuff is encapsulated in the netlayer; the relevant types that show up in accept/provide messages and such are opaque as described in rpc.capnp <isd>It's probably worth a read for anyone who hasn't looked at it. <Zarutian_iPad>3ph handoff continued: in CapTP of E NonceLocator.acceptFrom() and NonceLocator.provideFor() and Promise3Desc only relie on the comms channels to be authenticated and not nescisarilly confidential <Zarutian_iPad>this is basically why I just lifted the CapTP of E gift tables stuff wholesale to use in ActiveCapCerts. <Zarutian_iPad>(the safeEnv (basically just frozen primordials and other powerless things) is augmented with IssuerPrincipal spefic facets to aforesaid gift tables mechanism if you are curious) <Zarutian_iPad>aforesaid way, I think, solves the non-confidentiality of public computional blockchains neatly <Zarutian_iPad>ACTION gets an headache when he reads the Ethereum zkSNARKs based rollups are supposed to work.