Christian Decker <decker.christ...@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. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
