OCapN Pre-standardization Group

November 2023

Minutes

JAR: Should we handle merging PRs similar to how we handle issues, having a faster close process?

JAR: We'll review later

JAR: Reviewing the PR (https://github.com/ocapn/ocapn/pull/84) about removing op:bootstrap

#84 Remove op:bootstrap and instead always export at 0

Christine: We previously discussed this with the group and Kenton said it wasn't needed, and Agoric and Spritely had copied Cap'N Proto, so we agreed to drop it because it was determined it wasn't useful

KrisKowal: Our previous experience has been quick forward progress on merging and closing issues

JAR: I'm not sure there's been evidence but I could be convinced

KrisKowal: I think DanConnoly showed that for issues previously

JAR: I interpret that as if there's an open issue that we haven't reached consensus

KrisKowal: (a bit more extrapolation on that)

JAR: Okay that makes sense

JAR: Any objection to merging 84 on removing op:bootstrap

(no objections raised)

decision JAR: considering it merged

#97 Add acknowledgements of the Nlnet funding

JAR: Next one is... we have this item about... add acknowledgement about nlnet funding, pr 97, that sounds uncontrovercial

(no objections)

decision JAR: Resolved, we will merge PR 97

#96 Add implementation guide

JAR: Next is on implementation guide. Will ask about taking implementation guide there in the PR and actually committing that so that it's visible on main branch. Any thoughts or objections?

Jessica: not sure if I've seen feedback

Christine: I propose Jessica present the document

Jessica: (presenting) this document walks through the whole process of implementing ocapn step by step, refers to the spec in many places, gives a more opinion of how might implement it, eg tables for imports/exports and gifting. Has characters of Alisha, Ben, Carol who want to communicate and do so, shows message sending and handoffs

Christine: here's the image, it has some sophisticated images and animations to accompany it, partly inspired by MarkM's presentations

Jessica: It's quite a long document, took a while to write. it would be useful if people have feedback to comment on PR

JAR: That's great, that's my request for people to review this

JAR: Any urgency to multi-resolution, because I'd like subcommittee report on abstract syntax

Jessica: wouldn't say urgency, but if people could look if the group can collectively review the proposal (based on an idea by David Thompson) of how to reflect it

JAR: Good, will table that for review for next time

Abstract Syntax

JAR: Moving surrogate to after subcommitte report on abstract syntax, turning over to Kris if willing

KrisKowal: there's a will

KrisKowal: Purpose of this document is to answer not what the spec should say but to say what do we agree and disagree about

KrisKowal: I think the major axes of that are... for one thing abstract syntax, one thing that must be fixed is that abstract syntax might be the wrong name, maybe abstract syntax covers both data model and the messaging model

KrisKowal: within data model, one major design principle is round tripping which we haven't yet fully specified, and in hand wavey turns means if two lang implementations send messages intended to be on the other side, data should be identical on the wire and equiv in the data model of language. teeth is that language on wire should be byte for byte identical

KrisKowal: the other axis is that we are currently in alignment that a document lifted off of javascript side and then sent and round tripped over any arbitrary ocapn implmeentation and rewritten down to js should be lossless and equivalent, guaranteed to have same document dropped. mostly accurate, gives you the idea. not within scope of principles is ensuring that other json versions have same invariant

KrisKowal: would folks like me to walk through it bullet by bullet and see what we do and don't align on?

JAR: what would the alternative be?

KrisKowal: I could answer questions now before proceeding

JAR: nobody on the queue

KrisKowal: getting into it. undefined is not controvercial. null is agreed to have something suitable to round trip json doc in javascript over through a hop. we have consensus on this currently, but if there's further discussion about whether the principle of round tripping json is sufficiently well motivated it could be done without further conversation. currently agoric insists on this. boolean uncontrovercial. signed ints, we are in a particularly happy place with 3 languages looking at it, they all have readily distinguished byte types. in guile and python (racket?) these are syntactically the same and js it's the same. Debating name, most specific would be SignedBigIneger, and since signed and big are not dimensions that vary for ocapn, tentatively everyone discussing privately is content to rename this simply integer

MarkM: my favorite is integer. peano and the greeks would not have recognized the distinction of bigint needing to be distinguished.

Christine: not sure the greeks or peano recognize negative

MarkM: definitely not peano, not sure about greeks

JAR: sounds like no objections, it's integer

KrisKowal: floating point numbers, we're in a happy place, have consensus in principle. we agree to support -0 and we haven't put it on record but I'm here to put that to rest, work was in flight for our implmenetation last i checked. Strings would be in json subset, leads to deeper conversation about whether lone surrogates would round trip. would be inconsistent with idea that json could round trip if not. but lone surrogates respects utf-16's inconsistencies. anyone wish to discuss this now

JAR: let's discuss later

Christine: I think we should be careful to say this means the Javascript version of JSON specifically, since JSON is less opinionated

JAR: And I'm not convinced of it, hence I didn't want to discuss it right here

KrisKowal: not convinced of principle?

JAR: Principle seems ok, but not convinced if you did what you suggested that it would round trip and be lossless. Point me to a spec that guarantees this but do all IEEE floats other than NaNs have distinct representations?

KrisKowal: in ECMA spec it does have unique representations. but json spec in general does not. And also json spec does have opinion that the document is utf-8, but strings within that document but strings within it can use lone surrogates technically

KrisKowal: bytestrings non-controvercial

JAR: should they be octetstrings?

KrisKowal: we don't have consensus on name

MakrM: since nobody cares but we care that we have agreement, I like bytestrings. colloquially everyone says byte not octet, and suffix string, it's included a tier of strings

Christine: there was confusion in syrup

Jessica: I read too much into bytestring, thought it was specifically a string, but if you're not familiar with bytestrings but were with strings you might not assume they're the thing they are. it's the string part. so bytevector would be good. bytestring might lead to incorrect assumptions

KrisKowal: Python used bytestring, scheme used bytevector

MarkM: no objections

KrisKowal: I have a pref for bytearray but I propose JAR do a vote

JAR: I hate to do a vote but... if we could run polls in github that would be nice

KrisKowal: I propose an out-of-band poll on github is good. I can initiate. Nominees is ByteString, ByteVector, ByteArray

JAR: due date by next meeting

KrisKowal: we have consensus to argue about symols, whether we do so now is not material. Tentative consensus is there's one kind of symbol which corresponds registered symbol to intered symbol, and python will invent a thing from whole cloth. reality for JS is that a role for a symbol is different than role for guile. I personally wish to keep many wounds open and have future convos on dependent topics on method invocation normalization, and maybe emitting symbols entirely from ocapn. agreed to disagree on symbols so far but have tentative agreement there's one kind. sequences, we have a proposal to rename to list

(+1 from Jessica and Christine and DavidT)

KrisKowal: Struct which has (?) in json is uncontrovercial, there will be a hashmap of some kind. key order weirdness of js is not preserved over the wire. moving on, tagged, there's a way to do this in JS or in guile, not sure how to do this in python

Christine: we already have one in the syrup implementation

KrisKowal: I think it would be good to not leak syrup that high up, we don't have consensus on whetehr it's monadic or variadic

Mark: In the same sense in which we have consensus that we have symbols in that's what the recorded conensus was. with tagged we do have consensus that the payload is a singleton, is not variadic

KrisKowal: can't find that

Mark: In the issue with ian, issue 5

(Jessica says fine by me for singleton)

Christine: prefer variadic, but I prefer consensus more

KrisKowal: thank you for concession. remoteable and promised distinguished as two kinds

KrisKowal: remoteables and promises (discussing invocation)

Christine: let's please not discuss the invocation semantics thinggs at the moment

KrisKowal: it will be tricky but yes we can discuss later

Christine: we're in a pretty good place for teh last three, everyone agrees on different types for remote objects and remote promises, and everyone agrees that we don't know how errors work fully yet

KrisKowal: one more wiggle on delivery on JS side today. last point is that at moment javascript's analogue of message delivery does not give sender the ability to express whether they expect to receive a remoteable or promise

MarkM: When sending a message you don't know the result will be, so seems to require a promise

KrisKowal: by way of counterproposal, capn proto permits specifying requiring a remoteable

Jessica: spec for op:deliver always delivers a promise

MarkM: they can specify in capnproto the type of the result but not the identity? promises and remoteables... remoteables have fresh comparable identity and a promise that locally has the methods of the type but not the remote identity is not a remoteable it's a promise. I suggest we discuss that as a typed promise

KrisKowal: don't want to go to far into capn proto but yes simplifying to be a promise may be good