Open allhailjarjar opened 2 years ago
I'm not familiar with I2P, but it looks like there are recommendations to use I2P specific trackers and extensions. I found https://geti2p.net/en/docs/applications/bittorrent and https://www.reddit.com/r/i2p/comments/ccyhkh/i2p_for_torrenting_without_isp_finding_out/ for example on this. It should be possible to embed I2P addresses within the existing DHT and BitTorrent infrastructure if they can be made to fit within the 18 or 6 byte compact address sizes, but from a glance it looks like I2P addresses would exceed that.
This repo should already support adding arbitrary dialers and listeners, such as ones you might get from the library you linked to. I would welcome PRs that implement stuff along the lines of https://geti2p.net/en/docs/applications/bittorrent if it's required to interoperate with peers on I2P.
Let me know if you find more specs or existing implementations on this.
It should be possible to embed I2P addresses within the existing DHT and BitTorrent infrastructure if they can be made to fit within the 18 or 6 byte compact address sizes, but from a glance it looks like I2P addresses would exceed that.
Yeah, this is the part I'm not sure about because the library uses net.IP type in many places and net.UDPAddr in some places. I wonder if we could abstract that away with a new NetAddr type and use that everywhere instead. Would this go in the DHT repo since that repo would use it too? This change seems straight forward, but would touch a few places in both the DHT and Torrent repos.
Let me know if you find more specs or existing implementations on this.
I looked around more within .i2p sites and didn't find any new information that wasn't already in the page you linked. I can reach out to the dev who wrote that page to review my changes when I have a PR ready to make sure we are compatible with other i2p torrent software. I'll also run some end to end tests to make sure it all works with the existing torrent client in use
It should be possible to embed I2P addresses within the existing DHT and BitTorrent infrastructure if they can be made to fit within the 18 or 6 byte compact address sizes, but from a glance it looks like I2P addresses would exceed that.
Yeah, this is the part I'm not sure about because the library uses net.IP type in many places and net.UDPAddr in some places. I wonder if we could abstract that away with a new NetAddr type and use that everywhere instead. Would this go in the DHT repo since that repo would use it too? This change seems straight forward, but would touch a few places in both the DHT and Torrent repos.
This could be done, it might be a bit tricky and possibly not worth doing unless it's known in advance that the addresses can be made to fit.
Let me know if you find more specs or existing implementations on this.
I looked around more within .i2p sites and didn't find any new information that wasn't already in the page you linked. I can reach out to the dev who wrote that page to review my changes when I have a PR ready to make sure we are compatible with other i2p torrent software. I'll also run some end to end tests to make sure it all works with the existing torrent client in use
Sounds good to me. I'm happy to accept PRs that can be demonstrated to add interoperabilities to reasonably sized user bases.
I briefly took another look at this. I saw some criticisms of Tribler's handrolled implementation, and I consistently hear good things about I2P. I don't see any solid looking client implementations in Go however, and I am worried about the download speeds. It looks like using VPN might be a simpler path for now.
I would like to run this library over the i2p network, but have run into a few roadblocks that I'm hoping you can advise on how to get around. This issue would also concern Tor, but unlike I2p, Tor doesn't support UDP, so that is why I'm choosing it for this project.
There are libraries which make i2p integrations much easier by providing the common Go net.PacketConn, net.Listener, and net.Conn interfaces.
However, as I was reviewing the source code for this library, I noticed many explicit references to and expectations of IP addresses and ports [1, 2, 3, etc]. And without an IP addresses, it appears that peer exchange and DHT communication won't be able to take place with the current explicit ip address references.
Because I2p is an overlay network and aims to provide anonymity, IP addresses are never used. Instead of an IP/Port pair, a randomly generated base32 address is used.
Do you see a way for me to make progress with this roadblock? If you see that something needs to change to support such an integration, I wouldn't mind making pull requests.
Thanks!