[c-lightning] Plugins/passthrough for next version?

[ZmnSCPxj]

Good morning,

An idea I was considering before was to create a daemon that wraps around the JSON-RPC interface.

So there is a separate "command manager" daemon that wraps the plain lightningd JSON-RPC interface and presents its own JSON-RPC interface.

A JSON-RPC client could then set up a pub-sub with the "manager" daemon where it requests to be informed of a command.  It may (re)implement the command or just tap to its arguments (and potentially modify them) or tap to its result (and again potentially modify them).

A "pay" implementation client could then implement the "pay" command. Other clients of the manager could then issue a "pay" JSON-RPC command, which the "manager" would recognize as implemented by the "pay" implementation, and instead of forwarding the command to lightningd, forwards it to the "pay" implementation.  The "pay" implementation could then issue basic commands ("sendpay", "getroute", "waitsendpay") to the manager, which (if not registered by some other client) it forwards to lightningd.

This has the advantages below:

1. It is a separate process entirely, reducing potential problems with sharing memory with lightningd.
2. It is so generic it could be a separate project entirely: any JSON-RPC server could be usefully wrapped by such a manager.
3. Plug-ins can be implemented using any language that has a convenient JSON-RPC library, again as a separate process.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On August 26, 2018 7:40 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:

> Hi all,
>
> With 0.6.1 rc1 tagged, it's time to look forward. One area
> which needs work is making payments and automation: we do pretty well as
> a server, but we're lagging as an actual wallet.
>
> To that end, I want to add "plugins", which the lightning-cli or
> lightningd itself would pass through. These could do their own
> communication with c-lightning in the background).
>
> The first would be "pay" which really doesn't need to be part of
> lightningd (and is quite complex and growing more so); the lower-level
> commands should be (made?) sufficient. Another could be an autopilot,
> which would connect and manage connections. More custom ones should be
> encouraged, too.
>
> There's no reason these need be in C, either. They'll need some support
> to access commandline/config file options and other details, but that
> can be easily implemented.
>
> Feedback welcome!
> Rusty.
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> c-lightning mailing list
> c-lightning at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/c-lightning