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

Tahoe-LAFS trac at tahoe-lafs.org
Tue Sep 15 22:41:48 UTC 2015


#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 warner):

 The current trunk behavior (established in 1.10.1 from 15-Jun-2015) looks
 like:

 * `#tub.location=`: same as `tub.location = AUTO`. This is the `create-
 node` default.
 * no `tub.location` in the config file at all: same as above
 * `tub.location = AUTO`: use just the autodetected address
 * `tub.location = hint1,AUTO,hint2`: use three hints, replace AUTO with
 autodetected address
 * `tub.location = hint1`: use an explicit hint, disable autodetection
 * `tub.location =`: use no connection hints at all

 Does that change your question? I was claiming that `tub.location=` will
 *disable* autodetect, and your question sounded like you wanted it to
 *enable* autodetect. Are you maybe looking for a `tub.location = DON'T
 LISTEN ON ANYTHING` sort of explicit flag, to avoid the subtle confusion
 between `tub.location=` and `#tub.location=`?

 To avoid breaking existing nodes, we're stuck with `#tub.location=`
 meaning autodetect. Currently, `tahoe create-client` and `create-node`
 write `#tub.location=` into the new tahoe.cfg file, but we can change that
 without impacting compatibility.

 I'm cool with making don't-listen the default. I'm slightly less cool with
 adding an explicit don't-listen token (but not totally against it),
 because then we'd be scanning the config file for two different special
 values, increasing potential problems for things like "what if my actual
 hostname matches the special value", etc. But maybe an explicit negative
 token is clearest / most-usable option.

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


More information about the tahoe-lafs-trac-stream mailing list