The problem is that maintaining a global time across the network adds another complex layer in the core.
A much simpler solution which would need a minimal modification of the core is to add the following fields in StructuredData:
- min_date: i64 (default value 0)
- max_date: i64 (default value std::i64::MAX)
The i64 type represents the sec part of a struct Timespec generated from an UTC time (a number of seconds since the beginning of the epoch). Each nodes in the data manager group handling a data put would check that its own current UTC time is > min_date and < max_date. This is a little modification in the validation procedure.
If someone wants a proof of an approximate date for storage of data, then these 2 fields must be filled with the current date minus a margin for the min_date and plus the same or another margin for the max_date. The margins are added to take into account the variability of the vault times.
In most cases user don’t want a precise dating, so a 10 mn or even a 1 hour margin is sufficient and so there is no need to synchronize the nodes. A put to succeed only needs 28/32 nodes having a time within the margins. If the put is unsuccessful, the user can try again with:
- higher margins
- another name so that another group will handle the request (with more precise nodes maybe)
- min_date set to 0 because only a max_date is needed most of the times (to prove that we stored a file before a date).
Some more remarks:
- The default values insure that the check on the date is always successful when user don’t want dating (which is the current situation).
- To be sure that the dates are updated whenever the data is modified, the check has to be done every time that the SD is updated (put and post requests)
- The simplicity of this solution lies in the absence of time synchronization implemented by the safe network