..but this only applies to the protobuf fields from IPNS v1.
For wider background, documentation and cleanup of v1 vs v2 was done in #319, #376.
In IPNS v2 we store values in DAG-CBOR map in Data field, and fields like the TTL read from v2 Data field (DAG-CBOR) is represented as int64 (see boxo/ipns code).
In other words, in GO impl. time.Duration is represented as int64, and that is how "uint64" fields like TTL are stored in v2 Data field (CBOR). This is also confirmed by the way IPLD data model impl. at go-ipld-prime/node/basic works.
Solution
Ideas welcome. My initial idea is to move away from go specific.
Clarify this in the IPFS specification and mark these fields as language-agnostic integer and then add bullet points in their respective section that when represented in legacy v1, the type for protobuf is uint64, and when represented in v2 (dag-cbor) it is int64.
cc @2color as you've been working with TTL in JS recently.
Problem
IPNS Record spec lists Validity, TTL and Seq as uint64:
..but this only applies to the protobuf fields from IPNS v1. For wider background, documentation and cleanup of v1 vs v2 was done in #319, #376.
In IPNS v2 we store values in DAG-CBOR map in Data field, and fields like the TTL read from v2
Datafield (DAG-CBOR) is represented asint64(see boxo/ipns code).In other words, in GO impl.
time.Durationis represented asint64, and that is how "uint64" fields like TTL are stored in v2 Data field (CBOR). This is also confirmed by the way IPLD data model impl. at go-ipld-prime/node/basic works.Solution
Ideas welcome. My initial idea is to move away from go specific.
Clarify this in the IPFS specification and mark these fields as language-agnostic
integerand then add bullet points in their respective section that when represented in legacy v1, the type for protobuf isuint64, and when represented in v2 (dag-cbor) it isint64.cc @2color as you've been working with TTL in JS recently.