From jb55 at jb55.com Mon Jan 24 15:33:32 2022 From: jb55 at jb55.com (William Casarin) Date: Mon, 24 Jan 2022 07:33:32 -0800 Subject: [Lightning-dev] Lightning RPC In-Reply-To: <87lez5zugu.fsf@rustcorp.com.au> References: <20220118154645.5y6uwmet7kbtikkl@quiver> <87zgnsj8kf.fsf@gmail.com> <87lez5zugu.fsf@rustcorp.com.au> Message-ID: <20220124153332.sv5vuan2d57rdeon@quiver> On Mon, Jan 24, 2022 at 01:54:49PM +1030, Rusty Russell wrote: >Christian Decker writes: >>William Casarin writes: >>> I think the end goal of an RPC bolt [blip] 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! I ended up just using json+commando for my prototype[1]. I'm not going to overengineer anything yet. If there's a way write plugins for the other implementations I could start hacking away at a common control subset, since I do eventually want an iOS app that controls all node implementations. I will try to get something working across multiple implementations before writing up a spec. Cheers, Will [1] http://git.jb55.com/lnsocket/file/rpc.c.html