OCapN Pre-standardization Group

March 2023

Agenda

Minutes

TOPIC: Status report on progress on draft documents; how to contribute; next steps (@tsyesika).

Jessica: starting with status report on draft specifications

Jessica: writing three documents

Jessica: main document is document specifying CapTP, starting and breaking a connection, promises, promise pipelining, 3rd party handoffs

Jessica: 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

Jessica: third one is the "OCapN URI" spec, maybe controversial now, represents sturdyrefs, how to establish in-bound and out-of-bound locations

Jessica: 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

Jessica: 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

Jessica: and then the group can evolve as the group reaches decisions

Jessica: ETA on those, the Syrup one is ready for review, is ready as a PR on the syrup spec

Jessica: 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

Jessica: the other deliverable is a test suite, it'll obviously require a certain amount of concrete syntax

Jessica: 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

Jessica: those are the timelines and docs

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

markm: I know on the github repo, we pointed as the passable syntax agoric has agreed on

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

markm: if we can agree on which abstract syntax and have adaptors, everything can round trip

markm: with adaptors, one way to adapt system B to system A, then you can worry about subset

markm: you can compose those abstractions and they don't round-trip

cwebber: syrup stuff is donated, group agreed on that some time ago

cwebber: jessica has these 3 deliverables as part of her grant

markm: is the abstract part of these specs?

Jessica: currently it does mix the two

Jessica: but it does describe the flow and etc

Jessica: we could talk about how to make it so that the two are somewhat decoupled, I can do that

Jessica: now the test suite has to test against something

Jessica: I can implement spritely's, don't want to implement multiple, but I think there needs to be some concrete syntax

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

isd: one thing I'm fuzzy on is what agreement is here

isd: I'm curious how much Goblins to bend on this

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

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

Jessica: 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

dckc: would like to know about interop

cwebber: I think if Jessica 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

jar286: can we get a concrete action item?

dckc: I suggest using an issue for each document; for example, #29 for the "OCapN URI" spec

jar286: going to create an issue about this topic

TOPIC: Agoric/Spritely interop status report Demonstrate Agoric & Spritely interop #6; next steps (@dckc)

jar286: next topic is interoperability

dckc: this demo sketch is a writeup from talking with Kris Kowal and company

dckc: 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

dckc: and then a js chat app with an http endo plugin and a UI which goes on the Agoric side

cwebber: I think this is an interesting goal towards trying to show off how this would work

dckc: small amount of hacking I did do was about the core data types

dckc: started working on bridging widget

Jessica: 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

Jessica: 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

dckc: would like to see early stuff to the group

Jessica: in terms of asking for broader review, it may be in an earlier pre-draft state than I had hoped but I could

isd: I think dckc's comment adds some interesting questions, eg what can we do with low-level collections

isd: those layers are not separated out in syrup/preserves

isd: I think one of the questions is whether or not we can move those two things together

isd: how attached are we from what parts of this data level

isd: could you look at agoric's and see what parts we do and don't want to adopt?

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

(a pre-meeting discussion from markm to largely the same effect)

markm: dckc 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

markm: 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

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

markm: in some sense I'm hoping that agoric level 0 is the subset we agree upon

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

markm: (talks about layering, the pass style, the abstract syntax)

markm: so the abstract syntax embodied by that package, then the marshall package serializes and unserializes those things

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

markm: marshall round-trips between js representation of those types, and various serializations of those types

markm: the capdata protocol (deprecated), smallcaps protocol, encoded in json but nonetheless quite readable, and encodePassable

markm: but the thing about encodePassable is that crucially at layer1, not at layer 0, the rank order between all passables

markm: full order with ties, which is what you need for sorting

markm: issue about whether it's a stable sort only arises if it gets a rank order

markm: I didn't invent rankOrder

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

markm: it defines various higher level datatypes which are encoded into a tag that comes from a passStyle style

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

markm: but the important thing is that... an example, copy set

markm: the pattern layer recognizes something as a copy set only under two conditions

markm: the pattern layer recognizes only by seeing the ...?, the payload is any other passable

markm: the pattern layer recognizes something as a copyset if and only if it describes itself as a copyset

markm: as far as the copy thing is concerned

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

markm: it's still recognized as a tag, but not recognized as having only higher level meaning

cwebber: preserves alone is not expressive enough, just acking, because then we couldn't represent the liverefs over the wire

cwebber: but tagged data structures, that's part of the history of how preserves came about

jar286: who's shepherding this issue?

isd: I can manage, spritely folks can you look at the agoric's stuff

jar286: I did make a wiki page of my thoughts as chair, want to make people aware

jar286: I like assigning people to issues to find out next step

dckc: if next step on data model is to prompt spritely folks, I'd like to prompt spritely folks

cwebber: tsyeika did an incredible job on this doc, encourage people to look at it

dckc: 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

jar286: 3 minutes left, I liked the traidtion we had in the w3c of doing issue review

jar286: a drive to close issues or assign to people, so is there anything else we need to cover

Schedule for next monhtly meeting

jar286: looks like Tuesday April 25 at 19:00 UTC (next meeting)