Volker Mische

> * Only collect links without deserializing everything > > * Deserialize into a struct _and_ collect all links, in a single pass > > The latter might not matter...

> Which sorts the keys via lexicographic order of the strings, due to an interior use of `BTreeMap`. Order preserving codecs like `dag-json` will preserve this order, whereas codecs like...

> I'm not sure if there's actually a way to go directly from `DAG-CBOR` to `DAG-JSON` in the way you're describing. Currently not. But hopefully we will also have a...

> Okay, I _think_ this results in the same ordering as DAG-CBOR (which is based on https://datatracker.ietf.org/doc/html/rfc7049#section-3.9), because of the restriction of DAG-CBOR maps to String keys (which iirc are...

> Furthermore, the field labels are not actually relevant to content-addressing, per se. And I think it's strange that e.g. changing the name of a field in a Rust type,...

I haven't had a chance yet to look into the `Serialize_tuple` implementation. Though I agree that having a way to serialize a struct as a list is useful. From a...

To be honest, I haven't spend much time thinking about the `Block` interface, even when it was created. I'm still busy with the lower level things. I've no idea when...

> As far as I understand, the purpose of IPLD is to largely be codec agnostic, That's correct. The reason why the dag-cbor-derive only exists for CBOR is that one...

> I guess where I'm tripping up is where is the transformation from the concrete data type to the IPLD DM taking place? It doesn't seem to occur anywhere. It...

The IPLD and the Serde data model are very similar. At one point I thought they are incompatible enough, so that it doesn't make sense to use Serde. I was...