While playing with creating files and directories, I recieve the following responses from the launcher when I read directories :
DirInfo { name: “dirtest”, createdOn: 1459785541253, modifiedOn: 1459786007155, isPrivate: true, isVersioned: false, metadata: “” }
Are createdOn and modifiedOn timestamps ? I thought the network was not aware of time ?
They are timestamps that are created on your local computer based on system time. I believe they are for user consumption only and have nothing to do with the network. I can store time in structured data, it does not mean that the network is all of the sudden aware of time.
oh, ok, that makes sense. No way that it can be used as a proof of anteriority then
I sure hope not considering it is based on local system time (and has some race conditions, e.g. Log in with Atlassian account).
nvm 20 characterzzzz
If at all possible, I strongly advocate implementing some kind of “consensus” timestamps to every uploaded file. Someone pointed out that a hash on the bitcoin blockchain could be used for proof of anteriority, but having an optional timestamp might not be good enough. Having timestamps at the network level would be good not only for disputes, but also for the study of history.
There is an RFC for timestamping but it got rejected.
I think a timestamp can (and should) be added in a computing layer on top of the file system. Because let’s say for example I use the computing layer for implementing a decentralized cron job. Then there would be two separate timestamps if the computing layer has one timestamp and the file system another timestamp.
I wholeheartedly disagree. Firstly, the study of history is exactly what we don’t want. Even things like time remove anonymity. Secondly, if an app wants to store time, nothing it stopping it. If it wants some distributed time consensus it can use something like messaging or something else for an NTP-esque way to ensure accuracy. But the core network does not need this information at all in any way. It’s an app dev problem if your app cares about time.
One thing people don’t realize a lot is that the NFS features of SAFE (which stores things like timestamp) are really just an app, but they baked it in for ease of use. The NFS stuff could just as easily not be in the core and be a separate app or lib (which it kinda is as safe_core and safe_ffi). It does use local computer time to store alterations though it does it a bit different (e.g. it stores mod time of a dir if something changed underneath it). That is more for user friendliness probably to coordinate with things like fuse and should not be considered accurate as it is subject to skew of the current user’s clock. They even have some race conditions in their timestamps.
Speak for yourself. I absolutely consider the study of history to be of critical importance. I consider it our duty to future generations to document as much about the present as we can. The SAFE network has the potential to be of enormous value in the study of history. Every common data storage medium has a finite lifespan. By constantly copying data to new media, the SAFE network may be our only chance of archiving the enormous amount of historical data that’s in danger of being lost. I believe that this era, the start of the digital age, will be of enormous interest to future historians.
I’m all for anonymity, in the sense of not being able to trace a certain upload to a certain person, but I don’t think that will be compromised by knowing what century a file was first uploaded.
There are a lot of advantages to having it at the network level that I think you’re overlooking. Provable anteriority could be a very useful tool, one that you might not realize you need until it’s too late. If you upload a creative work with your signature, and someone else uploads it with your signature removed, being able to prove yours was uploaded first could be pretty useful. Everyone talks about the information that tyrannical governments don’t want you to see; timestamps could be a very useful tool in separating the real thing from the hoaxes.
Timestamping at the app level is not enough. It wouldn’t be universal, and it might not be verifiable.
This is very hard to do in parallel systems and is an easy way to make them become synchronous and slow. Again, I speak for myself, you speak for yourself, and we can each do as we choose in our apps. The distributed consensus models required for serial values (e.g. raft, paxos, single-file blockchains, etc) can be built in your app too. But you definitely shouldn’t saddle the network with this burden if it doesn’t need it. Anything can be as verifiable as you want based on your chosen consensus model. SAFE of course does have a consensus model, but not for ordered operations. I think that’s ok since the app level is enough if you build your app right. You can easily implement raft over messaging for example.
The non-trivial problem is having a time server that cannot be attacked.
And that’s where the idea dies. If we can’t ensure the timestamps are valid, we should not make it part of the design. And we can’t (well, not easily.)
Even if we could, mandatory timestamps simply don’t fit into the philosophy of the network, as @cretz already mentioned. He was not speaking for himself, he just pointed out an obvious fact about how this thing was envisioned.
Another argument: adding timestamps would not make the network do better what it’s design for; another therefore it is unwelcome (EDIT: which, I just noticed, is already mentioned by @cretz; why am I even commenting…)
There are ways to approximate timestamps. For example, there have been talks (sry about shameless self promotion) of building a ledger in the application layer that could be used as an optional (!) registry to store timelines whenever needed.
No, it wasn’t rejected. This is what I retain from David’s kind words:
The PR is still pending. Maidsafe may come up with an even better solution, but whatever the choosen solution is, basic security features will be implemented:
The solution will use the decentralized network consensus and won’t use any central server.
They will be optional.
Well if there aren’t going to be network timestamps, maybe someone will create a crawler to trawl the popular social networks and index when files first appear on them, and create an approximate timestamp that way.
I know that there can’t be a central server; I was thinking of a virtual “server,” however constituted, but omitted the necessary quotation marks.
Time and history are universal conceps common to us all, and of use in a great number of applications, it’s also not very complex.
I think a system such as safe should provide for this at basic level.
Examples of time based things I might want to do: write a private journal that becomes public in 100 years time. Create a digital will. Look at photos of the same place and see how they change with time.
This could not be more wrong in distributed and decentralized software, especially when ordering is concerned.
Then just store the time with your data. That piece of data doesn’t need to be independently verified via consensus any more than you would expect the network to validate the “location” data of your photos. The more complicated problem people have here is they want a trusted timestamp that cannot be attacked. This is usually done with a large enough consensus but adds a layer of complication in a network that can be handled by an app or could be incrementally added later.
Probably reversing my opinion in a few minutes!
So the argument is that time is a centralizing concept, and that it if it doesn’t NEED to exist in a decentralized network then it should be avoided.
proving order of events isn’t a safe problem, rather a problem for another project or projects.
It is up to the empowered user rather than controlling system to determine how they store their metadata and time should not be in anyway special.
If the user doesn’t really care about proving the time then they can just use that of their computer, if they have more complex requirements then they can store some kind of crypto Sig from another party.
That is my personal opinion, but does not necessarily reflect the opinion of others here. Others are making the argument that time can be derived independently and then consensus could be reached to determine whether it is accurate. Similarly this could be done for message ordering. SAFE has already put in the effort for consensus on other things. I personally believe all of these little things that apps need should probably never be in the core, but for sure shouldn’t any time soon. Granted the vast majority of the topics on this forum are sadly just for bike shedding purposes. So I guess the best answer is “maybe someday”.