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.