[tahoe-lafs-trac-stream] [Tahoe-LAFS] #517: make tahoe Tor- and I2P-friendly

[Tahoe-LAFS]

#517: make tahoe Tor- and I2P-friendly
-------------------------+-------------------------------------------------
     Reporter:  warner   |      Owner:  warner
         Type:           |     Status:  new
  enhancement            |
     Priority:  minor    |  Milestone:  1.13.0
    Component:  code-    |    Version:  1.2.0
  network                |   Keywords:  privacy anonymity anti-censorship
   Resolution:           |  i2p tor-protocol usability
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by str4d):

 +1 on simplifying the combinations. Regarding the currently-INVALID
 combinations:

 - I could imagine `control.port+launch` or `socks.port+launch` being used
 as an indicator to try to launch an existing Tor in case it isn't already
 running, but then the semantics are slightly different, because the other
 usages of `launch` imply a new Tor process (which is reasonable given that
 the process is client-only).
   - In I2P's case, running multiple I2P routers on the same machine is not
 recommended; thus `launch` for it **would** mean try to launch an existing
 I2P installation if it isn't already running.
 - Given that you can request the SOCKS port over the control port, the
 only reason for being able to set `socks.port+control.port` would be if
 the user wanted to use separate tor processes for outgoing and incoming
 connections, which I can't see a decent justification for. The `launch`
 flag is irrelevant here.

 I'd certainly recommend making `socks.port` an endpoint descriptor from
 the start, but given that it was mentioned above that `TorClientEndpoint`
 doesn't accept an arbitrary endpoint for the SOCKS port (just a hostname
 and integer portnum), you'd have to parse it regardless.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517#comment:85>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage