Magnet link in IPFS

[jxxp9]

Will it be possible to fetch and resolve a typical bittorrent magnet link using IPFS? This way, those link (referring to well identified content) don't get broken if (hopefully soon) we'll use IPFS to share files. They'd need to be mapped to corresponding IPFS object, I guess. But is it doable, theoretically, or I'm totally wrong?

[jbenet]

IPFS already has its own link, URI formats, which are 100% unix-safe:

/ipfs/<hash>/<path>
/ipns/<hash>/<path>
/ipns/<domain>/<path> # hacky shortcut to one below
/dns/<domain>/<path>

You can already use this in browsers. we are working on the many pieces necessary for resolution to work in browsers out of the box:

• an HTTP gateway for fallback: http://gateway.ipfs.io/ipfs/Qme3pKkedCfcebDmkZz5tU2suMjHP4EPi29NMNNxQrQzwy/done
• a javascript implementation: https://github.com/ipfs/node-ipfs (in progress)
• browser extensions that resolve ipfs links (chrome, firefox) using a local (or gateway) ipfs node (temporary)
• unixweb:// (actual name TBD) protocol that muxes unix-safe URIs, like /ipfs/..., /ipns/..., /dns/... (temporary)
• patches for the main browsers adding IPFS support (this is TRTTD, but obviously harder)

[jxxp9]

Great! Thank you so much!

[jbenet]

should we keep these open, or close them? am not sure if people will see them if closed?

[jxxp9]

Let it open, so others too can comment, thanks!

[Mithgol]

URLs in form ipfs:Qme3pKkedCfcebDmkZz5tU2suMjHP4EPi29NMNNxQrQzwy/done seem useful because they are relatively short (51 characters plus the length of the path such as /done).

For example, they won't be broken in the middle to be forcibly wrapped to the next line on a traditional (80 characters per line) terminal unless the path (after the hash) exceeds ≈28 characters. That's at least twice as good as the old 8.3 character limit.

They are also less likely to cause horizontal scrollbars in modern editors or HTML textareas.

Unfortunately, such short URLs are supported, as far as I can tell, only by the addon for Firefox.

For the sake of comparison:

• possible future unixweb://ipfs/ URLs are 10 characters longer than ipfs:,
• the current http://gateway.ipfs.io/ipfs/ URLs are 23 characters longer than ipfs:.

[jbenet]

the canonical paths will start to look like:

/ipfs/<hash>/<path>
/ipns/ipfs.io/docs/install

[jbenet]

please note that the unixweb;// or nix:// thing is a workaround, not meant as the canonical identifier. people SHOULD still use just:

/ipfs/<hash>/<path>
/ipns/ipfs.io/docs/install

it's annoying right now, but it will lead to a much better future if we fix the massive UNIX / Web rift.

[hikari-no-yume]

Does this actually work properly with the web's security model? If different IPFS sites are just different paths under one hostname, then under the Same-origin policy, all IPFS sites would appear to have the same “origin”, which could be problematic.

It's also inconvenient that IPFS sites are unable to use absolute paths with / for self-reference.

[whyrusleeping]

This is something we hope to address with per page suborigins: https://w3c.github.io/webappsec-suborigins/

[flyingzumwalt]

This issue was moved to https://discuss.ipfs.io/t/magnet-link-in-ipfs/385