This is basically exactly what I2P does automatically.
Each peer is also a router, so that point is covered.
It already has a well documented method of transmitting torrents over the protocol, unlike Tor.
I2P has dedicated .maggot links too for distributing files over that network.
It uses garlic routing too, which makes it even more difficult to discover hidden services through network saturation.
So by all accounts, I2P is the better network to choose for this, it has all the resources there and a community that's willing to help.
But you decided to go down the unsupported route with Tor, a route that's going to be very unpopular with the Tor community.
That's great to hear! I haven't decided anything, I'm just more familiar with Tor and thought this would be something interesting to do with it. I'm not even building anything really, just getting feedback on the idea.
I don't see any antagonism between the two, and I'm glad to know there's something being done with I2P already, will check it out.
I fully support this venture with I2P, since the infrastructure is pretty much already there.
I'm not an experienced programmer, more tinkering than anything, but I suggest that you pass these messages onto some of the I2P devs on Twitter (@i2p, @echelon and @str4d would be able to help you the best with this).
I'm actually trying to bundle I2P with a portable version of Seamonkey with less than exciting results. I was also hoping that there would be some open source equivalent to Bittorrent Surf available to bundle too, however the only plugin that's similar apparently uses a proprietary network.
We have operational code which combines Tor with Bittorrent. Operates exactly as you describe in this delightful read.
Current download speed is 23Mbit/sec for a 3-hop Tor onion circuit on average laptop. We're in contact with the real Tor people.
That's great news! From what I saw, it seems like you implement onion routing separately from the Tor network, right? Do you have plans to integrate this into the official network as a way to incentivize relays too?
You should look up i2psnark in particular, that was the first big one I'm aware of, but there are plenty of others too.
Tor has a large critical mass - which makes it safer in general, through pure volume - but I2P is more suited to this for a bunch of technical reasons I'm not going to go into in detail right now, but they involve garlic routing vs onion routing, end-to-end correlation, single-ended vs double-ended tunnels/circuits... basically, Tor hidden services are okay, but I2P is actually designed for more generalised use like this.
One of the hurdles for a technology is having "substantial non-infringing uses" which may be arguable (are there enough open-source movie torrents out there?), but it's unlikely GitHub felt like figuring it out and just took it down when a complaint came in.
It can be viewed as a copyright circumvention "device". If they published the code in a book like was done with PGP it could be viewed has having a legitimate existence as a physical work.
Will this also be able to connect to non-Tor peers (via exit nodes)?
One of the biggest problems for any peer-to-peer technology is the chicken-and-egg problem. You need to bring together a large number of users in a short time, or else everyone abandons your product because none of the friends/files/etc. they want are on the network. A BitTorrent client that can only connect to Tor-enabled peers is therefore doomed from the beginning. You need to be able to connect to all the existing non-Tor peers without compromising your own anonymity, while also providing plenty of incentives for other nodes to switch to Tor (i.e. presumed immunity from the MAFIAA). Maybe after 10 years when everyone is anonymous, then you can drop this "compatibility layer" and go entirely dark.
For a similar reason, I support your decision to use Tor instead of I2P. The latter's design might be easier to integrate into a BitTorrent client, but the former has many more users and much greater network capacity, is backed by an organization that will fight to the death to protect its integrity, and above all, just happens to be much better known.
The latter's network capacity scales up with each new user due to its design, which is far more efficient than the separate client-relay design that Tor uses.
And simply because Tor has the benefit of a greater pool of users doesn't mean that the network would benefit from the addition of this program. Tor is already being extensively used in other ways and the network is quite congested already. The addition of this extra data, plus from the scores of users that will strip out their relay to increase bandwidth for them, will make Tor a less attractive option for what it's being used for currently.
It should be noted that Vuze (Azareus) has a comprehensive guide on how to get their program working with I2P, and it also allows the user to mix torrents from both I2P and the clearnet, so such transitional software packages are possible and do exist.
OP's proposal is not just to add bandwidth-heavy clients to the Tor network, it is to add a large number of relays by making every BitTorrent client a Tor relay. OP also devotes two long sections on why he thinks his program will not harm the rest of the Tor network. Sure, there are issues to overcome before this can become reality. But the Tor network has improved by leaps and bounds over the last few years, and there's no reason to be pessimistic about its ability to handle a lot more traffic.
Sure, I2P already works reasonably well with BitTorrent. But what's wrong with trying to achieve a similar result with Tor?
The architecture is already there with I2P, it has proven to be efficient over I2P, Tor already has extensive use as an anonymous web browsing tool, whilst adding relays to each client would help mitigate Tor's network constraints somewhat, it would still degrade performance on the network to a degree due to the nature of how it anonymizes data.
There's also the issue of not being able to run a client and a relay AND remain completely anonymous, as I posted earlier.
The I2P network is also being underutilised at this point, it has a lot of potential for growth especially in this area. It makes sense to use that potential to grow a specific specialised network, rather than potentially impact an already perfectly functioning network that Tor currently is.
The idea that Tor is slow is widely spread but absolutely inaccurate.
In my experience, in the last two years Tor isn't slow, and the bottleneck seems to be my Internet Provider. People I know used Tor uploading files at more than 10 MBps.
Is there any kind of connection privacy on cjdns? I'm not too familiar. With labels/studios spying on trackers/peers to go after downloaders, it's important to have that added security.
Not really no, just plausible deniability that traffic didn't actually come from you. Cjdns (or really the only deployed cjdns network Hyperboria) also encourages knowing who you connect to somewhat personally. It's not yet (ever?) suitable for widespread anonymous deployment.
Each peer is also a router, so that point is covered. It already has a well documented method of transmitting torrents over the protocol, unlike Tor.
I2P has dedicated .maggot links too for distributing files over that network.
It uses garlic routing too, which makes it even more difficult to discover hidden services through network saturation.
So by all accounts, I2P is the better network to choose for this, it has all the resources there and a community that's willing to help. But you decided to go down the unsupported route with Tor, a route that's going to be very unpopular with the Tor community.