Fwd: removing IP-address autodetection, Tor integration

[David Stainton]

yay! i'm excited for this native Tor integration project.

The default Tahoe-LAFS+Txtorcon behavior will persist hidden service
key material to a private client config directory... however I'm sure
that ephemeral storage nodes would easily be possible as well;

I envision ephemeral Tahoe-LAFS onion service nodes would be
configured as such via a combination of a tahoe.cfg setting specifying
a ephemeral=True listening endpoint paramater as well as SystemD unit
files that caused the periodic restart of the Tor and Tahoe-LAFS
processes.

Anyway aside from epemeral HS... I was thinking that ideally the
Tahoe-LAFS user would select whether to launch a new tor process or to
use an existing tor process. Either the location of tor would be known
or guessed... or the socks port and control port must be known... and
we'd also want to provide the location of the tor control port cookie
auth file.

Qubes users for instance might want their laptop's instance of
Tahoe-LAFS to run in a separate vm from the vm running tor. Other
users might not care as much and prefer the convenience of
auto-launching tor.

Further I think by default weather the user is using the auto-launched
tor process or a preconfigured tor process.... client Tor connections
and onion service connections should utilize the same tor process.

We'll be using our own "transport plugin" system for Foolscap... and
each of these transport plugins will utilize client and server
endpoints. However, we won't be limited by the endpoint options
exposed to the Twisted endpoint parser plugin system... because of
using our own plugin system... we can instantiate endpoint objects
however we want; with or without the help of the endpoint parser
plugin system.