Floats

[DavidBuchanan314]

The atproto data model disallows Floats https://atproto.com/specs/data-model (although in practice, the current implementation(s) tend to allow them, due to reuse of generic IPLD tooling)

DASL currently doesn't have an opinion about floats. Should it?

[bumblefudge]

I personally have not thought this far ahead, but insofar as DASL uses DAG-CBOR w/tag42 implemented in place of a more unopinionated IPLD, so I would say we still have multiple options open to us, modulo a curveball from the CBOR WG. I.e., dCBOR implementations have the option to profile them out per application profile/implementation couple, but also tells you how to handle them if they're not profiled out, depending on whether they're standards signed 64bit ones or more exotic ones. See the third paragraph of section 2 specifically.

[achingbrain]

I think if dCBOR42 breaks compatibility with DAG-CBOR, it should use it's own codec to ensure compatibility. This is fine and exactly what the multicodec table is for.

Perhaps it could solve other rough edges with DAG-CBOR, such as when you deserialize a number, the number type returned is the smallest type that the value will fit in.

This leads to weird edge cases where you can put a low-value BigInt in but get a Number out, and the two types are completely incompatible in JS, but you don't want to mandate BigInts for everything because they are slow and cumbersome, so then maybe you need a schema, then you have to figure out how to ship your schema with your data, or you have to enforce the types some other way, and, and, or, or 🤮 ...