Skip to content
This repository has been archived by the owner on Jun 29, 2022. It is now read-only.

Data Model claims (erroneously?) that DAG-CBOR rejects integers outside of 64 bit range #362

Open
tysonzero opened this issue Apr 19, 2021 · 1 comment

Comments

@tysonzero
Copy link

The DAG-CBOR spec does not seem to mention this limitation.

The CBOR spec itself directly mentions how to encode bignums, so it seems like this limitation can be avoided.

@warpfork
Copy link
Contributor

We've gone back and forth on how to describe this. It's difficult because what a spec says and what implementations do are also never in perfect alignment, and I think we'd like to write specs such that most implementations don't have a hard time complying most of the time.

I believe the current stance we've adopted is "a compliant implementation of the IPLD Data Model must support integers up to at least 2^53". Note that larger number support is not forbidden by this definition, either. (So, indeed, the golang implementation will do 64 bits (signed). But we picked 2^53 because that's the upper limit that's reliably safe to use with native integers in all widely circulated javascript implementations.)


The CBOR RFC does mention bignums, yes.

However, they're in section 3.4. Tagging of Items. Notably, they are not included under 3.1. Major Types, which is where most of what I might loosely call "the core" of CBOR is defined.

DAG-CBOR doesn't generally allow use of CBOR's tagging feature. This is because it would be an uncomfortable superset of the IPLD Data Model: if we allowed arbitrary tagging, we would either have to add an equivalent feature to the Data Model (which would make mapping it onto every other codec harder), or, we would have to roughly double the depth of the Data Model tree with DAG-CBOR morphs into (so we'd have room for all the tags to be placed in a special map alongside the other data).

We don't currently have any support for bignums in our implementations. If we wanted to add them, we would need to start with the spec, and the most important thing to decide and define would be how we predictably transition to them (e.g. at exactly what threshhold we stop using the CBOR major type for ints and when we start using the tagged extension for bignums), because we would need that threshhold to be consistent if we wanted bijection between datamodel and this form of extended CBOR to work.


I hope this provides some useful clarificaiton, but I'll also leave this issue open as a reminder that we (still) need more discussion of this in the specs and documentation (and better crosslinking between places where the subject appears).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants