📅 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 13:05:03
in reply to nevent1q…lc8e
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 13:05:03Event JSON
{
"id": "214242b3619bd9f84fb4cabc1763eb7243be7dd94f5b34c87ebdfc92157b3dd2",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315903,
"kind": 1,
"tags": [
[
"e",
"bbafbc4c376e50a2d8622ab6c7d7bb850f33774ae8c88d4310ce7d7d80722085",
"",
"root"
],
[
"e",
"2771457da4c681af36dcf10126a75c939be715abb0ebf9c6b52ccc280f91428d",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2022-01-24\n📝 Original message:\nChristian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\u003e\u003e I noticed the commando c-lightning plugin just uses the JSON-RPC\n\u003e\u003e payload, but perhaps something more compact and rpc-friendly like grpc\n\u003e\u003e would be better... which is why this cln-grpc PR peaked my curiosity.\n\u003e\n\u003e Yep, JSON-RPC is rather bad with binary data, and doesn't have any\n\u003e concept of streaming. I personally like grpc because it ticks a lot of\n\u003e boxes: secure transport over TLS, mutual authentication via mTLS,\n\u003e possibility to add metadata to calls (technically prohibited by the\n\u003e JSON-RPC spec) which can help us use macaroons/runes in future,\n\u003e streaming support and compact binary format.\n\nThe rest is true, but spec doesn't disallow extra fields that I can\nfind?\n\n\u003e Having an IDL to describe the interface is also rather nice, even though\n\u003e for cln-grpc we actually generate that from the JSON-RPC schemas, so\n\u003e it's a bit less expressive than .proto files.\n\u003e\n\u003e\u003e I think the end goal of an RPC bolt would be super powerful, so that\n\u003e\u003e lnsocket could talk to any lightning node, but that could be further\n\u003e\u003e down the line. Choosing the right data format seemed like an important\n\u003e\u003e step in that direction. Would love to hear your thoughts on this!\n\u003e\n\u003e I agree. Exchanging the transport layer underneath grpc doesn't change\n\u003e semantics, but does unlock a number of potential use-cases. I think\n\u003e either the JSON-RPC or grpc can serve as a basis for a common RPC\n\u003e definition that can have any number of bindings, since we generate\n\u003e conversion code to/from JSON-RPC and grpc we can transparently map them\n\u003e back and forth.\n\nYeah, I don't think we'll end up with a control standard. But I've been\npleasantly surprised before: certainly a common subset would be nice!\n\nCheers!\nRusty.",
"sig": "4f2bfb1161a129f47d294bae1c499f28f18e0460af9b9a228d51be5d2393fb9ff91510b70ae8ffa8bf906a3dfb958768a0220d23db4dc1959f8f439314a291e1"
}