What about deletion? Should it have its own weight?
Personally I think it should reuse the data modification weight, BUT I also think that deletion should be implemented by storing an empty payload and incrementing the version, like previous implementation (see Deletion of SD objects topic). It is in fact a kind of data modification and so all existing weights are still prevalent after deletion.
If it is implemented by real deletion, then things are completely different: if a person able to modify data is also able to delete the SD object, then he/she can recreate it with a set of new owners. This renders owner weights completely useless.
So, under this condition, deletion should have its own weight.
But I don’t like this condition, because any user having the power to delete the object has an absolute power to modify ownership and data. And all this silently, because he/she can also reset the version to the previous version.
This is currently true, and will remain true even if SDs are revamped with the new weight-age system. The only way to correct this, is to restore previous deletion implementation.
Whoa that’s a long post you linked. Let’s see if i can get to an understanding quicker by discussing with you here rather than reading that in detail.
Taking it piecemeal:
What do you mean by empty payload ? Which fields ?
[Edit:
Currently the above is only for POSTs because DELETE is not used (or even implemented in case of AppendableData) - there’s a potential problem of replay attack, but that is not what you seem to be talking about - so would like to understand your take on it.]
Basically if you actually delete the SD object then you are free to recreate it and others would not be aware that it was deleted and recreated and just think the original was modified.
So if someone can delete they automatically have the right to modify the SD and change owners.
Ok - but why is that a problem - an SD is something owned and the owner has every right to do whatever (s)he wants with it. If it is a requirement of a system to prove irrefutability of someone’s claim then other mechanisms should be sought - such systems can ask for ImmutableData containing a serialised version of a particular SturcturedData (or simply a piece of some signed data along with sender’s public key) - those will also have better permanence. You can use asymmetric encryption to use someone’s encryption public key and your signing secret key to generate an ImmutableData that can neither be read by others nor can be refuted by you (the sender) to the receiver. There are many other options.
Further, on this point, putting someone’s keys into owner field is not a proof of irrefutability of ownership. It’s just a field in structured-data. You could even invent a field and put it there or put it in the data segment. None of these mean that the person actually acknowledged that action - after all his sign::PublicKey is a Public Key, by very virtue of it being public means it can be assumed to be known to all the world. What matters is if his signature is present along with it - that would mean that the person claims ownership (or has acknowledged the ownership) of the signed data.
I think you misunderstood. He was referring to giving others the right to delete. Not talking of the original owner
If one can delete a SD completely then ANYONE else can recreate that SD with ANY information in it.
So to allow complete deletion (destruction) of the SD, @tfa is saying is the same as allowing a person complete modification rights, of data or owners
BUT if you do not destroy, but rather delete by overwriting with blank data and flag saying deleted then NONE can impersonate the SD and claim its the original with new data. Spoofing.
For instance a SD used to inform the world about a contract is then deleted and then another person recreates the SD with a contract that has changed clauses. The world doesn’t know the SD has been changed, so then someone else just spoofed a contract and noone knows. If the SD was not destroyed then this could not happen as only the owner can change it. And changes mean the version changes.
Ah no - i’ll try to make it clearer. Taking your e.g. say A owned SD called XYZ that had some important information that people would trust because they trust A (this being the important part). Now say A after sometime decides to delete it. Let’s take the case of complete deletion which you say would be problematic. XYZ now no longer exist. Some ppl (but not all) try to access it and find out its fate. Out of them one guy is B. B creates (successfully) XYZ and puts garbage into data field.
But there is one crucial information that has changed now. The part that is in bold above. The signature and ownership keys are now those of B. Ppl trusted XYZ because of A. When they see (and for any crucial information you would always evaluate this - just like certificate evaluation for any site claiming to be https in clearnet) that A no longer has ownership of this data, they would stop trusting XYZ. Bcannot sign on behalf of A unless A’s private key is leaked (in which case A is screwed way worse).
Perhaps one solution is not to trust contracts which can be deleted without unanimous (or majority) agreement of all owners? You could then have both parties of the contract as owners, but both would have to agree to invalidate it.
This wouldn’t help non-owners know whether the owners had colluded in the deletion though. Perhaps such a contract SD could be linked from an immutable data type though, along with a hash of key data. This would make any changes (including deletions/recreations) obvious to third parties. It would add some complexity though.
Yes so if there are n owners you would have relavant weightage(s) of each as 100 / n (don’t know if flooring or ceiling off the result to an integer would cause a problem in some scenario). In that case it has to be a change by all to have any effect. As for non-owners, of-course they are trusting that information because they trust all of them collectively which also translates to - if all of them collectively decide to change/revoke/do-anything basically, all the non-owners automatically agree (it’s like terms and conditions). If there is a particular instance at which point one wants to hold on to the piece of data, (s)he can simply serialise and store the StructuredData of that point/time into an immutable-data - though repercussions would be interesting - owners can claim that’s not the latest and hence null-and-void - latest is of-course always what thier SD has. It’s like you keeping a copy of some terms and agreements and then company changes them, you can’t go back to them with the old copy and sue them (maybe you can in some case - but you get my point).
But now lets say its a forum and most don’t know the poster, except they post some juicy whistle blowing stuff and links. But they delete it, then a scammer recreates the SD with the links pointing to spoof/scam pages. The issue here might be that readers had before it was deleted made links to that SD telling others how good is the juicy story. Ironically this is the reason the whistle blower deleted the SD.
Please that is just an example and can be pulled apart on its merit. The idea is to see the process and technically behind it. This I believe was @tfa’s point that a destroyed SD allows it to be replaced with another SD spoofing the original that was destroyed. And the original owner may not be trusted or known, so its not always reasonable to used SD ID + Owner ID to uniquely identity a SD as being genuine. But we have to work with purely the SD ID (addr+tag+ver) to assume an SD is genuine. Obviously a contract or such legal info should include the trusted owner ID and my bad for a bad example of a contract.
This is the crux of the problem - (for me at-least) there cannot be a notion of semi-trust. A trust is, mathematically or cryptograhically, all or none in digital world. If you didn’t trust, or even know the owner as you say, why would you expect him to be well behaved ? What makes you think that this unknown owner could not have changed the content of his SD to contain something even worse than what the new guy, equally untrusted and unknown, would put ? It’s like going to a forum where the poster is tagged anonymous and you distributing a link to his website he posted in some comment. For all you know after he gets a certain number of hits he changes content to something gross or even illegal in your country.
So if you trust someone to distribute his/her SD name, just extract the sign key too and send it along as tuple (SD::name, SD::sign-key). That would solve all your problems.
[As an aside:
You might be surprised to know version field of SD was (and i think still is) never meant to be user-facing. It is something purely for the backend - for the network to handle and resolve conflicts and churn situation in a particular way. If we figure out another mechanism which we think is better, we could even remove/replace it. That is why the version bumps etc are internally handled by safe_core and vaults. User-facing is data field. That is what they should manipulate if they need and special behaviour.]
I mean data field of StructuredData struct in routing crate.
Currently validity of previous owners signatures is also checked when a SD is deleted. You cannot revamp this system without specifying what happens during a deletion.
The problem is that the owner can do this without modifying version field.
I want the simple mechanism which was implemented earlier and which maintained the following invariants:
version 0 proves that the object has never been modified since its creation
version > 0 indicates the number of times the object has been modified
Safe network should be trustless. Seeing a version equals to 0 should be enough to know that a SD has not been modified. We shouldn’t have to trust A for that, because he/she may behave nicely for months and then cheat for a very specific contract.
In fact, version field has just been added on my demand in low level API (RFC 42). So no need for a complex mechanism: if user sees version 0, then he/she can be sure that SD has not been modified since its initial creation.
Of course this is true only If SD destruction is reimplemented as before.
I don’t agree with this - ownership and trust go hand-in-hand. If someone owns something and you rely on it, you basically trust that someone - that is the whole point about signatures - else why would people require something to be signed. What if the person did change that and version is now > 1 ? All you would know is the data is changed. That person owned that data and has every right to do so. You can demonstrate no involvement in being included or being a part of that contract and because of this you cannot say it’s violation of contract between you and him - it is clearly not, you were never a part of it in the first place. If you wanted true immutability rely on ImmutableData - which is network owned and cannot be modified. If you were a part of a contract which you did not want changed without your involvement add yourself to the owners list with equal weightage. The system that you seek (trusting someone else’s data but not that someone) seems to be fundamentally flawed.
Yes and now that i know why, i don’t think there is any reason for that any longer. You want to trust some data owned by someone without trusting that someone - doesn’t seem fair. You want permanent immutability look for a different data-type (ImmutableData). You want something to be owned and not changed, make yourself a stake holder in that.
Anyway at this point i am only repeating myself. Pls go through all the discussions above so far to see what you can’t do with existing functionality. (To me) the whole premise of trustless trust seems fundamentally, logically and cryptographically flawed.
@tfa Just remembered two more points if it helps clear things further:
Version can be incremented even if data did not change. Changes in the previous-owners field, current owners-field etc. will all result in version increment. You can have SD of version 20 in which data field never got changed. If there is some other field added in future and that requires version field to be manipulated in particular way by the backend all the apps that rely on its behaviour will suffer. That is why i am not comfortable with ppl using non-user-facing aspects of a data-type/network in frontend apps. It was not meant for that, is subject to change and may not do what you think it does. Using that in a particular way would mean a guarantee from us that this is what it is for, when at-least currently it is not (and might cause both us and app devs trouble if we commit to it without proper thought).
If a system want to track the changes, use versioning. Store data as versioned files. And for some reason if there is a requirement that only cares to check if an SD that is being pointed to has been modified, just store the Hash of it (or its relevant fields - e.g data) too along with that pointer (to SD). That will be more robust, much better supported and wouldn’t need to tie in with how backend should go about deleting, version increments etc. which is ideally left to the way backend thinks best.
I am not talking about immutability but I am talking about another feature: mutable data for which I want to know it is has been modified or not. This feature was available in the past and has been removed when implementation of SD destruction was changed.
I don’t want to trust someone or some organisation. I want to trust data that are mathematically proved to be generated in sequence. Of course immutable data can do that, But here it is something else: the data can be modified and the proof only last while the data is not modified.
I am not sure to understand: I presented a valid usage for version field. Maidsafe accepted the feature apparently without really understanding it. And now that you understand it you will remove it because you don’t agree with it.
I don’t think version field was meant to be the feature addressing that problem. Point 1.
I was not involved so i cannot comment, but what i know is sometimes there is huge (as in really huge) amount of work we tend to do to deliver the product that you see. Some details might have been missed by people involved or they might be too occupied at the time to give this a lot of thought. In that case, apologies if that caused inconvenience.
it’s not up-to me to remove. i will however vote for its usage-deprection, unless there is convincing reason not to (which so far i don’t see). I think you will agree on this too - a half baked thing that is not going to fly is better revoked. But if there is no alternative to it in some requirement then it should certainly be looked into and a proper solution sought, but that requirement is yet to be presented.
At least, if SD deletion is reimplemented as before, we still could assert that: if version field is 0 then data has never been modified.
Furthermore I think that most apps won’t develop complex things like adding another user able to modify a post in a forum app (I mean other than its creator). And when they do they might consider counting any kind of modifications in the edit count. This is the simplest implementation, but it can be justified.
Versioning is costly in terms of safecoins because an immutable data is created for each version. This should be used only when we want to be able to retrieve previous content. Also I don’t think we can trust versioned file: if I remember correctly versioned file are stored in versioned SDs whose history can be manipulated client side.
Anyway, versioning is a more complete use case. The use case I was talking about is much simpler: detecting if a SD has been modified.
Testing that its version is equal to 0 would be much simpler to implement. And just displaying version field can be more easily trusted by users than a specific app implementation.
All that a user sees is the specific app’s implementation of stuffs. If app cannot interpret the data field of SD in the way it wants that SD is useless to the app and hence to the user. If app makes any mistake (even if it’s as simple as reading a particular field or a data) that’s what the user will see (the mistake).
pseudo-code
let stored_ptr_to_sd = S;
if stored_ptr_to_sd.SD.version > 0 { println!("Edited") } // Relies on SD being deleted in a particular way
// version to be incremented in a particual way etc
// vs
let (stored_ptr_to_sd, stored_hash) = (S, H);
if stored_hash != sha256(stored_ptr_to_sd.SD) { println!("Edited") }
I don’t think it is significantly simpler or harder - hardly noticeable in a code base.
Why ?
You can achieve those without caring about the ones mentioned previously (versioning and way SD is deleted).
Your use case might be to check for any modification. Someone else’s might be to check just for data modification and so on. The facilities provided can help achieve both.
Anyway i guess I have said all there is to it (i can literally now link stuffs from previous posts to answer you). i’ll stop now and give others a chance to comment.
My conclusion is this:
version field is not user facing - if that is the behaviour wanted then MaidSafe should be ready to attach guarantees of operation to it and not change it in future (as currently it is meant to resolve conflict handling, churn etc).
Whatever you want, i think i have demonstrated all of those can be achieved without relying on how SD is deleted, how/when version is incremented etc.
I will go with whatever the majority thinks - my personal vote being none of those requirements (of exposing the version field and deleting SD in a way to suit you) are currently of any use.
Of course, you don’t take into account the management of the hash.
With version field you only need the SD itself to know if it has been modified or not. With the hash you have to store it somewhere which creates complications like:
user has to be able to check that the object containing the hash has not been modified, so hash of this object, stored in another object, and then again … infinite recursion there
the SD can be a standalone one without any object pointing to it
the SD can also be pointed to by another object created before the SD, by another user (for example chain of SD objects whose names are determined by hash of a root name and then hash of hash, …)
I think that to solve all these problems you have to store the hash in an immutable data created in parallel to the SD. But then the question is: where to store its name? Not in the SD because storing the name here would modify its hash. Here I don’t see any solutions.
It is definitively simpler to get information internally from the version field of the SD itself.
No, you have not demonstrated this. Or at least your demonstration is not complete because it doesn’t solve the storage of the hash.