Accept I2P destinations

[duck]

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:

3u2mqm3mvcyc27yliky3xnr4khpgfd4eeadhwwjneaqhj25a65ua.b32.i2p

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

[duck]

Recognize base32 I2P destinations.

[duck]

See also #150 about HTTP proxy support for I2P.

[duck]

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

[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).

thanks!

-Brian

[Zooko]

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.)

[duck]

Recognize base32 I2P destinations v2

[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.

[killyourtv]

Patch refactored against 0.6.4.

[Zooko]

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.

[Brian Warner]

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