New IPNS key types

[ianopolous]

We're hoping to use new post-quantum (or hybrid) key types in IPNS in the next few years in Peergos and wanted to start a discussion about how to add new key types. In particular, ones that have 8k-17k signatures. The latter of which would put them over the 10k IPNS record limit.

The bigger issue is that you can't start using a new key type until most clients have upgraded to support it.

NB: I'm not talking about peerIds here if they can be decoupled.

[aschmahmann]

Some thoughts here:

In order to support the new key types as a MAY along with Secp256k1 and ECDSA we need one of two things:

1. libp2p adopts these keys and adds them to the supported key types with new numbers in the KeyType enum https://github.com/libp2p/specs/blob/d2106f43e878ae4c3a1c6465a7c329835290fe22/peer-ids/peer-ids.md#keys
2. We introduce a new way to refer to IPNS identifiers as strings that does not match the PeerID format since the current format is tied to the libp2p-key codec

   specs/src/ipns/ipns-record.md

   Lines 118 to 127 in f68df0c

   	### String Representation
   	IPNS Name should be represented as a
   	[CIDv1](https://docs.ipfs.tech/concepts/glossary/#cid) with `libp2p-key`
   	[multicodec](https://docs.ipfs.tech/concepts/glossary/#multicodec) (code `0x72`),
   	and encoded using case-insensitive
   	[Multibase](https://docs.ipfs.io/concepts/glossary/#multibase) such as Base36.
   	A good practice is to prefix IPNS Name with `/ipns/` namespace,
   	and refer to IPNS addresses as `/ipns/{ipns-name}` (or `/ipns/{libp2p-key}`).

Make it libp2p's problem

• Not totally unreasonable for them to want to support new key formats
• Clients need to update in order to handle the new key types
• If the idea is to use the Amino DHT to hold the records then the DHT servers would need to update to handle the new key type (and size limit)
• Either the set of implementations bumps the baseline supported max record size, or these only work in certain places

Diverge from libp2p-key

• Allows the different projects to move at different speeds here
• Makes it easier to be more explicit about evolving IPNS identifier and record semantics than previously
• Needs similar kinds of update propagation (although potentially more) as with it being libp2p's problem
• Requires agreement on the new formats (i.e. record formats, identifiers, and compatibility requirements) which could potentially be a bunch of work

---

Even if going with libp2p-key there's still the issue of whether increasing the record size everywhere even makes sense.

• If implementations are ok with this then things are relatively straightforward
• If not, since we're going from realistically under under 200 bytes feat: update IPNS specification #319 (comment) to like 20k bytes, then this is doable it just means they won't be able to go everywhere. For example anywhere that a record is too big to go instead insert pointers to the entities that have copies of the records since they are self-validating.
  • This is similar to how kubo does IPNS over PubSub by using the Amino DHT as a rendezvous point
  • Other mutability approaches like Mutable namespace using "Mutex blocks" #258 could operate similarly in that their validation could be "too expensive/difficult" to be done by Amino DHT nodes, IPNI nodes, arbitrary record databases, etc. and so you can tradeoff some convenience for smaller record sizes + extensibility here.

Also, as a bonus the approach where you store pointers instead of records in places like the Amino DHT also means that fewer systems need to upgrade to support new key types in order for the end-to-end user experience to work (e.g. no need for the Amino DHT network to update to support the new key type, just for the providing and client nodes).

[lidel]

Realistically, decoupling IPNS from libp2p-key codec across ecosystem will be way more work than the actual work related to adding a new key type. A side-quest that is bigger than the main quest of adding new key type.

Due to ecosystem effects, keeping them in sync always be way less work than decoupling, and (imo) as long it is specified as MAY, we don't have to add new key type support to every libp2p impl., just reserve the number in protobuf defn. to ensure libp2p and IPNS do not end up with conflicting codes.

@ianopolous if you are interested in pushing the IPNS specification work forward, and want to focus on new key type alone, introducing a new key type by reserving enum in libp2p-key protobuf definitions at both places feels like the first step.

Itwill ensure peerid and ipns remain in sync, and we don't run into problems when libp2p adds something new:

1. Open PR that adds it to https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md#keys (and include information on how signature is generated)
2. Open IPIP (template) that adds the same to https://specs.ipfs.tech/ipns/ipns-record/#key-serialization-format

Other details, such as increasing max size of IPNS record, would be part of the IPIP PR.

[ianopolous]

Thanks @lidel ! It will be some time before I can get to this, but I will do that.