David Goulet dgoulet@ev0ke.net writes:
Hi David,
Overall looks good! A few comments inline:
"onions/{current,detached}" No change. This command can support v3 hidden service without changes returning v3 address(es).
Does the control-spec need a note pointing out that you might get some "longer" (v3) addresses?
3.1.3. ADD_ONION
For this command to support version 3, new values are added but the syntax is unchanged:
"ADD_ONION" SP KeyType ":" KeyBlob [SP "Flags=" Flag *("," Flag)] 1*(SP "Port=" VirtPort ["," Target]) *(SP "ClientAuth=" ClientName [":" ClientBlob]) CRLFNew "KeyType" value to "ED25519-V3" which identifies the key type to be a v3 ed25519 key.
New "KeyBlob" value to support the new "ED25519-V3", if specified, will generate a new ed25519 private key.
This might need a couple more details; as-is ADD_ONION can take "NEW:BEST" (which should now return a v3 service?) or "NEW:ED25519-V3" for explicitly asking for a V3 key, or "ED25519-V3:<56 base32 chars>" for adding an already-existing v3 service.
Because client authentication is not yet implemented, the "ClientAuth" field is ignored as well as "Flags=BasicAuth".
I think these should generate a 500-level error (if used for a v3 service) instead of being ignored. That is, if you try to use auth with v3, you get an error.
For this event to support vesrion 3, one optional field and new values are added:
I echo Damian's comments on the positional-arg; making it [SP "DescriptorID=" ] or similar (i.e. an optional kwarg) would mean easier later extending and also it *should* then "just work" with most controller libs already at least as far as parsing goes (because controller libs in general have to accept new, unknown kwargs).
The rest all sounds good to me!
thanks, meejah