Transparency or opacity of SD modifications

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