Deprecating the Public Key DHT Namespace (/pk)

[aschmahmann]

Proposal

Move towards dropping support for the /pk DHT namespace. This seems to have been the intention for at least a couple years, see: https://github.com/ipfs/go-ipfs/blob/de6f783f7737d5c184f4cd2163d9ffa286f073c6/namesys/publisher.go#L234-L236

Background

The /pk namespace maps Hash(PublicKey) to PublicKey. It has been useful primarily retrieving the public key that verifies an IPNS record, which was necessary a couple years ago to resolve IPNS records. However, we have been embedding the public keys in the IPNS records for quite some time and so this functionality no longer appears to be useful.

Why Now?

On top of this being long overdue, I'd like to do some refactoring of the go-libp2p-kad-dht (e.g. separating out the libp2p and IPFS components more cleanly) later this year that could be made easier by dropping support for the /pk namespace. Additionally, js-libp2p and js-ipfs are looking to add more DHT support so removing some of the junk around /pk should make their lives easier as well.

While there is currently a bug in go-ipfs that may prevent us from dropping support for the /pk namespace immediately, I'd still like to do it soon as putting /pk records is a waste of resources and worrying about maintaining it is a bit of a headache.

Ask

If there are any applications currently using this namespace please post here so we can figure out next steps.

[lidel]

We still have /pk around, but might be able to do something about it soon:

• (remove cleartext /pk) include this as part of cleanup refactor IPNS: allow lean V2-only records #376
• (add privacy-preserving replacement) modernize on top of double hashing DHT work IPIP-373: Double Hash DHT Spec #373