Compare/Contrast PackManifests with torrent files. Identify UX strengths we want to repeat

[flyingzumwalt]

ipfs-pack PackManifest files have a similar structure to BitTorrent's "manifest-like" .torrent files. Torrent files play a prominent role in the BitTorrent UX. This issue is aimed at comparing & contrasting PackManifests and torrent files so that we can consider any implications for the ipfs-pack UX.

First-Pass at Comparison/Contrast

While IPFS has some distinct advantages over bit torrent, especially for distributed archives, there are strong UX advantages to using manifest files as a convenient, compact, relatable way of identifying and sharing datasets.

Implications

The main UX benefit for manifest files is that it allows UX scenarios where I give you a PackManifest (which is a lot smaller than the pack), or the hash of the PackManifest (which is only a few bytes), and you can use that to acquire the rest of the pack's contents directly from the network.

Some implications of this:

• ipfs-pack repo should include the PackManifest in the object store that it builds.
• Consider: in scenarios where I share a datasets, should I share the hash of the PackManifest or should I share the root hash of the dataset? What are the implications of each approach, since both of them ultimately let me retrieve the same blocks.

Background

The original draft proposal for ipfs-pack lists:

Other tooling examples

• BagIt - https://tools.ietf.org/html/draft-kunze-bagit-06#section-2.1.3
• WARC - https://en.wikipedia.org/wiki/Web_ARChive
• BitTorrent's "manifest-like" .torrent file

The ipfs-pack spec addresses the relationship to BagIt bag files in the background and the ipfs-pack bag method description, but it doesn't address the relationships to torrent files. This issue is aimed at gathering that info so we can update the spec and consider any implications for the ipfs-pack UX.

[whyrusleeping]

@flyingzumwalt Do you want to put this in the README?