No only update , so version increase to change. This is the default SD mechanism in any case. You cannot replace a version 1 with a different version 1 of the same name + type. You need a valid successor.
Will there be a mechanism that the owner can ālockā the SD at a certain time.
Basically once the owner has placed all the data into the SD then it can be ālockedā so no further updates are allowed.
Basically to signal to all who read the SD that the SD is now āset in stoneā and people can rely on the information not changing after that.
Would expect it would be just a flag that once set the SD cannot be updated and the flag is readable by everyone.
Yes if the ledger bit is set on any SD it will not delete, further versions may exist though, but that one will not update. So only way to update SD is to create a new version (even today). Leder means do not clear old version.
I āthinkā that is what you are asking ?
1 Like
background - Is there something I missed?
I thought when you updated an SD the new data is written to the SD and the version # updated. Just one SD object exists with that TAG-ID āaddressā
Now it seems you are saying that when you update a SD that the current version still exists and the updated SD with a incremented version is actually a new SD?
My previous post was a suggestion that at some stage (version) of updates we can call it quits and make the SD non-updateable and no new versions allowed. It remains at that version with that data.
The idea is so that at some stage the ledger entry can be declared the final version and everyone that uses the āledgerā can know they are looking at the final version. Thus they can be assured that no more updates will occur. This would be a flag set when doing the āfinalā update and once the flag is set the SD can never be updated to a new version
That is another flag - no further updates allowed. And if do-not-delete flag is also set then this in effect is an immutable SD object.
Why always another flag?
What you ask for is already doable today; there is no need to develop ledger items for this.
The app has just to update the SD with an owner key without any known private key (a hash of a string, for example hash of āDavid Irvine - Creator of safe networkā). The version will be incremented, but after that the SD cannot be modified and cannot be deleted.
This can be done any time. If you want to lock an existing SD without modifying its content, just update it with this special owner key and keep the same content.
This can be done also as soon as version 0 by creating a SD directly with this special key.
All this can be done right now!
1 Like
I see what you are saying here? I wonder though why not just know this is locked.
YEs at the moment without a ledger bit the SD will delete. The update will have to be a new version though. So you cannot overwrite version 1 with another version 1.
Yes as you say or set a ledger bit, then folk can query and know you have issued a no delete and cannot remove it. I suppose the invalid key is hard to prove you do not actually have the corresponding secret key?
But you can read your words as there will be an SD with version 1 and when you update it to version 2 then there will be both version 1 & 2 existing at the same time. Can you confirm which you meant
BUT the other users need to be able to verify that the SD was created by a specific owner. If you make the owner anonymous then the others cannot verify authenticity.
Really even if there is 32 bits of permissions/attributes then its not such a problem. Normal file systems and database objects have way more attributes once you add them all up. Early unix had 9 bits just for r/w/x attributes then the other attributes for filesystem use.
1 Like
Yes, of there is a ledger bit set to tell the nodes not to delete it. So you cannot make a new version 1 for instance, you can make version 2, but version 1 today would be removed. With a ledger bit we would keep version 1 as well.
So today all updates mean removing the old copy, a ledger bit will mean do not delete this particular SD. This is what allows a safecoin receipt to happen etc. as well as a lot more like immutable comments on forums etc.
5 Likes
If you take a random key, yes it is hard to prove you donāt have the private key. But if you take the hash of a known string as public key then it is a proof, because you havenāt chosen the public key value and itās admittedly impossible to get the private key from the public key.
But authenticity is lost. The owner of the ledger is no longer able to prove ownership if the SD owner is changed to one without knowing the private key.
This is important if the application or person needs to sign proof that the āundeletableā SD is authentic.
@dirvineās use of a flag allows all the normal proving/authenticity methods to be used and the other people accessing the SD objects can verify the authenticity of the said SD objects.
Using the āunknown private keyā allows anyone to create an SD object with that owner and claim to be the authentic creator of said objects, by simply changing ownership of the fake SDs to the one used for undeletable SDs
The previous owner key and signature are both present in the locked SD. This proves that you owned the SD and you updated it to make it not modifiable/deletable.
To put it in other words: in a transfer of ownership the previous owner has to sign the new SD, so there is a proof you owned the SD.
So, no need to add flags still!
Maidsafe people have designed a very powerful ownership system and before creating ad hoc flags we should check what can be done within this ownership system as is.
3 Likes
Ah yes, I forgot the previous owner field. My Bad
One underlying factor that irks me with this solution though apart from the technical issues that, as you have shown, are are not an issue is that its a hack and reminds me of all my workaround hacks done over the years. Its not a clean solution and somewhere sometime there will be a situation where the hack will not be a solution.
The attribute bit, is a cleaner solution and one that is obvious. The hack has to be explained in its usage and requires changing the ledger owner. This means more code when traversing the ledger chain to account for more than one owner, be it the null prev owner or the anon final owner.
As I said before even if we have 32 or 64 bits of attributes for a SD, it should not be an issue and compared to file/data systems it still compares favorably. The code required for this attribute bit is a simple test on delete request. Why the resistance to the attributes, is it just because āits yet another bit/flagā?
An attribute is cleaner, and Very Importantly shows intent rather than a potential accident. Saves extra code in all the applications that use ledger (undeletable) SDs.
But yes at this stage your idea of changing the owner to an anon owner will work.
3 Likes
To sum up my position:
The flag for unmodifiable/undeletable SDs is not useful because this is already possible today.
The flag preventing complete removal of a SD is also not useful because this was previously implemented for all SDs. Complete removal has no gain for the user: the space that is freed was bought by him/her but he/she cannot reuse it. And I doubt it gives a significant advantage to the network because emptying the content already frees the major part of the SD. This is also to be compared to the bulk of immutable data that can never be deleted.
For me the alternative is:
- Either going back to delete by emptying the content with no flags at all (choice of simplicity)
- Or adding a flag that brings something that is really useful (SD timestamping).