IRC channel logs
2023-09-14.log
back to list of logs
<Zarutian_iPad>due to something that came up I had to forego this months meeting, sorry <Zarutian_iPad>tsyesika: hmm I did write an ebnf for spki s-expression based captp a long while back but for the life of me I do not know where that went <Zarutian_iPad>re canonicalization for cryptographic signature purposes: the rule thumb I heard is not to relie on such. <Zarutian_iPad>that is, it is better to serialize the data into a bytestring then sign that, and on the other end check the signiture before deserializing from that bytestring <ICRainbow>Zarutian_iPad, that requires retaining the original bytes while parsing, carefully slicing it to match the decoded AST by tracking offsets. Very fragile, if available at all. <kriskowal>I would like to borrow someone’s time to help me finish a matrix of ocapn language reified values and serializations. <kriskowal>My hope is to roll this up into an omnibus convergence issue. <kriskowal>Having drawn out some concrete examples of 2/3 of Agoric’s experimental marshalers from Richard and Mark, I’m more optimistic that we’ll converge! <kriskowal>One thing that’s working well is the selection of just canonicalized double and bigint number types. <kriskowal>There are a small number of sticking points I’m not sure about before we get into my opinions-of-various-strengths. <kriskowal>We can get this one out of the way quickly, I hope: If JavaScript sends null, does that get reïfied as '() in Guile? If JavaScript sends [], does that also get reïfied as '()? <kriskowal>I would invite you all to push back as hard as you like on Agoric’s position that OCapN should support both null and undefined. But, if JavaScript did send undefined, would that get reïfied as a sentinel value exported by the ocapn library? <kriskowal>I think Agoric could be convinced to ween itself off of undefined if Spritely supported some horrible way to represent in Guile. <kriskowal>The situation with symbols is: I’ve been convinced that we can make interned-symbols round-trip between JavaScript and Guile and it won’t be terrible. Agoric already believes that it should ween itself off of well-known-symbols like Symbol.asyncIterator that would impose JavaScript protocols on the OCapN ecosystem. We’re already of the opinion that JavaScript’s iterator protocol unnecessarily defeats promise pipelinin <kriskowal>and that we should have some other OCapN conventions for streams and pubsub. <kriskowal>That being said, my opinion remains that OCapN stands a better chance if method names are reïfied as kebab-case symbols in Guile, dromedaryCase strings in JavaScript, snake_case strings in Python, and normalized in method invocation messages on the wire. <kriskowal>And since it would be a burden for Guile actors to be limited to either receiving invocation form (receiver 'name) or application form (receiver #f), I think we can find a way to support both on Agoric’s platform. Something like Far('name', applyHandler, invokeHandlers). <kriskowal>MarkM’s also of the opinion is that there is not one-perfect-concrete serialization for all our cases within Agoric, so I’m increasingly feeling like Agoric should finish a Syrup-style marshaller so we can start iterating on it together, and perhaps co-evolve some alternatives. <kriskowal>Another factor to iron out is syrup-records, which would be Agoric’s JavaScript tagged payloads. We have a couple constraints. MarkM’s under the impression that we already agreed to only use label and single-value records. There’s no technical reason we couldn’t go to variadic records, but momentum is carrying us forward with monadic records. <ICRainbow>> JSON.stringify([{hi: undefined}, undefined]) <kriskowal>But the technical sticking point is that Agoric currently surfaces records above the marshalling abstraction and does not use them below that line. <ICRainbow>aren't we mixing serialization values with language native types?.. <kriskowal>ICRainbow: Yeah, Agoric’s smallcaps is a JSON format that represents undefined as "#undefined". <kriskowal>ICRainbow: We’re negotiating the correspondence of native types across languages, as must be supported and round-trippable through ocapn over the wire. <kriskowal>That is to say, there must be a one to one correspondence between all passable native values over all supported languages. <kriskowal>E.g., if Agoric sends null to Spritely and Spritely sends it back, it should arrive as null, not []. <kriskowal>Round-tripping is a concise way to talk about the design constraint, but the more interesting problem is where Spritely is talking to Spritely with an Agoric ocapn-terminating proxy between them. <kriskowal>Such that if Agoric sends Agoric a null through a Spritely proxy, it should arrive as null. <kriskowal>One thing I’m sure of is that we could use niladic syrup records on the wire to fill gaps like undefined and null, regardless of their Guile representation. That works since they can’t be confused for label+single records. <kriskowal>I’m also sure that, if we did that, we would not want to expose niladic records outside of the marshal. If we converged on exposing variadic syrup-records outside the marshal abstraction, we would not be able to use niladic records to fill in for null and undefined. <kriskowal>My preference regardless is to have special values on the wire for one or both of these nulls, like "n" and "u" in the spirit of "t" and "f". <kriskowal>Is the shorthand for messages in ocap fully described or just correspond transparently to equivalent syrup? <Zarutian_iPad>which shorthand? afaik each message type has op:something kind of tag and I do not know of any kind of shorthand <Zarutian_iPad>op:deliver, op:deliver-only, op:gc-export, op:gc-answer, op:listen, and op:abort <kriskowal>I’m actually not clear whether the shorthand <op 1> is shorthand for <2"op 1+> or <2'op 1+> <kriskowal>would be more clear if the shorthand distinguish <'op> from <"op"> given that syrup records do not appear to have an opinion <Zarutian_iPad>iirc, the syrup spec for records expects symbols as the type tag <kriskowal>that lack of opinion might be important for distinguishing <'desc:etc> from user <"copy-set" [1 2 3]> <kriskowal>>>> syrup_encode(record('isodate', '2020-05-01T14:08:11')) <Zarutian_iPad>has not thought of using this distinction betwixt symbols and utf-8 strings for that purpose <kriskowal>presumably syrup_encode(record(Symbol('etc')) works too <kriskowal>yeah, the altnerative is to hilbert-hotel e.g., <user:date "2020-05-01"> <Zarutian_iPad>but then again I am known for (ab)using json arrays as sort of se-expressions <kriskowal>That could solve some convergence obstacles for Agoric. <kriskowal>Agoric’s marshaler would recognize <desc:import-promise 1> under the marshal abstraction and reify <user:copySet [3 2 1]> as {[Symbol.for('passStyle')]: 'tagged', tagName: 'copySet', payload: [3n, 2n, 1n]} <kriskowal>That’d allow for records to be used above and below the marshal abstraction. <kriskowal>That is, either differentiating symbol-labeled records (internal) from string-labeled records (external) or just have a string label with a prefix to differentiate internal and external. <kriskowal>Has to be one or the other since <desc:> records are inline with other passsable data. <Zarutian_iPad>that is, having spefic hole markers that say stuff like 'put object reference here by looking up the 6th item in the agreed c-list' kind of thing <kriskowal>That’s at least the same between Agoric and OCapN as-wrought-today. <kriskowal>A rosetta stone for ocapn and 2/3 of the agoric wire formats. <Zarutian_iPad>and using the fast json parser given by the runtime to turn bytestrings into object trees that are then visited, yes? <kriskowal>richard is building a third that produces a lexicographic rank order of serialized values which makes it possible to do range queries over passable data in a sqlite. <kriskowal>dean’s smallcaps rely on JSON for structure and abuse strings for differentiations inexpressible in JSON. <Zarutian_iPad>I think the syrup ocapn parser in spritely goblins does the pluging-of-holes whilist deserializing from the bytestrings source <Zarutian_iPad>in the cases of op:deliver and op:deliver-only messages the behaviour is pretty much equiv of making an event togo onto the event queue of the vat, yes? <kriskowal>anyhow, i’d like to borrow someone from spritely to look over my shoulder at a cross-language cross-format matrix, cwebber, if you can spare them for an hour overlapping pacific time.