~The handling of the crud endpoints for chifra names is significantly over-complicated. Two quick examples. (Much of it is due to the original C++ code being overly complicated, so please read this as a criticism of my own code). A few examples:~
~We distinguish between custom and non-custom names. This is needed (to protect the end user from accidentally revealing names but we don't need to store these two identical data sets in a different file. A simple boolean flag would suffice. One of the reasons for doing it with two files was so we could simply install our own names database without worrying about over-writing. We could have easily done this in other ways.~
When processing CRUD data, we overcomplicate with a Generic Value|Updated crudData type. But we should instead simply use the Name type directly, pre-load it with any existing data, and overwrite any non-empty values with the updated data. No need to check anything. Just load the existing name, overlay with new data, write the Name using a cache.
In the C++ code, we used a binary cache with fixed width fields. Very fast. That got lost in translation to Go code.
We never properly handled searches for ENS names reporting both and error and the located record (try it with chifra names trueblocks.eth
We never should have stored the names database in the repo. It should always have been stored as an IPFS pin in the Unchained Index Smart contract. Always available. Always up to date. No distribution problem. Gives a path for other users to publish their own list of names.
Upshot:
Re-write with better testing including testing using a simple web interface.
~The handling of the crud endpoints for chifra names is significantly over-complicated. Two quick examples. (Much of it is due to the original C++ code being overly complicated, so please read this as a criticism of my own code). A few examples:~
chifra names trueblocks.ethUpshot:
Re-write with better testing including testing using a simple web interface.