Convert Bittorrent to IPFS files/folders

Hi, I’m new to the IPFS and I love the concept. I think the IPFS may take the place of the Bittorrent in the future.
So I’m thinking of how we can make use of the IPFS. I think IPFS is a great way to replace Bittorrent, so how can we convert Bittorrent with IPFS?

A naive way is that we can download the files of the .torrent and upload it. But I wonder if there is a better way?
Can there be an global identical mapping between a torrent file and an IPFS (folder/file) hash?
If we can handle this well, I can think of some good use cases.

  • If a user wants to download a file list in a torrent, he can use a tool (or a website) to check whether this files in the torrent exists in IPFS so that he can download it from IPFS.

  • there will be .ipfs-torrent file compares to .torrent file

  • IPFS will be an alternative content deliver means better than Bittorrent

4 Likes

sounds interesting. There are already magnet link search engines. You could make a browser or some other program that downloads files from magnet links and automatically uploads them to the IPFS. Every new magnet link that is appears would automatically be downloaded and uploaded.

1 Like

I. First point: “there will be .ipfs-torrent file compares to .torrent file”

In the end you can just publish the IPFS link, i.e. something like /ipfs/Qm... or just the hash Qm..., and if you have a client application that can deal with IPFS hashes, it will simply download the file. Of course you would need a few options in the software’s preferences similar to file distribution with BitTorrent, e.g. (1) only download file, (2) cache file, (2a) and seed for 1 week, (2b) and seed only while downloadinga, (2c) and seed until up/down parity etc., and (3) pin file & seed until manual removal.

There is really no need for an actual .ipfs-torrent file. Why? Let’s see what’s in such a file (or a magnet link); example:

http://download.documentfoundation.org/libreoffice/stable/5.4.4/mac/x86_64/LibreOffice_5.4.4_MacOS_x86-64.dmg.torrent

❯ torrentcheck -t Libre*
Torrent file  : LibreOffice_5.4.4_MacOS_x86-64.dmg.torrent
Metadata info : 21021 bytes, 869 pieces, 262144 bytes per piece
Torrent name  : LibreOffice_5.4.4_MacOS_x86-64.dmg
Content info  : single file, 227641654 bytes
Announce URL  : http://tracker.documentfoundation.org:6969/announce
❯ transmission-show Libre*
Name: LibreOffice_5.4.4_MacOS_x86-64.dmg
File: LibreOffice_5.4.4_MacOS_x86-64.dmg.torrent

GENERAL

  Name: LibreOffice_5.4.4_MacOS_x86-64.dmg
  Hash: dfe72b7cda0d323d0790cfa690ff731489bece1e
  Created by: MirrorBrain/2.18.1
  Created on: Wed Dec 13 21:45:19 2017
  Comment: LibreOffice_5.4.4_MacOS_x86-64.dmg
  Piece Count: 869
  Piece Size: 256.0 KiB
  Total Size: 227.6 MB
  Privacy: Public torrent

TRACKERS

  Tier #1
  http://tracker.documentfoundation.org:6969/announce

WEBSEEDS

  http://artfiles.org/documentfoundation.org/libreoffice/stable/5.4.4/mac/x86_64/LibreOffice_5.4.4_MacOS_x86-64.dmg
  [etc.]

FILES

  LibreOffice_5.4.4_MacOS_x86-64.dmg (227.6 MB)

(1) You don’t need the name of the share (or names in case of several files), because it is (they are) enclosed in the IPFS parent hash, automatically in case of several files—just add the enclosing folder instead of each file individually—, and in case it’s just one file, it will be enclosed if you add the file using ipfs add -w, which an “IPFS torrent software” (in reality: an IPFS GUI software) should all do by default, if a user wants to add content;

(2) you don’t need an equivalent to the torrent hash (bencode), because the IPFS parent hash is generated automatically, and it’s immutable, and when you list the contents, you will get the IPFS hashes for all files as well;

(3) you don’t need info on who created a share or the creation date, because if a different user adds the same file(s) with a different software at a different time, the hashes including the parent hash will still be the same;

(4) you don’t need info on file sizes etc., because if the hash is the same, the file will always have the correct file size; a file with a different size would produce a different IPFS hash; furthermore, a listing of the share’s contents will reveal every individual file’s hash and filesize, which should be sufficient for the usual filesharing information on a website;

(5) you don’t need info on tracker URLs or webseeds, because the IPFS will take of it all automatically.

So all you really need is one IPFS hash, a next-generation IPFS-based filesharing GUI application, and a URI for IPFS filesharing links that will automatically open the IPFS filesharing application of your choice.

II. Second point: “If a user wants to download a file list in a torrent, he can use a tool (or a website) to check whether this files in the torrent exists in IPFS so that he can download it from IPFS”

This is to my knowledge not possible, because if that file list doesn’t contain the IPFS hashes, there is no way to check the IPFS if the files are available there. You would need to download the files first using legacy BitTorrent, then run ipfs add -n, which will print the hashes, and only then can you ask the IPFS if anyone else has the files, which isn’t relevant anymore, because you already have the file you wanted.

III. Third point: “IPFS will be an alternative content deliver means better than Bittorrent”

Very true, but people will have to prefer IPFS over BitTorrent; for that you’ll need a GUI software, something like “Transmission for IPFS”, you will need websites where developers publish the IPFS hashes of their releases, other websites where people publish the IPFS hashes of their files, you need people leaving BitTorrent and switching over to IPFS-based solutions etc.

IV. So as to your first question: “how can we convert Bittorrent [to] IPFS?”

Only by downloading all relevant content with BitTorrent, then adding it to an IPFS node to get the IPFS hash, then publishing the hash on a website that allows it. This would have to be done as a community effort, I assume, with torrent websites whose administrators are willing to play along with regard to the new protocol, but it would probably be better to start fresh with a new IPFS-only website.

4 Likes

Thanks for your reply. Now I know that there is no need for .ipfs-torrent just an ipfs link (or hash) would be fine. Now that you‘ve pointed out that we need a next-generation IPFS-based filesharing GUI application I think we also need an IPFS file download URI to indicate the file should be download (in client) rather than opened in the browser. I’m not sure if it exists.

This is very interesting!

So, theoretically we could use the IPFS C++ library to integrate IPFS into any open-source torrent client, like Transmission, right?

We could change a few things to start the transformation into IPFS:

  • After we completely downloaded a torrent, the client would offer the option to upload it into the IPFS and it would store the IPFS hash locally
  • When we are planning to create a new BitTorrent file, the client would also offer to upload the folder/files to IPFS first and store the IPFS hash locally (and potentially in the newly created .torrent metainfo file as well, I’m sure if it was allowed)
  • The user should be able to list all IPFS hashes of their downloaded torrents, so that the he/she could upload them manually as a comment on the torrent indexing sites (it would be nice to automate this and use the indexing site’s API for this, but it would need the site’s willingness to implement it, I think)
  • The client would recognize the IPFS URIs/hashes and it would download the content from the IPFS
4 Likes

Would love to see this happen!

2 Likes

I’m also thinking of it. It’s will be super cool, if it is completed.

For galacteek i wrote a torrent to IPFS “bridge”, it first downloads the torrent’s content, and then adds the result to IPFS.

I don’t think some kind of magical “mapping” between the torrent network and IPFS would be trivial to implement …

To try to replace or at least complement BitTorrent, we need to get filestore (which is still experimental as of now) done and enabled as default first. The whole chunking, blockstore, and pinning mechanism is all too much to digest for newbies and non-technical users. Even eMule is more user friendly than IPFS at its current state.

Here is definitely the use case for --mount option to use root IPFS folder CID as mount address to put into BitTorrent client as the path. But the stability… I cannot expect a miracle