{"type":"rich","version":"1.0","title":"Christian Decker [ARCHIVE] wrote","author_name":"Christian Decker [ARCHIVE] (npub1wt…gtuyn)","author_url":"https://yabu.me/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2022-01-19\n📝 Original message:\nHi Will,\n\n\u003e I noticed you are doing RPC stuff... I'm looking to do RPC over\n\u003e lightning itself. I started a C library called lnsocket[1], scrounged\n\u003e from clightning parts, so that I can send messages from iOS to control\n\u003e my lightning node.\n\nSounds interesting, and similar to commando's goals. Rusty also has a\nsummer of bitcoin project attempting to expose a websocket directly to\nbrowsers in order to provide another way to communicate with your node,\nand of course there's commando.\n\n\u003e I've got to the point with lnsocket where I can send TLVs to my node,\n\u003e and now I'm starting to think about what format the RPC commands should\n\u003e be.\n\u003e\n\u003e I noticed the commando c-lightning plugin just uses the JSON-RPC\n\u003e payload, but perhaps something more compact and rpc-friendly like grpc\n\u003e would be better... which is why this cln-grpc PR peaked my curiosity.\n\nYep, JSON-RPC is rather bad with binary data, and doesn't have any\nconcept of streaming. I personally like grpc because it ticks a lot of\nboxes: secure transport over TLS, mutual authentication via mTLS,\npossibility to add metadata to calls (technically prohibited by the\nJSON-RPC spec) which can help us use macaroons/runes in future,\nstreaming support and compact binary format.\n\nHaving an IDL to describe the interface is also rather nice, even though\nfor cln-grpc we actually generate that from the JSON-RPC schemas, so\nit's a bit less expressive than .proto files.\n\n\u003e I think the end goal of an RPC bolt would be super powerful, so that\n\u003e lnsocket could talk to any lightning node, but that could be further\n\u003e down the line. Choosing the right data format seemed like an important\n\u003e step in that direction. Would love to hear your thoughts on this!\n\nI agree. Exchanging the transport layer underneath grpc doesn't change\nsemantics, but does unlock a number of potential use-cases. I think\neither the JSON-RPC or grpc can serve as a basis for a common RPC\ndefinition that can have any number of bindings, since we generate\nconversion code to/from JSON-RPC and grpc we can transparently map them\nback and forth.\n\n\u003e I've cc'd clightning/lightning-dev as well to see if anyone else is\n\u003e working on this or thinking about this stuff right now.\n\nDefinitely open to suggestions, comments and criticism: the cln-grpc [1]\ncrate is rather new, and will see a number of rebases and fixups, but\nshould be reviewable as is. The cln-plugin [2] crate is a bit less\nwell-fleshed-out, but has the core functionality needed for\ncln-grpc-plugin which was the goal of this first exploration. The\ncln-rpc [4] crate is also missing many RPC commands, but that's just\ngrunt work that I plan to tackle separately :-)\n\nCheers,\nChristian\n\n[1] https://github.com/ElementsProject/lightning/pull/5011\n[2] https://github.com/ElementsProject/lightning/pull/5012\n[3] https://github.com/ElementsProject/lightning/pull/5013\n[4] https://github.com/ElementsProject/lightning/pull/5010"}