rvagg
commented
4 years ago re serialization in Rust:
- Node: https://github.com/ChainSafe/forest/blob/b9ae7e8f53aeecaf2f3a7546dcdf40bb8b8ff55b/ipld/hamt/src/node.rs#L56 seems to be right, if
(x,y).serialize(..)is going to be a tuple - Pointer: https://github.com/ChainSafe/forest/blob/b9ae7e8f53aeecaf2f3a7546dcdf40bb8b8ff55b/ipld/hamt/src/pointer.rs#L28-L45 the complex
{"0":CID}&{"1":[...]}for serialization and deserialization seems to be all good. - KV: there's no custom serialize or deserialize but I gather that the definition makes it a tuple and it gets all that free: https://github.com/ChainSafe/forest/blob/b9ae7e8f53aeecaf2f3a7546dcdf40bb8b8ff55b/ipld/hamt/src/lib.rs#L37-L38
Khas to be a serializable thing so I hope that means that it'll always end up as bytes. The Go HAMT strictly assumes string keys, not serializable keys, and it does a conversion of string to bytes (hopefully avoiding unicode questions for the most part). Lotus does this thing where it'll take something that's bytes and convert it to a string for aSet()and then internally the HAMT converts back to bytes. I'm a little concerned about the cross-language compatibility of that process but this is where test fixtures are going to come in handy.
👍
I believe this is correct as of now, but there's some potential modifications that may happen prior to mainnet.
This section will get linked from https://github.com/ipfs/go-hamt-ipld/pull/52 and the Filecoin specs which currently just point to the top of this doc.