rich1.0Christian Decker [ARCHIVE] (npub1wt…gtuyn)https://yabu.me/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://yabu.me📅 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