Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2022-01-24 📝 Original message: Christian Decker ...
📅 Original date posted:2022-01-24
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
>> I noticed the commando c-lightning plugin just uses the JSON-RPC
>> payload, but perhaps something more compact and rpc-friendly like grpc
>> would be better... which is why this cln-grpc PR peaked my curiosity.
>
> Yep, JSON-RPC is rather bad with binary data, and doesn't have any
> concept of streaming. I personally like grpc because it ticks a lot of
> boxes: secure transport over TLS, mutual authentication via mTLS,
> possibility to add metadata to calls (technically prohibited by the
> JSON-RPC spec) which can help us use macaroons/runes in future,
> streaming support and compact binary format.
The rest is true, but spec doesn't disallow extra fields that I can
find?
> Having an IDL to describe the interface is also rather nice, even though
> for cln-grpc we actually generate that from the JSON-RPC schemas, so
> it's a bit less expressive than .proto files.
>
>> I think the end goal of an RPC bolt would be super powerful, so that
>> lnsocket could talk to any lightning node, but that could be further
>> down the line. Choosing the right data format seemed like an important
>> step in that direction. Would love to hear your thoughts on this!
>
> I agree. Exchanging the transport layer underneath grpc doesn't change
> semantics, but does unlock a number of potential use-cases. I think
> either the JSON-RPC or grpc can serve as a basis for a common RPC
> definition that can have any number of bindings, since we generate
> conversion code to/from JSON-RPC and grpc we can transparently map them
> back and forth.
Yeah, I don't think we'll end up with a control standard. But I've been
pleasantly surprised before: certainly a common subset would be nice!
Cheers!
Rusty.
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
>> I noticed the commando c-lightning plugin just uses the JSON-RPC
>> payload, but perhaps something more compact and rpc-friendly like grpc
>> would be better... which is why this cln-grpc PR peaked my curiosity.
>
> Yep, JSON-RPC is rather bad with binary data, and doesn't have any
> concept of streaming. I personally like grpc because it ticks a lot of
> boxes: secure transport over TLS, mutual authentication via mTLS,
> possibility to add metadata to calls (technically prohibited by the
> JSON-RPC spec) which can help us use macaroons/runes in future,
> streaming support and compact binary format.
The rest is true, but spec doesn't disallow extra fields that I can
find?
> Having an IDL to describe the interface is also rather nice, even though
> for cln-grpc we actually generate that from the JSON-RPC schemas, so
> it's a bit less expressive than .proto files.
>
>> I think the end goal of an RPC bolt would be super powerful, so that
>> lnsocket could talk to any lightning node, but that could be further
>> down the line. Choosing the right data format seemed like an important
>> step in that direction. Would love to hear your thoughts on this!
>
> I agree. Exchanging the transport layer underneath grpc doesn't change
> semantics, but does unlock a number of potential use-cases. I think
> either the JSON-RPC or grpc can serve as a basis for a common RPC
> definition that can have any number of bindings, since we generate
> conversion code to/from JSON-RPC and grpc we can transparently map them
> back and forth.
Yeah, I don't think we'll end up with a control standard. But I've been
pleasantly surprised before: certainly a common subset would be nice!
Cheers!
Rusty.