type is not polite, it's mandatory. I just made a PR for this

So conceptually, type is part of the metadata, it is just hidden inside the content objects. In case of a metadata redesign, I'd want to move it to the actual metadata. That's clearer and also saves a few bytes (because there's no need for a string key "type").

I think removing the sequence number forces the hand of implementers a bit too hard.

Doesn't it free the hands of implementers? Right now, there is an enforced way to deal with them, the change would allow them to handle them how they want. Maybe handling message-embedded sequence numbers is done implicitly when using a schemaless database, but that's not the only choice. Since metadata is actually structured, it would make sense to store it in a relational database. And in that case, implementers need to deal with it anyways.

Having to roll your own sequence number memoization can't be that complicated. Saving a tiny amount of work for a subset of the implementors (of which there won't be that many) can't be worth complicating the protocol. In some sense, explicitly transmitted timestamps sacrifice user experience (in the form of performance) for developer convenience. Which is not an approach to software engineering I support.

Fyi, to me personally keeping the core as minimal as possible is a stronger motivation than the performance. But I can't really support the desire for minimalism with concrete argument, just a general sense that a minimal, simple core leads to better result in general. Performance improvements are just a symptom of that.

Also, timestamps: The application layer loves timestamps. Everyone is requesting indexes for that. As protocol designers, the application developers are our users, we need to keep them happy if we want people to use our protocols.

Distributed timestamps are broken, that's a fact. And the current design encourages devs to use them anyways. As protocol designers, we have a responsibility to keep devs from doing broken things. It's like telling your kids that playing with firecrackers is unsafe, and then putting them unsupervised into a room full of firecrackers and lighters. Ok, that's a ridiculous metaphor, but you get my point?

If you remove the timestamps they'll just add them to the content, anyway, so I don't think you'll win this argument.

That's what I'd consider winning the argument (except I don't think of this whole thing as something to "win"). Timestamps are a nice, cosmetic thing to display, humans like them. Go ahead and add them to your messages. Go through the trouble and create flumeviews if you like. And then deal with the problems when things inevitably break. But you can't go and blame the protocol designers.

If someone starts spraying randomly timed messages it will tend to be behave weirdly in applications, and that will have social rammifications.

Yeah, that's a real interesting thing about ssb. Some people would start blocking you if you randomized them, others might understand the privacy concerns and actively seek out clients/apps that use timestamps sensibly (i.e. as nice-to-have, completely unreliable pieces of information that may or may not be true). If timestamps are not mandatory, than these things sort themselves out through social dynamics, and each group can have its preferred solution. Making them mandatory removes this agency from the users, everyone just has to pay the cost for them.

Timestamp randomization is fascinating, because it may look like malicious action to some(I actually toyed with the idea to do it, just to make client devs deal with it, which is basically altruistically motivated malicious behavior), whereas it's an anonymity-preserver necessity for others.

Who knows what would happen if all the timestamp-opponents (and I'm definitely not the only one) coordinated to simultaneously start randomizing. Would that divide scuttleville, or would the popular clients adapt? I will not try to start this experiment, but I would definitely be in the randomization camp.

Anyway, while these might be good ideas, I think it's going too far introduce these all at once. Just rolling out the binary format will be hard enough.

I fear that the introduction of the binary format might be the best shot we get at doing these changes. Adding a new multihash is not something we should do lightly, but these changes require a new multihash. Hsdt requires a new multihash as well. I'd rather not rush out the binary format and then never get the momentum for the improved metadata encoding, but instead take some time and clean up the whole hashing-related business, which involves both message data and meta data.