this post was submitted on 30 Dec 2024
86 points (81.6% liked)
Piracy: ꜱᴀɪʟ ᴛʜᴇ ʜɪɢʜ ꜱᴇᴀꜱ
55212 readers
130 users here now
⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.
Rules • Full Version
1. Posts must be related to the discussion of digital piracy
2. Don't request invites, trade, sell, or self-promote
3. Don't request or link to specific pirated titles, including DMs
4. Don't submit low-quality posts, be entitled, or harass others
Loot, Pillage, & Plunder
📜 c/Piracy Wiki (Community Edition):
💰 Please help cover server costs.
 |
 |
|---|---|
| Ko-fi | Liberapay |
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
What’s the advantage to that? I don’t want the torrent I’m downloading to change.
I want that. For example you downloaded debian iso version 13 and after some time it can be updated to 13.1. Obviously it shouldn't be an automatic operation unless you allowed it before starting download.
I wouldn’t call that mutable, more like version tracking in which each torrent is aware of future versions.
I kind of like that, but you might be able to accomplish it with a plugin or something.
Put a file in the torrent called “versions” or something like that, and in there would be a url that the client can use to tell you if there is a new version.
It wouldn’t change the protocol though, since the new version and old version would still need to be separate entities with different data and different seeding.
Like the 13.1 torrent being only a patch to the 13 one and listing it as a dependency? Downloading the 13.1 torrent would transparently download the 13 if it wasn't already, then download the 13.1 patch and apply it. But I don't think any of this needs to be at the protocole level, that's client functionality.