So are you saying every transaction of a safecoin coin MD will be recorded forever? If every mutation of a MD is going to then that includes safecoin MDs and every database mutation that uses MDs.
Good point, I personally wouldn’t like that, and I wasn’t trying to suggest that either, I personally haven’t even tried to think how to implement this, I was just basing my comment on the fact that we want data stored in perpetuity so in such case the scenario of deleted entries wouldn’t be possible.
Thinking out loud wrt safecoin TXs, perhaps ownership transfer is/can/could/should be made the exception to the rule of keeping history of all type of “mutations”? (as it’s usually said, you need an exception to be able to say you have a rule you know 
), or perhaps safecoins end up not being a MD as per what I understood from briefly looking at recent alternative proposal for safecoin?, or perhaps …
1 Like
But really this goes against the concept of Mutable where you can change data.
The concept of perpetuity was aimed at public data with the specific example of web pages.
So for public data (eg web pages) then the concept is sound.
BUT for database data then the concept is on shaky ground in my opinion. Some databases see massive amounts of mutation per second/minute and if we attempt to try and keep a copy of all the changes then we really will start seeing the SAFE network storage filling up.
ALSO for safecoin we do not want history kept unless receipt is requested.
ALSO many mutable data has no purpose in being kept for perpetuity and especially if private using unique encryption keys. The data is meaningless to all except the key holder and it is reasonable to leave that decision of perpetuity to them on a case by case basis.
I can only see that public data is important to be kept.
What about NFS where there will be a lot of temporary files kept in Mutable Data so that it can be discarded. E.G. a word processor that keeps temporary files and mutates it very often and then deletes it when writing the file back out. What needs to be kept is the original file and the new file, which is already done if stored in Immutable data files. That temporary file maybe seeing changes to numerous mutable data objects per minute or 5 minutes depending on settings in the APP.
Imagine your personal disk if all the temporary files (portions) are being save with every change made to them. As in say a 20MB temp file (5000 blocks) has every block that is changed copied into a permanent store that cannot be deleted. What would your disk look like (size) in a year when browsers, word processors, operating system, messenger programs, zip APPs, etc which are all using temporary files (usually many MB and at times GB) for simply aiding in processing actual files. Your disk would be full.
Lets just look at this website. It is writing/changing Mutable data every second to allow users to see forum updates quickly and to see who is typing etc etc.
Imagine millions of these sorts of websites each altering 100’s or 1000’s of mutable data objects per second/minute (or hour/day if poorly used site) to keep track of each user and each topic so that a browser can enquire every second if a change is made to the particular topic/whatever it is displaying. And that is not the actual content either. So a forum with thousands of users and 100s of thousands of topics (or posts if small forum) thus requiring a few hundred thousand mutable data objects (doesn’t matter if field or whole) and every time a view of, or change therein happens there is a few mutations.
Those are not the sort of mutations that should or need to be kept in order to have persistent data.
3 Likes