ancapone on Nostr: Referencing an external clock such as a block height does not solve the underlying ...
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.
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.