From @Piruzzolo on Tue Aug 25 2015 21:30:55 GMT+0000 (UTC)
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?
Copied from original issue: https://github.com/ipfs/faq/issues/25
From @jbenet on Tue Aug 25 2015 22:10:20 GMT+0000 (UTC)
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)
From @Piruzzolo on Tue Aug 25 2015 22:14:46 GMT+0000 (UTC)
Great! Thank you so much!
From @jbenet on Tue Aug 25 2015 22:15:33 GMT+0000 (UTC)
should we keep these open, or close them? am not sure if people will see them if closed?
From @Piruzzolo on Tue Aug 25 2015 22:16:42 GMT+0000 (UTC)
Let it open, so others too can comment, thanks!
From @Mithgol on Mon Sep 14 2015 09:11:16 GMT+0000 (UTC)
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 thanipfs:, - the current
http://gateway.ipfs.io/ipfs/URLs are 23 characters longer thanipfs:.
From @jbenet on Mon Sep 14 2015 16:28:22 GMT+0000 (UTC)
the canonical paths will start to look like:
/ipfs/<hash>/<path>
/ipns/ipfs.io/docs/install
From @jbenet on Mon Sep 14 2015 16:29:39 GMT+0000 (UTC)
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.
From @hikari-no-yume on Mon May 02 2016 19:46:08 GMT+0000 (UTC)
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.
From @whyrusleeping on Mon May 02 2016 20:09:58 GMT+0000 (UTC)
This is something we hope to address with per page suborigins: https://w3c.github.io/webappsec-suborigins/