On 06 May (18:19:58), George Kadianakis wrote:
Hello list,
here is a control spec patch for adding v3 client auth commands to add/remove/view clients from the client-side (so Tor Browser -> Tor): https://github.com/torproject/torspec/pull/81/commits/3a26880e80617210b4729f...
I'm currently unhappy with the naming of those commands, and in general with how easy it is to confuse them with the (non-existent) service-side commands. I'm wondering how to name them better so that when we add the respective service-side commands (at some point we should) there is no confusion.
Very nice!
(Replying here so tor-dev@ sees it all and do not miss comments on the PR.)
1. So yes on the naming and a way to highlight service vs client. The command naming scheme on the control port is a bit chaotic and I'm all for one trying to come up with "namespace" a bit better.
HSPOST, HSFETCH, ADD_ONION, DEL_ONION...
We can't change the above but we can at least from now on try to come up with a better naming related to onion services.
Something like:
- ONION_CLIENT_ADD_AUTH - ONION_CLIENT_DEL_AUTH - ONION_CLIENT_LIST_AUTH
I know a bit long but these commands in the end should rarely be typed by a human person anyway.
And if we have service side only commands, we use:
- ONION_SERVICE_...
Not sure we'll ever have a command that applies to both a service and a client... maybe who knows, but then we can either do two commands or just generalized on:
- ONION_ ...
2. We need LIST/ADD/DEL to specifies what code is returned in case of success and error. There can be many errors like "Key blob unparseable" or "HSAddress" is invalid or "a client auth already exists" which I assume for this we will force the user to remove/add instead of replacing.
3. The VIEW_ONION_CLIENT_AUTH, for "Type", I think you need to define this differenlty:
[SP "Type=" TYPE]
and then define TYPE:
TYPE can be: "Permanent" - <description>...
Cheers! David