[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:  ioerror
         Type:           |     Status:  new
  enhancement            |  Milestone:  undecided
     Priority:  minor    |    Version:  1.2.0
    Component:  code-    |   Keywords:  privacy anonymity anti-censorship
  network                |  i2p tor-protocol usability
   Resolution:           |
Launchpad Bug:           |
-------------------------+-------------------------------------------------

Comment (by str4d):

 Replying to [comment:29 warner]:
 > From today's meeting, we're aiming for a static approach, in which all
 allocation (of hidden services and regular TCP ports) takes place during
 the execution of `tahoe create-node`, and the runtime code (`tahoe start`)
 just has to follow the instructions left behind in `tahoe.cfg`.
 >
 > This would simplify Tahoe's main `allmydata.node.Node` constructor to be
 completely synchronous, removing the awkward code that waits for the Tub
 to start running before it can register FURLs for whatever services are
 being exposed.

 This all fits well with I2P too. Like dawuud has said elsewhere, it's easy
 to have a static HS / Destination, and let Tor / I2P handle the network
 side. An I2P Destination can be set up automatically in the same way that
 a Tor HS now also can be, although right now `txi2p` assumes a running
 router. It wouldn't be hard to implement an auto-start feature for a
 configured router location, but this is usability semantics that is
 irrelevant to the current approach.

 >
 > It would force server operators to choose a TCP port and a connect-hint
 hostname (or IP address) when they create the server (or modify the config
 file). New nodes would no longer use IP-address autodetection (but old
 ones would continue to work).

 I'm ambivalent on this, so whatever makes it easier for you. I tend to
 think that servers aren't really going to be moving around too much, and
 it's obvious enough to the sysop when they do and this breaks, and simple
 enough to fix.

 >
 > The necessary tasks (many of which can be parallelized) are:
 >
 > * Get http://foolscap.lothar.com/trac/ticket/236 done
 > * Move the controlport/logport to a separate Tub, with its own private
 key, defaulting to only listening on 127.0.0.1 with a dynamically-
 allocated port, and add some config knobs to control this
 > * Replace the remaining `Tub.setLocationAutomatically()` (in the
 keyserver and stats-gatherer) with something else
 > * Replace the asynchronous IP-address-autodetect code used when
 `tub.location=AUTO` with a synchronous form (using stdlib's `subprocess`
 module). Move this call from `Node._setup_tub` into `Node.create_tub`,
 which runs during the constructor. Move the `Tub.setLocation` up there
 too. Replace `when_tub_ready()` with synchronous calls, and remove the
 whole async `_startService` method.
 > * change `tahoe create-client` to make a tahoe.cfg that doesn't listen
 on anything
 > * change "tahoe create-node" to require --listen and --location
 > * change "tahoe create-node" to handle the new Tor arguments, once we
 figure out how they should be spelled

 The mailing list post referred to a bunch of Tor-specific arguments.
 Functionally, I assume the Tor-specific arguments will be passed to the
 Tor plugin, the I2P-specific arguments will be passed to I2P, etc.

 I think from a usability perspective we need to make sure it is obvious to
 the user which arguments do what (the `--tor-*` arguments definitely
 achieve this), but also we don't want to overwhelm the user with
 configuration options. I can see at least the following distinct setups
 being viable:

 * Clearnet-only
 * Tor-only
 * I2P-only
 * Tor + I2P

 and potentially:

 * Clearnet + Tor
 * Clearnet + I2P
 * Clearnet + Tor + I2P

 The `--tor-only` and `--listen-on-tor` -style arguments IMHO aren't going
 to scale nicely. I don't expect more than Tor and I2P realistically (in
 the near future), but if each combination is being given its own flag...
 Maybe instead there could be a single `--listen-on=` argument that takes a
 comma-separated list of plugin identifiers, ie. `--listen-on=tcp,tor,i2p`.
 This would also then simplify the logic for plugin-specific arguments:
 `--PLUGINIDENTIFIER-*` gets passed directly to `PLUGIN`.

 > * add Tor support to the main tahoe runtime: launch the Tor executable
 if necessary, configure and install the Foolscap plugins if necessary

 * add I2P support to the main tahoe runtime ;)

 > * finally remove the code that writes to Node._portnumfile
 >
 > We also need to figure out the override-specific-servers mechanism (to
 use TCP for some whitelisted servers, even though we're using Tor for
 everything else). I think this will involve a Foolscap plugin that can
 either use Tor or TCP for TCP hints, depending upon some lookup function
 that it calls at runtime.

 Again, this needs to be planned to handle more than just Tor.

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