'Mutable' Torrents Proposal Makes BitTorrent More Resilient | Hacker News Reader

'Mutable' Torrents Proposal Makes BitTorrent More Resilient

torrentfreak.com

23 pointsokket11 comments

> For torrent sites, this would be an attractive solution because they wouldn’t need to maintain a central HTTP server which implies costs and can be easily shut down. On the other hand, their mutable torrent magnet link cannot be easily shut down, does not imply maintenance costs, and cannot be easily tracked down,

This would imply that all torrent sites exist because they believe in the "cause" and have no other motive. While a small subset might the rest enjoy the ad revenue while appearing to only care about supporting p2p networks.

I have had an idea for a new type of torrent (or better yet, onion routed torrents like Tribler) that is updatable by the original author for some time.

This would be useful, for instance, to have a torrent of a video series which always contains the latest episode instead of creating a new torrent each time, so the torrent would act more like subscription or RSS feed, which would encourage seeding as well since you would need to keep the torrent active in your client.

One major problem is malicious authors who would update a "verified" torrent with one that contains malware. Perhaps the torrent could somehow contain user reviews, and those reviews would be deprecated upon each update.

Does anything like this exist yet? Any other ideas on how to solve the malicious author issue?

This seems to differ from what is being proposed, which if I am understanding correctly is something like a link to an RSS feed which provides updates to an archive of torrents. Could this provide similar functionality to what I propose?

The situation is somewhat similar to Certificate Authorities. CAs are trusted at differing degrees and also have to watch out not to get their root certificate stolen.

I think that this is pretty much what IPFS [1] (and others I cannot remember right now) does. If I remember correctly, it builds on some of the BitTorrent ideas, but does not implement whole BitTorrent protocol.

It might be interesting to integrate IPFS into standard BitTorrent clients.

[1]: https://ipfs.io/

EDIT: Of course I ment IPFS in combination with IPNS (Inter-Planetary Name System)

IPFS is most definitely the long term solution, but I'm now of the opinion that in order to bridge the gap, IPFS needs to incorporate the Bittorrent protocol so you're serving IPFS from "supernodes". These nodes would abstract away Bittorrent and IPFS to the underlying data, since its SHA hashes all the way down (both entire objects, and chunks of the object).

Think of how S3 can serve content either via HTTP or via torrent for each object. Same idea, except with a distributed announcement/hash table.

I'm of the same opinion. It's much easier to gain mindshare by abstracting over the status quo and swapping out the innards than by starting from scratch with better tech but no existing culture around it.

Existing torrent clients already support RSS.

They support using RSS to obtain torrent data. OP is insinuating using a torrent as RSS is being used now, to make it resilient.

A few days ago we had another discussion about the actual BEP-46 this article is about, with some good comments: https://news.ycombinator.com/item?id=12257065

Can torrents actually share chunks? Because otherwise when downloading a large 'mutable' torrent which is often changed slightly one couldn't use all possible peers.

There are already a number of ways that torrents metadata could be shared more robustly, but none of them (including this one) allows the torrent sites to inject advertising and extract revenue.

Reply on news.ycombinator.com