Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2022-01-19 📝 Original message: Hi Will, > I noticed you ...

📅 Original date posted:2022-01-19
📝 Original message:
Hi Will,

> I noticed you are doing RPC stuff... I'm looking to do RPC over
> lightning itself. I started a C library called lnsocket[1], scrounged
> from clightning parts, so that I can send messages from iOS to control
> my lightning node.

Sounds interesting, and similar to commando's goals. Rusty also has a
summer of bitcoin project attempting to expose a websocket directly to
browsers in order to provide another way to communicate with your node,
and of course there's commando.

> I've got to the point with lnsocket where I can send TLVs to my node,
> and now I'm starting to think about what format the RPC commands should
> be.
>
> 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.

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.

> I've cc'd clightning/lightning-dev as well to see if anyone else is
> working on this or thinking about this stuff right now.

Definitely open to suggestions, comments and criticism: the cln-grpc [1]
crate is rather new, and will see a number of rebases and fixups, but
should be reviewable as is. The cln-plugin [2] crate is a bit less
well-fleshed-out, but has the core functionality needed for
cln-grpc-plugin which was the goal of this first exploration. The
cln-rpc [4] crate is also missing many RPC commands, but that's just
grunt work that I plan to tackle separately :-)

Cheers,
Christian

[1] https://github.com/ElementsProject/lightning/pull/5011
[2] https://github.com/ElementsProject/lightning/pull/5012
[3] https://github.com/ElementsProject/lightning/pull/5013
[4] https://github.com/ElementsProject/lightning/pull/5010