IPIP-0428: Allowing V2-Only Records in IPNS

1. Summary

Introduce support for creation and validation of compact, V2-only IPNS Records.

2. Motivation

IPNS record creation and validation is overly complex due to the legacy of decisions made in 2021.

The "V1+V2" record creation and validation was reverse-engineered and documented the current state in ipfs/specs#319, which created a base for specifications to improve upon.

A quick refresher on how IPNS Record lifecycle works today (2023 Q2):

• Record Creation produces both V1 and V2 signatures, and the record has duplicated values in both top level protobuf AND data CBOR field.

• Record Validation only cares about V2 signature, but still requires fields related to V1 to be always present in a record and match values from CBOR in data field, for the record to be considered valid.

We've been producing and expecting these hybrid V1+V2 records since 2021.

An unfortunate result is that all mandatory values MUST be duplicated, even when both ends use a modern client that only cares about signatureV2 that guards CBOR field, otherwise the record will not be valid.

What this IPIP aims to improve is allow implementations to produce lean, V2-only IPNS records and ensure clients will interpret them as valid IPNS.

3. Detailed design

Finish V2 story by making V2-Only records possible, namely:

• Record Creation: document and default to lean V2-Only records, keep V1+V2 as legacy backward-compatible variant.

• Record Validation: adjust the algorithm to stop requiring V1 fields when there is no signatureV1.

For details, see the updated [ipns-record] specification.

4. Design rationale

For modern IPNS, the outer IpnsEntry protobuf should effectively only have two required fields: data and its signatureV2, and such record, as long signature is valid, should be accepted as valid.

At the same time, we don't want to break existig software, especially software and hardware devices which use IPNS for pulling updates.

We can get to that future in two steps:

1. Reference implementations (boxo/ipns, js-ipns) will keep producing V1+V2 records as backward-compatible default, but we adjust validation algorithm to allow V2-only records, and support creation of such records as opt-in in modern implementations of IPFS+IPNS, like Kubo (GO) and Helia (JS).

   • Namely, only check/require fields to be duplicated in top level protobuf IF signatureV1 is present in the IpnsEntry protobuf.
     • IF there is no signatureV1, the V1 record would be invalid anyway.
     • IF there is no signatureV1 but signatureV2 and data fields are present and valid, the V2-only record should be considered valid.
       • This will allow people to build V2-only systems that produce records that are considered valid.

2. At some point in the future, e.g. when we see the majority of the public swarm supports V2-Only records, libraries like boxo/ipns, js-ipns and implementations like Kubo will stop producing V1+V2 and switch to publishing V2-only records that are protobuf with only two fields: Data CBOR+signatureV2.

5. Test fixtures

To make testing easier below are test vectors in form of IPNS records along with the expected verification results. These test records are valid for 100 years, making them safe for use in CI tests.

1. V1-only → record invalid
2. V1+V2 (both signatures valid) → record valid, value points at /ipfs/bafkqaddwgevxmmraojswg33smq
3. V1+V2 (both signatures valid, but 'value' is different in V1 pb vs V2 CBOR) → record invalid
4. V1+V2 (only signatureV1 valid) → record invalid
5. V1+V2 (only signatureV2 valid) → record valid, value points at /ipfs/bafkqahtwgevxmmrao5uxi2bamjzg623fnyqhg2lhnzqxi5lsmuqhmmi
6. V2-only (no V1 fields) → record valid