add dnslink namespace

[lidel]

Rationale:

• been around since the very early days, seems we just never added it because /ipns/ was good enough for existing use cases
  • we already have dnsaddr, which works similar way, but for multiaddrs (TXT records), adding dnslink removes the uncertainty if someone wants to use codec to distinguish between the two
  • cc @Stebalien in case I am missing any reason we should not have this as a codec
• we want to support DNSLink chaining without /ipns/ in TXT records, so it is useful for non-IPFS use cases
  • dnslink=/dnslink/example.com
  • (we had to remove mentions of it https://github.com/ipfs/ipfs-companion/issues/1039 for now due to ambiguity and lack of support in our stack, this PR will enable us to close this gap)
• we want a clear way for pinning DNSLink names within Pinning Service API (https://github.com/ipfs/pinning-services-api-spec/issues/85), that is separate from pinning IPFS (cryptographic records)

[rvagg]

sgtm, but could we bump this above 0x7f to save that precious single byte space? or do we anticipate the codec code being used enough to warrant a short code?

[mrodriguez3313]

I understand the problem, but I don't understand the solution. Would adding this one csv entry, allow go-ipfs to interpret /dnslink? Thus we would re-add (later on) this feature in the dnslink docs to say, 'Hey! If you're using dnslink for your site, use "/dnslink" instead of "/ipns". Because of this...! :

• we want to support DNSLink chaining without /ipns/ in TXT records, so it is useful for non-IPFS use cases dnslink=/dnslink/example.com
• we want a clear way for pinning DNSLink names within Pinning Service API (https://github.com/ipfs/pinning-services-api-spec/issues/85), that is separate from pinning IPFS (cryptographic records)

[lidel]

@rvagg I don't think it will be as useful as /ip4, more likely usage will be closer to ipfs-ns and ipns-ns ones. Moved to 0xe8 – would this work?

@mrodriguez3313 It is not enough, this PR is only a formal prerequisite that needs to happen before we implement support for mentioned use cases.

[RangerMauve]

What would CIDs with this new codec look like?

[lidel]

@RangerMauve bit bizarre, but in places where DNSLink has to be passed as a CID, one could inline DNS name (ASCII) using identity multihash, something like:

$ echo -n 'dnslink-site.example.com' | ipfs add --inline --raw-leaves -Q
bafkqagdenzzwy2lonmwxg2lumuxgk6dbnvygyzjomnxw2

(but with dnslink instead of raw codec)

[RangerMauve]

Hmmm. Personally, the CIDs for DNS Name approach seems like it'll add a lot more burden for pinning service client implementations since they'd need to include CID libraries in whatever code they're writing (I'm a dependency minimalist 🤪).

Have you considered alternatives to CIDs like URLs? e.g. instead of passing a CID, clients could specify a ipfs://bafywhatever URL or ipns://ipfs.io/subpath URL. It'd add more work on the pinning service implementor side, but it might make the client side a lot more flexible. 🤷 (I'm also really into URLs)

[lidel]

@RangerMauve agree on many of your points, would appreciate your feedback in discussion on "how to pin mutable content paths" happening in https://github.com/ipfs/pinning-services-api-spec/issues/85.

Let's keep discussion in this PR limited to adding dnslink codec (to be in pair with existing dnsaddr)

@vmx @rvagg ok for me to merge this?

[vmx]

I know too little about all this, hence this one is not blocked on me.