[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