IPNS public keys, PeerIDs, and resolving IPNS names with gateways

1

Peer ID encodings

I’m trying to understand better the different representations of an IPNS name and PeerIDs and which representations are supported by gateways. Below are some insights that others may find useful and could be moved to the IPNS docs, which currently don’t explain the anatomy of the actual IPNS name.

The Peer ID Spec says that PeerIDs are:

  • Derived by hashing the encoded public key with sha256 if the key is more than 42 bytes, i.e. RSA key
  • Use the identity multihash (which doesn’t actually hash) if the key is less than 42 bytes, i.e. ED25519 key.

By default, the PeerID that ipfs id returns is a encoded as a raw base58btc multihash (without a multibase) which isn’t a valid CID. For example:

  • QmbLHAnMoJPWSCR5Zhtx6BHJX9KiKNN6tpvbUcqanj75Nb is a raw base58 of sha256 RSA key. Because it’s raw hash without any multibase, CID inspector will confuse this for a dag-pb even though it’s a peerID.
  • 12D3KooWRBy97UB99e3J6hiPesre1MZeuNQvfan4gBziswrRJsNK is a raw base58 of an ed25519 key.

Which string encoding format are supported by IPNS gateways?

The IPFS HTTP Gateway spec is somewhat ambiguous about the supported representations that are supported.

From my experiments, the following encodings are supported:

This begs the question, does Kubo use the same internal representation for all these requests so that if the IPNS record is cached in the data store, all requests will return from cache?

Signed IPNS records from gateways

Kubo 0.19 add Gateway support for returning signed (verifiable) IPNS records.

However, from initial testing this only works for CID encodings of an IPNS names (base32 and base36) but not with the raw base58 multihash.

I’ve opened an issue about this: Gateway support for signed IPNS records doesn't work with raw base58 PeerIDs · Issue #9749 · ipfs/kubo · GitHub