[Cuprate](https://github.com/Cuprate/cuprate) is an alternative Monero node implementation.
The next section that needs work is the RPC handlers. The design, interface, routing, types, and (de)serialization were completed in my previous CCS, see here:
- Past CCS: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/456
This CCS is for the handlers, i.e. the functions that turn requests into responses.
Once the handlers are complete, Cuprate will have a working RPC stack that [mostly](https://architecture.cuprate.org/rpc/differences/intro.html) mirrors `monerod`.
The 1st/2nd milestones are for the RPC handlers. This is the majority of the work.
This includes:
- JSON RPC handlers (methods behind `/json_rpc`)
- Binary RPC handlers (binary endpoints, e.g. `/get_blocks.bin`)
- Other handlers (other JSON endpoints, e.g. `/get_height`)
The RPC handlers will most likely be in its own library/section, built on-top of the RPC libraries Cuprate has so far. The current RPC interface library ([`cuprate-rpc-interface`](https://github.com/Cuprate/cuprate/tree/main/rpc/interface)) allows for custom handlers, as in, the mapping of `request` -> `response` can be customized. The handler created in this CCS will be a standard implementation that (mostly) follows `monerod`'s behavior, i.e. request comes in, get some data from the database and such, return a response. Although, other implementations are possible, such as an RPC handler that caches blocks, as mentioned in [this meeting](https://github.com/monero-project/meta/issues/996#issuecomment-2086710102).
Testing, [crate (library) documentation](https://doc.cuprate.org), and [architecture book](https://architecture.cuprate.org) sections will also be written.
### Binary strings
There are a few RPC methods that require further discussion before implementation in Cuprate, see the [binary strings proposal](https://github.com/monero-project/monero/issues/9422).
If the above proposal finds consensus on future `monerod` behavior, this CCS will implement that behavior.
If more time is required for the proposal, the related endpoints/methods will be left in a semi-unfinished state until behavior is agreed upon, where after Cuprate will implement that behavior.
If the proposal does not move forward, Cuprate is planning to fallback to implementing `monerod`'s current behavior.
## Other work
The 3rd milestone is for any miscellaneous work that needs to be done for Cuprate, but also, these 2 concrete things:
- Lints
- Benchmarking
I'd like to focus on these as:
- If they're always pushed to the side, they'll never get done
- I believe it's important to establish these early on in the project
I started integrating lints & benchmarks into Cuprate last CCS, this CCS will finish integrating them for all the libraries I've written so far, and [other libraries](https://architecture.cuprate.org/appendix/crates.html) if time allows.
The issues tracking the progress of these two can be found here:
