Interface for external clients

[josibake]

Off the top of my head, we currently have a Rest HTTP server, an RPC interface, ZMQ, an IPC interface, and (potentially) a kernel API that allows access to the internals of a running node. Ideally, we slim this down to one.

Whatever interface chosen should support the following clients:

• indexers
• wallets
• gui (node and wallet)
• remote control? eg invalidate block, generate block
• testing hooks
• bridges to other interfaces (e.g. http)

For each of the users mention, you can imagine both a local and remote version. Another consideration is the interface should support access in a language agnostic form, e.g. a python script for collecting some metrics about block data, a rust tui for monitoring the node, a C++ wallet + Qt GUI.

Given all of that, of the existing interfaces which makes the most sense? Or is there a better way of doing this not considered yet?

[josibake]

For mining, one requirement is push based mechanism. Currently, sv2 is using IPC because it needs the node to push a new template (better fees) as soon as its available. Prior to this mining was using a poll based mechanism via the getblocktemplate RPC.

[josibake]

Worth mentioning, wallets, guis, and indexers would also benefit from a push based mechanism, e.g. new block added to chaintip, but I wouldn't list this as a requirement given that polling on a 5-10sec interval is more than sufficient and immediate updates is not critical (unlike mining).

[josibake]

see #24

[janb84]

Imho, the best course of action would be to enrich IPC interface and move the other interfaces (if still used) to "IPC bridges" .
"The" external interface with the node would become IPC.

If there is need for a REST interface, create a IPC to REST bridge. Keeping it modular, separated and isolated.

In the case that IPC is superseded with something new, create an "something new to IPC" bridge creating a clear upgrade path with backwards compatibility.

[josibake]

Excellent. This approach also allows IPC bridges to be written by clients that don't want to fully refactor away from X old interface. They can write and maintain their own translation bridge. We, of course, can also provide bridges in the project but only when truly necessary.

One concern I have with IPC today is it doesn't feel like we are using CapnProto in an idiomatic way. I suspect this will hurt the usability of the IPC interfaces. But its also unclear if its worth it/possible to start rewriting it. I do suspect that cleaner, more idiomatic CapnProto will make it easier to use and maintain in the long run.