BEP:46
Title:Updating Torrents Via DHT Mutable Items
Version: baadc751e455b5d58a153088c42c4831013a92df
Last-Modified:Sun Aug 14 22:16:29 2016 +0200
Author: Luca Matteis <lmatteis@gmail.com>
Status: Draft
Type:Standards Track
Content-Type:text/x-rst
Created:24-Jul-2016
Post-History:

Abstract

This extension enables torrents to update based on data stored in the BitTorrent DHT [1], rather than an HTTP server. The publisher has control over when the torrent is updated, and which content it contains, via mutable DHT items. It is similar to BEP 39 [2], with the difference being that it uses the DHT to notify and be notified about updates of a torrent, hence should provide more decentralized capabilities to both publishers and consumers.

The intention is to allow publishers to serve content that might change over time in a more decentralized fashion. Consumers interested in the publisher's content only need to know their public key + optional salt. For instance, entities like Archive.org could publish their database dumps, and benefit from not having to maintain a central HTTP feed server to notify consumers about updates.

Rationale

BEP 39 [2] allows to automatically update torrents based on HTTP URLs. With DHT storing capabilities [1], we can implement similar functionality in a more decentralized fashion without resorting to central HTTP servers, and using features already present in the BitTorrent network (mainly DHT store).

Publishing content

Publishers should issue a mutable put request when they want to notify consumers about an update of a torrent. The value of the payload v contains a dictionary with key ih (info hash) and value the 20 byte infohash of such torrent. Note that while a DHT entry under a particular key maps to a single torrent at any given moment, many different keys can point to the same torrent.

{
  ...
  "v": {
    "ih": "<20-byte infohash of target torrent>"
  }
}

For request and response details refer to BEP 44 [1].

Consuming content

Consumers issue a get request using the target ID of the mutable item they are interested in. Periodically polling such ID by issuing get requests to see whether the v property of the response has updated. If an update is found, the torrent can be updated using the infohash found in the response.

Both publisher and consumer should periodically put the mutable items they have active to keep them alive in the DHT. For details on the republish algorithm see [1].

Test Vectors

test 1 (magnet to target ID)

public key (hex):

8543d3e6115f0f98c944077a4493dcd543e49c739fd998550a1f614ab36ed63e

target ID (hex):

cc3f9d90b572172053626f9980ce261a850d050b

test 2 (magnet to targetID, with salt)

public key (hex):

8543d3e6115f0f98c944077a4493dcd543e49c739fd998550a1f614ab36ed63e

salt (hex):

6e

target ID (hex):

59ee7c2cb9b4f7eb1986ee2d18fd2fdb8a56554f

Reference implementation

https://github.com/lmatteis/dmt

References

[1](1, 2, 3, 4) BEP_0044. Storing arbitrary data in the DHT. (http://www.bittorrent.org/beps/bep_0044.html)
[2](1, 2) BEP_0039. Updating Torrents Via Feed URL. (http://www.bittorrent.org/beps/bep_0039.html)