Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add a `sendcustommsg` RPC call and a `custommsg` plugin hook for experimental protocol extensions #3315
This pull request implements the
The limitations mentioned above aside, this PR opens a wide variety of
darosior left a comment
Looks good, but answering the open question I'd argue for
Good point, however I get the feeling we might end up confusing people, and they might think this is to send some sort of chat message to an arbitrary node. It's more of a "don't show a normal mortal what they aren't supposed to use" kind of deal :-)
Maybe rename to
Let's keep it a developer-only option for now, and see if my fears of causing confusion is justified. If it is we can always rename while making it non-dev-only :-)
These messages may be exchanged between the master and any daemon. For now these are just the daemons that a peer may be attached to at any time since the first example of this is the custommsg infrastructure.
This is currently in opening_control since that's the only part that has access to the uncommitted_channel internals. Otherwise it's independent from the specific daemon.
This command injects a custom message into the encrypted transport stream to the peer, allowing users to build custom protocols on top of c-lightning without requiring any changes to c-lightning itself.
We cannot let users use `sendcustommsg` to inject messages that are handled internally since it could result in our internal state tracking being borked.
This solves a couple of issues with the need to synchronously drop the connection in case we were required to understand what the peer was talking about while still allowing users to experiment, just not kill connections.
This is mainly meant as a marker so that we can later remove the code if we decide to make the handling of custommsgs a non-developer option. It marks the place that we would otherwise handle what in dev-mode is a custommsg.
This completes the custommsg epic, finally we are back where we began all that time ago (about 4 hours really...): in a plugin that implements some custom logic.
It's a dev-* command for now, but better document it so people can use it rather than having them guess how it's supposed to work.