Live data from Hacker News

IPFS Maintainers Winding Down

ipshipyard.com

11–20 of 226 posts

Re: IPFS Maintainers Winding Down

#11
Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check, libp2p, ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, Wikipedia-on-IPFS.

It kinda feels like the AWS or Azure of file distribution, so much stuff so confusing. Also apparently with Protocol Labs owning several of those things despite not operating those things?

Ironically seems quite a fragile setup.

Regardless, very sad news.

Re: IPFS Maintainers Winding Down

#13
post #4

Sad to see it go having been a maintainer some years ago. For anyone wondering, there are more sustainable (with a viable, focused business backing the project) options to do p2p, namely Iroh - https://www.iroh.computer/ which was built by ex-IPFS ex-Protocol Labs devs (I have no relation to the team beyond having worked with them back in the day). Sadly Protocol Labs is doing.. ehh whatever now, except apparently su…

I love Iroh but it doesn't quite work the same as IPFS if I understand correctly.

Re: IPFS Maintainers Winding Down

#14
post #7

Earlier quoted context omitted.

I think something like IPFS is definitely needed. There is nothing stopping you from distributing a webapp on bittorrent but you'll also need to add a README for instructions on how to run the webapp on localhost so a browser can render it. So thats not something that any non-technical user wants to do.

Can you share potential webapp use cases that would rely on IPFS or using IPFS for referencing resources would be an improvement? Perhaps my mental has gaps on this topic, and my thoughts and assertions could be incorrect.

The arguments for "reproducible builds" are strong and so think reproducible builds but for something that can be loaded in the browser. Browser is a big deal because its a sandbox also. For example Signal could be a webapp if we had content addressable hashing and it would be sandboxed.

Re: IPFS Maintainers Winding Down

#16
post #7

Earlier quoted context omitted.

I see this very similar to IPv4 and IPv6, and adoption. Non content addressable URL addressing simply is "good enough" for most use cases, and bittorrent is "good enough" for serving content durably and somewhat in a content addressable manner (file hashes, magnet torrents, immutable torrents). Do we need IPFS URLs? It doesn't appear so, it seems like a solution seeking a problem. IPFS gateways will always be a targe…

I think something like IPFS is definitely needed. There is nothing stopping you from distributing a webapp on bittorrent but you'll also need to add a README for instructions on how to run the webapp on localhost so a browser can render it. So thats not something that any non-technical user wants to do.

Content-addressable storage as a whole is a non-starter with non-technical users.

Re: IPFS Maintainers Winding Down

#17

Does IPFS actually have users? I remeber when they raised 270 million and a bunch of people there got wildly wealthy

Wait are you telling me yet another supposedly ground breaking technology turned out to be yet another grift.

I know a lot of people on HN are going to call me overly cynical. But this pattern should be so obvious by now. Any cynicism to any new ground breaking technology which is gonna solve a problem that exists because of capitalism, that this cynicism is more than warranted.

At this point we should all be cynical of any new technology.

Re: IPFS Maintainers Winding Down

#18
I can not say IPFS was a bad idea. Consider GitHub: it is a massive content-addressed store with a smiley on it. There has been some very hot P2P products, e.g. Tailscale. Protocol Labs had its peak during/after the ICO, but long-term, (1) they did not focus on some particular audience and (2) performance of the network was not great. I personally believe that their bet on DHT was not the right one (I worked in this area long before IPFS btw). OK, in retrospect we are all wise.

Re: IPFS Maintainers Winding Down

#19
post #5

This is really unfortunate. When cloudflare dropped IPFS you could say this next step was sort of already on the way. I may be biased but I think when IPFS decided to put so much time into "IPNS" in order to support non-static webapps years ago what they came up with did not fit the need. And without webapps on IPFS things were going nowhere. A year or so ago I wrote IPFS-boot which allows serving webapps on IPFS whi…

I agree that IPNS has always seemed a bit naff; but alternatives naming systems can be used too (if your system's name resolver can understand them); e.g. this uses pkarr addresses for IPFS content: http://www.chriswarbo.net/blog/2026-05-08-pkdnslink.html

Regarding an "update path", GNS has support for that built-in; though I've not been able to try it myself, since I can't get GNUNet to bootstrap :-(

Post reply on HN