|
|
|
|
|
by kevincox
1575 days ago
|
|
But arguably those have a single point of failure, the company owning the data. In theory Filebase is storing your data on a distributed system (that you can verify) that has no single point of failure. You can make this even more reliable by using two filebase-like providers to store the data. Thanks to IPFS you can access the data the same way and transparently use both providers so that if any single one is up you can access your data. Of course it isn't perfect, if filebase goes bankrupt you need to scramble to get another set of pins for your data. But I think it does provide a much better system overall. You can also imagine shifting the data around providers over time much like S3 storage tiers, maybe on provider provides cheaper storage but more expensive access, you can pin cold data there and remove it from your hot data provider. This would be completely transparent to any users. It also provides interesting opportunities for bring-your-own storage. Users can just give my the CID and use it on my app/service. It will be around as long as they keep it alive. Or they can pay me and I can pin it for them. |
|
I think this is a big feature that I hadn't recognized until you phrased it this way. It allows a strategy of guaranteeing *at least 1* pin of your data if it's important, but from the application side, you can forget about the details of the data storage.
I doubt IPFS is fast enough to justify it over other strategies today, but it makes me think of a type of cache where if a CID can't be found, you might rehydrate some slow, cold-storage data and push it back out to the network.