Why use "/ipfs/" instead of "ipfs://"?

If you told that IPFS is a protocol, why do not use “ipfs://” for canonical links?

The browser extension “IPFS Companion” is using “/ipfs/” for canonical links, why not “ipfs://”?

Typing ipfs:// in the browser would be more beautiful and simple than the ugly and proprietary https://ipfs.io/ipfs/

The browser could find directly the file behind “ipfs://” in the network, instead of going through the “ipfs.io” server. This would be truly decentralized and easy to share.

An ipfs link is easier to share and less destructible than a ordinary, ugly, and centralized http link.

The only problem with the ipfs:// link is that you would have to install a browser extension (or a new browser itself, who knows?), but we can hope that common browsers will include the ipfs:// protocol directly in their code in a near future.

See this github thread for an extensive discussion. The link is to a comment that attempts to summarize the thread.

TL;DR: ipfs:// in particular is reportedly wrong according to W3C rules for non-authority based protocols, but protocol labs’ tools will redirect ipfs://.

1 Like

If i’m not wrong Brave Browser allows files to be accessed using ipfs://

@Hazae41 - Check out their IPFS plugin. It may interest you.

Furthermore it’s a file system, so /ipfs/* should be canonical, and maybe file://ipfs/*.

I’ll just add some related reading for curious cats:


  • browser extension enables users to copy either:
    • Canonical, future-proof NURI (Nestable URI a.k.a. path addressing), as it can be used in both browser (by prefixing it with dweb:) and command-line tools (as-is)
    • URL to resource at public gateway (that can be shared with people without IPFS extension/daemon)
  • ipfs:// support and usability are highly limited (that is why it is not “canonical”), for more context:
  • partial native support in Brave (progress tracked here)
  • no native support in Firefox and Chrome, only redirect to gateway URL (ipfs-companion/#164)

The simple answer is that the colon makes it NOT compatible with Unix filesystems while the way it is structured now with /ipfs/ makes it so that it is compatible with unix filesystem which opens a whole new door.

Juan Benet explained this in one of his talks but I can’t remember which one.