Is this repo actually used?

[anacrolix]

I can't find any packages that reference this repository (and none are shown on godoc.org). Functionality seems to be reimplemented in github.com/ipfs/go-ipfs/namesys. As such I think it's potentially misleading to have an implementation that can drift from the official IPFS behaviour. The ipfs tool has the dns subcommand, among others that perform the behaviour in this package. Perhaps it should be deleted?

[anacrolix]

See #5 as an example of drift from canonical behaviour.

[Stebalien]

You appear to be correct. I've filed a bug in go-ipfs: ipfs/kubo#5902

[Stebalien]

@anacrolix per the discussion on the go-ipfs issue, want to put together a PR with a note deprecating this? Leaving buggy repos around for users to trip over is not particularly nice.

[anacrolix]

What about just removing it entirely, and directing to ipfs/go-ipfs/namesys? The repo's existence alone will lead consumers of the PL ecosystem to assume that it contains the implementation of dnslink.

[Stebalien]

I try not to break links (and code we may not know about) unless we really need to. Instead, we can:

1. Add a deprecation notice pointing to ipfs/go-ipfs/namesys.
2. Archive the repo. That way, it shouldn't show up in the org's repo list, as far as I know.

[jbenet]

I use this. don't delete it. This tool is standalone-- do not deprecate it. It's not harming anybody. If you don't want it, transfer it to me. i'll keep it.

We build modular tools that can be used for a variety of things.

Stop removing things, just because you don't use them. Imagine if people started removing tools from the unix or gnu toolchain!

Stop breaking things. we are the group of people that believe in not breaking links.

[jbenet]

Sounds like @anacrolix is bothered by the note dnslink resolution in go-ipfs. Just remove that if it's not used in go-ipfs anymore.

But for those of us who use the cli tool-- don't break us

[Stebalien]

We should add a notice explaining that it hasn't been kept up-to-date with the spec and is no longer maintained. The idea behind archiving is to clearly communicate that. It leaves it in place for people using it but makes it clear that it may not work as expected.

Concretely, this tool:

1. Doesn't resolve _dnslink.domain.
2. Resolves /dns/..., not /ipns/....

[jbenet]

hasn't been kept up-to-date with the spec and is no longer maintained.

that's backwards. /dns/... is the newer way of doing things for dnslink. /ipns/<dns-domain> is older than /dns/<dns-domain>. I'm motivating change toward /dns/<dns-domain>. Though, purely for IPFS's use case, it doesn't need to worry, and can leave /ipns/... working as intended.

note: dnslink is not just for ipfs. perhaps, dnslink should live in multiformats org not in ipfs org.

The idea behind archiving is to clearly communicate that. It leaves it in place for people using it but makes it clear that it may not work as expected.

I don't think archiving is a good mode for that. Put a bold, clear notice that says:

This should work as expected, but it is not actively maintained. You should use with caution.