@moid unfortunately, we already made timestamps non-monotonic I was the only one arguing for them.

@aljoscha you can query by recieve time. You could also query by log offset (relative order). local receive time was the only api available before flume, and when I refactored flume in, I continued to support it so that clients wouldn't need rewriting.

log offset is used internally by views (because you can do O(1) reads of the log), and clients could use it I don't think any do currently.

I have at times waved my hands and talked about a "social proof" of timestamps. Basically, detect the causal order of all interactions between feeds. like the ssb-sort used by threads, but on every message. A large proportion of messages are replies or likes, so the partial order would be fairly tight. Also, since a hash link proves that the hashed message was created before the linking message, I think you could use this to estimate bounds for the timestamp. This would be useful because you'd get consistency (after a fuzzy period). I havn't actually sat down and figured out how such an algorithm would work though.