Regarding the API / interface for communicating client-keys for hidden- services .. I thought we were encouraging ADD_ONION based services?
Personally, I think using the filesystem as "an API" isn't very good. From a controller standpoint, it's *way* simpler to use ADD_ONION properly than on-disc services (i.e. via SETCONF) because directory permissions, file permissions etc have to line up and it's not immediately clear if the files will always for-sure be on-disc when the SETCONF command says OK. (Also, you have to deal with the one-shot nature of SETCONF and order-matters configuration options)
On the disadvantage side, this means any applications using these services are then responsible for their own key-management.
In any case, something like growing an "ADD_ONION_CLIENT" command or similar might be way easier to understand and implement.
A flow might look something like this:
- client creates a key(/pair) in tor-browser or whatever - client sends it to service operator ("exercise to the app-developer"?) - operator uses their controller to run "ADD_ONION_CLIENT" - ??? - profit!
Definitely out-of-scope for "ng hidden-services", but it would also probably be nice to have more separation in the control-protocol. Right now, you get the authority to do anything at all -- but maybe you'd like to give an application *just* the authority to "add hidden services and/or clients". You can use a control-port-filtering thing (e.g. roflcopter) to get something like this, but ... not ideal (and not really the same as being able to grant limited authority to an application).
I'm thinking here of scenarios where you have an application that wants to "use Tor" to do service-stuff -- so "just edit the config" isn't a satisfying answer at all. Also, having every app launch its own Tor instance (which is about the only answer currently) seems bad.