Volker Mische

@raulk: You can deserialize to an `Ipld` enum. See https://github.com/ipld/serde_ipld_dagcbor/blob/ea9b594421a47ac431627781a65d641ff54a3f2b/tests/de.rs#L88-L98 for a full example.

> Yes I know, but validating the whole input would imply deserialising into ipld::Ipld, which uses owned data, so it's not zero-copy syntactical validation? Correct. Though I think zero-copy should...

> as upstream (cbor4ii) doesn't validate minimality. We already kind of patch upstream in serde_ipld_dag_cbor, could it be integrated there? I'd surely be interested in pushing as much as possible...

The reason are probably the floats. Though as the IPLD forbids non-numeric floating point numbers (such as NaN), it should be possible to implement it manually.

A problem I haven't thought about before seeing the PR is: Currently we don't enforce that there are no non-numeric numbers on the data model level. So how do we...

I just discovered that [f64 got `total_ord` in Rust 1.62](https://doc.rust-lang.org/std/primitive.f64.html#method.total_cmp). What if we just use that? As per IPLD Data Model spec, there shouldn't be any non-number values, but if...

@Stebalien writes: > * Not imposing anyhow on downstream crates. I'd like to talk about this from a usability (for maintainers of this library, as well as for users), rather...

`toJSON()` is mostly there for test purpose. It shouldn't really be used. I would've long removed it (as in other codec implementations) if it wouldn't break so much.

[`RawValue` like `serde_json`](https://docs.rs/serde_json/latest/serde_json/value/struct.RawValue.html).

Agreed. Though I'd like to get close to feature parity, so that people using the legacy codec can smoothly upgrade.