[Suggestion]: better error message if sync fails due to time difference (or allow sync with large time difference)

[umlaeute]

Suggestion

so today i've managed to sync my laptop with my PC.
it took a couple of trials though, even though both were on the same local network.

synchronisation failed, and clicking on the error message i got something like:

Packet took too long to reach its destination, please check your network conditions

now the network conditions were fine (i checked and double checked).

eventually i found out that my PC's clock had drifted by 80 seconds or so.
manually syncing the clock withntpdate fixed the problem.

so i think the error message is somewhat misleading: the packet reached the destination in time (ping tells me that the roundtrip trime is between 1..2ms), but the timestamp in the package differed too much from the expected value.

probably the client could send a "ping"-like packet where the server responds with its own timestamp, so a more meaningful error message could be displayed.
(if that's necessary at all; it would of course be nice if the two could sync even if the time is off)

Submission checklist

• I have specified my suggestion in the issue title

[GleammerRay]

Hello @umlaeute . Sure thing, I will look into allowing the client to find the server time difference and adjust to it if necessary, but I am not making authentication an optional thing as it provides a nice additional layer of security.

[umlaeute]

but I am not making authentication an optional thing as it provides a nice additional layer of security.

not entirely sure what you mean, but of course, i was not suggesting anything like that :-)

[GleammerRay]

Apologies, I misread what you wrote earlier. Of course, I believe that it would be pretty trivial to resolve for time difference.

[turtaf]

+1
I didn't realize I had no time sync on my server and with the only error message I would not be able to understand what the problem was. Thankfully I found this issue...

[GleammerRay]

I am planning to implement the use of a cryptographic challenge for the synchronization layer instead of time-based authentication for the next release.

This will allow for better security and better compatibility with systems that use non-matching time zones.