I2P Proxy settings

[glassez]

Did I understand correctly that for an I2P proxy, not the usual settings (proxy_hostname and proxy_port are used, but separate ones: i2p_hostname and i2p_port? If so, why?

[jiigen]

Did I understand correctly that for an I2P proxy, not the usual settings (proxy_hostname and proxy_port are used, but separate ones: i2p_hostname and i2p_port? If so, why?

I don't know exaclty why, probably cuz internally they are used differently by libtorrent. Maybe @Vort or @arvidn can have the answer.

[Vort]

probably cuz internally they are used differently by libtorrent

This is most likely the reason.
SAM protocol is similar to proxy, but unlike proxies, it gives access to different network, not just allows different route to the same network.
Let's wait for @arvidn answer.

[arvidn]

I don't remember why the i2p hostname and port ended up as a separate setting. There are some remnants of a proxy type for i2p, and I think it may have worked that way at some point in the past. it seems to need some straightening out though.

maybe setting proxy type to i2p (and using proxy_hostname and proxy_port) could be made synonymous with i2p_hostname and i2p_port.

[glassez]

The presence of these alternative settings (i2p_hostname and i2p_port) would be necessary only if they could be used simultaneously/in parallel with proxy_hostname and proxy_port. Otherwise (if i2p can only act as another type of proxy), they are confusing.

[arvidn]

yes

[zzzi2p]

Well, libtorrent and the downstreams need to decide whether you eventually want to support "mixed" networks or not, and if so what's the default.

Mixed = both I2P and clearnet at the same time, "bridging" clearnet torrents into I2P. This has obvious anonymity issues but BiglyBT supports it and lots of people run it that way. There's complexity with bandwidth and peer management if you do it that way because of the vastly different speeds.

Whether you support mixed or not, you have to make sure you're not trying to pump clearnet traffic or announce to clearnet trackers or do uTP through SAM, that's why it's not a real proxy and perhaps why it's a different set of configs. So think through where you're headed.

Speaking of, defaulting to localhost/7656 would help your users, as that's where the i2p router will be 99.9% of the time.

[Vort]

I just want to note that right now settings_pack::allow_i2p_mixed already exists in code.
However, I did not tested if it works correctly or not.

[absolutep]

Well, libtorrent and the downstreams need to decide whether you eventually want to support "mixed" networks or not, and if so what's the default.

Mixed = both I2P and clearnet at the same time, "bridging" clearnet torrents into I2P.

I would highly request for mixed network options as described aforementioned.

The default state can be public (normal as it is now), and users can then choose to make it mixed from settings or i2p only.

As shown in screenshot; that would be nice.

[arvidn]

After having looked into this, I believe the rationale for having i2p SAM settings be separate from proxy settings is to allow non-i2p connections to use a proxy, while still supporting pure i2p torrents along side regular ones. Also in mixed mode obviously.

This patch clarifies the documentation: #7305

[glassez]

@arvidn
Just to make sure I got it right:

1. I2P connection, if any, lives in parallel with regular one (either direct or proxies)
2. Client app should never use i2p_proxy type (really I don't like such internal thing that is technically public but just marked as internal in comments) so to enable I2P it needs only set i2p_hostname/i2p_port

[arvidn]

saying "internal" as the first line of the comment is special. The generation tool will not include it in the html by default. Another "magic" word is "hidden". See: https://github.com/arvidn/libtorrent/blob/RC_2_0/docs/gen_reference_doc.py#L204

[arvidn]

both (1) and (2) are correct

[glassez]

saying "internal" as the first line of the comment is special. The generation tool will not include it in the html by default. Another "magic" word is "hidden". See: https://github.com/arvidn/libtorrent/blob/RC_2_0/docs/gen_reference_doc.py#L204

You are talking about docs, I'm about the C++ itself.
Of course, it's clear to me that the current (workaround) approach saves you from extra work.

[arvidn]

You are talking about docs, I'm about the C++ itself.

I see. Right. My long term ambition is to replace http_connection with something simpler based on boost.beast. Maybe at that time this interface could be fixed to not rely on proxy_settings_t needing to communicate i2p settings as well.

[jiigen]

Is someone working on dht and/or ut_pex with i2p?
I've not the skills for doing it myself but I'm curious to know if something is going on. Thanks

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Neustradamus]

@jiigen: @arvidn has done a good job, he has done a PEX PR which has been merged:

• implement i2p_pex, peer exchange support for i2p torrents #7831