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

Tahoe-LAFS trac at tahoe-lafs.org
Sat Sep 12 23:16:32 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 daira):

 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.
 >
 > 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 definitely feel like I'm missing something here. If old nodes continue
 to work --with AUTO meaning to autodetect at node startup-- how can the
 Node constructor be completely synchronous and `tahoe start` just have to
 follow the instructions left behind in `tahoe.cfg`?

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


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