Volker Mische

> seems to me that (a) this hasn't been a problem discovered by JS consumers and (b) if we're really the only consumer, via IPFS + UnixFSv1, then it doesn't...

> 1. Layer it: For now, we can define a new path namespace for IPLD+ (IPLD data model). This namespace would transparently handle things like HAMTs. In the future, we'd...

> The question is: should we do this in two layers or one. I would do two layers. One reason for that is graph replication (aka. Graphsync). I want it...

> Or do we actually have advanced layouts where we'll plug in the logic and it'll specialize itself to whatever kind we actually use it with? Do I recall correctly...

Your Data Model aligns with the one outlines here https://github.com/ipfs-rust/rust-ipld/blob/a2b6f30631bfd45a0ffdc78a9aa7e12c2b809f1e/core/src/ipld.rs#L8. The only difference is naming one things `String` or `Text`. Though I kind of like the name `Text` as this...

Please note that the "strings" @warpfork mentions can contain arbitrary bytes. So in Rust it's a `Vec` and not a `String`. Also the current Data Model spec allows for arbitrary...

> If `Text(String)` needs to be `Text(Vec)`, can we use `Bytes(Vec)` ? I don't understand that question. > * Provide two API, one to check and return the previously-assumed-string as...

> I'm not certain that this is necessary in Rust, we could take some inspiration from [`serde`'s zero copy deserialization](https://serde.rs/lifetimes.html), which achieves the same goal (I think) via lifetimes on...

BTW: I just re-read the CBOR spec about [major types](https://tools.ietf.org/html/rfc7049#section-2.1). The CBOR type for strings (major type 3, text strings) must be encoded as UTF-8. So even if the IPLD...

In regards to Rust. I know I've been warned by @warpfork often enough that I should put thought into this early on. I haven't put much thought into it yet....