by mutable hash but not signature, I mean you could take a valid message, and change some utf8 chars and the hash was the same but the signature wasn't. Oh, sorry just realized that "mutable hash" is not the right phrase for that.

The idea for the hash field, is to enable switching to a new hash algorithm at some point. The idea is that the expressed hash is the primary id, and if you want to refer to an old message with a new hash, you'd use the old hash concatenated with the new hash. Saying "of values with this (possibly collided) insecure hash, I mean the value with this secure hash"

Now that I think about it again, this idea may have included some assumptions about how the implementation might work. With flume style database it wouldn't be that hard to just add a second key index for a new hash.

Actually, second thoughts, I think we should focus only on defining the implicit format, not changing it. "hash": "sha256" should be required (so that implementations will drop messages if they have a unknown hash). Also the key order should be defined. Note: messages may have "author" and "sequence" positions switched, but all other fields are fixed order.