I suggest including a few of the largest open trackers by default. You'll have a high hit rate for semi-popular torrents, and they can be faster than waiting for a cold DHT lookup in most clients. It's a minor decrease in privacy, but the BitTorrent network isn't really eavesdropping-resistant in the first place.
I wish IPFS had finished their BitTorrent support so we could use their standard gateway paths instead. The prefix https://ipfs.io/ipfs/f017b1114 should identify a hex-encoded BitTorrent infohash, letting us use a full URL like https://ipfs.io/ipfs/f017b111464d052f755e01d1c947848ad3d2218... through any IPFS gateway, which would resolve the content using a combination of IPFS' own network and BitTorrent with its DHT, but the implementation was never completed.
I'll use the occassion to recommend Tixati [0]. I've gone through many BT clients, sometimes coming back to them multiple times, and Tixati is definitely my favourite. Disk usage, features, configurability, project's activity are all great. The only semi-weird thing is that while it's free and without adware or ads, it's also a closed-source one-man show.
The way BitTorrent uses magnet URLs isn't quite semantically consistent with the way other P2P networks have used them. They probably should have just picked a different scheme.
No. You need to match all the metadata in the info part of the torrent file, the final hash is a hash of that info dictionary. The fields you lack are largely name and piece size, but without the original file you cannot create the hash of each correctly sized piece. If you have the constituent file (not just it's sha1) you could eventually get it by trying common piece sizes and knowing its name.
I believe that ultimately happens via DHT bootstrapping, where your client finds peers to join the DHT via a bootstrapping server that provides nodes, then DHT lookups are used from that point forward.
my experience with magnet links is that they are unpredictably slow: sometimes it works almost instantaneously, sometimes it takes literally forever to fetch the peers and the transfer never completes. busiest torrents will of course propagate better...
I was hoping I could transfer semi-public files (say some music with a friend) without putting them on the public trackers, but my tests with different clients were not conclusive, so those really only make sense for busy, wide-distribution torrents and not one-to-a-few transfers, for which things like magic-wormhole are a better alternative.
The DHT performs poorly for unpopular hashes, cold starts and with poorly configured networking. Particularly the last point, an open udp port is required for best results.
I wish IPFS had finished their BitTorrent support so we could use their standard gateway paths instead. The prefix https://ipfs.io/ipfs/f017b1114 should identify a hex-encoded BitTorrent infohash, letting us use a full URL like https://ipfs.io/ipfs/f017b111464d052f755e01d1c947848ad3d2218... through any IPFS gateway, which would resolve the content using a combination of IPFS' own network and BitTorrent with its DHT, but the implementation was never completed.