@mix

mmmmm.... not sure. I think matt is right about post type really benefiting from timestamp. It's really annoying reading things that are old when you want new things and a person just came into gossip range of you. or rather, it's strange, and sometimes embarassing when you don't realise how out of time your reply might be.
It's annoying when a whole persons feed sits on top of all your other friends content, that makes me tend towards blocking to remove the noise.

I think causal order would mostly solve this. Imagine if the ssb-client API had taken causal order into account from day one, do you think you'd still need a timestamp on every message for convenient client development? Implementing causal order in sbot, adding client-sbot rpcs that use it, and recommending them as the default is something we should probably do. It would be unreasonable to expect every client to do this by themselves. Checking consistency of claimed timestamps would then be trivial, even if they are part of the message content, not the metadata.

I'm somewhat inclined to dismiss every argument of kind "message type xyz benefits from timestamps, therefore timestamps should be mandatory". Ssb does not enforce a schema on your data. If you as a dev prefer to have timestamps available, feel free to add them. But if you want true interoperability, you must live with the fact that others may still produce messages without them, just as you must currently live with the fact that all timestamps you receive might be bogus.

I think if you remove timestamp you might have to make branch compulsory.
I think branch is actually way more interesting that timestamp.

I suppose you are talking about post messages here? As said above, you can just add a timestamp to it. But I agree that branch is more interesting, for the same reasons that I prefer relying on causal order rather than timestamps.

Downsides would be losing ability to do any easy queries.

<subjective opinion>If you can not rely on it being correct, then sbot should not make it easy.</subjective opinion>.

Do note that queries are implementation specific, not part of the ssb protocol. Ok, that is only half true, here is the more precise version: I do not know what kind of queries are part of the ssb protocol and which are not. Sbot uses the same rpc mechanism for talking to other servers and for talking to client applictions. Since every server could call these rpcs, they are technically all part of the network api (aka ssb protocol). In practice, a lot of these rpcs are intended to only be called by clients. For replication, you basically only need "hey fellow server, please give me all messages of feed @foo, starting at sequence number 42". There's no queries involved in that. I'd prefer if we clarified which subset of rpcs is protocol relevant, and which is not. And timestamp-based queries would probably end up in the "not part of the ssb protocol" camp.

Instead, they would be sbot-specific, and applications written against that interface would only run agains sbot as the server implementation (or any other implementation that emulates the API). And that is totally fine (for the context of this discusion), it is also how any more advanced db stuff via flume works. But ultimately, the core ssb protocol specification is not directly effected by this.

Of yeah I tihnk as the database gets older being able to say "only message published in the last year" might become really useful. I think this might be the case with all message types. Something like tags don't really need a timestamp to operate, but at the same time, if I want to see new tags my friends have been gathering how do I do that.

Causal order to the rescue again. Pick an arbitrary message which you trust to be from the correct point in time (e.g. a year ago), query for all tags which are higher up in the causal order.

Additionally, even if we don't consider queries by receive time as part of the ssb API, a server implementation is still free to store those and offer an API to the client. Combine those with causal order, and you get a pretty good approximation. And timestamps don't give you anything but an approximation as well, except that it can be arbitrarily bad.

I think we need to imagine a range of scenarios and propose how to build those quiries. Or to spend a week re-writing modules and avoiding using timestamps to see how hard it is.

This would only be a fair comparision if sbot allowed to sort by causal order. I hope that in that case, the effort for clients would be reasonable. But simply avoiding timestamps even though sbot development has assumed their usage for years, will only give a skewed outcome.

I am against anything that makes querying any harder than it currently is - either I don't have good strategies or some queries are really hard already.

Again, we need to be careful about what of this is actually part of the protocol, and what is not. A server could have non-protocol rpcs that look for a field named "timestamp" inside messages and sort by it. I unsurprisingly think of that as an abomination, but if that is what it takes to keep the core protocol simple, I'm willing to accept it.