SYSTEM Cited by 2 sources
Cap'n Proto¶
Cap'n Proto (capnproto.org) is an RPC protocol and serialization format created by Kenton Varda ~2013. It was the first widely-deployed system to combine object-capability RPC with promise pipelining, and it is the spiritual ancestor of Cap'n Web — which drops the schema language and binary format but keeps the capability + pipelining design.
Design choices Cap'n Web inherits¶
- Object-capability RPC model — functions and objects can be passed by reference; method calls on stubs route back to their origin. "Cap'n" is short for "capabilities and …".
- Promise pipelining — a chain of dependent calls ships in one round trip because the return value of an in-flight call can be used as the argument to a subsequent call before it resolves.
- Bidirectional / symmetric RPC — either peer can invoke the other; there is no privileged "client" role at the protocol layer.
Design choices Cap'n Web drops¶
- Schemas. Cap'n Proto requires a schema language (
.capnp) and codegen; Cap'n Web uses plain TypeScript interfaces and a JSON-ish wire format with no generation step. - Zero-copy binary wire format. Cap'n Proto's headline feature is that the in-memory representation is the wire representation (no encode/decode step). Cap'n Web picks human-readable JSON instead — unsurprising given the browser target.
.map()over promised arrays. Cap'n Proto, per Varda's own statement in the 2025-09-22 post, never supported this. It's a Cap'n Web innovation (solved via record-replay DSL capture of a synchronous lambda).
Seen in¶
-
sources/2025-09-22-cloudflare-capn-web-rpc-for-browsers-and-web-servers — named as "spiritual sibling" and design ancestor of Cap'n Web by Varda himself. No dedicated Cap'n Proto source on the wiki yet; this stub exists for link-integrity and to record the lineage.
-
sources/2024-09-16-lyft-protocol-buffer-design-principles-and-practices — contrast pair. Lyft Media's protobuf design-practices post is the canonical source on the wiki for the alternative schema+RPC lineage. Cap'n Proto and protobuf were both designed by Kenton Varda (protobuf v2/v3, then Cap'n Proto as the successor he'd have built from scratch); Cap'n Proto picked zero-copy wire-equals-memory, protobuf picked explicit encode/decode with stronger forwards/backwards compat guarantees. Lyft's post grounds its design argument for protobuf in the same extensibility + clarity frame Cap'n Proto also invokes; the two systems sit on the same axis with different chosen trade-offs.
Related¶
- systems/capnweb — the JS-native descendant
- systems/protobuf — sibling schema+format by the same author, different trade-offs (forward/backward compat over zero-copy)
- concepts/object-capability-rpc
- concepts/promise-pipelining