Opened 14 years ago

Last modified 7 years ago

#151 new enhancement

Accept I2P destinations

Reported by: duck Owned by: duck
Priority: minor Milestone: undecided
Component: network Version: 0.5.0
Keywords: i2p transport review-needed i2p-collab Cc: Zooko, zooko@…, killyourtv@…

Description (last modified by Brian Warner)

To be able to use I2P with Foolscap (see #150 and Tahoe-LAFS #1007, I have extended decode_location_hint to accept I2P base32 destinations. Since I2P destinations can't have a port as part of the location, the current IPv4 regex doesn't work.

These I2P destinations look like this:


They have the format: base32_encode(sha256_hash) + ".b32.i2p"

Attachments (3)

151_i2p_destinations.txt (1.1 KB) - added by duck 14 years ago.
Recognize base32 I2P destinations.
151-accept-I2P-destinations.patch (2.6 KB) - added by duck 13 years ago.
Recognize base32 I2P destinations v2
151-accept-i2p-destinations.patch (3.5 KB) - added by killyourtv 10 years ago.

Download all attachments as: .zip

Change History (15)

Changed 14 years ago by duck

Attachment: 151_i2p_destinations.txt added

Recognize base32 I2P destinations.

comment:1 Changed 14 years ago by duck

See also #150 about HTTP proxy support for I2P.

comment:2 Changed 14 years ago by duck

Keywords: review-needed added

Please review if you agree with the approach in general. Your suggestion how to unit test would be most welcome!

comment:3 Changed 13 years ago by Brian Warner

Hm.. not a bad approach overall. Two thoughts though:

  • our plan for adding new protocols was to use a "name:" prefix, rather than relying on regexps to glean protocol information out of an otherwise-identical-looking string. So something like {{{if hint_s.startswith("i2p:")}}} rather than the regexp
  • the hint type would then be used by the connection code you patched in #150 to decide that it needs to make an I2P-proxied connection instead of the normal kind. The http-proxy option would only get used for these connections.

Hm, the second part makes me realize that the #150 patch has problems: once you've set that http-proxy option, that Tub can no longer make connections to non-I2P addresses, which would be unfortunate (I'd want to be able to connect to both kinds of nodes, assuming that I2P addresses are like Tor .onion addresses: protecting the anonymity of the server more so than the client).

So yeah, use the connection hint to discover that you're using the "i2p:" protocol (which is a lot like the regular foolscap protocol, except that the initial hello message has some extra "http.." letters in it, and the connection is made to a tub-option-level proxy instead of by doing DNS resolution of the connection hint's address), and then let the Negotiation connection-making code deal with the variations.

The unit test should demonstrate that a Tub with the i2p-proxy option set can still connect to regular connection hints, and ideally that a FURL with two hints (one I2P, one normal) that it can connect to either type (by invoking Tub.getReference while the proxy is running but the normal listener is not, and then again vice versa).



comment:4 Changed 13 years ago by Zooko

Owner: set to duck

duck: are you still interested in updating this patch in order to get it ready for inclusion in foolscap? (Sorry about the long delay between your initial offering and this modern feedback.)

comment:5 Changed 13 years ago by Zooko

Keywords: review-needed removed

comment:6 Changed 13 years ago by Zooko

Cc: Zooko zooko@… added

Changed 13 years ago by duck

Recognize base32 I2P destinations v2

comment:7 Changed 13 years ago by duck

Brian's suggestion to use the name: prefix (i2p:) has been taken. Detection based on the ".b32.i2p" postfix has been deprecated; it can be dropped after the entire I2P Tahoe-LAFS network has upgraded to Tahoe-Lafs 1.8.1 and Foolscap 0.6.0.

I disagree with deciding to use link the http proxy usage to detecting the address being for i2p. This would allow for de-anonymizing attacks.

Unit tests have been written as well.

Changed 10 years ago by killyourtv

comment:8 Changed 10 years ago by killyourtv

Cc: killyourtv@… added

Patch refactored against 0.6.4.

comment:9 Changed 10 years ago by killyourtv

Keywords: review-needed added

comment:10 Changed 10 years ago by Zooko

Keywords: i2p-collab added

Adding the i2p-collab tag, which is the same spelling used on the Tahoe-LAFS trac to indicate a ticket that is currently blocking the I2P project from using trunk.

comment:11 Changed 8 years ago by Brian Warner

Component: unknownnetwork
Description: modified (diff)

comment:12 Changed 7 years ago by Brian Warner

I think we can close this now, with the i2p support in the last few releases. Any objections?

Note: See TracTickets for help on using tickets.