OCapN Pre-standardization Group

July 2024

Minutes

Baldur was casually curious about issue #101 and why the body and slot seperation.

JAR: On the agenda is issue triage. I'd like to go from oldest to newest.

Jessica: We'll start with issue #1 I don't know what it's about

Kris: My sense is that we've answered most of this already

Jessica: This is an "epic issue" that should probably be broken into smaller issues

Kris: And it largely has. There's an administrative task to figure out what remains open and close this one.

Jessica: Yeah, it mentions abstract and concrete syntax which we've dealt with. Sounds like we need to assign someone to go through and verify if there are things still open and capture them in new issues.

MarkM: I wanted to suggest that a useful GitHub notational tactic is to turn the separate bullet points into checkboxes and then check off the ones that are done in-place, so that it's clear in context.

Jessica: That sounds like a good idea. I guess I should ask if anyone wants to take on the job of doing the checkbox conversion and perhaps spinning individual things off into their own issues if they're still relevant?

Kris: I'll take that on.

MarkM: Thanks!

Jessica: Next is #2 opened by Christine. I guess this is about the protocol being easy enough to implement that it can done in a short amount of time. I'm not sure how to quantify this.

Dave: I want to say that it's good to want to do this, but in terms of a Github issue it's not actionable. I think we should capture this some other way and close it.

Jessica: Where should this go.

Baldur: suggests wiki or readme in chat

Jessica: I'll take on adding it to the README and then close it.

Jessica: Next is #3. I think this can just be closed. We are still working on certain aspects of things, but we have broad agreement of abstract and concrete syntax.

JAR: I agree.

Jessica: I'm gonna hit the close button. Done.

Jessica: Next is #4. This is for the underlying operations in the spec are kind of long, and that's not desirable because of how many bytes we're sending over the wire.

Dave: I agree. Christine wrote this up, names are too verbose. I agree that we should have some short names to conserve bandwidth.

Kris: I am torn on this issue. First, I want to clarify that the scope is enums in the protocol level or within data? I assume that is for enums in the protocol.

Jessica: I think, probably.

Kris: De-symbolifying is a good idea, going from strings to numbers. It will help with evolution of the protocol. Clients can forward along numeric enums that it doesn't understand.

MarkM: I'm getting confused. We've agreed on the principle that we have a common set of data types and that we define the semantics of them in terms of round-tripping requirements. Given both of those principles, I don't understand what you just said.

Kris: That's why I was asking if the scope was the data model or the framing of the protocol. I take it that this is a question if CapTP has 'op:deliver' as a symbol or an integer opcode.

MarkM: Whatever the representation is, we standardize on round tripping. I don't see how it's a problem.

Kris: I'm describing an abstract problem. There are reasons why string names could cause a problem. There's a decision to be made between readability vs. less bandwidth.

Jessica: Seems like we have agreement that we should use shorter names. Maybe a number or a shorter string. We need an action item.

JAR: Yeah I think there's gonna be some questions about this. What's the point of using a readable format if the opcodes are going to end up being numbers? It should be discussed, I don't want to shut it down.

Kris: I share that sentiment.

Jessica: While today it is somewhat readable, I don't necessarily think it has to be that way. If you print out all the things you are sending, it's not all that readable. It's less important to be readable and more important to be efficient.

Kris: We should discuss this at a future meeting.

Jessica: It would be good to discuss when Christine is here.

Jessica: Next is #5 It's about core data types. I think we can close this because we have agreement and its in the wiki. I see that MarkM, Dave, Baldur, and Kris agree. I'm going to close this.

Jessica: Next is #6

Dave: DanC is not here, but we've talked a little about this since Agoric has the pet daemon and Spritely has Fantasary which is a chat system. These could be a good target in the future. DanC is working on Zoe2escrow.

Kris: I just wanted to let you know that pet daemon is largely in the hands of the MetaMask kernel team. An interop project with them would be valuable. I think there are smaller steps in between but that's a good "north star"

MarkM: I think another good "north star" would be distributed debugging between spritely and agoric. Spritely has put together a Causeway-like debugging tool with a rendering of causality. Kris has been working on an error info collector for Agoric things. It's fine to keep going separately right now but we should keep our eye on if there's a single stack/log/error/whatever format that we can both use and debug computation that spans both systems.

Dave: I agree that would be great. I would like to explore this. We should add a comment about the "north stars" mentioned here.

Jessica: I'll add the comment.

Jessica: Next is #7 about the current write-up of the CapTP protocol. We have the write-up I did for NLnet, so I think it makes sense to close this.

Dave: Yes, this issue calls for a "basic" write-up and what you've done is more than basic.

Jessica: Not hearing any objections, so I'm going to close it.

Jessica: Next is #9 It sounds like we've agreed on the bulk of this.

Kris: I think our agreement is narrower than what I've proposed, but we've agreed to interop on a protocol and agreed on core data types and a concrete serialization format. I agree we should close and I can do that.

Baldur: I just wanted to request to put a comment in this issue with links to the relevant issues/etc. that justify closing it.

Jessica: Sounds good to me.

Jessica: Next is #10 How should exceptions and errors work?

MarkM: I volunteer to take on making a proposal for this. Not this meeting, but soon. I have a couple of PRs in process for moving the Agoric infrastructure towards what I think I want to propose, which will give me a concrete basis for the proposal. Not necessarily along the lines of this issue, but a starting point.

Jessica: I will assign you to this issue.

Jessica: Next is #11 Promise shortening. Do you remember this Mark?

MarkM: Shortening of unresolved promise chains is a big issue. Agoric has "painted itself into a corner" due to the constraint of working with JS promises. It's hard for us to get the information needed at the endpoints, but it doesn't have to inhibit the protocol. The endpoints should have what they need to shorten unresolved promise chains. Once the endpoint of a promise is settled, that endpoint propagating its way through, settles everything upstream and then there's no longer a promise chain. The issue is while the promise chain is unsettled. E did this, but a flaw was found. This is a long-term thing we need to get to, but we can go a very long way without unsettled promise chains being shortened before anyone feels the pain. I suggest we leave it open and mentally file it as a long term project, not a short term one.

Jessica: That sounds good to me. I don't see any objections. We can work on it later.

Jessica: Next is #12 Third-party handoff design requirements. Potential complications because on-blockchain stuff cannot keep secrets.

MarkM: There's a strong interaction between this and message ordering requirements. E took on E-order which is stronger than FIFO. At Agoric we've backed off to point-to-point FIFO due to the difficulty of maintaining E-order with the added complexity of third-party handoffs. Is there an item for message ordering requirements for OCapN as a whole?

Jessica: Issue #40 is about ordering guarantees.

MarkM: FIFO order doesn't have the problem. FIFO being point-to-point can't constrain what happens in third-party handoff because those aren't point-to-point.

Jessica: I think the above issue mentions E-order and could encompass what you're saying, Mark.

MarkM: There's another issue we call the "auxilary data problem" which I don't think we've explained to this group. Getting the constraints for third-party handoff including the problem cases, specifically blockchain endpoint problems, would be good. Blockchains can't hold secrets. There's another that Brian Warner taught me about: The instability of endpoints, what we'd call a vat id. The forkability of blockchains, the temporal constraints, create a real difficulty in stable identity. Stable identity is fundamental to the third-party handoff problem. I'm not prepared to go into it now and I'd like Brian here to explain further.

Jessica: It would be good to go into this more later. I can speak quickly about Goblins. It doesn't impose requirements about ordering. So, I don't think that should cause any issues. On the secret side of things, all the messages on the wire could be published and not break third-party handoffs. It uses certificates. It does assume that the nodes can keep their key secret, but it's not a key you share over the wire. It's the key you use to create the certificate.

MarkM: That's like the old E CapTP. We moved to a model where we didn't rely on the secrecy of swissnums for third-party handoffs. We did rely on swissnum secrecy to go from sturdyref to live ref, but that's a separate issue. With blockchains, there's no real equivalent of the endpoint signing with a secret signing key. This is part of the problem of blockchains not having stable identities that CapTP has always assumed. This might be another place where Agoric has painted itself into a corner.

Jessica: In Goblins, the identifier for the node is based on the public key of the node. The keys are pairwise for the session. New sessions get new keys. The identifiers are derived from the 2 keys, sorted and hashed. They are ephemeral and do not live beyond a session. Going back to the issue of documenting the requirements: Third party handoffs are documented in the draft spec. I did also give a presentation about handoffs where we walked through how they worked. I'm suspecting that there aren't any problems with the requirements, but I'm not sure how the implementation that Goblins uses would impact blockchains. I suspect it's okay, but it's something that Agoric would need to confirm.

MarkM: Yeah, I think we can leave it at that. Agoric needs to confirm/investigate. I suspect there will conflicts with blockchain constraints.

Jessica: To move forward, I can write on the issue what we've discussed here and link to the presentation I gave and assign it to you, Mark. At some stage you can review it and see if there are issues that can be addressed.

MarkM: I'll try to hand it off to Brian.

Jessica: Re-assign as you see fit.

Jessica: Next is #13. Distributed garbage collection. Opened by Baldur.

Baldur: This is long-term and we should keep it open.

Jessica: Next is #15. Replacing a deliver.rdr with op:listen.

MarkM: I'm guessing that's a reference to E's protocol and replacing it with something else.

Jessica: I will assign this to myself and bring it up at the next meeting to propose closing or discussing something else.

Jessica: Next is #16 about calling conventions. We are not going to make any progress on this right now.

Dave: We should put this on a future agenda, but not the distant future. The time is coming to settle on something.

Kris: Agreed.

Jessica: Who wants to scribe next time?

Kris: I think it's Agoric's turn to scribe.

JAR: Does someone want to volunteer?

Jessica: I can volunteer.

Dave: And someone from Agoric can scribe the meeting after next.

Jessica: Shall we wrap up?

JAR: Sounds good.

Jessica: Thanks everyone!