IRC channel logs
2023-03-24.log
back to list of logs
<isd>Meeting in 10 minutes, yes? <jar286`>was I supposed to do something to cause channel to exist? <jar286`>oh no... i can try another computer bit no video <jar286`>maybe jessica can just start the meeting, I don't want to hold things up <isd>Audio only is probably fine; I don't think anyone even did cameras last time. <cwebber>=============== MEETING LOGGING STARTS =============== <isd>Better than not having you there :P <jar286`>ok. i will go to other computer. give me 3 minutes and please don't wait for me <cwebber>tsyesika: starting with status report on draft specifications <cwebber>tsyesika: main document is document specifying CapTP, starting and breaking a connection, promises, promise pipelining, 3rd party handoffs <cwebber>tsyesika: a smaller amount is netlayers, opening a channel through a particular transport protocol, at first it'll be the TOR onion netlayer, but obviously other netlayers will be added and implementations can pick and choose their netlayers. that covers opening a secure channel between two machines <cwebber>tsyesika: third one is the "OCapN URI" spec, maybe controversial now, represents sturdyrefs, how to establish in-bound and out-of-bound locations <cwebber>tsyesika: that would be the three main documents, the fourth may not be included, but is the Syrup spec, which is the serialization form based on preserves <cwebber>tsyesika: mainly written with a draft README, since the specs will *initially* based on Spritely's implementation, not to favor it, but as a starting point, but the group can take these draft specifications that we were writing <cwebber>tsyesika: and then the group can evolve as the group reaches decisions <cwebber>tsyesika: ETA on those, the Syrup one is ready for review, is ready as a PR on the syrup spec <cwebber>tsyesika: CapTP, which is the bulk of the initial docs, hoping to have it ready by rest meeting. that'll have the bulk of the stuff that's probably interesting. hoping that one for april's meeting. the other two are smaller but don't anticipate they'll be there for may / june <cwebber>tsyesika: the other deliverable is a test suite, it'll obviously require a certain amount of concrete syntax <cwebber>tsyesika: the plan is to develop that test suite, initially it'll be written to test the draft specs I'll have written by that point, as those evolve, so will the test suite <cwebber>tsyesika: those are the timelines and docs <cwebber>markm: I'm missing the first document I'm most eager to see happen, which I think is the first thing we coordinate around, which is the abstract syntax <cwebber>markm: I know on the github repo, we pointed as the passable syntax agoric has agreed on <cwebber>markm: certainly agoric has not agreed to syrup as the concrete syntax, but we don't need agreement on concrete, if we can agree on abstract <cwebber>markm: if we can agree on which abstract syntax and have adaptors, everything can round trip <cwebber>markm: with adaptors, one way to adapt system B to system A, then you can worry about subset <cwebber>markm: you can compose those abstractions and they don't round-trip <cwebber>cwebber: syrup stuff is donated, group agreed on that some time ago <cwebber>cwebber: jessica has these 3 deliverables as part of her grant <cwebber>markm: is the abstract part of these specs? <cwebber>tsyesika: currently it does mix the two <cwebber>tsyesika: but it does describe the flow and etc <cwebber>tsyesika: we could talk about how to make it so that the two are somewhat decoupled, I can do that <cwebber>tsyesika: now the test suite has to test against something <cwebber>tsyesika: I can implement spritely's, don't want to implement multiple, but I think there needs to be some concrete syntax <cwebber>isd: so in terms of is to whether the abstract syntax is specified, I'd look at Preserves, so Syrup is just one encoding for Preserves <cwebber>isd: one thing I'm fuzzy on is what agreement is here <cwebber>isd: I'm curious how much Goblins to bend on this <cwebber>isd: it's clear we can't get capn'proto and agoric to agree, but not sure we can't get spritely to bend to agoric's, I want to get clear as in terms of a scope thing <cwebber>isd: is it something that's on the table? or have we already decided that's not feasible and we're trying to see whether <cwebber>tsyesika: I think spritely can make some changes re: captp, but as relative newcomer to the group I don't have Agoric's CapTP spec in my head <cwebber>danc: would like to know about interop <cwebber>cwebber: I think if tsyesika can have abstract stuff "as separate as possible", and we *aim* for as close as possible compatibility between agoric and spritely, and not decide whether it's possible to get full compatibility *yet* <cwebber>jar286: can we get a concrete action item? <cwebber>jar286: going to create an issue about this topic <cwebber>jar286: next topic is interoperability <cwebber>danc: this is a writeup from talking with Kris Kowal <cwebber>danc: here spritely has a chat, spritely has spritely chat on one side, so spritely goes over a unix domain socket plugin which then the endo plugin for sockets, and then a captp bridge <cwebber>danc: and then a js chat app with an http endo plugin and a UI which goes on the Agoric side <cwebber>cwebber: I think this is an interesting goal towards trying to show off how this would work <cwebber>danc: small amount of hacking I did do was about the coordinated types <cwebber>danc: started working on bridging widget <cwebber>tsyesika: so there are a few things to add... we don't currently actually have one in spritely's side, but there is a PR, but hasn't been reviewed <cwebber>tsyesika: obviously the goal for the captp docuent is for next meeting, but if you're willing to hack on something I can send an earlier draft of the captp document, that might facilitate this conversation <cwebber>danc: would like to see early stuff to the group <cwebber>tsyesika: in terms of asking for broader review, it may be in an earlier pre-draft state than I had hoped but I could <cwebber>isd: I think DanC's comment adds some interesting questions, eg what can we do with low-level collections <cwebber>isd: those layers are not separated out in syrup/preserves <cwebber>isd: I think one of the questions is whether or not we can move those two things together <cwebber>isd: how attached are we from what parts of this data level <cwebber>isd: could you look at agoric's and see what parts we do and don't want to adopt? <cwebber>isd: I think having that conversation is the first order of businsess in terms of whether or not we can converge on a shared protocol <cwebber>markm: danc said mapping a subset to a subset... if there's a joint subset that round trips, I'd describe that as a subset we've agreed upon. so the layer separation we have now, that was partly inspired by one of these conversations. I was trying to put collections in at the arrays/records stuff. and I had to write down a lot of semantics of what it meant for two keys to be equal. for example, if they're keys in a map or a set and <cwebber>the set has a cardinaltiy, you need a definite semantics of whether they're equal, and if maintaining their meaning while passed, they have to maintain that invariant <cwebber>markm: so the thing that inspired me to separate things are that you guys talking about a tagged type, and that solved a lot of our problems, and I think that given a tag, I think we did find the cut-point, and I think I want to defend the cut-point we have, in order to minimize what's needed in terms of what's needed for interoperability <cwebber>markm: in some sense I'm hoping that agoric level 0 is the subset we agree upon <cwebber>markm: and the nature of the agoric level is that if people agree on layer one (two?) but not on layer (2/3?) but nonetheless people can relay data through things that do <cwebber>markm: (talks about layering, the pass style, the abstract syntax) <cwebber>markm: so the abstract syntax embodied by that package, then the marshall package serializes and unserializes those things <cwebber>markm: the pass describes not just.... the passable is a bit biased towards js in a way that we've agreed upon before, it's neutral enough such that we can map it onto the neutral versions <cwebber>markm: marshall round-trips between js representation of those types, and various serializations of those types <cwebber>markm: the oldcaps (?) protocol (deprecated), smallcaps protocol, encoded in json but nonetheless quite readable, and encodePassable <cwebber>markm: but the thing about encodePassable is that crucially at layer1, not at layer 0, the rank order between all passables <cwebber>markm: full order with ties, which is what you need for sorting <cwebber>markm: issue about whether it's a stable sort only arises if it gets a rank order <cwebber>markm: and then the crucial thing is that the passable layer doesn't take a stance on ordering or distributed equality, then the pattern layer <cwebber>markm: it defines various higher level datatypes which are encoded into a tag that comes from a (?) style <cwebber>markm: only as of the pattern layer that we need to define a pass invariant notion of equality, and pass invariant notion of key order <cwebber>markm: but the important thing is that... an example, copy set <cwebber>markm: the pattern layer recognizes something as a copy set only under two conditions <cwebber>markm: the pattern layer recognizes only by seeing the ...?, the payload is any other passable <cwebber>markm: the pattern layer recognizes something as a copyset if and only if it describes itself as a copyset <cwebber>markm: as far as the copy thing is concerned <cwebber>markm: if the tag doesn't have the invariant... as long as speaking to someone with notion of different concepts they want to encode into tags <cwebber>markm: it's still recognized as a tag, but not recognized as having only higher level meaning <cwebber>cwebber: preserves alone is not expressive enough, just acking, because then we couldn't represent the liverefs over the wire <cwebber>cwebber: but tagged data structures, that's part of the history of how preserves came about <cwebber>jar286: who's shepherding this issue? <cwebber>isd: I can manage, spritely folks can you look at the agoric's stuff <cwebber>jar286: I did make a wiki page of my thoughts as chair, want to make people aware <cwebber>jar286: I like assigning people to issues to find out next step <cwebber>danc: if next step on data model is to prompt spritely folks, I'd like to prompt spritely folks <cwebber>tsyesika: and provide feedback on issue before next meeting <cwebber>tsyesika: on that point, I am guessing it doesn't matter if it's not part of captp in the specs, but in relationship there is a draft PR <cwebber>cwebber: tsyeika did an incredible job on this doc, encourage people to look at it <cwebber>danc: if it's useful to have two people assigned, the interop demo is going to involve going from one thing to another, so I'm willing to be assigned as well <cwebber>jar286: 3 minutes left, I liked the traidtion we had in the w3c of doing issue review <cwebber>jar286: a drive to close issues or assign to people, so is there anything else we need to cover <cwebber>jar286: looks like Tuesday April 25 at 19:00 UTC <cwebber>=============== MEETING LOGGING ENDS =============== <tsyesika>jar286` (or jar286 ): I'll update the website with the next meeting as soon as we have a new github issue :) <tsyesika>I think matrix might have done something weird there <tsyesika>also I suspect we can merge the minutes from feb