Add support for I2P torrents about btfs HOT 23 OPEN

Metadata collection is done through curl, which does not support i2p as far as I can tell.

from btfs.

However, only http and https metadata collection is done through curl. If I2P support was implemented for other types of torrents, would that work for you?

from btfs.

It would be for I2P torrents only, not for normal torrents

from btfs.

Sorry, I'm not quite sure how an I2P torrent is different than a normal one - is there a different format? I had assumed it was just a proxy type.

from btfs.

Yes it is just a proxy type, but I don't know how metadata collection can be done... Maybe @str4d could help here to give some details ^^ (He is an I2P developer)

from btfs.

Is it possible I2P torrents are already supported? Looking in libtorrent, there's already some code to check if a torrent is an I2P torrent, and code to deal with I2P torrents. Is there a difference between an I2P torrent and an I2P proxy?

from btfs.

In libtorrent-rasterbar it is just a type of proxy. Also, when saying I2P proxy, in fact it is the address of the SAM TCP bridge which communicates with the I2P router. What I said is that I don't know how metadata collection could be done using curl...

from btfs.

Does an I2P torrent start with http:, https:, magnet:, something else, or is it a file?

from btfs.

It is like normal torrents, it just uses I2P trackers and also I2P peers, but it should use I2P to get the file if an url is specified

from btfs.

@PlasmaPower an I2P torrent is a regular torrent running over the I2P network. In fact, if there are bridging nodes (torrent peers connected both to clearnet and I2P swarms) then a clearnet magnet link or torrent file can often be opened up with an I2P torrent client. See the documentation for further details, although most of that should be abstracted behind libtorrent. And yes, when the libtorrent documentation refers to "I2P proxy" it really means "I2P SAM API", because that is the API that libtorrent is using to make I2P connections via the user's I2P router.

If you separately wanted to connect to trackers outside of libtorrent, then you could use the I2P HTTP proxy (which by default is 127.0.0.1:4444, though a config option should be provided to change it, as with the SAM API).

from btfs.

I think I2P support should be in the latest version of my proxy support PR. Could someone check if it works?

from btfs.

@PlasmaPower
Tested this command with i2pd and it didn't work.
btfs --i2p-http-proxy=http://127.0.0.1:4446 --proxy-type=i2p

from btfs.

@donat-b If you pass -f to btfs, does it output any errors/warnings? Also, I should be able to troubleshoot it myself in ~5 hours when I'm not on a network that probably blocks i2p.

Edit: Oh, also, you might need a proxy hostname+port (specified with --proxy), from the libtorrent documentation:

The only used fields in the proxy settings structs are hostname and port.

from btfs.

@PlasmaPower no errors or anything suspicious. It's just not receiving anything, I guess.

from btfs.

@donat-b with the config options in that PR, I believe you need to run:

btfs --proxy=127.0.0.1:7656 --proxy-type=i2p --i2p-http-proxy=127.0.0.1:4446

ie. SAM port must be specified, and I don't believe the http:// is necessary (but I could be wrong on that).

@PlasmaPower 127.0.0.1:7656 is the default SAM API port, which you could use for --proxy by default if --proxy-type=i2p (but of course listen to --proxy if set).

from btfs.

@str4d I'll look into implementing a default, but yeah, that's what I edited into my post. Also, yes the http:// is optional.

from btfs.

I've added a default for i2p proxies.

from btfs.

I've gotten i2pd setup, and metadata collection through i2p is now working. However, it seems to stall whenever you try to cat a "file". I'll look into this more tomorrow.

from btfs.

In your setup you should make sure you enabled SAM, because by default it isn't

from btfs.

I enabled SAM and ensured that the port was open, but still nothing when I try to cat a file. Any ideas for how to investigate? The log.txt just has Azureus5.7.0.0.jar added, and there's nothing from the console when running with -f. Looking at it with -d, it would appear that the read calls are locking up as expected.

from btfs.

Oh, also, it's really annoying because the cat process gets locked up in the D state, so it's a bit of a pain to clean up.

from btfs.

@PlasmaPower that's exactly the result I have.

from btfs.

Just FYI, I2P has launched a development program aimed at helping developers integrate I2P into their apps. If you'd like some help with this in July during our Apps month, let me know! We are currently in APIs month, and have a contributor looking at updating/improving libtorrent's I2P support.

from btfs.