Interop with IPFS tools

[lidel]

May be worth considering to support proposed subdomain convention (https://github.com/ipfs/in-web-browsers/issues/89):

https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.<example.tld>

That way:

• Original CID is easy to identify and copy&paste
• .ipfsSubdomain(url) could be used for quick validation by various tools and websites
• Service becomes protocol-agnostic, eg. IPNS support can be added in future as https://<key-in-b32>.ipns.<example.tld>

[ricmoo]

I would love to, and have considered it. The problem is that it does not play well with ENS.

The reason to start a domain with 0xg is to mark it immediately as an invalid ENS name, since names starting with 0x can be confused with an address, so are recommended not to be supported as ENS names, and the g provides a version, so in the future we can change the following format a bit.

Other ides I’ve considered is specifying a limit to the length of an ENS name, or simply using 2 separate domain names, one for ENS and one for multihashes.

But you could imagine, someone could purchase the ENS name “bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq” to hijack that multihash, so we need some way to know the difference.

I will be likely getting multiple domain names, since I worry about trademark infringement with Meeseeks too. :)

[lidel]

Let me know if I understand correctly: the problem you are solving with 0xg prefix is mixing mutable and immutable things under a single namespace. Is that the only real reason?

The convention I proposed uses an explicit .ipfs. subdomain exactly to avoid that mixing:

• It creates a separate namespaces for immutable v. mutable content, which makes it easier to validate, control caching and reason about (identifiers are not mutated, better UX overall).
• Subdomains approach is not bound to a specific technology, as you can add new "resolver subdomains" in the future, or keep multiple versions side by side.
• If you have separate namespaces, you could also provide "public ens gateway" service, similar to IPFS one.
• You can still have a "catch all" namespace if you really want one, but it should return HTTP 30x redirect to a resource under a specific subdomain, making it extra clear to user what is being loaded, eliminating "ENS name spoofing" problem

An illustration of subdomain-based approach applied to different things:

# right now
                      <???>.meeseeks.app # immutable (ipfs as 0xg-prefixed stuff) + mutable (non 0xg?)

# subdomain-based "ENS gateway"  
                      <???>.meeseeks.app # → redirect to one of subdomains below
human-readable-ens-name.eth.meeseeks.app # mutable data, exposes *.eth in a way that keeps nice URL
            <cidv1b32>.ipfs.meeseeks.app # immutable data (ipfs gateway)
      <dnslinked-fqdn>.ipns.meeseeks.app # mutable data (ipfs gateway)
          <key-in-b32>.ipns.meeseeks.app # mutable data (ipfs gateway)

When I am looking at the above I feel I am still missing some context to see the point of keeping 0xg and a single namespace. Am I missing something obvious?