Post

I don’t have an answer to your question, but is there a “design doc” for postcard-rpc that explains why design decisions were made? I’m wondering why a small, serially allocated integer is insufficient, when both sides know the full set of possible message types?

I've started working on it at postcard.rs, but the short answer is that postcard is a non self describing binary format, and so if you change the schema on one side but not the other, you could misinterpret or fail to decode messages. Using a hash of the schema means the ID changes if the type does.

Why simple: I do it in const context in Rust Why no length: I do it recursively, would prefer not to need to collect and then hash, instead of hash as I recursively walk Why 64 bit: I dunno that's the size I chose. I could mix down with xor if I need to I guess

Not 100% sure if it fits all the specifications. But I use xxh3 for anything I need. Usually checking for duplicates in DB inserts or when possibly getting duplicate payloads in web requests docs.rs/xxhash-rust/...

Murmurhash? Been my default for a 64-bit non-cryptographic hash for a while.

I did look at murmur3, but it seemed non-deterministic on different architectures, and only has 32 and 128 bit versions. I didn't look too closely at previous versions.