Hacker News new | ask | show | jobs
by keyle 2833 days ago
Cool explanation. I found Cloudflare's explanation really well put. https://blog.cloudflare.com/distributed-web-gateway/

Since hosting a ipfs node feels like being an onion endpoint, can you restrict bandwidth?

Also can you control the size of your local cache or how does it work with the replicated content?

1 comments

Yes, and yes! There's a cache plus the concept of "pinning".

Hosting a node is not quite like being an onion endpoint, because the bandwidth load gets shared out very quickly.

Hosting a _gateway_ is a big bandwidth commitment, but I pay for lots of bandwidth for just that reason.

If we compare hash content with http urls, urls are easy to remember, while hash are hard to remember?

It feels like the dark ages before altavista, and you had to know the url. Still, a url was more memorable to pass friends by email, than a hash.

Will there be ipfs search engines and wouldn't that just be bittorrent?

Also browsers remember urls... If everything goes through your local gateway, it's all just /hash, hard to remember / re-discover? Or is the plan also to move away from browsers?

DNS works just fine for IPNS content-hash-addresses too, and heck, you can do that right now. You just use that, the same way you'd use anything else - just say that dweb.foo.xyz is associated with a particular IPNS address (and www.foo.xyz can be the regular ol' web address).
Here's something of a search engine for IPFS: https://ipfs-search.com/

It works by crawling the DHT, though I don't think it's quite perfect yet. As for URLs vs Hashes, you point URLs to a hash through DNS TXT records.