You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 29, 2022. It is now read-only.
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.)
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
The text was updated successfully, but these errors were encountered: