Closed absolutep closed 1 year ago
Last comment was from 2018 by arvidn. It is 2022 now.
New features in I2P have been added and some changes have been done on their side, I hope that, now it will be easier to integrate it into qBittorrent & will be successful this time.
In any case, eagerly waiting for this feature request to be completed.
+1 for this feature. It also can help establish connection between passive clients.
+1 for this feature. It also can help establish connection between passive clients.
exactly.
As can be seen from the below screenshot.
A seeder/leecher can connect to the following simultaneously 1) trackers 2) DHT, PEX 3) I2P DHT
Im not a developer, but maybe it must be first implemented in libtorrent. I suppose that libtorrent cant use domain name instead IPv4/IPv6 adressess.
Any update ?
any update on this?
Libtorrent team is actively trying to solve i2p issues. https://github.com/arvidn/libtorrent/pull/7272
qBittorent team should keep tabs on it, so that they can implement changes as early as possible. Thanks.
Most of the issues related to i2p have been fixed in libtorrent with this commit: https://github.com/arvidn/libtorrent/commit/94ed94ec1468e786bea2610c59586c4bf2994697 I've personally tested the fixed library with deluge-torrent and apart some minor issues it seems to work: https://dev.deluge-torrent.org/ticket/3583 So I hope that qbittorrent will implement it so that with more testers other issues and/or new features can be fixed/added. Thanks in advance.
I have never used I2P. Could someone explain with an example of some easily reproducible scenario how it is supposed to work with qBittorrent? So that I can figure out what we have to do.
I have never used I2P. Could someone explain with an example of some easily reproducible scenario how it is supposed to work with qBittorrent? So that I can figure out what we have to do.
It is not supported by the qBittorrent. That's what this whole thread is about.
I have never used I2P. Could someone explain with an example of some easily reproducible scenario how it is supposed to work with qBittorrent? So that I can figure out what we have to do.
It is not supported by the qBittorrent. That's what this whole thread is about.
So I'm trying to figure out what needs to be done to implement its support.
I have never used I2P. Could someone explain with an example of some easily reproducible scenario how it is supposed to work with qBittorrent? So that I can figure out what we have to do.
First of all, user installs either Java I2P software or i2pd.
Then user enables SAM protocol either in web console (I2P) or in config (i2pd).
Then user should specify SAM address and port (usually 127.0.0.1:7656) somewhere in qBittorrent UI (proxy settings maybe?).
qBittorrent should translate it to lt::settings_pack::i2p_port
and lt::settings_pack::i2p_hostname
and set lt::settings_pack::proxy_type
to lt::settings_pack::i2p_proxy
.
Now torrents can be downloaded via i2p network.
Now torrents can be downloaded via i2p network.
How can I test it? Should they be some special torrents (from some specific trackers)?
How can I test it? Should they be some special torrents (from some specific trackers)?
With this magnet for example:
magnet:?xt=urn:btih:cb18974db461c640c0d938710203bb263a746694&dn=I2P%2B+Universal+Installer+2.0.0%2B&tr=http://tracker2.postman.i2p/announce.php
These are the settings that Deluge exposes to the user:
which essentially enable the settings in libtorrent mentioned by @Vort (plus some extra ones).
This is a code snippet related to that (not C++ deluge is written in python):
core/preferencesmanager.py
def _on_set_proxy(self, key, value):
# Initialise with type none and blank hostnames.
proxy_settings = {
'proxy_type': lt.proxy_type_t.none,
'i2p_hostname': '',
'proxy_hostname': '',
'proxy_hostnames': value['proxy_hostnames'],
'proxy_peer_connections': value['proxy_peer_connections'],
'proxy_tracker_connections': value['proxy_tracker_connections'],
'force_proxy': value['force_proxy'],
'anonymous_mode': value['anonymous_mode'],
}
if value['type'] == lt.proxy_type_t.i2p_proxy:
proxy_settings.update(
{
'proxy_type': lt.proxy_type_t.i2p_proxy,
'i2p_hostname': value['hostname'],
'i2p_port': value['port'],
}
)
elif value['type'] != lt.proxy_type_t.none:
proxy_settings.update(
{
'proxy_type': value['type'],
'proxy_hostname': value['hostname'],
'proxy_port': value['port'],
'proxy_username': value['username'],
'proxy_password': value['password'],
}
)
self.core.apply_session_settings(proxy_settings)
Essentially lt.proxy_type_t.i2p_proxy is the python version of lt::settings_pack::i2p_proxy
Hope it helps.
This is a code snippet related to that (not C++ deluge is written in python):
Thanks. The code is not a problem. I was more interested in what it was from a user perspective (I remind you that I have never used I2P myself). So it turns out it's just another type of proxy, right? Then it shouldn't be a problem to add it soon. It would be very helpful if one of the interested persons could test the build from the corresponding PR when it is published.
I've tried to modify some code to add i2p support but for some library problems (outdated qt5 on my system) couldn't try a build: https://github.com/qbittorrent/qBittorrent/commit/cd7b9ea701fae1d5d746c0e38868cc4552c476bf so I didn't go ahead.
Anyway I think there are more people interested on this feature sure @Vort and me (when I update my system) will be glad to test.
So it turns out it's just another type of proxy, right?
SAM protocol is similar to proxy protocols. It allows to route all communications with I2P network through single IP:port. However, because I2P network have some unique properties, I2P support needs to be deeply integrated into libtorrent code. For example, I2P network do not use IP addresses. It means that both library and client should be tuned accordingly. Also SAM protocol allows to make tradeoffs between security and speed. For now default value is used, so it is enough to make SAM support to look just like another proxy protocol, but in future it is better to allow user tweaking such parameters.
It would be very helpful if one of the interested persons could test the build from the corresponding PR when it is published.
I don't know what are my capabilities regarding building binaries. But in case Windows 7 compatible binaries will be available, then no problems.
As side note, since i2p is for anonimity and privacy maybe could be useful to force proxy use when in i2p mode to prevent leaking. Extra options for those that aren't concerned about privacy could be using "i2p-mixed" mode of libtorrent so that will be possible to use both i2p and clesrbet peers.
@jiigen I suspect that "force use" mode is default now. And I doubt that mixed mode work at all. Did you tried it? It may be needed to think about disabling DHT however. Theoretically, it should work through I2P, but looks like support is not implemented correctly yet.
To try mixed mode a torrent with both i2p and clearnet seeds would be needed, and so far I hadn't the chance to test. In deluge is possible to set mixed mode through a plugin: https://github.com/ratanakvlun/deluge-ltconfig
I've tried to modify some code to add i2p support
@jiigen link to your commit is incorrect - it have 1 extra character.
@Vort thanks, now I've corrected it
@jiigen your commit was almost right. I fixed it a little: 585dbebcc5ee9de246cd9ab2a20cd79679a16fea And here are the results:
Looks like the same problem as with Deluge: peer list shows wrong information.
@jiigen your commit was almost right. I fixed it a little: 585dbeb And here are the results:
So it retrieve peers and the download starts that's a good starting point :-) ! Which setting did you use in the preferences?
Looks like the same problem as with Deluge: peer list shows wrong information.
This makes me think that the problem could be somewhere in libtorrent maybe.
So it retrieve peers and the download starts that's a good starting point :-) !
Yes, this is good.
Which setting did you use in the preferences?
This is what I used:
For some reason type option is not saved for me and client crashes at exit.
But it may be because I changed some build parameter - build was failing otherwise.
This makes me think that the problem could be somewhere in libtorrent maybe.
But client_test shows peer list correctly!
But client_test shows peer list correctly!
So it's something in both client we didn't find so far. I can't do reliable tests atm cuz I'm building in quickly built docker environment but I got same results and settings didn't get saved for me too. Anyway I think that now @glassez has something to start with.
For some reason type option is not saved for me.
@Vort maybe I've fixed this: https://github.com/qbittorrent/qBittorrent/commit/62f422bbb3d899e85f3ccf901fe589f06f956509
maybe I've fixed this: 62f422bbb3d899e85f3ccf901fe589f06f956509
With this change proxy type is loaded correctly.
@jiigen
Would you mind to create Pull Request?
Or if you want me to continue this work, you could create Pull Request to i2p
branch of my fork.
@jiigen Would you mind to create Pull Request? Or if you want me to continue this work, you could create Pull Request to
i2p
branch of my fork.
I've done both...just in case :-)
@glassez I did an error pushing the wrong mod, fixed it now: https://github.com/qbittorrent/qBittorrent/pull/18462/commits/b54903f3611445f3a428c5fff92835abbcfe5758 Sorry
But client_test shows peer list correctly!
@Vort Maybe I've found what causes the issue in deluge : https://github.com/deluge-torrent/deluge/blob/2a945de0695ba0a5bf2d928ce4bd541d0f5cf2a8/deluge/ui/gtk3/peers_tab.py#L257 Peers are listed using their IP as key and removing duplicates so since every i2p peer has 0.0.0.0 as IP they get all discarded apart one. Maybe in qBittorrent there's something similar?
@Vort I was right, with some little modifications I managed to make deluge show the i2p peers correctly:
This confirms definitively that the issue is with the clients (Deluge and qBittorrent) not with libtorrent. Too bad I wasn't able to do the same in qBittorrent but guess there must be a similar issue. This commit https://github.com/jiigen/libtorrent/commit/02884d367b5641136cf9938d27fdb8d685b32c6d makes the python code more clean too, without it was still possible to distinguish i2p peers comparing ip with 0.0.0.0 but thought that would have been better to have that flag available.
Which application is shown in this screenshot? Excuse my ignorance, are these identifiers called "destinations" according to I2P? Unfortunately, I did not find any identifier other than IP/port in the information provided by libtorrent (however, I found that the internal classes contain "destination" property for I2P peers).
Which application is shown in this screenshot?
BiglyBT
are these identifiers called "destinations" according to I2P?
Almost. It is base32 representation of hash of destination: https://geti2p.net/en/docs/naming#base32
Destination is I2P equivalent of IP address.
I have installed the unstable version of qbittorrent from this repo: https://launchpad.net/~qbittorrent-team/+archive/ubuntu/qbittorrent-unstable on ubuntu.
On the desktop version there is the i2p option, but the nox/web version is missing i2p
@Bkeinn, you can try to edit configuration file manually for Web version.
@Vort I never used qbittorrent before, so I am not quite sure what I should be looking for. ~/.config/qbittorrent/qBittorrent.conf does not include any mention of i2p
@Bkeinn I thought it should. But if not, can be added. Look at these two messages: https://github.com/qbittorrent/qBittorrent/pull/19079#issuecomment-1722202984 https://github.com/qbittorrent/qBittorrent/pull/19079#issuecomment-1722466972.
Suggestion
I would like to suggest I2P support for qBittorrent in the form of a plugin or inbuilt facility.
Use case
Use case is -
1) Anonymous torrenting, since I2P network is a closed system the IP addresses do not get leaked via torrenting swarm.
2) It will help people facing a port connectivity issue or any other connectivity issue as peers from I2P network will help in ul/dl of a file.
Screenshots are attached, to further explain my points.