Hacker News Reader

Comment by jstanley | Hacker News Reader

You host anything you want to host. If nobody wants to host something it disappears.

When you put it like that, it doesn't sound much different than how website hosting works today.

The content addressing and peer-to-peer architecture are the main differences.

The difference is that if you decide to stop hosting, it doesn't just disappear. If there is anyone else in the world who wants it, it stays.

It also means you don't need to trust the server to send you the correct content, since everything is automatically checked against its content hash.

It also means it's automatically a CDN - you don't need to be able to serve every single person who wants to look at your content, because they'll all be serving it to each other.

I'm having a hard time imagining this at scale.

I have a few thousand web pages on my site, blog posts, etc. Most of it won't be seen in any given day. So I have to pin it as it's realistically unlikely anyone else will. Not much different from today. This probably describes 90% of web content out there, where a single node is all that is keeping that content alive.

Now imagine something slightly more popular than my website. Maybe a particular Medium article. If it's two years old, it's unlikely to be getting any hits at this point, though it might have been popular at one time. So again, Medium has to pin it (or maybe the author would). Popular stuff would stay floating around while it's being viewed.

It's almost a dynamic CDN/torrent which could help with bandwidth, but I don't see any advantage for persistence in most cases.

I think the advantage is that it's easier for _anyone_ to be able to keep a site/file alive without having to implement an archive.org style of rewriting all the URLs/links. If you want, you could pin that medium article you talk about and now even if the medium node(s) decide its no longer worth pinning, you've still got it pinned so it's accessible to anyone at the expected "location".

Similarly, this makes take-downs harder. It's no longer one node/machine hosting a file, but as many nodes as who find it valuable.

If users never pinned anything, you'd be correct, it would be basically the same as the current internet, with one organization maintaining everything. But IPFS gives you the ability to change that.

Thank you for that perspective - that makes sense. I hope there is an easy way to pin an entire site and not page-by-page so, for example, a full documentation set could be kept.

Yes, content on IPFS is represented as a Merkle tree so if you pin the top of the tree it will traverse down and recursively pin all of the subtrees as well. (You can, of course, pin a subtree explicitly if there's a only certain part you want.)

Maybe you'll find an article interesting and want to pin it yourself. Maybe you yourself will link to it and want to pin it for that purpose. Maybe someone else will link to a very influential article you wrote and that will make it stay.

Overall, it's a subset of the availability of a single server, plus the page always stays at the same "place" and never moves.

>Maybe you yourself will link to it and want to pin it for that purpose.

This is an important point. If you pin all the content you link to, the links on your site will never break so long as your node stays up.

Which essentially means you node is now a web server with all the responsibilities that entails (keep backups, always connected, etc). It feels fragile - I can't imagine pinning everything I ever read (or think might possibly be important some day).

What about all the .EXEs (games, etc) and SDKs I download? I'll bet over the past 10 years I've downloaded and viewed a few hundred GBs (or more) of content.

If I ever want to see anything again, I have to pin (cache it locally). I could do _that_ (cache locally) with today's web.

I like the idea. But just don't see it working well at scale.

you need to review the technology if you think ipfs is more fragile and needs data nodes to always be up.

you need one data node up. You can have as many as you want.

if nobody wants to keep the old exes, they'll be lost forever. ipfs was never meant to keep everything forever. Its meant to guarantee you that the file you're viewing (if it still exists) is the same one that was published under this hash. With no regard as to the source of the file. It could be shared with you by your neighbor or the original uploader. And, if you see value in the content, you can also share it with others by pinning it.

its essentially bittorrent as a filesystem. as long as nodes exists, the files will be available.

we built a little tool for organizations to share their "pin lists", so hackerspaces could back up each other's content https://github.com/c-base/ipfs-ringpin

The difference is that if you pay someone to host this site for you you are paying for bandwidth, DNS registration, and disk space. One DDOS attack could mean the end of your project.

With this kind of system the idea is that the cost difference between unpopular content and popular content isn't so pronounced. You might have to pay a little more up front, but there are fewer surprises in your bill.

> It also means you don't need to trust the server to send you the correct content, since everything is automatically checked against its content hash.

This is the confusing part to me. How does updating content work? Lets say I want to visit the jstanley blog. Does this mean you can only ever publish once, because adding an entry would change the content hash? Does everyone have to contact you for the new info hash? Does ipfs work with existing DNS?

On top of the content-addressed IPFS is an IPNS layer which maps addresses to content hashes. The address of a piece of content is a public key, which is used to sign the content hash. This means only nodes in possession of the private key can change where the IPNS address points to. In addition, IPFS gateways also support a special SRV record in DNS, which can point either directly to a hash or to an address which points to a hash. (This is how you can associate a domain name to content served by IPFS. If you also point the A record of the domain to a public gateway, the gateway will automatically look up the SRV record and return the content when someone retrieves it by HTTP.)

At the moment, go-ipfs (the reference implementation) only supports pinning content hashes, so if you have someone else pinning your content (like a pinning service) you have to notify them of the change. There are plans to add support for mutable pins in the future.

Put in the vocabulary of git: any given commit is referenced by hash[1] and is therefore immutable; IPNS addresses are like references (branches, etc) which can be updated at any time to point to a different commit.

[1]: Since the content is a merkle tree, if they've only changed a few files most of the pinned content will retain the same hash.

That's pretty neat. Do you know if there is protection against rollback?

IPNS records have a fairly short expiry, so you have to keep republishing them. This also keeps the DHT from getting overly full of records that nobody is using anymore, but does mean that a node with the private key must be kept online. They're working on improving this situation; here's a discussion on the topic: https://discuss.ipfs.io/t/confusion-about-ipns/1414/4

I am still learning about IPFS but I participated as a minor party in the design of one of its intellectual predecessors, Freenet.

IPFS is not just going to act as an ad-hoc CDN, it's also going to work as a regional CDN.

If someone does a report on your funny video on WGN-TV and ten thousand Chicagoans hit your tiny little website in the next ten minutes, your server will get a few hits because nobody else has it yet. After that the network effect kicks in, and eventually everyone is loading it from an IPFS server somewhere in Chicago. When they start 'retweeting' it and everyone is looking for it, it'll end up scattered all over the country.

Until people lose interest, and then the copies will begin to disappear as the next fad automatically pushes it out.

Reply on news.ycombinator.com