> 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.
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.