An example of a use case is the uploading of a video. It’s useful to know when it was uploaded. Without a secure date, the clients can adjust their local clocks and fake all kinds of dates.
Legal conditions may require this, such as requiring that disposal of stocks or other assets not happen until after some time has passed since a triggering event.
1 Like
That make sense. (20 chars)
1 Like
Time worries me, syncing with ntp servers is a take down source as well. So we need to tread very carefully, the whole network works without time. For instance there is a version number at the moment, versions can update and therefor entropy is taken into account. There is an RFC coming that allows update collisions to be handled as long as the owner does not change.
ATM if there is a double spend type attack on any data (not only coins) then the network will most probably dissolve the data, meaning nobody will own it and if it’s a coin it’s recycled.
So the time thing I find alarming to the point where it’s sirens everywhere, I find no ants with watches or cells looking a a clock and wonder why time, for what purpose?
I am a single person and no more, but I can say any talk of time in maidsafe till now has been quashed very quickly as an uncontrollable man made facet not required in a system. It takes a lot of effort to realise what we can do with time we can do with entropy, it is just harder.
I find time like servers, it is always easier to say use time or use a server as this will work dead easy!
So I am very hesitant over any shared timestamp as it’s way outside how the network works or how I think, so for me this will need to be after launch as the mental capacity to look at such a deviation from the current working would be significant and need a few weeks alone to consider it with no distractions.
Don’t get me wrong here, I understand humans need for time and timestamping of stuff for “proof” of something, but I see it as a higher order function than any autonomous system can or would want to handle.
I hope this makes sense, also I hope it’s seen as a discussion point and not anything definitive.
[Edit, at the moment there is exactly zero interaction with something requiring a server (like dns/ntp etc.) IMO it is vital to retain this otherwise it’s not autonomous any more but a symbiotic relationship with existing tech and I feel that is dangerous]
9 Likes
But the RFC describes using only the nodes in the SAFE network themselves for generating a secure timestamp. Or do you mean that the nodes indirectly are dependent on external servers in order to keep their local clocks having accurate enough UTC time?
1 Like
Yes, this is a concern for sure.
1 Like
In addition to what Irvine said, why does this have to be native to the network again?
2 Likes
Yeah, what ^they said 
Just do it on the app level.
Don’t mess with the core system. It’s very well thought out and every part fits perfectly already, so don’t throw in other things that can throw it all out of whack
3 Likes
On a SAFE forum for example it’s good to be able to timestamp comments and threads etc. Without a secure timestamp the users can easily create fake dates by adjusting their local clocks.
1 Like
It’s Mr. Irvine! …,…,
1 Like
I didn’t say timestamping is useless, the concern I have is making it a core feature of the network and hammering the Maidsafe team with more feature creep when app developers can create their own timestamp system and host it on the network.
That would be centralized solutions. A secure timestamp produced by the SAFE network is a trustless solution. Think of for example legal documents, contracts and other such data where objective provable dates are needed.
?
The apps are all decentralized though.
I think it’s the best solution, and don’t see any reason to try to force it into the core.
If people need it, they’ll create and use apps that offer it
I can absolutely understand the concerns, but time does pass, whether we measure it tick by tick or not.
If there is another way to measure sequencing of events, maybe that will help?
The apps run locally in the user’s computer. And the user can set his or her clock to any date and the app would store false dates. That’s the very opposite of a trustless solution.
Can’t they do that with their vaults too?
So it’s the same thing if you try adding it into the core
This is true, but would not fool a curation app where the owner of a website has control over what appears. This is the way SAFEpress is planned to operate, so if you build a website with it, and allow people to comment or post, you can still ensure the time is correct based on your reference clock.
The neat thing with the RFC is that 28 out of 32 nodes need to be within the defined timestamp accuracy. So it will be a secure timestamp. If people running the vaults try to set their clocks to a wrong time the network would reject them. [Disclaimer: If I correctly have remembered what it says in the RFC.]
EDIT: On a second thought, there are security problems with this solution. Darn! If many vault owners would start messing with their local clocks, the timestamp wouldn’t work.
1 Like
I think you could still do this on the app level
The reference clock, does that require a separate server?