Discussing pre-existing specs, adoption and behaviors

[lidel]

@autonome @jonnycrunch
Something I'd like to understand before we proceed is the nuance of registering at IANA.

Wrote short summary below to make sure we all have the same context.

History

Initial four stages of the upgrade path for path addressing (2017) looked like this:

• HTTP-to-IPFS gateway https://ipfs.io/ipfs/<cid> (path gateway)
• Short term: URL ipfs://<cid>
• Mid term: URI dweb:/ipfs/<cid>
• Long term: NURI /ipfs/<cid>

Then came reality check.

Content root (CID) not being the authority component of the URLs not only made it harder to publish websites due to relative path issues, but the lack of origin separation in web browsers caused us recurring headaches.

That is why we are in the process (2020) of extending the first stage with a new type of HTTP gateways that follow Web Security model:

• HTTP-to-IPFS subdomain gateway https://<cid>.dweb.link/

Current Status

ipfs:// URL

Current status quo is at https://docs-beta.ipfs.io/how-to/address-ipfs-on-web/ and #native-urls section defines ipfs:// URLs as pragmatic way of addressing IPFS resources in web browser contexts.

Adoption:

• Our desktop app and browser extension add support for resolving ipfs://<cid> URLs
• People seem to expect URL instead of URI, at least in browser context
• ENS specs use ipfs://<cid> notation when in text: https://eips.ethereum.org/EIPS/eip-1577

dweb:/ipfs/<cid> URI

The idea of URI+NURI hybrid we were historically toying with was dweb:/ipfs/<cid>, but multiplexing protocols other than IPFS (eg dweb:/dat/<hash>) does not seem to be feasible given how protocol handlers work in browsers today. This not advertised in our docs anymore.

See discussion at: arewedistributedyet/arewedistributedyet#28

Adoption:

• experimental support in desktop app and browser extension, but that is about it
• AFAIK no adoption outside of our experiments

Arguments against:

• people pointed out this feels like not invented here syndrome
• existing solutions that we could adopt instead of creating new URI
  • URN: urn:ipfs:<cid>
  • Magnet links magnet:?xt=urn:ipfs:<cid>

NURI /ipfs/<cid>

Supported only by native IPFS tooling.

Next

Having the above context, I think we need to answer below two questions:

1. should we register URI at IANA ipfs:?
   • As URI>URL, does this mean we effectively register ipfs://, or am I getting this process wrong?
2. should we also register URN namespace at IANA: urn:ipfs:<cid>?
   • Any reason not to?

[jonnycrunch]

URL vs URI

In effect, URLs are a form of URIs. The ipfs:// does define a URI that is self describing by the CID, but may also defines a path to a file hierarchy below the CID. (i.e. ipfs://<cid>/README.md). How the URI is dereferenced and resolved via multiple distributed locations or mechanisms such as libp2p, via an http gateway or even raw binary that can be embedded in the CID and made into a qr-code makes it a URI. The ABNF rules defined in the application will define the syntax. The reservation of the ipfs:// scheme name can happen in parallel with the definition of the ipfs protocol and will define dereferencing and resolution. My take is the syntax is stable enough for adoption into IANA registry.

The initial application just reserves the scheme name ipfs and the initial rational for its need in the world before the international poopy file system takes it.

URN

I like URNs, but most people don't understand what a URN is and most browsers don't support them anymore as native links that can be dereferenced and they are no longer resolvable. Mostly URNs are the bastard step-child of the href with <a href="http://example.com" urn="urn:">link</a>. This can happen in parallel. Certainly would be helpful for semantic web application where URNs are broadly used. Also, a URN doesn't specify any guarantees that the resource can even be resolved, only it is under that namespace authority. (like books under isbn, i.e. urn:isbn:978-0385476768, which my favorite book, but I challenge you to find it by this reference without using the ISBN website).

dweb

I think this will get immensely complex and messy with too many cooks trying figure out the syntax and protocols, etc. It also seems like a registry of registry and I'm not sure who would organize the path namespace /ipfs/<cid> or the trailing <cid>.ipfs. Besides, most people understand scheme names ipfs:// is just like http:// and ftp:// and easier for people and browsers to get their head around.

NURI

I'd love to see this happen! Linux Foundation and native kernel support would seem like the best approach.

[lidel]

URI

Great, I feel we are on the same page regarding ipfs://
How does the IANA process look like? Fill up sections and submit produced PDF?
Anything specific I can help with?

URN

We should get URN in parallel to ease adoption in semantic web contexts via urn:ipfs:bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
Is the URN process similar? Do we need a separate repo?

[edsu]

I don't think URN is really used in semweb contexts is it?

[christianbundy]

I thought that URNs were a subset of URIs, right? The SSB URI format closely resembles a URN.

[lidel]

@christianbundy yes, for most practical purposes they are, but here we talk about urn:ipfs, specifically for use in contexts that require urn: and "formal backing of IANA".

• I am closing this as ipfs:// and ipns:// URIs got accepted by IANA:
  Register URI with IANA ipfs/in-web-browsers#29 (comment)
• URN registration work in tracked in: Register URN with IANA ipfs/in-web-browsers#161
  • cc @jonnycrunch – I believe we can repurpose this repo for that work