Change IPFS Path format

[guillaumemichel]

Is your feature request related to a problem? Please describe.
Currently sharing an IPFS url in the browser isn't as straightforward as a http url. I need to copy the the "IPFS Path" first, (/ipfs/bafy...), and then manually replace the prefix /ipfs/ with ipfs:// in order to have a link that can be pasted in another browser using IPFS Companion.

Also, having a "shareable Link" suggest that the other links (e.g IPFS path) are not shareable. Maybe it would be good to rename Shareable Link to something else (e.g HTTP Link, Web2 Link, ...) to emphasize that other links are also shareable.

Describe the solution you'd like

• Change the IPFS Path format from /ipfs/bafy... (interpreted as a file), to ipfs://bafy... that can be resolved by a browser.
• The same with IPNS Path
• Rename Shareable Link to HTTP Link, Web2 Link or something else.

Describe alternatives you've considered
I don't know much about browsers, but an alternative (even better?) solution could be to have the ipfs://bafy... directly in the url bar, that was it is easier to copy paste and share.

Having the following urls (respectively CID and IPNS name) in the url bar isn't very insightful for the end user (especially the .ipfs.localhost:8080 part). Sure, under the hood it is served by a local http server, but the end user should not have to care about it.

http://bafybeic6dlhlnsmzkvzdx3htx4jr6xqgu6ecbrm5dhqmkgvhsi3sbqpxci.ipfs.localhost:8080/2023-how-to-host-dynamic-content-on-ipfs/#use-case-edge-computed-applications
http://blog.ipfs.tech.ipns.localhost:8080/2023-how-to-host-dynamic-content-on-ipfs/#use-case-edge-computed-applications

But again, maybe it is something that cannot be changed in browsers, it is just a "nice to have" if it is possible.

[whizzzkid]

Thanks for submitting this issue @guillaumemichel, this makes sense for the most part. I have some thoughts:

• The browsers don't allowing having a custom protocol using an web-extension, we do register protocol handlers i.e. a ipfs://... and ipns://... link will work and will redirect to your configured node. However, it won't let the url change in the address bar. This works in Brave out of the box, because they have control over the entire build pipeline when using chromium as their base. @lidel and little bear labs are working on https://github.com/little-bear-labs/ipfs-chromium which might solve this issue to an extent but if they can patch this in chromium upstream, that would be the ideal solution.
• The change in formats and labels can be applied fairly quickly, and those make sense.

Thanks again for your feedback!

[lidel]

Good point about missing option to copy ipfs://cid – but ipfs://cid is no longer a "Path" – you copy URI with CID as the authority component.

Note it is easy to reason about labels for simple /ipfs/cid, but you need to consider UX ramifictions for IPNS and DNSLink websites.

For example, on http://en.wikipedia-on-ipfs.org.ipns.localhost:8080/wiki/ we have:

• "Copy Shareable Link" → https://en.wikipedia-on-ipfs.org/wiki/
  (for DNSLlink we use Canonical HTTP URL from website itself, and not public gateway, because it is arguably better security and UX for end user that does not use IPFS)
• "Copy Snapshot Link" → https://ipfs.io/ipfs/bafybeiaysi4s6lnjev27ln5icwm6tueaw2vdykrtjkwiphwekaywqhcjze/wiki/
  (we show this only on /ipns/ namespace, purpose is the same as previous one, but we always copy HTTP URL to immutable snapshot)
• "Copy IPFS Path" → /ipfs/bafybeiaysi4s6lnjev27ln5icwm6tueaw2vdykrtjkwiphwekaywqhcjze/wiki/
  (immutable path, useful for all CLI tooling, and also importing to MFS via IPFS Desktop GUI. Currently, ipfs://cid is not supported there – which is a gap we should close before we remove this)
• "Copy IPNS Path" → /ipns/en.wikipedia-on-ipfs.org/wiki/
  (mutable path, we show this only for /ipns/)

So I see two open questions:

• If we want to change label for "Copy Shareable Link", we need to figure out what to do with "Copy Snapshot Link" too
• We should not remove "Copy IPFS Path" until all tooling understands ipfs:// and ipns://
  • Due to this, I would either not replace, but add a separate menu item for copying ipfs://cid instead of /ipfs/cid, and keep existign ones, OR park this until we have ipfs://cid and ipns://id URI support across the stack (bare minimum: webui and kubo cli)