News for hackers. Stuff that matters.

A comment on IPFSify Documentation. Parent comment

Re:IPFSify Documentation by stavros on Monday August 02, 2021 @07:53AM (#28035435)
Well, technically the public resolvers aren't meant to be used. If you're going to be using IPFS with bridges, just stick your content on a static host and you're done, why complicate things?

Then again, there isn't much incentive for people to use IPFS, and it's hard to embed and resource-hungry, which hampers adoption.

[ Parent | on HN ]
Re:IPFSify Documentation by karmanyaahm on Monday August 02, 2021 @11:41AM (#28038101)
> just stick your content on a static host and you're done

1 (relatively small) advantage is not needing to control the server, just the domain. The server then polls IPNS and updates things with the latest stuff.

2 There's the standardized (and perhaps more meaningful) cache busting aspect for assets. i.e. the IPFS Companion browser extension takes all /ipfs/<CID>/filename.ext urls and sends them from the local datastore instead of making requests. This way, assets aren't requested from a remote each time when they're the same on multiple websites. This helps since CDN's don't use common caches anymore. Though, it might come with the same privacy risks. https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...

> it's hard to embed and resource-hungry, which hampers adoption

yes.

[ Parent | on HN ]
Re:IPFSify Documentation by jeroenhd on Monday August 02, 2021 @09:11AM (#28036040)
Cloudflare's public resolver is definitely meant to be used by Cloudflare.

I get that IPFS as a protocol assumes everyone is running their application in the background, but there's just no market for that. The pinning and sharing part of IPFS is definitely a value add for most users, but they won't discover the features if everything is locked behind some mysterious, super technical application that they need to run next to their browser.

[ Parent | on HN ]