[MayeulC]

I'm really excited to see support for torrents v2. If only because transmission will stop chocking on hybrid torrent files, which should lead to more adoption across the board.

I wish transmission supported mutable torrents (BEP46). It would allow completely re-thinking distribution: grab a torrent of your favorite distribution, and have it auto-update to the latest version.

Or grab a "super-torrent" that lists isos for all known distributions, select the ones you're interested in, and let it update... Of course, that can be used for file-sharing repositories too.

Maybe transmission is not interactive enough for such a use-case (you'd have to ask the user what they want to do when the torrent mutates, and possibly add simple scripting interfaces for more complex heuristics).

[capableweb]

> I wish transmission supported mutable torrents (BEP46). It would allow completely re-thinking distribution: grab a torrent of your favorite distribution, and have it auto-update to the latest version.

That sounds horrible. My own expectation is that if I have a torrent file/magnet link and I download from it, I always get the same content. This is why I commonly keep the magnet link/torrent file around even if I delete the content itself, so if I want the same thing in the future, I just re-download it and I'm 100% it's exactly the same.

This change would break that expectation, for what benefit? This could be implemented as a HTTP call instead, that serves different torrent files, so you can just change whatever serves the torrent file in order to mutate what gets downloaded.

[MayeulC]

> This change would break that expectation, for what benefit? This could be implemented as a HTTP call instead

The main benefit is not having to rely on a centralized HTTP server and repository, as well as the associated infrastructure: DNS, TLS, CA, etc. One could host a blog over torrents (more or less what IPFS is doing).

We already have RSS feeds for what you describe (though not supported natively by transmission).

> My own expectation is that if I have a torrent file/magnet link and I download from it, I always get the same content.

That wouldn't change significantly. The mutable torrent content is basically a .torrent that points to whatever the current version is; so just save that instead.

The good thing with mutable torrents (or mutable content in the DHT, as pointed out in another comment) is that instead of the hash (content-addressing) being stored in the DHT, a public key is retrieved. Once you got a torrent ("trust on first use" of sorts), you can verify that the new version is from the same uploader (or at least, one that knows the private key).

I would present it with a new set of checkboxes in the torrent client: "download new versions", then if checked "delete previous version after downloading updated content" and for more granularity "download new files", "download updates to existing files". Of course, for ease of use it would be better to have a historical view. I think the main use-cases would be to archive every intermediate version, or to just grab whatever is latest. There's infinite variations in-between. One thing I would like to stress, and that I didn't point out enough in my original comment is that this goes extremely well with v2 torrents and their de-duplication feature: if the same file exists in multiple versions of the torrent, peers with any version can contribute to the swarm.

It's not as good for deduplication as a rolling hashes could be, but you could host whole distribution repositories with mutable v2 torrents.

[compressedgas]

It doesn't unless your magnet does not contain an infohash and only contains the btpk.

[KirillPanov]

First it needs to support BEP44 "Mutable DHT", which is arguably a much more useful feature than mutable torrents. It is also a much simpler feature.

http://www.bittorrent.org/beps/bep_0044.html

[MayeulC]

I agree that's a dependency, but I am not sure how much more useful it would be comparatively?

[contravariant]

Pretty sure it gets you most of the way there by simply putting a mutable magnet URI in DHT. The rest is just a clever way of reusing already downloaded blocks.

[theptip]

This is a cool feature that I've idly wondered about in the past, but I didn't know it was actually spec'd/implemented in Bittorrent.

You could imagine hierarchically pushing the entire of TPB or whatever into the DHT. And even, each torrent having an `index.html` that renders a page containing links to the rest of the sub-torrents, so that the entire site is hosted in the DHT.

[MayeulC]

Right, and we saw some examples of Sqlite+torrent in the past; those databases could be made editable more easily (although it would be nice to de-duplicate unchanged parts, not sure if sqlite DBs can be chunked).

Not necessarily sqlite, that said. It might be useful for openstreetmap tiles/db, or indeed repositories like library genesis, wikidata/wikipedia dumps, etc.

[theptip]

Oh that’s an interesting idea. I saw someone built SQLite over HTTP with the Range header: https://phiresky.github.io/blog/2021/hosting-sqlite-database...

So presumably in a similar manner as https://github.com/phiresky/sql.js-httpvfs you could map SQLite pages to leaf torrents too and get the chunking you are looking for.