Native CBOR Support

[WebWeWantBot]

---

title: Native CBOR Support date: 2021-02-18T18:11:14.044Z submitter: Brad Isbell number: 602eadc2a6174300d5585008 tags: [ ] discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/ status: [ discussing || in-progress || complete ] related:

• title: url: type: [ article || explainer || draft || spec || note || discussion ]

CBOR is a standardized binary structured data format, akin to JSON, with additional benefits:

• Efficient storage of binary and numeric data types
• Data types such as Date can be stored directly
• Extensible with future data types, while maintaining backwards compatibility (https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml)
• It's inherently streamable (similar to NDJSON in that it's easy to skim a stream of objects as there is no top-level enclosure)

CBOR was first published in RFC7049 in 2013. Some editorial improvements have been made, with the current standard published at RFC8949

The format is well supported, with implementations in most all commonly used languages: http://cbor.io/impls.html

Use cases include:

• Encoding binary file data inside a structured object for API-like calls without base64-encoding the payload or cross-referencing multipart MIME. (There are a handful of questions per-day on Stack Overflow about base64 encoding file data so that a file upload can be kept in context of an object being sent to a server. This is horribly inefficient.)

• Encoding/decoding all of the data types modern JavaScript engines support, including typed arrays.

• Efficient and extensible web tokens with CWT

Currently, we can work around the problem by loading a CBOR JavaScript library to encode/decode. However, I believe a native implementation would have performance improvements. At a minimum, we wouldn't need to load a library.

I propose that a standard CBOR encoder/decoder be implemented, with support for all of the datatypes supported by JavaScript.

The ubiquitous availability of JSON is what made JSON a popular choice. CBOR's benefits make it better choice for most applications. If CBOR were natively available, I have no doubt that it would be used much more broadly.

---

If posted, this will appear at https://webwewant.fyi/wants/602eadc2a6174300d5585008/

[aarongustafson]

@cwilso @tantek @captainbrosset @bkardell This is outside my wheelhouse. Do any of you have familiarity with CBOR and/or have thoughts?

[captainbrosset]

I don't know much about this either, only that browsers already encode/decode CBOR for different internal use case (it looks like Gecko uses it for WebAuthn).

[bradisbell]

^G Any feedback or additional thoughts on this?