cuprate
cuprate copied to clipboard
Cuprate
`cuprated` binary
What
This PR will flesh out the skeleton of the Cuprate node application binary.
This includes:
- [ ] Command line argument parsing and documentation (
./cuprated --help) - [ ] Mapping arguments to specific code paths
- [ ] Configuration file (de)serialization
- [ ] CLI & on-disk config mixing and validation
- [ ] Disk permissions/
umaskhandling - [ ] Documentation handling (
./cuprate --docsopens in browser) - [ ] Graceful shutdown at end of
main()and any end hooks (e.g flush data)
It may also include:
- [ ] Logger initialization
- [ ] Initial thread spawning
- [ ] Internal Cuprate initialization (force lazy statics, assert start conditions, define order of processes, etc)
Q/A
Some open design questions that don't have answers yet.
Q = question A = probably the answer but undecided
Q: Binary name?
A: `cuprated`
Q: Default disk permissions?
A: Admin/User read/write on Windows, `umask(027)` or `rwxr-x---` on Unix
Q: With overlapping/conflicting `--cli-flags` and disk configs, which takes precedence?
A: CLI - disk config gets parsed first, then CLI overrides
Q: Config file format?
A: TOML
Q: How is documentation stored/opened by the binary?
A: Similar to rustc: ZIP -> uncompress into `~/.local/share/cuprate` or equivalent -> open
Q: Does the binary handle log init?
A: As we have direct access to `--log-level` and such, it would be easier
Q: Does the binary spawn _all_ threads? (as opposed to spawning a few key ones, which spawn others)
A:
Q: Should `cuprated` be able to parse and use `monerod.conf` (or at least translate it into `cuprate.toml`)?
A: Probably no - even if yes, it's very low priority.
Q: What configurations and `--flags` should `cuprated` support in the first place?
A:
Q: Should `cuprated` directly handle X.509 certificates and keys (and thus HTTPS/SSL)?
A: Yes.
Q: Should `cuprated` write to an on-disk log file or only STDOUT?
A: Both on disk and STDOUT.
Q: Should `cuprated` be able to do local JSON-RPC invocation (e.g `./monerod get_info`)?
A: Probably not.
Q1: Should `cuprated` mix in ENV_VAR's with the CLI/disk config (e.g HTTP_PROXY)?
Q2: If yes, what takes precedence?
A2: CLI > ENV_VAR > disk
Q: Should `cuprated` contain a JSON-RPC HTTP(s) client (that is more user-friendly than curl)?
A: No, should be in `cuprate-cli` if at all.
A possible name of cuprated instead of simply cuprate for the binary was mentioned on Matrix, with d standing for daemon I assume. Here my take on this:
In my view of things what you build here is not the cuprate daemon, but simply cuprate, and thus adding d is unnecessary.
It also makes the binary name uglier, and the pronounciation suddenly is a bit unclear.
What happens if you go on after a roaring success with cuprate and e.g. build a command line wallet app fully in Rust that gives the official CLI wallet a run for its money? Won't there be two things cuprate and qualifying necessary? Well, maybe, but nothing will stop you to come up with a completely new name for that project and app!
I don't like monerod either. Here, with a family of binaries, qualifying makes some sense, but the d at the end makes the binary name unelegant for me. "What kind of rod is this? A metal rod or a wooden rod? Oh, no, it's a mone-rod" :)
cuprated differentiates the specific node binary from the cuprate family of services, which may or may not solely be the node at this time. If cuprated is considered ugly, cuprate-node is the immediate alternative. I do support existence of some suffix (d or -node).
Parsing the existing .conf would be one option, yet offering a cuprate-conf tool to perform the conversion also would.
Inclusion of an RPC client in the daemon sounds like a horrible idea. It crams everything into location without legitimate thought or process. Bitcoin has the dedicated bitcoin-cli tool for such functionality.
For the record I am slightly for cuprated.
cuprate is extremely tempting, but it will undoubtedly cause confusion that we'll have to deal with forever (cuprate the node binary, or cuprate the project?) ... it may be worth it though.
@Boog900 Thoughts on binary name?
I would be for cuprated, for reasons already said: cuprate might not only be a node, differentiates cuprated the node binary from the rest of cuprate but @rbrunner7 does bring up a good point about potential confusion over pronunciation: cup-rated. I do still think cuprated is the better choice especially as we already have monerod. I don't really like the idea of cuprate-node.
I do agree with @kayabaNerve I would rather have an RPC client as a separate binary, if were to be included.
I would also say that parsing and converting monerod.conf should be very low on the TODO list, if there at all, I would say it is unnecessary.
I prefer cuprated. the confusion with cup-rated is funny, the community is already used to it, and people will easily find out what the d means. It could be a dinner topic. just imagine :
Alice: I just learn that cuprated meant cuprate-daemon. Did you know that ?
Bob: - Wow I didn't knew that
So yeah. I prefer cuprated
Q: Should
cupratedirectly handle X.509 certificates and keys (and thus HTTPS/SSL)?
I don't understand the meaning of directly handled ? If the question is Should cuprate support user supplied certificates and keys, the answer is yes.
Q: Should
cupratewrite to an on-disk log file or only STDOUT?
The two. monerod does that, and a lot of projects does that. I would even add that there should be a flag to disable stdout
Q: Should
cupratebe able to do local JSON-RPC invocation (e.g./monerod get_info)?
I don't see a lot of use case beside dev testing. So I would say no, but I might be wrong
A2: probably ENV_VAR > cli > disk
I disagree. Really depends on the option. Logging for example should prioritize disk and cli over env var. Same for http proxy. cli should at least override env var
Q: Should cuprate directly handle X.509 certificates and keys (and thus HTTPS/SSL)?
Some programs simplify internals by relying on an external program to handle encryption, i.e they only expose HTTP since it'll be encrypted via NGINX/Apache anyway. Thinking about it again though, you're right - cuprated needs to handle encryption anyway.
Q: Should cuprate be able to do local JSON-RPC invocation (e.g ./monerod get_info)?
Monero GUI relies on ./monerod rpc_command for retrieving some info.
It would be interesting if cuprated could run in a compatibility mode and act as a drop-in replacement daemon for the GUI, although, it's probably not worth it if implementing/maintaining this is hard.
A2: probably ENV_VAR > cli > disk
You're right I think CLI > ENV_VAR > disk is correct: https://doc.rust-lang.org/cargo/reference/config.html#command-line-overrides.