feature request: cap'n'proto rpc

[nothingmuch]

arguments for:

1. practically no overhead for binary data
2. possible to make pre-determined recursive queries with no overhead (e.g. ancestor transactions of ancestor transactions of a given transaction) without requiring specialized batch APIs (promise pipelining)
3. amenable to attenuation, allowing RPC clients (e.g. if electrum service is itself just a translation proxy, it needn't consume all of the capabilities, only those that it requires)
4. cheap if used in the same process space

arguments against:

1. binding wants to own the representation, so 0 copy IPC not generally possible
2. relatively high complexity of serialization layer
3. no existing consumers in ecosystem apart from internal types in multiprocess bitcoin

[reardencode]

Can you provide a link and more info about cap'n'proto? I'm not familiar

[nothingmuch]

by analogy, if protobuf is like C style product types, cap'n'proto is also supports sum types/enums and interfaces (trait objects)

interface types, being statically typed, allow compound operations like foo.get_bar().get_baz() to be pipelined, the binding can return a future for get_bar() and calling get_baz() on it arranges for that to be called by the remote side without another round trip (promise pipelinining)

see also object capability model, which is the approach to handle authorization https://papers.agoric.com/papers/robust-composition/full-text/ and which should feel familiar (macaroons, output descriptors are capabilities)

https://capnproto.org/