Transparency or opacity of SD modifications

[ustulation]

@Viv

The main advantage being mentioned for tfa’s approach is by using the version one can confirm if the data has “since” been mutated(regardless of data field in SD changing).

This is something i have a problem to. As you said the original intended purpose of version field was (and for me is) solely :

@Viv

Also it makes churn handling certainly easier in vaults with option A which was one of the reasons it existed previously as it helps prevent data coming back from the dead. Sure they’re ways to work around this by keeping a delete cache that will block any refresh of the data getting into the chunk store, which was an approach that was tried and found functional but this does leave a time based cache which itself isn’t refreshed to other nodes open.

It does not indicate change in a way ppl might think -

1. Maybe the data changed.

2. Maybe only the owners changed. Maybe some other field in future-scope.

3. Maybe nothing changed - I just did a post of exactly the same SD (it’s free anyway).

I don’t know what ppl would be tracking with tracking the change in version, unless it’s for the mere pleasure of version-gazing. For anything more serious, more concrete and better method should be sought (vaults return a hash of entire or fields of choice or client keep it themselves or whatever) - this being my argument and suggestion. If vaults could handle churn and others without version, we could even remove it from SD without affecting users.

@Viv

Personally I’d like to side with "nullify signatures and data.

This is just for my understanding - what was the downside to a full delete and restart from version 0 ? Was it the above concern mainly or was it tied to replay attacks or were there other caveats ?