OCapN Pre-standardization Group

December 2022

Agenda

Minutes

Jessica: should we start off with introductions?

Topic: Introductions

Jessica: Jessica: I'm Jessica Tallon, I've previously been doing standardization work on activitypub in the w3c SocialWG

Jessica: a little over a year ago I started working on spritely in an nlnet grant implementing a petname system

Jessica: just recently I got another nlnet grant to work on this pre-standardization phase of standardizing ocapn

cwebber: Co-founder of spritely institute, fan of OCap stuff for a while.

cwebber: CapTP is the piece of technology that really blew me away

alankarp: Alan Karp, in 1996 was dev'ing distributed stuff, realized that ACLs wouldn't work about 2 minutes in, re-invented ocaps independently, have been doing it every since

alankarp: not interested in spritely as much for social media aspects as for distributed computing aspects

Jessica: you and I agree, as interesting as the social stuff is

Zarutian: I'm Baldur, I've been around here for a while, I'm interested in many uses

Zarutian: my goal is to get a simple / easy to implement protocol going

Zarutian: was because of me not being near enough the mic and a bit of stagefright

DannyOB: I'm Danny O'Brien, work for FFDW, sponsor of spritely, here to listen in

garbados: I'm Diana, am a CouchDB maintainer, interested in distributed protocols, IPFS, etc, very interested in spritely, goblins, ocapn, because what I believe they can provide paradigmatically to distributed systems programming

garbados: recently wrote an article describing profound implications of these standards

Brooklyn: I'm Brooklyn Zelenka I've been working on capabilities for a couple years, primarily around UCAN. Similar to Alan, we kind of accidentally reinvented this stuff internally at my company, and then dove into Mark's work and have been doing capabilities stuff since! Super excited to possibly getting all of these systems working together with OCapN!

warner: I'm Brian Warner, I've breen doing several captp things, built one in Python, in Javascript for Agoric I made one called swingset, dont' have handoffs but we do have promise pipelining

DanC: Dan Connolly, I'm very interested in spritely <-> agoric interop, I used to do w3c standards stuff, now doing ocaps at agoric

Dmitri: Hi I'm Dmitri Zagidulin, I work on VCs and DIDs, but also helped with zcap specification / zcap-ld libraries, so I'm a huge fan of cert style ocaps, I'm interestd in ocapn, couldn't quite understand it, but christine said ocapn rules so I want to join and see if I can understand it better

JacobWeisz: I'm a community contributor to SandstormIO, I found I was basically complaining on G+ at the time about the awful state of cloud stuff and wanted to take my apps with me, kentonv said hey I'm working on something, so I've been following sandstorm since there was such a thing. it takes webapps and lets you easily run them from one platform and ocap security is built in at a core level with capn proto

isd: I'm Ian Denhardt, also a sandstorm contributor, also way back wrote a handful of plugins for gnu social that never got merged, but sort of interesting thing from this group is the sandstorm stuff and I'm also maintainer of the Go/Haskell versions of cap'n proto

isd: Jacob alluded to this but it's roughly a captp

isd: I think with that, spritely, agoric, those are the 3 we're looking to reconcile

danc: when I said spritely <-> agoric interop, I should have included cap'n proto.

elplatt: I'm Edward Platt, relatively new to ocap, largely came to it through following spritely, really excited about it, really fits well with many of the things I've been thinking about, really looking forward to being part of the future, learn from all of y'all

jar286: I'm Jonathan Rees, I worked on lisp implementation and standardization back in the 80s, and lisp/scheme in the 90s, and ocap was in parallel, in ignorance with Joule/E, so that was amazing to discover it was all happening at the time. So I then discovered all the huge problems I cared about were solved, so I went to work at millenial pharmaceuticals, Science Commons, Open Tree of LIfe, and reconnected with Christine since then,

jar286: got re-interested in ocaps. And yes I was on the W3C TAG with Dan C for 4 years

jar286: so we got to interact a lot

kriskowal: I'm an engineer at agoric, we have an execution environment on a blockchain, I'm actively reconstructing as a user agent that could communicate p2p with our captp variant which we hope to reconcile with ocapn

markm: I'm Mark Miller, I've been working on all this stuff for a long time, it's nice that many people here seem aware. I want to endorse the idea that CapTP should be described to mean a family of protocols: capn proto, spritely, agoric are all in the captp family, but we hope we can make it interop under ocapn. many positive things flow from network effects when you have a uniform fabric that represents a flow of the world. I

markm: think that the most important starting point to contribute is that the interop should be focused on the abstract syntax not the concrete syntax. the abstract syntax is what we must all agree on, if we can agree on that we can do adaptors for the concrete syntax

Jessica: sounds great, hope we can agree on concrete syntax too but even that is good

mathieu: Mathieu Hofman, I work at Agoric with Waner, MarkM, etc. before at agoric was trying to build on top of basic RPCs, so I've always been interested in that. I ended up reinventing many distributed GCs ideas that MarkM and others invented 20+ years ago

mathieu: interested in how we can converge

mikayla: I'm Mikayla Maki, I'm kind of just hanging around to keep an eye on things. been getting into ocaps, recently did the heart of spritely, asynchronously now, hoping to expand that to actually hosting and serving my personal blog

juliana: Hi, I'm Juliana, I'm just kind of here to listen honestly. I heard about OCap through Spritely and am really excited for its potential to make distributed computing more accessible and secure.

MikeStay: I worked with MarkM at Google on the Caja project, right now I'm the CTO of Pyrofex - corporation working on a new blockchain based around Go, I intend for smart contracts to communicate over OCapN, so would like to be part of this

Randy Farmer: hi I'm Randy Farmer, I'm happy to meet many of you. I've been involved in much of this work for years, at Electric Communities, at Agoric when called Agorics, wrote some of the first code in Joule and the first production code in E. excited to return to catalyzing getting this mainstream. I'm going to mostly listen but am co-founder of Spritely Networked Communities Institute but glad you're all here

RichardGibson: relatively new here with MarkM and Agoric, but excited to see what comes of this effort and contribute

Jessica: happy we have about 22 people here, that's great

Topic: NLnet grant

Jessica: I'd like to explain what the NLnet grant is since it will impact our group. This grant was given by NLnet to work on pre-standardization of OCapN on captp, netlayers, uris

Jessica: grant split up into multiple sections, one of which is to have multiple implementations talkign to each other (guile and racket), then a big chunk of the grant is drafting specifications based on current implementation spritely is doing

Jessica: of course captp is bigger than spritely, this is just a starting point so we can see where we agree and disagree, try to find consensus, and then we can change the draft specifications as we go. so those are the 3 specifications of one captp and netlayers (formerly VatTP, MarkM and Christine have adopted netlayers as a new term), and URIs for studyrefs, etc

Jessica: so part of the group is to kick off these meetings, come to consensus

Jessica: another part of this grant is to implement a full compliance test suite based on the things we write here

Jessica: so as the specifications evolve, so will the test suite

Jessica: finally an implementation guide, standardization is about adoption, we want to make it as easy as possible to implement and a guide will help that effort

Jessica: and once we've gone through pre-standardization, we can take this to standardization

Jessica: someone asked if I had a standards group in mind, I don't, we have experience with activitypub

Jessica: but I don't want to have unilateral direction setting

(DanC: +1 github as tooling)

Jessica: to talk a bit about how these meetings should work, of course they're about all of us, since we have the ocapn github page that I put this meeting issue on and scheduling it, I thought we could use that to file issues and discuss things as well as having that for a place for meeting minutes and collab on draft specifications

(Dmitri: +1)

Jessica: if people have ideas we can bring that up

Jessica: but I thought to kick that off we could do that at the beginning

Jessica: I'm currently assuming role of chair but I think going forward I think the group can nominate another chair

Jessica: I think the group can nominate a chair

Jessica: I think who wants to be the chair in mind, someone can nominate, but we can take a vote

Jessica: with voting itself I've had good experience with w3c approach of 0, +/-0, +/-1

Jessica: and we can do that on irc which can keep it in meeting minutes

Jessica: +1 is in favor, +0 is in favor but not strong, 0 is no opinion, -0 is don't agree but won't block, -1 is strong disagree

Jessica: we should aim for consensus but we can discuss through it

Jessica: if needed majority vote but should aim for majority vote

markm: eventually will have a lot, but have a question where we plan to be our own org, or should we bring this to a specification org

markm: I'm fine leaving it independent, but there's a lot of lessons from the experience of TC39 which are relevant in particular things only get accepted by consensus

markm: which is a purposely fuzzy notion

markm: but when they don't achieve consensus

markm: we don't fall back to majority

markm: we leave blocked until we achieve consensus

markm: and that work sout surprisingly well

isd: yes and I think we've got real projects and etc.

isd: so consensus is kind of mandatory

Jessica: I've had good experience with w3c method

Jessica: and I'm happy for consensus to be the goal

Jessica: and of course I'm not the deciding factor

Jessica: so that's certainly a topic for now

Jessica: in terms of where this is going obviously we have to choose a standards body, and it probably makes sense to follow whatever they're doing. w3c, ietf, etc

markm: not obvious to me we need to pick a standards body rather than being a standards body

isd: I'm a +0 of stakeholders at the table

cwebber: we haven't decided a queue mechanism

cwebber: the grant we have says that it's pre-standards. The motivation there is partly that our experience (myself and Jessica) doing ActivityPub wishing we had everything ready to go before bringing it to a standards body, so it'd be good to have multiple working implementations and test suite before beinging it to standards

cwebber: the people here might have some differences, but those differences are quite small, not like that me and Jessica had in the social wg.

Jessica: to finish this topic, the final thing is the frequency of these meetings, when they would be held

Jessica: I was personally thinking of proposing every 2 weeks or every month

Jessica: depending on what everyone has time for

Jessica: definitely what we need to get consensus on

Jessica: perhaps next meeting should be in January 2023 to kick off in earnest

Jessica: not sure if we should discuss those now or move on to status of implementations but

JacobWeisz: between meetings what are we trying to accomplish?

Jessica: certainly once we have the drafts, discussing issues, etc

Jessica: and also time we have available

Dmitri: not sure if I should comb back later, but wanted to speak about benefit of standards bodies, and that's ip restriction agreements. basically standards groups have magic that mostly shield us from predatory patent processes

Dmitri: but the friction of community group in w3c or ietf are minimal

alankarp: I've been sitting in many w3c meetings, and procedures are fairly heavy for early in process, might be better to get along before we do that

alankarp: and I think there's a number of topics we've been talking about, many of those have frequent smaller groups

alankarp: maybe bringing this group together once a month

danc: do we have polling facilities on meeting frequency

cwebber: let's check who wants to do frequency in group chat of video

cwebber: everyone has said monthly for now

Jessica: monthly for now

(Kris Kowal: +1 monthly or fortnightly)

Topic: Implementation summary

cwebber: status in spritely:

cwebber: very working racket implementation and getting close in guile

cwebber: we have:

cwebber: we're hoping by next meeting we'll have guile and racket talking to each other

Jessica: for agoric is it mark? warner?

warner: comms protocol from one kernel to another, we have a star configuration, one kernel can talk to another kernel through a comms protocol, it has promise pipelining and acyclic gc, there's a distinction between weakrefs and weak maps (?), not sure if that's a distinction for gc or not, don't have 3rd party handoff yet. currently kernel assumes a safe way to connect kernels, we have vattp and captp division as usual

danc: there are some smaller vattps

markm: we do have a p2p protocol, and both vats talking to kernel, and one chain talking to other chains or non-chains. we don't have chains talking to other chains yet

markm: there are some hard problems to take on, one of the constraints of having an endpoint be a conventional blockchain is that a computationally conventional blockchain cannot keep secrets, so that has constrained the captp architecture in particular. helps bootstrap from offline to online connectivity. in certain conventions impossible to do a captp as a bearer right (sturdyrefs). the ordering issues are important and probably

markm: things we're going to need a variety, not a one-size-fits-all, and the thing we'll probably repeatedly revisit is distributed failure models... to what degree are failures masked or apparent for means for participants to recover from various failures

Jessica: ian would you like to present on capn proto?

isd: yes one difference is that we have substantial existing users and deployments so unfortunately we have a lot less flexibility in terms of change than others, but we currently have no implementation that does 3 party handoffs, there's some datatypes and specs in rpc.capnp but that's likely to change in next few months. have a client that wants various improvements in go, including handoffs

isd: so that's interesting to me to make sure that we have better chance of interop

isd: so I'd like to see if we have a way to shake out requirements early, so that's what's kind of going on on the go side

isd: the other interesting thing within last week or so is that one of the forgefed people (forgefed attempting to do federated code forges) was planning on doing stuff with activitypub but has found that it's annoying to do anything but social pubsub, but they're interested, we wanted to possibly pull them in but they're in israel/palestine at the moment

danc: agoric has shipped, have plans to throw it away, but we'll be constrained also

warner: blockchains provide especailly exciting backwards compat constraints

mikayla: what did you say you were saying was shipping

danc: agoric 1.0 is in production running some version of captp but our plan is to largely stop that whole thing and deploy new software that doesn't have strong resemblance

danc: but we plan to do that soonish

mikayla: thnks for verification

Jessica: getting towards end of meeting

Jessica: I think you were mentioning something markm about teasing out different layers of stack, not sure if you wanted to elaborate

markm: there's probably not much time to go into it, there's the issue of ordering semantics, 3party handoffs between different media, thus also routing issues

markm: the distributed failure model issues... don't think there's one size fits all answer, but we are trying to introduce a p2p fabric

markm: so I think after we solve the straightforward problems (which can still be years long effort) that's where the meat of this body would be, how to provide mechanisms which provide a variety of policies without having those issues

markm: I doubt we'll find simple agreement on distributed ordering

markm: lesson I want to conclude with is... concrete syntax agoric with is likely one we're not likely to move from... concrete syntax capnproto is one they cannot move from, so I think that right there explains why this body trying to get agreement on concrete syntax is probably at the outset unrealistic. but we can start off with the 2-party point-to-point abstract syntax of a protocol with c-list based 2-party introduction and fifo

mark:order delivery of messages over one connection. I think that's something cap'n proto got right, they extracted that from the old captp work. get the 2-party thing settled well as a 2-party mutually suspicious system in the absence of GC and failure, get that all well settled, and once that's a solid base, and then the other issues can be layered on top

Jessica: it's only a few minutes till end of meeting, so it's probably sensible to wrap things up things up here, want to thank christine for scribing, want to get those minutes to ocapn repo, not tonight because it's quite late, but also want to open an issue for scheudling next meeting in January, and will also open an issue for nominating a chair, so if anyone is interested in that job, or nominate someone, discussion can go there

Jessica: would like to thank everyone for coming

cwebber: and thanks to Jessica for chairing!