Need some trusted time servers among our PCs.

[leftside2]

Step 1: Please describe your environment

• ZeroNet version: 0.6.5 r3340
• Operating system: Ubuntu 16
• Web browser: tor-browser
• Tor status: always
• Opened port: no
• Special configuration: ____

Step 2: Describe the problem:

Refer to : <Comments order bug based on timestamps of each other's PC, maybe? #115> HelloZeroNet/ZeroMe#115

I noticed a strange phenomenon today while commenting on the post in ZeroMe.

Another guy make a comment just now, and I read it and make a next comment following him, but my comment popped up under his comment. I deleted mine, and made another again, but it still goes under his one. I thought he hacked something or what, but I decided to wait 10 seconds and made another one only to fail. At last I could see my new comment above his one after around 40 to 50 seconds.

What was happened?

@HelloZeroNet : Since there is no central computer involved in ZeroNet the timestamp is added by the sender's computer. So if yours or the sender's computer time is out of sync, then it could break the order.

Steps to reproduce:

1. One PC make a comment on ZeroMe or something.
2. Within a second or more, another PC with the system time 30 seconds or more shifted backward from the above PC makes a comment on the same post as the above.
3. The above time shifted PC's comment stays under the the first PC's comment for about 30 seconds even though he deletes his comment and make again within 30 seconds.
4. After the amount of the shift time, it will be placed over the first comment if at least he made a new comment after 30 seconds the first guy did.

Observed Results:

• What happened? This could be a screenshot, a description, log output (you can send log/debug.log file to [email protected] if necessary), etc.

Refer to the above paragraph I described.

Expected Results:

• What did you expect to happen?

We need to appoint some trusted time servers among the decentralized PCs, don't we? Have them be chosen by voting. Predefined upvotes to downvotes ratio will switch off some of them or switch on others of them.

[HelloZeroNet]

It could be improved as:

• Add the client's current timestamp to connection handshake
• Every hour the client calculates a median time offset relative to current time of the computer
• Add that time offset to serverInfo API response
• The sites could use that offset to correct the Date.now() value (so it requires change in every site)

[leftside2]

@HelloZeroNet : What if the client's system clock changes itself many times during continuous offline state and the client uploads the posts and comments many times during the same period? (This can be happened in case of the battery on the mainboard malfunctions.)

• We can keep a kind of flash memory space (HDD is also OK) in order to keep the zeronet.py specific relative time counter. It increases only after the checking the previous written counter in the same memory location whenever it senses any event which zeronet.py logged or triggered. It can not replace an accurate clock, but at least it can tell zeronet.py which event is ahead or behind of which event independent of the system clock error.

• How to apply this technique over network or inter-network wide? Each activity of the client sometimes depends on the other users' activities such as making a comment to the other user's post/comment or making a post to the other user's recently updated site. These relative timing activities could be recognized by the local zeronet.py and recorded in order to make the proper order for the various users' comments or posts. (refer to 'Comments order bug based on timestamps of each other's PC, maybe?' Comments order bug based on timestamps of each other's PC, maybe? ZeroMe#115 ). And the more precise time gaps between the client's activities could be calculated by the client's [Relative Time Counter] which is introduced in the previous paragraph. But this calculation is just as precise as at best only relatively because the client's PC could be turned on and off intermittently with very long time gaps in-between while the system clock is malfunctioning. zeronet.py still has to heavily depend on it's PC's system clock anyway. Especially after the PC's turned off and turned on again with the system clock malfunctioning, zeronet.py will experience the biggest erroneous time shift.

• How to reduce errors in time shift? zeronet.py could pop up the dialog box asking the user for the current time he [thinks], periodically and Relative Time Counter Alert dependently (system wakeup event, etc), showing the current system time and the timestamp of the most recent activity, so that user could recognize the time gap between the events. But to avoid the case the user lies to zeronet.py about the current time, zeronet.py should restrict the current time value which the user inputs, depending on the calculation.

• How to prevent the user from fabricating the Relative Time Counter value in the flash memory (or a certain file)? Relative Time Counter format could be encrypted by zeronet.py.

• Any better solution to keep the track of the order of the activities of the various users? Here comes the Trusted Time Servers idea. In addition to the timestamps which were calculated by the zeronet.py's of various users, another field [Time Server Received Date] could be created for each activity by the any one of the Trusted Time Servers when it receives the new data from the outside world, so that at least people can tell the subtle differences between various posts and comments anyhow.

• SSD wear-leveling problem in regard of Relative Time Counter memory. zeronet.py could make the Relative Time Counter [file] to be increased continuously like log files to avoid re-wring to the same memory location repeatedly. (And periodically discard the over-sized file.)

• How to reduce the access time of the Relative Time Counter file? zeronet.py could write to the Relative Time Counter in the file and in the variable (in the RAM) at the same time, and could read the value only from the variable. The file could be read when the PC power-on or wakeup event is detected, in which case the variable must have been emptied.

[HelloZeroNet]

If you have totally faulty RTC, then it will mess up lots of things (eg. ssl certs won't be accepted), so I think the out of order zeronet post is the last thing you will worry about.

[leftside2]

@HelloZeroNet : We may need a tag "#non-authenticated-timestamp" for the users whose zeronet clock has not been signed by any of the authorized ZeroNet RTC peers, so that people notice that the some users' strange comments might be caused by that reason. Plz refer to this post: http://127.0.0.1:43110/Me.ZeroNetwork.bit/?Post/1oranGeS2xsKZ4jVsu9SVttzgkYXu4k9v/1AWwhg4EiWAVttfQboJZ4wJfX3WawfJT3h/1535159559