bittorrent.org

There is this https://github.com/bittorrent/bittorrent.org/pull/174 We would love this to gain more traction so we can use mainline also for content discovery. But we have to be realistic: mainline moves slowly, and for good reasons.

> I wish you could also delegate this problem to the mainline DHT, but alas that is not possible because of some mainline limitiations. Have you seen https://github.com/bittorrent/bittorrent.org/pull/174 - does that address the main issue?

Rationale for hash function change: https://github.com/bittorrent/bittorrent.org/issues/58 Discussion of other changes: https://github.com/bittorrent/bittorrent.org/pull/59

Please have a look at this pull request I submitted some time ago to Bittorrent.org: https://github.com/bittorrent/bittorrent.org/pull/35 It's about updating torrents via DHT mutable items. Meaning that torrent sites could share their public key and simply seed an .rss file containing their indexed torrents (a mapping of infohash -> descriptions). When they want to share new torrents, they simply update their torrent to a new .rss file and consumers will hop on that new swarm. We need more support to get this into a standard BEP and also into torrent clients. I know there are other networks (IPFS, I2P, Freenet, ZeroNet, etc..) that do this, but BitTorrent is the most widely used and I think implementing functionality in the torrent ecosystem itself would have much more effect.

I personally wish torrent search engines stop using DNS systems (at least centralized ones) and HTTP servers. What they could do instead is use the DHT feeds idea [1]; share their feed URI (a hash of a public key) which is a mutable DHT key, and have that point to a .torrent of their whole crawled database - I doubt their magnet_link -> description database is larger than a few dozen megs. When new torrents need to be updated, the DHT key is mutable and they can point to a new torrent - users will then just get the new stuff. Idea is laid out here: https://github.com/bittorrent/bittorrent.org/issues/19#issue... Sure it's more complex than typing somesite.com in your address bar, but it's not that much more complicated. 1. http://libtorrent.org/dht_rss.html

One DHT entry per tweet. I do agree that it does create overload on the DHT. Initially in fact I was looking at implementing it as such: https://github.com/bittorrent/bittorrent.org/issues/19#issue... Problem is that you don't get the "hosting" effect that you get with the DHT so you always need a peer seeding your feed or else it won't be reachable. Anyway, I hope others take on the challenge of implementing alternatives looking at different methods.