Yea sure. It’s nothing crazy right now but it’s a start. I’ll offer some background on why it’s relevant and where it could go , and then I’ll say what I actually did. There’s a thread here if your interested on following the progress.
TLDR:
It’d be cool if we humans could issue commands to make a running node do interesting things (that don’t involve dying). I proposed a proof-of-concept that might solve that, and maybe help in improving existing code… maybe… 
Background:
The idea was kind of born of the fact that most of the tools/commands for doing things with nodes are pretty course-grained right now. For example, you can run or kill a node from the cli, but you can’t do something more complicated like collect statistics. That’s because there isn’t a good interface yet for when you’re looking from the outside, into the node. If nodes were houses on a street, it would be like not having doors or mailboxes on the houses. They do their thing while they run, but there’s not much you can do to communicate with whoever’s inside.
The commands we do have operate on the node itself or on the environment surrounding it. In the case of kill, It doesn’t work with the node (i.e. telling it to shutdown nicely), it operates on the node process (i.e. kill just tells your operating to go out axe the process at whatever stage of running it’s in). In the house analogy, it’d be like knocking down the house to tell your tenants the lease is up.
Despite everything, this approach works reasonably well for the most part, but it has some obvious drawbacks. One is that the node needs to be prepared to die at any moment, because there’s no clear path for things like shutting down, so designing error handling becomes trickier. Beyond that, it would be cool to collect things like logs from the node, or collect usage statistics for improvement, fetch debug information, etc.
This is something that’s been talked about before, but hasn’t ever been fully addressed to my knowledge.
What the Async Server Example does
Given that as an ultimate goal, the program I wrote is a proof-of-concept mostly. The idea is to use the same library that the authenticator currently uses (called qjsonrpc, which is in the sn_api repo) to build a mailbox of sorts for the node to accept incoming commands. The node and the authenticator are different enough, though, that it’s not a copy-paste job to make a node accept commands like the authenticator.
The async server example does two things. First, it provides, well, an example usage of qjsonrpc. In general, that could be handy to other developers looking to use it one day. It also might help to highlight some areas for refactor and enhancement in the qjsonrpc library itself (actually, that’s what my little contribution last week was about). Secondly, it shows how you might build a scheme that the node could use to accept commands, in a manner similar to authd, without requiring massive modification to the existing node’s code structure.
Where to Next
Well, technically this hasn’t even been merged yet and it’s just a PoC, so I’m talking hypothetically, assuming the patch isn’t rejected outright 
Next though I want to take some of the learnings from creating this little example program and maybe use it to propose some further enhancements to qjsonrpc. If the dev team comes to the conclusion that this PoC might be a good model for the node to accept commands, then maybe work could commence on implementing it in the node.
On a related note, there are some conceptually similar things between commanding authd and a node process, so I’m particularly interested in maybe making the command interface generic enough that it could be used for both the authenticator and the node. It’d be cool because then really only one implementation would need to be maintained, and would cut down on existing code in the authenticator (as well as any future implementers of the system), which is rarely a bad thing in software.
One step at a time though. For now, I really just wrote a PoC.