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

[dmitriid]

So. Let's go back to my original statement: "Otherwise it will be regular centralized storage providers with IPFS bolted on top for one or two geeks who care about it."

What does IPFS bring into the picture apart from "oh yeh, there's a near-zero chance that someone will keep hosting your file"?

[zeroclip]

There's two specific attributes that are unique to IPFS.

1 - A content addressable URI protocol that allows you to locate a file without linking to a singly-owned and named server or host. This is not the case with HTTPS URL protocol.

2 - Open source clients where multiple parties, including competing parties and individual users, can all simultaneously and permissionlessly peer-to-peer host an asset behind the content addressed URI.

[dmitriid]

I understand that. This doesn't address https://news.ycombinator.com/item?id=32743041 or any of the subsequent discussion.

[zeroclip]

We are entering a recursive loop, because I’ve already responded to that. :)