-
Notifications
You must be signed in to change notification settings - Fork 0
Description
A more detailed tracking of this issue can be found in codex-storage/nim-codex#1137.
Initial implementation of the proposed protocol extension to support BitTorrent content.
Inputs:
info
BitTorrent v1 dictionary for a single file content,- the corresponding
info
hash - the corresponding content
Normally the user will just use the
info
hash to locate the content, but because in the end we will be integrating with a BitTorrent client, every time the user downloads BitTorrent content that the user also wants to seed to Codex network, we will use the very sameinfo
dictionary that was used by BitTorrent protocol, so that we have exactly the same matching triple: (content, info, info_hash).
The high level design is illustrated here.
Based on the input we will be storing something called a BitTorrentManifest
, e.g.:
type
BitTorrentPiece* = MultiHash
BitTorrentInfo* = ref object
length: uint64
name: ?string
pieceLength: uint32
pieces: seq[BitTorrentPiece]
BitTorrentManifest* = ref object
info: BitTorrentInfo
codexManifestCid: Cid
And we will make sure that the nodes having the relevant BitTorrent content advertise their SPRs under info
hash in DHT.
Then when downloading, we:
- fetch the
BitTorrentManifest
, from which we get theinfo
dictionary, which we can use to computeinfo
hash locally and check that it aligned with the requestinfo
hash. - form
BitTorrentManifest
we also get originalcodexManifestCid
which will allows us to fetch the relevant blocks, and while getting them, we will be computing the corresponding hashes for the pieces, which we can validate using the data from theinfo
dictionary that we preserved in theBitTorrentManifest
, we can check that the reconstructed pieces match the original BitTorrent content.