[tor-dev] RFC: Ephemeral Hidden Services via the Control Port

[meejah]

>From my perspective, the entire point of this feature is to allow
applications to use "the system Tor" (or, at least "some already-running
tor") to put their hidden services on.

(Or, looking at it another way, if you don't want to share a tor
instance with other applications, you can do that easily today -- you
start up a tor, and can use __OwningControllerProcess as you see fit).

The *only* reason that txtorcon by default launches a new tor process
for the "onion:" endpoints is because nothing else will work reliably.

I'd very much like the default to be that it adds a new onion using
Yawning's API. This will still fall back to "launch a new tor process",
but if you know what you're doing you can have a system (or personal)
Tor instance running (with cookie authentication) that can have hidden
services added and removed from it.

Obviously, this will be a lot faster than launching a new Tor (and less
load or DirAuths). As a bonus, Yawning's API is nice and simple (versus
SETCONF, which makes it super easy to nuke all the *other* hidden
services you configured).

What I would expect of people using this feature is that the process
that's "adding the hidden service" is the very same one that's
"providing the service"...

(If you're doing something with a separate nginx or whatever process
running your hidden-service, than you should know enough to be able to
add a couple lines to your torrc and make a normal, "permanent"
hidden-service).

So, in that context, if your application code isn't perfect and might
sometimes crash, definitely the right thing is to nuke the hidden
service. If the app didn't even save its private keys before that
happened, well, too bad.

I guess to put another way: I can't see a use-case to keep the hidden-
service around if the application that added it went away.

-- 
meejah