[tahoe-lafs-trac-stream] [Tahoe-LAFS] #3888: Handling Tor and i2p in NURLs

Tahoe-LAFS trac at tahoe-lafs.org
Wed Apr 6 18:18:02 UTC 2022


#3888: Handling Tor and i2p in NURLs
--------------------------+-----------------------------------
     Reporter:  itamarst  |      Owner:
         Type:  defect    |     Status:  new
     Priority:  normal    |  Milestone:  HTTP Storage Protocol
    Component:  unknown   |    Version:  n/a
   Resolution:            |   Keywords:
Launchpad Bug:            |
--------------------------+-----------------------------------

Comment (by exarkun):

 Summarizing some further discussion from IRC ...

 There is existing support for having a lot of control over how connections
 are made.  This is in the `[connections]` section of tahoe.cfg and there's
 docs for it.  Essentially, the GBS client should be prepared to use Tor
 even for a "pb://..." NURL because maybe the client is configured to
 prefer privacy-enabling connections even when they are not required to
 reach a server.

 There is other configuration required to be a Tor client but it does not
 belong in NURLs.  It covers, eg, the address of a Tor-ifying SOCKS server
 to which to connect.  This configuration is already supported in the
 `[tor]` section of tahoe.cfg and this is how the GBS client can figure out
 how to create a Tor client endpoint (or `IAgent`) to use.

 Foolscap's I2P support is somewhat more featureful than the `pb+i2p://...`
 example given here.  It accepts mostly-arbitrary key/value pairs in the
 connection hints.  There's room in the `pb+i2p` scheme though - for
 example, in the query arguments.  eg  `pb+i2p://1WUX44xKjKdpGLohmFcBNuIRN-
 8rlv1Iij_7rQ at sdsdfsdfds/jhjbc3bjbhk#v=1&foo=bar`

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


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