Support other hash-linked filesystems.

[Stebalien]

So, it should be possible to "bridge" between hash-linked filesystems by somehow indicating that we're jumping to a different filesystem. For example:

{
  "type": "dir",
  "system": "swarm",
  "data": CidOfSwarmDirectory
}

{
  "type": "dir",
  "system": "torrent",
  "data": HashOfTorrentFile // i.e., what you get in a magnet link.
}

We can probably punt on this but:

1. Do we want to prefix the type with "ipfs-" or do we want to (possibly later) add a "system" (universe?) field? IMO, we should just use a separate field for simplicity.
2. Should we use this for "bridging" with UnixFS-1.0? The only alternative I can think of is to apply some kind of transparent transform for old merkledag-based files.

[AndreaCensi]

Can this functionality be realized by using CIDs?

[mikeal]

This would be pretty cool.

I’m partial to modifying the type attribute alone though. So something like:

{
  type: “dir:torrent”,
  data: HashOfTorrentFile
}

Since this would be an extension of unixfs-v2 that we don’t expect every implementation to support, this makes it much less error prone for implementations that don’t support the extension.

Can this functionality be realized by using CIDs?

I’m less familiar with swarm, but with torrents it’s a little more complicated than just linking with a CID. The infohash is not the hash of the actual torrent file, it’s a hash of several parts of the metadata that is then added as a property of the torrent file. So the hash itself isn’t something we can easily put a CID on because there isn’t a block that matches that hash. If we link to the torrent file it becomes hard to distinguish between whether you want the torrent file as a file in unixfs-v2 or if you want to interpret the torrent file as a directory for the underlying resources. It’s a much nicer flow on the bittorrent/webtorrent side if we just hand off enough data to get the files in their own terms, which is what this proposal is doing. I’d actually err on the side of embedding a full magnet link, rather than just the hash of the torrent file.

[Stebalien]

Can this functionality be realized by using CIDs?

TL;DR: We can link to the raw content with CIDs but that doesn't tell us how to interpret the data as a directory/file.

---

I’m partial to modifying the type attribute alone though.

That also works as long as we have some consistent type scheme. From a UX standpoint, I'd like to be able to tell a user "this is a directory but we don't know how to understand it". That's why I had separate fields but we can combining them using some form of subtype syntax also works.

[mikeal]

let’s pull @warpfork in at this point to tell us how schemas might help us with a consistent type scheme ☺️

[rvagg]

closing for archival