So how would that function compared to the header timestamp? Couldn’t the functionality of the header just be extended rather than creating two different ways to indicate the time of write?
Indeed — in some cases this is enough, but in most cases it isn’t, because you want some way of disambiguating entries that would otherwise have the same hash. On the DHT two entries containing the text “hello” will collapse into one entry with two author signatures. This isn’t what you want in, say, a messaging app, because if one agent deletes their “hello” they’ll delete it for everyone, even people who try to say “hello” in the future.
So what you want is some way of distinguishing those two identical messages, such that one agent can modify it without affecting anyone else’s message. Ideally this information should be semantically meaningful, not just a random number. Fortunately, adding an author ID and timestamp do add semantic value to that entry and distinguish it from all other entries with the same message. It may seem silly because you already have headers that contain that info, but I think the data should be able to stand on its own without needing to call up the header.
But you’ve got a chicken-and-egg problem if you want to take the entry’s source chain timestamp and insert it into the entry content because it doesn’t have a source chain timestamp until it’s committed. That’s where a timestamp function could come in handy.
@pospi you’re right; you wouldn’t need signatures for ‘trusted timestamp’ — I was suggesting a signature when I was still interpreting ‘trusted’ as ‘provably trusted’ rather than ‘implicitly trusted’.
Thankyou for that last post @pauldaoust - that is a succinct and exact description of the problem. I’m pleased to hear that others have been asking for this since it seems like necessary core functionality and a straightforward request.