RPC for downstream users to test whether data is standard

[yanmaani]

Namecoin has a few rules regarding names:

• Names (keys) must begin with a valid prefix (presently "d/", "dd/", or "id/")
• The non-prefix tail of the name, if any, must validate by the rules for the namespace (e.g. for "d/example", "example" must match /^(xn--)?[a-z0-9]+(-[a-z0-9]+)*$/ AND not match /^[0-9]*$/.)
• Values must be valid JSON
• Values must not contain tabs or certain other characters
• Values should be compact
• Keys in the JSON map should be valid keys by the standard of the namespace (e.g. "tor" is valid, "asd" isn't)
• Values of the JSON map should be valid by the standards of their key with respect to their namespace (e.g. Tor onions must have valid checksum, DNS names must be FQDN in some places)

(I'm sure I got some of these wrong)

These rules are non-trivial, not really collected anywhere, and liable to change. It would be nice to have an RPC that can validate the data. Downstream users might want it, we could use it for GUI purposes and to warn people when trading, and it would do double duty as documentation.

Here's my rough proposal, which I think could be improved by a lot:

name_isstandard name D/name -> {"rc": "error", "info": {"type": "name", "details": "prefix unknown"}
name_isstandard name D/NAME -> {"rc": "error", "info": {"type": "name", "details": "prefix unknown"} (Without a prefix known, the validation rules for the key can't be further known)
name_isstandard name d/NAME -> {"rc": "error", "info": {"type": "namevalue", "details": "invalid name for namespace"}
name_isstandard name d/name -> {"rc": "ok"}
name_isstandard value {} d/ -> {"rc": "warn", "info": {"type": "value", "details": "no valid keys"} (This is standard, but maybe not what they want)
name_isstandard valuekey d/ tor -> {"rc": "ok"} ("tor" is valid in "d/" namespace)
name_isstandard valuekey d/ asd -> {"rc": "warn", "info": {"type": ["valuekey", "asd"], "details": "key unknown"}} (This is invalid, but it doesn't make the name as a whole invalid)
name_isstandard valuevalue expyuzz4wqqyqhjn.onion d/ tor -> {"rc": "ok"} (In the future, we may want to deprecate v2 onions, but that would make this example unwieldy)
name_isstandard valuevalue xxxxxxxxxxxxxxxx.onion d/ tor -> {"rc": "warn", "info": {"type": ["valuevalue", "tor"], "details": "onion checksum error"}} (This is invalid, but it doesn't make the name as a whole invalid)
name_isstandard value '{"tor": "expyuzz4wqqyqhjn.onion"}' d/ -> {"rc": "warn", "info": {"type": "value", "details": "whitespace"}} (This is discouraged)
name_isstandard value '{"tor":"xxxxxxxxxxxxxxxx.onion"}' d/ -> {"rc": "warn", "info": {"type": ["valuevalue", "tor"], "details": "checksum error"}} (Specify where the error is by returning an array for type)
name_isstandard value '{"tor":""}' d/ -> {"rc": "error", "info": {"type": ["valuevalue", "tor"], "details": "no suffix"}}
name_isstandard value '{"tor":"x.onion"}' d/ -> {"rc": "error", "info": {"type": ["valuevalue", "tor"], "details": "validation error"}} (This would be used for http://valid.onion, valid.onion., etc)

If there's an error in some part, the error message should be the same whether observing the erroneous part in isolation or the value as a whole.

If there's multiple errors/warnings, it should either return one in an unspecified manner or return an array in info ("info": [{}, {}]). If there's both errors and warnings, I think it should just return the errors, because otherwise you might get cascade problems (D/ is invalid, and there's no valid keys for the D/ prefix).

Errors should roughly correspond to "show an error message and block the user from registering it unless he overrides it manually". Warnings should roughly correspond to "show a yellow triangle".

It shouldn't need to point out which specific part is in valid with helpful red lines, this isn't a spell checker.

This is going to be a lot of very mundane dev work, just to implement all the rules. It is probably going to be able to be used it in a lot of places though.

It would probably be good to standardize the strings for "details" somewhere. The idea is that even if the string is unknown, it should get a rough outline by the rest of the error message.

[domob1812]

Sounds good to me, although especially with the value checker (which in your post seems to be specific to .bit) we should be careful to have it as separated from the core code as possible. E.g. have all verification logic in a separate .cpp file at least. Probably this should also be coordinated with @JeremyRand 's efforts to port the name configuration UI (which it probably is already between you two anyway).

[JeremyRand]

FYI I started implementing validation for names (not values) since I need that for the name management GUI. Haven't gotten very far yet, but should have something in a few days if all goes well. I'm not sure I see the need for separate "error"/"warning" severities, or the need for the "valuekey"/"valuevalue" validation modes. I think the API would be a lot simpler if this method just accepts a name and a value, and validates both of them according to the namespace implied by the name. @yanmaani can you elaborate on why the complex API is actually needed?

E.g. have all verification logic in a separate .cpp file at least.

@domob1812 I'm putting all of this validation code in names/applications.cpp, so it should be easy to exclude that file from downstream projects like Xaya, so you won't have a mishap like happened in Electrum-NMC's names.py.