Feature request: More robust timestamps

[oskarth]

Discussed in #397

^{Originally posted by bgits June 11, 2021}
Having reliable timestamps would be valuable for a wide range of applications. Even accuracy within a range of minutes from time of origination covers a wide range of applications. What research or proof of concepts already exists into how this could be implemented?

---

Currently we have receiver timestamp, and there's a WIP to get sender timestamp. See this PR: #417 and discussion here #219

In the future, having block height as a timestamp might be desirable for some applications.

What are more precise requirements and expectations here @bgits? cc @staheri14

---

There is the open timestamps project which uses blockchain based timestamps. Some use cases are outlined here: https://petertodd.org/2016/opentimestamps-announcement

In use cases like voting for now it's possible to handle requirements using block height and vote specific nonces.

The canonical use case is when chat dialogue is used for discussion in things like dispute resolution, the question of when something was said maybe germane to resolution.

[oskarth]

I'm wondering if notarized timestamps would make sense. It could basically work in that each node that receives or stores a message appends a signed timestamp to the message. Any protocol that needs to verify could then use several different approaches. Checking if the timestamps deviate a lot, or trusting only certain signatures, thresholds, etc. Is there anything here that makes this DOA such as privacy or security concerns? (Barry)

FYI @D4nte if this is interesting to support from a DappConnect POV

[D4nte]

It could be interesting yes. Some notes:

• At this stage, as you mentioned, the exact requirement is not clear to me
• @Szymx95 is currently working on "Featured community gasless polling" that do involve some guarantees around the timestamp that may answer some this problems.

The way I see it is that it is mainly application level, except if we want the store nodes to do something special with the timestamp, apart for registering the "received time".

[jimstir]

issue moved here