Encoding pieces and aggregates that have size in uint64

[Gozala]

Here is what IPLD spec has to say about the integer support https://ipld.io/design/tricky-choices/numeric-domain/#integers

In principle, we consider the range of integers to be infinite. In practice, many libraries may choose to implement things in such a way that numbers may have limited sizes.

We require that IPLD libraries support integers up to at least size 2^53 in order to be considered a full-featured core-compliant IPLD library.

We love IPLD libraries that support arbitrarily large numbers. But 2^53 is the critical minimum.

It is not yet clear what will happen if e.g. CBOR is given a number greater as in would it silently fail or, crash or something else.

[Gozala]

My plan is to do following:

• [ ] Try to find out with IPLD OGs what the expected codec behavior is for uint68
• [x] Find out how IPVM deals with uint64 / uint128
• [x] Look into how data-segment library encodes this information

[Gozala]

Look into how data-segment library encodes this information

Looks like data-segment lib encodes log2 of leaf count from which size of the pice could be derived https://github.com/filecoin-project/go-data-segment/blob/41a48065383eca6f52efc4ee78a9902a9d25293b/merkletree/hybridtree_cbor.go#L139-L145

We could probably follow this approach instead of encoding size itself. Only downside is it will not work for anything else. I do kind of wish CID contained than information instead however

[Gozala]

Here is the fun fact

JSON.parse('{ "n": 18446744073709551615 }')
{ n: 18446744073709552000 }

[Gozala]

Did bit more investigation and it appears that at least DAG-CBOR and DAG-JSON handle uint64 as expected https://observablehq.com/@gozala/uint8-in-ipld

[Gozala]

Find out how IPVM deals with uint64 / uint128

IPVM team had not got around to dealing with this yet