hashmap: document Filecoin HAMT variations

[rvagg]

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.

[vmx]

Thanks for documenting the Filecoin variation. I haven't checked if the schema matches the Rust implementation as it would be more time consuming than I anticipated.

[rvagg]

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 K has 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 a Set() 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.

👍

[rvagg]

They've switched to SHA2-256 for hashAlg upstream so the whole murmur3 hassle has gone away. Have updated the PR to match.

[rvagg]

932af7c