@Dominic Ack. But we still want to keep type in the metadata, right? It may not mean much, but everything fundamentally relies on interpreting it.

Would you be open about changing the "type" information itself to be an arbitrary byte string rather than a utf8 string? That's trouble for the js API, but it allows using hash digests as types without any annoying encoding. The js API would have to use a buffer for the type, so it couldn't be a regular key on the content object anymore. That's a breaking change too, but it would reinforce that type is metadata, not content. Also, are there any reasonable arguments against moving the size to 512 raw bytes, to allow larger hash digests as types? Or maybe even a few bytes more, so that such a scheme could use multihashes?

cc #ssb-clients

I don't think we will get around a breaking js api change anyways, so we might as well try to put as many of those changes as we can into a single major update (I'm open to splitting those up depending on how we end up rolling out the underlying changes):

• move type out of the content, make it a buffer in the metadata, with some size cap (say 512 + 8 = 520 bytes)
• allow the timestamp metadata to be missing (if we do optional timestamps)
• allow the content itself to be missing (#offchain-content)
• We'll have to use some sort of non-enumerable properties to introduce the new hsdt types, otherwise they would be indistinguishable from regular objects. Not necesarily breaking, but clients need to be aware of those to not accidentally treat them like normal objects.
• change to Object.getOwnPropertyNymes (or similar) for hash computation (I'm unsure how doable this on is, also not sure if this really is breaking to the client api, but it does mean that some things might get ignored that previously affected the message's hash)

I'm probably forgetting some more breaking js-api changes.