[ahnick]

So I have read this is why they didn't implement deletion support before. With that said, I would still think that 1) 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 2) If all the node software supports deletion, then even if you couldn't provide a 100% guarantee at least it would provide some mitigation.

[derefr]

Keep in mind also that Filecoin's storage layer is IPFS; and IPFS nodes don't have incentives that are perfectly aligned with those of Filecoin.

There's maybe a reason for the owner of a "Filecoin node" to want to delete data "on the network." But that data ends up stored on many IPFS nodes, some (many?) of those hosted by people who've never even heard of Filecoin, but are just running on the public IPFS network for other reasons (usually the same reasons someone would donate to the Internet Archive, or host a public-access Debian APT mirror.)

When you look up a file "on Filecoin", you're really looking it up from the IPFS network. Filecoin just incentivizes the insertion process. But data inserted "into Filecoin" is now on IPFS. So you have to think about what an IPFS node would (want to) do with your data.

Why would these "pure" IPFS nodes that have your data, care about deleting it in response to requests? That's not what IPFS is "for." These nodes aren't participating in the filesystem-like storage paradigm that Filecoin represents. They're participating in a "content-addressable storage" paradigm. Deletion would be a violation of the ideology that likely motivates them to run their node.

[ahnick]

Yes, I understand that. I have this same issue with using just pure IPFS to store private data. IPFS for public data makes a lot of sense to me. When using IPFS for private data there seems like there is an inherent risk (hopefully only a small risk) that the encryption or its implementation can be broken at some point in the future potentially exposing the content that is hosted on the network. Normally, in this scenario the response is just run your own network of IPFS nodes if you want to restrict access, which is totally reasonable. I'm just expressing my desire to have something like Filecoin, but at the network level have the clients enforce access permissions and honor deletes. I may be the only one though. :)

[derefr]

I think the thing is that, because, as you say, there’s no true “Proof of Deletion” possible, then people who are considering alternatives when implementing a system that has private data, and needs a storage layer, just won’t choose IPFS/Filecoin, since it can’t offer them the same guarantees that e.g. using S3 can.

Using S3 at least means you’re in a contractual relationship with Amazon, who thus has a monetary incentive from all its customers to “do what it says on the tin”, lest they all lose faith in its claims and boycott/switch to some other object-storage provider. Amazon can do this, because it's a single coherent closed-membership hierarchical organization, rather than an open-membership p2p network which people could join for reasons at odds with the network's "designed" incentives.

Without a "Proof of Deletion", adding a deletion-request system to Filecoin would only be a mitigation against ciphertext-recovery at best—something that increases the probability that your file will be fully erased from the network—rather than a true guarantee that the entire system will attempt to achieve an explicit consensus state where the ciphertext has been purged from it.

So, if you're a system architect, why would you choose to store private data on a service (Filecoin) that can only offer a high probability of erasure, rather than one (S3) that can offer a guarantee of non-recovery?

And if it's clear that there's no reason to make that decision in favour of Filecoin, then turn that around: why, as the Filecoin or IPFS node-software authors, would you bother to add this feature, if it would be the game-theoretic dominant strategy for software architects that have this use-case to ignore Filecoin/IPFS in favor of some other solution, with or without the added feature?

-----

All that being said, I'm ignoring a distinction here that's fairly important: there are two types of private data — timely and timeless private data.

• Timeless private data would have just as much value if it was obtained years from now, as it would have if it were obtained today. (Someone's Bitcoin-wallet private keys, for example. Or compromising photos of a politician.)

• Timely private data has high value to its owner upon creation, but that value erodes over time; until, at some point, even the creator themselves doesn't much care if it gets leaked. (Apple's next iPhone design, for example. Or the source code to Super Mario World. Or military intelligence.)

There's actually far more timely private data in the world than timeless private data. And encryption, all by itself, basically solves the protection needs of timely private data. Cryptanalysis seems to only really advance in power alongside Moore's law; so anything encrypted using modern encryption technology, won't be brute-forced for a number of years yet. So you can take your timely private data, encrypt it, and stick a printout of the base64 ciphertext in the public square, if you like. By the time anyone can decrypt it, there'll be no value in doing so.

Filecoin/IPFS works just fine to hold timely private data. And since that's most private data, it actually supports the needs of most system architects just fine.

It's quite the rare use-case that requires decentralized storage of timeless private data. The fact that this type of data is so rare, though, is another strike against IPFS or Filecoin node-software developers being interested in introducing a feature specifically meant to help that use-case. Filecoin/IPFS would still be a non-dominant strategy for the timeless-private-data case, so there'd still be no point; but on top of that, it's a niche-within-a-niche.