kayabaNerve
commented
3 years ago Apparently, there isn't a HTTP server available.
Nim's standard library ships with one, yes, yet it doesn't work with chronos. It is technically possible to run both async runtimes at the same time (by manually stepping one; we can't call runForever), yet it's a really bad 'solution'.
Status does have a bounty open for one (https://github.com/status-im/nim-chronos/issues/76), and it does have a reply. That said, the reply is not only for an unfinished library, but also one that doesn't meet the necessary quality requirements, unfortunately.
Status's JSON RPC library does have a HTTP server, despite their README saying otherwise, and it is used in their Eth2.0 node. That said, we'd have to fork it if we wanted to do authentication via it, or even IP-lock, as it doesn't expose any of that info.
We could also write our own impl, yet that sounds like a recipe for bugs and added hours. It may be worth it given what's in front of us though...
Speaking of authentication, I'd also like to handle that in this issue. There are a few HTTP auth protocols (basic, used by BTC, digest, used by XMR), yet an IP-lock would be the simplest solution for now. I have had requests to leave the RPC open, so anyone can ask for info from nodes, so we could always only IP/auth-lock certain methods.
While I am happy with the decision to use JSON-RPC 2.0, despite the routes having their own annoyances that should be re-tooled (notably use of arrays for arguments), running directly over TCP is horrible.
This decision was made when I first wrote the RPC as I dislike HTTP very much. Beyond the bloat of a compliant HTTP server, all responses must be ordered like their requests. This means the ID field of the JSON-RPC 2.0 spec is completely unused, and any request's response must wait for previous requests to finish, even if it's ready.
That said, despite these two technical benefits, breaking compatibility is so brutal this cannot at all be described as a good decision.