torrent

BitTorrent v2 has the incremental hashes via merkle trees. They're surprisingly good. I implemented them here https://github.com/anacrolix/torrent/issues/175#issuecomment...

Any clean room impl. is good news to me, but is the support for private torrent/tracker complete (https://github.com/anacrolix/torrent/issues/531)? NB: especially after https://github.com/Luminarys/synapse died and Transmission "botched" its 4.x rewrite (currently on 3 with some backported patches).

I had a super seeder implementation that seeded over 400k torrents simultaneously using some fancy callbacks at certain points in the protocol. If this is actually a common use case, I can resurrect it into a usable form for the public if there's interest or funding. https://github.com/anacrolix/torrent

My client anacrolix/torrent has most of that, including streaming, hybrid, v2, all trackers and protocols. I don't do much port forwarding, it's too fiddly. I think I provide upnp out of the box and few other variants that were contributed. I also have all the DHT extensions, like mutable torrents and get/put etc. Large torrents do pop up occasionally, but it's been a long time since someone found a performance issue there but it used to happen every few months. Lots of optimisation. GitHub.com/anacrolix/torrent

I'm the author of https://github.com/anacrolix/torrent and added v2 support a while back. The short answer is: You just publish as v1 infohash as if nothing is different, but the info contains extra stuff for v2 supporting clients. v1 clients will still work, it's backwards compatible. So generate your torrent files as hybrid v1/v2, then just do everything else like you always have. Pretend v2 isn't a thing. v2 clients know how to tap into both swarms and will take advantage of improvements when applicable. It's very well designed.

Yea, this is correct. ```go import ( "net/http" "os" "github.com/anacrolix/torrent" tstor "github.com/anacrolix/torrent/storage" ) ``` would import as: http, os, torrent and tstor. That guy is mixed up.

https://github.com/anacrolix/torrent has a fuse driver since 2013. I'm in the early stages of removing it. There are WebDAV, 3rd party FUSE, and HTTP wrappers of the client all doing similar things: serving magnet links, infohashes, and torrent files like an immutable filesystem. BitTorrent v2 support is currently in master.

That's exactly the problem my BitTorrent client solves. https://github.com/anacrolix/torrent. It's been around since 2013.

I'm the author of https://github.com/anacrolix/torrent (started in 2013) and https://github.com/anacrolix/dht (started in 2015). I have a DHT indexer implementation I developed in 2021. It's currently closed source but available for use as part of https://www.coveapp.info/. I have found that after several hours the search is excellent and stays up to date with ease.

https://github.com/anacrolix/torrent/blob/master/cmd/torrent... does exactly that. Install with `go get github.com/anacrolix/torrent/cmd/torrent@latest`, and then run `torrent serve <torrent paths>`.

Hit me up if you want to discuss using BitTorrent to back images. https://github.com/anacrolix/torrent

It has some small latency but only when resources are spread across many different infos. If you can constrain your resources to a single DHT traversal, it's pretty quick. I run several services that stream from BitTorrent on demand, using https://github.com/anacrolix/torrent which are surprisingly quick to start. However it does choke up when you try to start many different resources at once, which multiplies horizontally the number of DHT traversals, and per-torrent related overhead to get started. It is solvable, but any solution that spreads resources out across many different targets in the DHT is slow. Basically anything that was inspired by BitTorrent, but isn't BitTorrent itself does this, because they get overly excited by deduplication of data.

For whatever reason the ARM version of Transmission does not work well on my M2 laptop - it downloads quickly at first and then drops off to zero, and had some other bugs (the x86 version always worked flawlessly). I tried playing around with different settings, running their nightly builds, etc, and nothing fixed it for me. In the end I searched for other clients and found them all filled with ads and bloatware, and decided to use this excellent open source command line client instead: https://github.com/anacrolix/torrent It has a few frontends built on top of it (linked in the project readme), but I just run `torrent download <magnet link>` and it downloads at full speed / with no issues.