@Dominic

I think a maximum of fields should be inside the encrypted portion, and that portion should be as uniform as possible. having two separate encrypted portions would leak metadata, in that the length of the type field could imply what sort value it was.

Valid point, but not a show-stopper. The encrypted message can simply be created by concatenating the length-prefixed type and the content, then encrypting the whole thing. Same for the timestamp.

To be honest, I don't have a concrete use case for non-map content. But allowing it strictly expands the set of possible messages, without any real drawback. And viewed from another angle: As we change the metadata anyways, we have full, unconstrained freedom to chose any format we like. How could we possibly justify to emulate a hacky and entangled legacy solution, if there is a cleaner one?

If you insist on a use case: The closest thing to a blob that is still verified to have been uploaded by a certain id at a certain point in the causal order, is a message whose content is solely a binary string.

@dinosaur

I'm not so sure about protocol awareness of tangles. Not every message really needs these, but everyone who does need them has all the tools to build them. Also, the desire for a tight partial order is opinionated, not in itself better or worse. And due to arbitrary network partitions (the most common case being an offline peer writing data), branches/tangles can never give us any quality guarantees anyways.

The thing I found most interesting about tangles are the conflict resolution rules. But those differ form use case to use case, so that won't benefit from being part of the core.