sgoendoer
commented
7 years ago TL;DR:
Use "active" and "revoked" flags to (de)activate datasets. Dataset time out at "timeout" and should be renewed by the client periodically.
Full response:
We decided against allowing a delete operation, because it would give way to the (unlikely) possibility of another user "claiming" the same GUID and thus essentially taking over an identity. Anyhow, as stated, the possibility of this happening is extremely low.
We decided to have a "timeout" parameter in the dataset instead, that causes the dataset to become invalid at a certain point in time. Anyhow, there is no automated function being executed at timeout of a dataset since we never discussed this option further. (Plus, it would be interesting how this could be achieved in a decentralized system such as an DHT.)
Furthermore, we have a "revoked" and an "active" flag in the dataset. If revoked it is set to "1", the dataset is to be considered invalid indefinitely. If "active" is "1", the dataset is temporarily inactive.
Last but not least: Adding an HTTP DELETE endpoint to the API would require the client to send some form of authentication. As DELETE does not allow to send any body data, this would mean we would have to do that via POST or PUT, making the API less "clean".
I don't see any interface for suppression of an entry. In #1 , DELETE method is proposed, or PUT with inactive. But I think it is not available. Beside the fact that the test platforms will be populated with many fake entries, why wouldn't it be possible to erase the traces of one's identities?