I'd like to register a weak vote of dissent on this. And I'm pretty well down the conversion funnel on "Content-addressable is the way, the truth, and the ligh

I'd like to register a weak vote of dissent on this. And I'm pretty well down the conversion funnel on "Content-addressable is the way, the truth, and the light". Binary keys are very dubious. I'd rather a format without them. It's just incredibly annoying to work with non-string keys in almost every language. To pick an example, just for the sake of being concrete: in golang, `map[string]interface{}` is manageable; `map[interface{}]interface{}` is utterly disgusting to work with. We have to print keys, almost invariably. Values we can sometimes shrug and say "...elided [binary content]...", but doing it on the keys is typically nonviable. Keeping the data in binary and choosing ways to stringify it to print at runtime has historically been a disaster: keys, key fingerprints, which base-$N they're going to use, and so forth, has been an unmitigated trainwreck in openssl and its ilk. I have a cheatsheet of pgp and ssl commands to print key fingerprints in various formats and I hate that cheatsheet with the cold weeping fire of a disintegrating neutron. Let's not do that again, for anything, ever, please. Picking a format composed of printable characters once and using it consistently in an application is the far better road. Non-string keys are something that if permitted, almost no one will ever use; and yet every client library will have a massively more complicated interface in order to handle. At the same time, if my prior experience with people using e.g. yaml parsers that return wildcard types for keys is any indication, every caller will so aggressively disregard the feature that whether libraries support it will be moot: callers writing in any strongly typed language will write code that rejects non-string keys out of hand anyway in order to simply the rest of their program. I can't imagine the battle to be worth fighting.