Right but filecoin isn't a centralized service, it's a decentralized network. Just like how ultimately your facebook post is stored on a server somewhere, stuff you stored using filecoin is stored on a random computer somewhere. At least with facebook there's some central entity that gets to decide where their servers are located and who gets access to them. You don't get that with a decentralized network.

Just because the storage network is decentralized (i.e. I don't get to choose where the files are hosted) doesn't mean that the nodes operating on that network can't be designed to honor a deletion request. For example, Tardigrade (https://tardigrade.io) is an decentralized network that provides an S3-compatible storage layer and also provides a removal command for the client. (https://documentation.tardigrade.io/api-reference/uplink-cli...)

It's not just a decentralized network, it's an open membership decentralized network, i.e. anyone can be a node, and any compatible software can be used to run a node.

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?

In terms of an incentive, I would say that the node owner would honor the deletion request if the network pays them to do that. If I'm a node operator I don't so much care about the particular data I'm hosting, just what the network is paying for me to do.

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.

What if they claim publicly to delete your data, accept decentralized payments to delete the data, actually delete that data on the node in the sense that nobody can retrieve the data on the public internet using any official protocols, but routinely take filesystem-snapshots of their servers and the owner browses them offline undetectably at their leisure?

Then 3 years later all the snapshots end up on a torrent site, after you paid that whole time to "delete data".

Yes, I think that is a risk in the absence of a true "Proof of Deletion". Perhaps though it would be so expensive to maintain a copy of all this data that no one is paying you for that nodes would be incentivized to just perform the actual deletion, since the rewards of keeping the data are unknown and the time horizon for maintaining that data at your own expense is unknown.

You can issue removal commands all you like. There's still no guarantee that the client performs the operation.

I agree, at least afaik there is no way to construct a formal "Proof of Deletion". This risk though I believe exists with even centralized services, so for example if I ask Amazon to delete this blob of data I actually don't know if in fact they did delete it. We all just assume they are doing what they are purporting to do, because if they aren't then there could be significant legal repercussions.

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.

There's just no point. Encrypt the data. Ask the people with access to delete their keys. This way you don't have to make Filecoin more complicated.

I disagree. Again encryption is not the same as not having access at all to the data. If centralized services offer the concept of having access control mechanisms available and we trust them to delete the files, then why not have those same types of mechanisms in place for a decentralized network? Asking people to delete their keys is user hostile and will likely lead to people just not using the service.

> Again encryption is not the same as not having access at all to the data.

Yes, it is. If you delete the keys, nobody has access at all to the data. The ciphertext is irrelevant.

The ciphertext is irrelevant now, today. That might not always be the case if computing power improves sufficiently to be able to breakthrough that encryption or a flaw in the encryption algorithm (or default parameters being used in a particular implementation) is discovered. At that point, it would be nice to know that even the ciphertext was not exposed.

If your data is so important that it needs to be protected from future theoretical attacks.... what the heck are you doing uploading it to a globally distributed and decentralized platform?!

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.

They're running software that connects to your overlay of the network, no? It doesn't involve human interaction.

When I say "user" here I'm talking about me the service provider being the user of the network. Instead of "user hostile", what I should have said is it "just doesn't solve the problem of access".

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.

This is the only sane solution.

>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.

But all that would do would be to push people to do it off-network instead.

Yes, I agree. It is just a mitigation. At least though it would not be actively available on the main network. The more I think about this, the more I think being able to have some sort of reputation system for node operators would be really valuable.

Ultimately the network will be storing blobs of some kind. You can build whatever encryption structure you want to, on top of that layer.