[jhunter1016]

Disclaimer, I am head of product for Pinata

I think of IPFS as being an open data platform first. You can connect to it and disconnect as frequently as you like. The underlying p2p capabilities don't have to necessarily be fast. It just has to do the job it was designed to do—get content in a permissionless fashion.

Speed, convenience, reliability, and more are not the problems protocol need to solve for. Providers can solve for these problems without infringing on your ability to "take your ball and go home." Take Pinata for example. We provide dedicated IPFS gateways that provide essentially the same experience you would expect from traditional cloud providers. But if you ever want to leave Pinata or back your data up or just inspect your data, you don't need Pinata's permission. IPFS media is public and open. Convenience is a layer on top of that.

IPFS also doesn't need or have tokens. Filecoin is a separate entity. IPFS is especially powerful because it is not linked to a specific blockchain or currency.

[dmitriid]

> Speed, convenience, reliability, and more are not the problems protocol need to solve for. Providers can solve for these problems

They can't if the protocol doesn't allow it.

Otherwise it will be regular centralized storage providers with IPFS bolted on top for one or two geeks who care about it.

[zeroclip]

That’s kinda the whole point. A couple of centralized gateways can be the main hosts, like Protocol Labs and Cloudflare, and provide the best performance, and also compete with each other on the same content hash. If one or both of them goes down, any user in the world can re-host the data by pinning it, if they still happen to have the file on disk or if they’ve backed it up.

[dmitriid]

I don't understand the point, really. Especially not from the user's point of view. IPFS doesn't add anything in n this equation except additional complexity and "well, if this already centralized service goes down, you're still screwed because the chances of someone storing your files are asymptotically approaching zero"

[zeroclip]

If your centralized X.png URL is changed, or the website goes down, or the host goes down, then the URL is dead, and so is everything that points to it. Even if somebody has the asset backed up locally or in their cache, they will have to re-upload it to another URL.

Because IPFS links are not URLs, it works on a different paradigm.

The chance of somebody storing your HTTPS files and IPFS files is the same. Users pay hosts to keep hosting them. With IPFS, if the user stops paying the file hosting service, another user can pick up the slack without the link becoming dead.

[dmitriid]

> if the user stops paying the file hosting service, another user can pick up the slack

Too much faith in someone picking up your files when a centralised host goes down. This is an important detail that for some reason is always dismissed by IPFS proponents.

[zeroclip]

If a user stops paying for hosting, and they are not hosting and pinning it themselves locally, they can't expect the file to persist indefinitely on the web. Hosting is not free.

But if another party is interested in the file, they have the option to persist the file regardless of what the original party and centralized services choose to do.