| HN Mirror

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.