[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2824: allow `[connections] tcp = none` ?

Tahoe-LAFS trac at tahoe-lafs.org
Sun Sep 4 18:05:15 UTC 2016


#2824: allow `[connections] tcp = none` ?
-------------------------------+------------------------
 Reporter:  warner             |          Owner:
     Type:  defect             |         Status:  new
 Priority:  normal             |      Milestone:  1.12.0
Component:  code-nodeadmin     |        Version:  1.11.0
 Keywords:  anonymity tor i2p  |  Launchpad Bug:
-------------------------------+------------------------
 str4d remarked that you can't set up an i2p-based client without also
 configuring Tor. I don't know the exact problem, but one that I can think
 of is that there are only two legal values for `tcp=` (either the default
 `tcp`, or `tor`), and `--hide-ip` requires that it not be `tcp`. And you
 can' set `tcp = tor` without having `txtorcon` installed.

 I'm wondering if we should add `tcp = none`, which would disable (ignore)
 TCP-based hints entirely.

 I'm undecided about whether `--hide-ip` should set `tcp = tor` or `tcp =
 none` (see #2820). We've discussed having some other client-oriented
 create-node CLI argument that says "I want a Tor-kind-of node", or i2p,
 and if we had such a thing, it'd be a good indicator of what `tcp=` should
 be set to. (if we're also setting up a server node, then the `--listen=`
 argument might be a good indicator of what the user wants from their
 client, or maybe we should go back to having a simple `--tor` or `--i2p`
 argument that says "whatever else I've asked you to do, do it this way").

 It might also be a good idea to update the server-status section of the
 Welcome page to indicate when servers could not be contacted because of
 connection-hint problems. Like an extra status line, below the server-id,
 which shows "no tor plugin" if the FURL has only tor hints but there is no
 tor handler, or "tcp disabled" if the FURL has only tcp hints but tcp has
 been disabled.

 I'm putting this in the 1.12 milestone so we can decide if we want it, to
 make i2p setup better. If we find some other solution, I'm happy to push
 it out to a later release, or not implement it altogether.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2824>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage


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