Mutable torrents creation/update

[frafra]

13508 has been closed based on the erroneous assumption that librtorrent did not supported mutable torrents (BEP 46), while it had experimental support since 2015 (https://github.com/arvidn/libtorrent/commit/ccc7e45406430e19348a539d5ca1435c0aac0074), which received various updates during the latest months.

qBittorrent can create torrents, but it misses the functionality to update a created torrent, which it would be nice.

If the qBittorrent team thinks that this functionality is out-of-scope, I would like to apologize for creating a useless issue.

Thanks for your maintaining and developing qBittorrent :-)

[itlezy]

Totally agree, V2 mutable torrent support would be a true game-changer. People could "subscribe" to other people mutable torrents, bringing the experience much closer to a "Share Folder.." and keep it shared with others.

In addition, I understand V2 torrents are suited to identify identical files shared across different V2 torrents, which again would greatly improve the user experience.

I think this is something worth implementing, it would drastically change the way people share files in BT. The library supports them, it's just a matter of making the UI around the feature. Should be very feasible, see this detailed description of the process from https://github.com/RangerMauve/mutable-webtorrent

BitTorrent is widespread and is used all over the place for sharing files without having to rely on centralized third parties. Even though it's great for sharing content, it doesn't provide a method for updating that content. Luckily, BitTorrent is a constantly evolving spec, and there was a push to provide a mechanism to support this use case in 2016. This library implements the "Updating Torrents Via DHT Mutable Items" proposal on top of WebTorrent.

Essentially, you create a public/secret keypair using ed25519. Then, you create a torrent and note it's infoHash, an identifier calculated based on the torrent contents. Then, you sign the infohash with your secret key, and publish a value to the DHT under the sha1 hash of your public key. Only you are able to publish changes to this key because it's automatically validated by nodes in the DHT.

Then, you create a magnet link which points to your public key instead of the infohash of the torrent and share it somewhere. Then, if somebody wants to download your content, they'll take the hash of your public key, look up values in the DHT, then verify that those values got signed by your secret key, and get the infohash of the torrent. From there they use the usual peer discovery methods for other magnet links.

What this gives you is the ability to share a torrent, and update where it points to over time. My goal with this is to enable people to create websites and other types of archives that can be used as a peer to peer alternative to the HTTP-based web.

libtorrent\tools\dht_put.cpp provides examples of how to use it

        "USAGE:\ndht [options] <command> <arg>\n\nCOMMANDS:\n"
        "get <hash>                - retrieves and prints out the immutable\n"
        "                            item stored under hash.\n"
        "put <string>              - puts the specified string as an immutable\n"
        "                            item onto the DHT. The resulting target hash\n"
        "gen-key <key-file>        - generate ed25519 keypair and save it in\n"
        "                            the specified file\n"
        "dump-key <key-file>       - dump ed25519 keypair from the specified key\n"
        "                            file.\n"
        "mput <key-file> <string> [salt]\n"
        "                          - puts the specified string as a mutable\n"
        "                            object under the public key in key-file,\n"
        "                            and optionally specified salt\n"
        "mget <public-key> [salt]  - get a mutable object under the specified\n"
        "                            public key, and salt (optional)\n"
        "\n"
        "OPTIONS:\n"
        "--log-packets               print DHT messages as they are sent and received\n"
        "--log-dht                   print DHT log messages\n"

[davispuh]

Any updates on this? This would be incredibly useful since a lot of data is not static but always changing. For example I could subscribe to latest Arch Linux ISO and I would never have to think about it, I always would have latest version to flash on USB.

Only I think from users perspective it would be useful to have per-torrent setting with "Keep previous torrent data" and "Delete previous torrent data after new one is downloaded"

[DejayRezme]

I feel this is a really important feature for normal bittorrent clients to implement so updates and lists and databases can be shared completely independently without relying on any website or DNS. It's like a platform feature that once there and easy to use for people, will enable new ways of doing things.

This would also benefit from an integrated markdown viewer to show a changelog for a new release of software.

Creators could even distribute their "youtube" channel videos with this, no need for any fancy new website or services, just use any seedbox to host.

[TiredSysOp]

I've been waiting on an implementation of this feature for a while now. Makes the sharing of forever changing datasets easier, especially when I'm not worried about version control like in gittorrent.

Would be perfect for pushing updates to my jukeboxes and media players. Great for automatic archival too.