Oddbean

Not sure about antedating or postdating the note, but you have to consider, what is actually the time of publication. In a centralized service. it's either the time the client sends the request, or more likely the time, when the server receives the request. You can however publish the same note for example a week apart to two different relays. What is the time of publication of that note in that case? You could argue that it would be the first publishing recorded by any relay anywhere. Then the question is, how would the other relays know that?

True, good point. By referencing another note you'd know it came after that, i.e. partial time-ordering, but no absolute time. Including current Bitcoin block height + hash could also be a good practice, although does not prevent antedating by itself. Maybe we could build a kind of "collective merkle tree" that increases the coverage of partial order among notes

Referencing an external clock such as a block height does not solve the underlying issue. Looking at the NIP0, the note id is also derived from the timestamp. The client can insert any timestamp, but it cannot publish the same note with different timestamps and the same id. This solves the consistency among relays issue, but does not solve the problem of a client faking the timestamp. What could kind of solve this, is if all relays provided "received_at" field, which works similarly to created, except that it would be created on the relay. That would be a relay specific publish timestamp. If you needed a global one, you cannot have an absolutely reliable one, but you can have a good enough one, if you just took the earliest received_at timestamp accessible on the relays you have access to. That one may change though depending on which relays you fetch the note from.

I kinda like the received_at solution. Clients could alert users if the received_at varies wildly for different relays. Timestamp consensus in a fully decentralized system seems like an interesting - but rabbit holesque - challenge! 😁