Move IPFS addressing spec to ipfs/specs

[lidel]

The best and up-to-date source of truth about IPFS addressing right now is in ADDRESSING.md memo.

As more and more people add IPFS support to their software, especially on the web,
we should decrease noise and increase signal around addressing by adding proper technical spec doc to the ipfs/specs repo, as suggested in #138.

Timeline

• 2022:
  • WIP gateway specs, compliance and consolidation work
• 2021: 💚 Brave supports ipfs:// an ipns:// out of the box (details)
• 2020: 💚 Collab with Igalia resulted in ipfs:// and ipns:// URIs being registered at IANA (details)
• 2019:
  • interop with foo:// libraries: should work with case-insensitive identifiers (Base32)
  • spec on addressing & use of multiaddr
• 2018: ADDRESSING.md memo is created as a techncial summary of ipfs/specs/dweb-addressing
• 2018: Suborigins & Subdomains
• 2017-2018: ipfs/specs/dweb-addressing branch with lots and lots of notes
• 2015-2017: Memo with Background on Address Scheme discussions: Background on Address Scheme discussions (dweb, ipfs:// and more) #152
• 2017: Tackle identifying origins: Tackle identifying origins with (or without?) dweb: paths in-web-browsers#6
• 2017: The four stages of the upgrade path for path addressing Background on Address Scheme discussions (dweb, ipfs:// and more) #152 (comment)
• 2016: Support Custom Protocols in WebExtension Support Custom Protocols in WebExtension ipfs-companion#164
• 2015: First discussion about addressing schemes Standard URI for ipfs and ipns protocols (Discussion) kubo#1678

TODO

• create a new PR to ipfs/specs (consolidate technical content from Prior Art)
  (https://github.com/ipfs/specs/blob/master/DWEB_ADDRESSING.md, reuse Background on Address Scheme discussions (dweb, ipfs:// and more) #152)
  • PR should aim to close spec: ipfs: and ipns: URI schemes #138
  • close First draft of ipfs: URI spec, see #138 #139 and point at new PR
• ensure it covers /ipns/ as well (IPNS: should work with case-insensitive identifiers (Base32) kubo#5287, IPFS Addressing in Web Browsers, ipns://, and DNSLink in-web-browsers#118)
• get it merged to ipfs/specs repo
• update ADDRESSING.md to point at the doc in ipfs/specs
• close remaining issues/PRs about addressing with comment pointing at document in specs repo (add links below so we don't forget)
  • URLs for IPFS paths ipfs-inactive/interface-js-ipfs-core#287
  • [NEW CONTENT] Dweb addressing ipfs-inactive/docs#91
  • Standard URI for ipfs and ipns protocols (Discussion) kubo#1678
  • IPFS Addressing in Web Browsers, ipns://, and DNSLink in-web-browsers#118
  • spec: ipfs: and ipns: URI schemes #138
  • Tackle identifying origins with (or without?) dweb: paths in-web-browsers#6
• identify remaining content from Prior Art that could be extracted into ipfs/blog post or less technical ipfs/docs

cc ipfs/in-web-browsers#118 ipfs/in-web-browsers#3 ipfs/ipfs#227 ipfs/in-web-browsers#4 ipfs/in-web-browsers#28 #139 @autonome

[vanrein]

ip[nf]s://<domain.name>/object

Retrieval would be processed as "DNS look up domain.name IN TXT, resolve resulting IPFS/IPNS identifier, retrieve object".

I was reading this, hoping to find just that. IPFS wants to get away from hosting locations for reasons of persistency, but IPNS is different. I love the idea of using DNS (and DNSSEC) and getting very powerful bookmarks:

1. Stored domain name, for human reference where it once originated from
2. Stored IPNS key, so we can lookup the names from anyone who pins them, along with new versions from the same origin
3. Stored IPFS hash, so we can retrieve the version that we bookmarked for as long as it is pinned

I will add the spec to my reading list, it's useful stuff!

[BigLep]

2022-03-01 discussion: we may add an issue for separating out the gateway tests that are in go-ipfs so have a "poor-mans" compliance test suite for gateway implementations.