yes - because (again), it wasn’t designed for that. You might continue to see more edge cases as things evolve.
Thread Summary (Version field):
We decided we will have no changes to the current impl. Client libs will expose this but the functionality of the same needs detailed in docs as disclaimers to not mislead users.
Version field is used by Vault to handle POST operations and sync data during churn and not risk replacing old data with new. This however from the PoV of Vaults could mean any change(data/owner-keys/…) or no change if the user chose to explicitly POST with just the version incremented. So this CANNOT be considered as a guarantee of mutation of data.
Now if client-A is expecting version “5” of some data(D), when Client-A makes a Get(D) request and gets version “5” from the network, this merely means “There has not been another POST operation to this data item in the network which is accepted”
With Version only influenced in POST operations, it can also have a different meaning based on the specific data type in terms of data mutation.
StructuredData - if we expect version “5” and get same version from the network, we know for sure nothing has changed(data/owners/…). If version has changed to “6” for example, it could mean anything. data has changed or owners have changed or no change has happened.
(Pub/Priv)AppendableData - since non owners do not make POST requests to “append data” but use “APPEND” rpc, data mutation can occur even in the same version (this is what allows multiple people to append data and vault takes the union. This is outside the signed scope of the type). For this type, version if expected at “5” and what is received by Client-A making the Get(D) request is also “5”, it could mean data has changed. Owner-only editable fields such as owners-list or filter-options cannot have changed. If version has changed to “6” for example, it could mean anything: data has changed or owners have changed or no change has happened.
If there is a requirement to track the actual data mutation, this can be kept client side right now with an expected hash instead of version and get it to just selectively include the parts for which mutation needs to be tracked. Eventually we can also look at the network providing hash replies for data to avoid needing to fetch the entire data before confirming expectations, As a performance optimisation, this needs taken to a separate rfc and handled once vault/routing team are sorted with their current backlog (which is long already)
5 Likes
Thread Summary (Deletion handling):
Considering data space being paid for is just when submitting a PUT request, Delete flow is being changed to accommodate the use cases highlighted in the thread by @tfa
So in essence all three options expected as use cases should now be achievable (well once it’s implemented)
to retain ownership but empty content
- Owner submits a POST request with empty content.
to let go of ownership and NOT allow anyone else to claim this data
- Owner submits a POST request with empty content and sets the new owner to a known constant value used to represent “no owner”. All further requests targeting that data will fail, except for GETs which will return the data as normal.
to let go of ownership and allow anyone else to claim this data
- Owner submits a DELETE request (which has the version incremented by 1 and then resigned) to the vault and the vault nulls all fields excluding version.
- For someone else to now claim this data, they would need to first do a GET request to retrieve the chunk and learn the current version(v) of data.
- POST and further DELETE requests will return an error regardless of version used by sender.
- PUT request similar to normal PUT request but use the version as “v + 1” instead of “0”. any other version will return an error.
5 Likes