In the Filecoin case, I would still think that it should be possible to guarantee that a particular object is not being actively served by a node on the network at any particular point in time and penalizing nodes (loss of Filecoin) that do not pass this check.
The concern I have is about malicious actors being able to access the raw objects held on the Filecoin network. They won't be able to do anything with the encrypted objects immediately, but I don't know that you can claim that will always be the case decades from now.
Yes, it is. If you delete the keys, nobody has access at all to the data. The ciphertext is irrelevant.
Said another way: you are trying to fit a centralized-shaped peg into a decentralized-shaped hole... wrong tool for the job.
If your use case does involve this situation somehow (?) then the only real solution is to encrypt it, as others in this thread have pointed out. There is simply no other option in an open-membership P2P network... otherwise the RIAA and MPAA would have long ago crushed BitTorrent.
Other networks have implemented mechanisms for the network nodes to delete files as detailed elsewhere in this thread and I think it is entirely reasonable to say there is more that could be done at the network level to help mitigate exposure. Dealing in absolutes is a dangerous proposition.
But all that would do would be to push people to do it off-network instead.
What the parent posters are saying is that there's no way to trust that your (encrypted) data won't end up landing on the hard drive of someone who chooses to capture everything that passes through said hard drive.
Whether the node itself keeps the data is kind of immaterial, if there's no technical limitation preventing the owner of the node from keeping your data.
But also, as an open-membership decentralized network, there's also no real way to incentivize node implementations to obey deletion requests.
It's helpful to think about peer-to-peer networks as if every node was programmed from scratch by the person or organization running it, to do exactly and only what that person/organization wants it to do. (Not true, obviously, but the incentives behind there being a free market of p2p node software work out similarly to if it was.)
In such an environment, why would a given node owner want to add a "read a deletion-request log, and actually-delete everything mentioned in it" feature to their node in particular? Especially if they weren't a party with their own private data stored that they were interested in ever deleting, but instead were only on the network to make money hosting other people's stuff; or because they wanted to insert public data sets onto the network?
The threat model I'm thinking about is a malicious actor requests an IPFS object that he/she knows holds data that is valuable, but that they can not decrypt. They then hold this object for a period of time till at some point they are able to break into it using improved computing power or exploiting some flaw in the implementation.
Now, you raise a good point about Filecoin being an open membership network. In my particular example, the malicious actor could just decide to run an IPFS node and start holding any data that comes to it for future malicious purposes and maybe they start pulling down specific files that they want to target directly. I don't have a solution to this other than to think that having some reputation built into the IPFS node network could help mitigate that risk. You might imagine that nodes with high reputation are trusted and it is harder(requires a lot of time/money) as a node operator to become part of that group. People might decide to only trust the highly reputable nodes with their private data and utilize all nodes for public data.
Then 3 years later all the snapshots end up on a torrent site, after you paid that whole time to "delete data".