OCapN Pre-standardization Group
October 2024
- Chair: Jonathan Rees
- Scribe: Christine Lemmer-Webber
- Present:
- Baldur (uFork maybe?)
- Jonathan Rees (Independent) (JAR)
- Christine Lemmer-Webber (Spritely)
- Dan Connolly (Agoric)
- Amy Grinn (Spritely)
- grypez (MetaMask)
- Kris Kowal (Agoric)
- Richard Gibson (Agoric)
- Erik Marks (MetaMask)
- David Thompson (Spritely)
- Juliana Sims (Spritely)
Agenda
- Closed issues - discussion only if there are objections
Review open issues e.g.
- Zoe Escrow in Goblins, an Experience Report
- CapTP in Hoot in the Browser: Status Update
Minutes
Agenda review
DanC: I have an agenda request. Would like to do an experience on Zoe Escrow using Goblins
Abstract Syntax PR
KrisKowal: And I'd like to append to the queue that I submitted a proposal for finalizing our abstract syntax
https://github.com/ocapn/ocapn/pull/125
KrisKowal: In excitement that we got agreement on abstract syntax I submitted PR capturing. Open for comments
JAR: Ok, I think we should spend some time on that. Only other thing is open issue review. We can talk about this for... maybe 15 minutes? So let's go!
JAR: so PR 125
KrisKowal: I'll share my screen. Folks should be seeing "propose abstract data model", what we had already written up for wiki and move into repository.
JAR: Maybe this is just a me thing but I appreciate it when news of an agenda request if that comes up in advance of the meeting in advance of agenda preparation. This is fine, it's not high stakes, but I feel more comfortable as chair and having expectations of timing if I understand what is happening ahead of time. Not a complaint, comfortable with this here. Happy to do it now.
KrisKowal: Great feedback, I had wondered about how to do that in the past. For this particular PR I invented a label called "meeting" last month and I propose that we use this to accumulate topics.
cwebber (chat): We usually append to issue.
KrisKowal: That sounds good to me.
JAR: I'd prefer keeping it on the agenda.
KrisKowal: I'll be more diligent in the future when queueing up a topic. Substance is very light and normatives / non-normatives are very thick, felt non-normatives very useful. Structure is breaking up into containers and atoms include undefined and null that exists for case of appealing json where that matters, booleans, integers, float64, string, this json indicator means it's participating in json subset of ocapn and asterisk indicates we're only accepting valid unicode subset and not accepting unpaired surrogates.
DanC: Can you show number again?
KrisKowal: Integer is bigint and float64 is...
DanC: JSON numbers can be arbitrarily long?
KrisKowal: Yes, json subset that roundtrips with javascript only round trips float64. Byte array, we agreed on both byte and array at a previous meeting, selector we agreed would accept as symbols in guile and special pastile container in JS and probably similar in python, list is arrays in js and... structs, tagged, remotables and promises as two capability types, and notes on how we represent these in javascript which likely will have to change to accomodate functions as a potential remotable, I could use feedback on how guile handles promises, and error is handwavey at the moment. This is text we've captured in spec and I think unblocks experimentation and feedback is welcome.
Dave (chat): No promise type in guile itself, have it in goblins library
JAR: My question is what constitutes adequate review
Christine: Previously Jessica was managing the spec. This group agreed that Jessica and Kris would be the chief editors and when they have achieved consensus. I'm hoping we can get Jessica's views on this. As long as Jessica is going along with what the rest of the group has agreed upon we will be in good shape.
Jessica is notably on vacation this entire month, she will have some time after she gets back but she'll be catching up. Let's aim for her to review before the next meeting but be forgiving if she does not by next month.
JAR: I see Jessica already assigned to this task on issue. How do we ensure that she hears?
Christine: Dave Thompson will make sure she sees it
Kris: I'll point out this also has remotables.
Christine: I saw the remotables thing and from my perspective it's a terminology decision thing and I belive we have the same conceptual version. We can potentially set up a bike-shedded name but that could also be its own issue. My sense is that if we agree abstractly and the 'remotable' becomes contentious it will end up being a positive impact on the project.
Kris: Agoric came up with this term. We use remotable in our in-memory representation because it betrays the fact the remotable may not be remote.
Christine: Jessica has already written a significant amount of spec text. PR should reflect the new language chain.
Kris: I'll leave a note online so Jessica can figure out which term the spec already uses.
Christine: Excellent, thank you.
JAR: Anything else on this topic? I'd like to move onto open issue review
Agenda review (cont)
DanC: Where did my request show up in terms of my request to present on zoe escrow in goblins report? Before or after open issue review? Where should it go in the agenda?
JAR: Technically that would be new business at the end, open issues are old business. I'll allow 5-10 minutes at the end
Backpressure #20
JAR: First on this list is backpressure, giving people a minute to review
Baldur: My understand with CapTP of E and other systems I've seen, it relied on underlying transport for backpressure. I've never understood why you would want to do it in captp
Christine: Regarding the CapTP and backpressure: Baldur is right, historically backpressure has not been a first-class thing in any CapTP implementaiton. Baldur identified it could be done in netlayers in OCapN or on an object level where individual objects where they are refusing messages after a certain timeout which could be more difficult.
I'll admit I feel underinformed about how we should consider suggesting backpressure methods. It might be good to encourage in netlayers abstractly and certain netlayers for rate limiting. There's specific types of backpressuring about waiting until work is accepted and promise is fulfilled. I think it's risky to try to come up with something that's not one of those two things. If somebody proposed something more concrete it would be interesting. Unfortunately, Ian is no longer here with us to advocate for his position.
Is anybody in the group have a point of advocacy for having a backpressure feature as part of OCapN?
JAR: This sounds to me like something Mark would like to comment on.
Kris: I'll do that and dequeue myself. I'm sure that Mark does have an opinion but he's in Tokyo for TC39 and won't be able to attend. I can say that... my view is largely consistent with Christine's, I think there's a place for netlayer backpressure, but maybe not too much, the nature of TCP backpressure is it obligates the peer to take messages off the wire and queue them in memory. If you were to implement backpressure... there are certain datalock situations if you don't take messages off the wire and handle them eagerly. There can be a lock between two things not managing to coordinate. But of course mitigating to prevent denial of service, it is appropriate to do so at the netlayer, because we of course must deal with Denial of Service. At the object level I suspect we can have multiple solutions and for instance Agoric has used various pubsub abstractions above the captp layer which have different properties with who foots the bill, whether multicast or unicast, etc etc. In short there's a lot of opportunities in terms of work above captp layer in terms of cooperatively, and I look forward to it, and in terms of abstract model we're in a good place to look into it. I suggest we close this issue.
JAR: Do we have a solution to close with?
KrisKowal: I suggest when we have progress on this we say we handle this on netlayer or we handle it as protocol above CapTP, which is also not part of captp spec.
JAR: Volunteer to add such a message?
KrisKowal: With group's blessing of close or not, I'll add a comment of course
Christine: My vote is, it's a good question if we have no solution. I think that we should have a more specific thing that we ask for, which is because we agree that backpressure is something that needs to be implemented on some netlayers, we should include documentation on how netlayers should implement backpressure. For individual netlayers we should add specific instructions. I believe Kris was correct in saying that these are the two occasions they will occur. There are some cases were people try to handle backpressure in cases where we need to prevent DDOS.
Kris: I agree Christine, we should make a note that DDOS mitigation is a netlayer responsibility, that the CapTP layer is not going to have mechanism added to CapTP. We can note that there's cooperative scheduling done above CapTP which does not require captp mechanisms
Dave (chat): Does a peer drop messages if it's overwhelmed?
Christine: It should not intermittently drop messages and handle others.
Kris: No I don't think it can drop messages, but it can drop connections or slow them down. It must maintain invariant of FIFO.
JAR: Can we move some discussion to issue?
Christine: I believe Kris summarized all the things I believe so I would love it if Kris summarizes
Kris: I will summarize on issue
JAR: And we should have minutes to draw on as starting point
Kris: Aye
Amy: Are we closing issue then?
JAR: I would like to see it open, we can bring it up next time and see if we're able to close then
JAR: Going to suggest Dan's item goes higher than other two issues on agenda, giving floor to DanC to talk about Zoe
Zoe Escrow in Goblins, an Experience Report
DanC: (screensharing) does anyone see use-module widgets?
https://github.com/Agoric/agoric-sdk/blob/dc-escrow-formal/packages/zoe/spec/escrow2013.scm https://github.com/Agoric/agoric-sdk/pull/8184
DaveT: I see emacs
DanC: So there's this Zoe escrow service that's 42 lines in a 2013 paper, and escrow paper here, try to formalize here. And here's a 42 line piece of Javascript, and here it is with our current linting rules, you get line breaks... here's js code with heart of Zoe escrow service, read all about it in paper. Hand translated to scheme, but it's very closely transfer, define transfer, decisionp, decisionp, etc. For a moment I got alice and bob talking. Trying to formalize some of this, and I've got some property testing in JS with ERTP level with amounts of brands and integers, and found equivalent in scheme world called quickcheck, amounts if you have $5 and first doing thing you might think you can pass number 5 around, and maybe you thought you meant $5 and you meant 5 EUR so you start passing around brands. And amounts are not necessarily nubmers, they can be 5 potions and a scroll, and will trade for $5, and that's an escrow operation. These tests work with plain natural numbers and I've lifted to amounts, and so then that runs 100 tests and each level and I can run as many of those as you want, and that's a default in the library. So the experience here involved learning that for example synchronous method calls are not just normal function calls in Goblins. So if I want to synchronously get value of this ledger table then I don't just call get I do $ ledger payment. In JS world if you want to do a synchronous method call looks like function or method call. Learned how to transfer lots of idioms, also still learning how to load file into scheme repl, etc. That's a very short version of this. That's enough to prompt any questions
Christine: This looks really cool. By the way the dollar is because in Goblins, it was the reason the 'mint' example was so simple.
?: It also looks like an S.
DanC: No eventual sends in this file, in escrow file it certainly is.
DaveT: I see you using a lot of things I didn't expect and I'm happy to see them. This is cool. all-of joiners, etc. Some of the code might be better phrased in terms of a syntax sugar called let-on but that's cool
DanC: Yes race and stuff, hope that's in here but... JS code has a diagram where it looks like AND and OR gates, promise join looks like AND and race looks like OR
Christine: This is incredibly cool, Dan. I think it deserves a round of applause. Dan Connolly has been one of the biggest champions about investigating our two code bases, Spritely and Agoric. From me personally, you get a little applause.
Dan: I'd like to have actual messages going back forth sending purses and payments between JS and scheme over ocapn
Dan: The actual motivation was finding out a formalization to prove this thing works. Are there actor libraries for ACL2? I know there's an actor library for scheme (goblins) so I'll try it out.
CapTP in Hoot in the Browser: Status Update
Christine: Last thing: Hoot has been really coming along recently, like a lot. The latest release actually has a REPL on the page where you can play with hoot very easily. It's has almost all of scheme you can play around in, live. In the next version we will have user-defined macros. At that point, we will have pretty much everything Juli has been doing the work of porting goblins to the browser with hoot. Juli, would you mind sharing what is the state of OCapn and Goblins on hoot?
Juli: Hello. In theory we have everything we need to run CapTP in the browser in hoot. The tests for interopability of tests in CapTP are not complete but we do have our regular test suite.
Christine: The other big thing Juli is working on is crypto bindings. We are on the verge of having goblins and OCapN in the browser.
Dave: Hopefully we can demonstrate goblins working on a virtual machine over websockets.
Kris: What delimits a CapTP connection.
Dave: We're looking at websockets for a first example.
Juli: It's still a theory because we haven't tested specific netlayers.
JAR: Meeting is over. The conversation will continue privately.