Hacker News Reader

Comment by Thorentis | Hacker News Reader

I'm amazed that cloudflare ever provided a public ipfs gateway to begin with. That said, I don't think ipfs is actually useful for anything besides being an interesting thought experiment. Every problem it aims to solve, another protocol or tool specific to that problem solves it better. There is no real world use case I think of where I would ever consider using ipfs.

View on HN

Hello from a user of Cloudflare IPFS gateway! Satisfied and happy. For the moment, I use it as a redudant backup of my GitHub-hosted web gallery. https://ipfs.awalkaday.art. In case servers belonging to Github or Microsoft go down, the ipfs version of the same site is accessible. A peer-to-peer solution to hosting media content (in my case, an online photo gallery).

There is actually a conference of ipfs devs and users in Brussels going on (or held not long ago). https://2023.ipfs-thing.io/

Do you know how many Ipfs nodes have actually pinned your content? Have they done so purely because they are ipfs enthusiasts? Do you feel this solution is better than hosting it on a raspberry pi from home or on a cheap VPS?

Why not both? Hosting content on a paid IPFS gateway is cheaper than any VPS ever will because of the enthusiasts, and if you still don't trust it enough you can have your own raspberry pi hosting/pinning your own files.

There's a misunderstanding here. IPFS' content addressing exists to serve the interests of people who might want to save someone else's content, and of people who might want to find and access content which others have saved, much more than the interests of people who want to upload their own content and wouldn't mind a freebie. (That said, it does does also have advantages for uploaders who don't want to administer an Internet-facing Linux box and don't want to fiddle with DNS to move web hosts.)

That doesn’t seem like a misunderstanding as much as the person you’re replying to has a deeper understanding of how the whole system works. That seems important to ask because as far as I can tell the person they were trying to was under the impression that it provides free hosting.

I don't have a place that I own or rent that's called home. I am living as an undocumented refugee, somewhere in Europe. Sorry, I can't rely on physical storage of information (except mobile/portable devices). The place in which I live at is not on the list of what I can control. That's mainly decided by government(s) or my social network members a.k.a friends.

I have no idea of who or what pinned the ipfs content. I really don't gather those statistics and have never tried to do so. The only "metric" which grabs my attention is that the content is widely distributed and that its reliably accessible via more than one way (not depend on a single point of failure) over large-scale electronic networks/protocols (HTTPS, DNS, IPFS, ETH, ENS..).

> Every problem it aims to solve, another protocol or tool specific to that problem solves it better. There is no real world use case I think of where I would ever consider using ipfs.

Insofar as I understand IPFS, the most natural use case I've come across would be serving Nix packages.

That is, my understanding of IPFS is "protocols related to distributing content based on its content". Nix stores all its packages in a nix store, where its address there is a hash of the inputs; but, there are experiments for addressing Nix packages by the package's contents.

https://www.tweag.io/blog/2020-09-10-nix-cas/

On the Nix side of things: a cache-miss from a binary cache would just mean that a package would need to be built from source.

It solves some things that have an overlap with torrent 2. If you're interested only in single files, or collections of files which change but remain 99% the same, then ipfs is great and doesn't really have a widespread alternative right now.

How is IPFS better than torrents for changing files, considering that it uses content-based addressing?

Changing collections of files, not changing files. Let's say you have a collection of 1000 books. You get two more and publish a collection of 1002 books. With torrent, you'd have a completely separate download. With ipfs all previous users can now share the existing files as part of the new collection without doing anything special.

> With torrent, you'd have a completely separate download

That sounds more like a limitation of your bittorrent implementation. You think seeders have dozens of identical copies of each release hanging around on their drives just to be able to share it on separate trackers through separate torrents? :p

Or is there some new feature in IPFS that's an actual differentiator here? It's been a while since I was fully up to date on protocol development.

I don't think you understood the issue. Maybe read it again, or check the change in BitTorrent v2 which provides something similar as per-file trees https://blog.libtorrent.org/2020/09/bittorrent-v2/ (v2 support in clients in the wild is still very low though)

That was a bit tounge-in-cheek, cheers for complementing. Just to clarify, I think its fair to consider v2 if comparing with IPFS (which doesn't really have a large number of mature implementations either).

> BitTorrent v2 not only uses a hash tree, but it forms a hash tree for every file in the torrent. This has a few advantages:

> Identical files will always have the same hash and can more easily be moved from one torrent to another (when creating torrents) without having to re-hash anything. Files that are identical can also more easily be identified across different swarms, since their root hash only depends on the content of the file.

So I guess the question stands, how is IPFS supposedly the preferred protocol over Bittorrent (v2)?

Technically you can do the same thing for the transfer itself in v2. The preference may be for ergonomics where BT requires something like "download this file, from package with this hash, ask these hosts about it", while ipfs is more "yo all, who's got this hash".

You could make the experience similar though if you really wanted. So in theory, no difference. In practice, ipfs solved this years ago, has a nicer interface to it and put updateable naming on top for convenience.

> while ipfs is more "yo all, who's got this hash".

Isn’t that the purpose of BitTorrent’s DHT?

It depends a little on how you arrange those files, but with UnixFS (the standard way to arrange them?) the files contents are arranged into a merkle DAG, so any shared files (and indeed chunks thereof) between the two versions would remain the same and thus still be ‘seedable’ by the parties that have it. It’s similar to BitTorrent in that regard. The root of content would get a new content address, but all the identical data below it in the merkle DAG would have the same content address as before

The one thing missing for me on IPFS is the ability to have ACL rules for access based on gateway id. When I was working next to the people from protocol labs, they mentioned the idea of having lists of friend peers, but that wasn't enough.

Reply on news.ycombinator.com