Add torrent-file and torrent-info resolvers

[BubuAnabelas]

I took ipld-ethereum's code and modify it to complement with the parse-torrent and bencode packages to adapt it to implement the IPLD Interface.

I think this implementation is pretty much complete, it has both torrent-file and torrent-info resolvers. It also has some test cases to check it working fine, but I'm sure there are lots of other things that can be tested out to be sure it works as intended.

This is related to ipfs/js-ipfs#779 and maybe it will help to implement the ipfs-torrent service.

[rvagg]

I'm suspecting that @mikeal might be the best person to review this, I'm not as schooled in torrent formats. My initial question though is regarding the CID:Binary mapping which is critical for IPLD and I believe might be a problem for torrents. In your implementation, do you have a clear mapping of CID to whatever is decoded? Could I encode from the data you're instantiating back into binary form and generate the same CID from that data or are there additional bits of information missing, or added that break the "this raw data is all hashed and prefixed with multihash+codec+etc to produce a CID" contract of IPLD?

[BubuAnabelas]

@rvagg In the case of torrent-info, CIDs are produced by hashing the binary representation of the info dictionary, the same way info-hashes are calculated. In this implementation I just considered BEP3's definition because BitTorrent v2 (BEP52) isn't really implemented anywhere afaik (it's been added to libtorrent but hasn't shipped yet).

For torrent-files it's a little different, since they just add metainfo to the torrent-info, there can be many different torrent files for the same torrent. For example, by adding a tracker to the announce-list would change a torrent-file CID, but the torrent-info would remain the same.

Given that both torrent-info and torrent-file are bencoded data, there's an unique mapping between CID and torrent-info/torrent-data. Both resolvers have a test case for this in the code I have submitted.

[BubuAnabelas]

A long time has passed since I've made this PR, I don't even remember if there where any caveat why this wouldn't work, yet it hasn't been merged.

I just wanted to mention a project built on top of IPFS which could take advantage of this IPLD interface with some modifications.

gigacat is a standalone web application designed to use IPFS peer-to-peer network to retrieve torrent dumps, formatted as CSV files, and to build a local database from the dump, letting the user search through it using text search.

Also, BitTorrent v2 was added to libtorrent and some clients are already testing it.

I will leave this PR open so it can be merged if it's find useful in the future.

[vmx]

In case someone wants to pick up this work, I'd like to mention that IPLD Codecs now have a new interface. IPFS is now using https://github.com/multiformats/js-multiformats#ipld-codecs-multicodec for IPLD things.

[rvagg]

closed for archival