[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