IPFS Maintainers Winding Down

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 supporting the projects it got its VC/crypto funding from.

Re: IPFS Maintainers Winding Down

#5

Post by rhodey » Mon, Aug 24, 2026, 4:17 PM UTC

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 while providing also an update path and without breaking content hashing:

https://github.com/rhodey/IPFS-boot

But now if you want to serve a secure webapp and not use IPFS IMO the only option you have is to tell users to install Tailscale and to host the webapp themselves and then to install Tailscale on all devices.

Re: IPFS Maintainers Winding Down

#6

Post by toomuchtodo » Mon, Aug 24, 2026, 4:23 PM UTC

rhodey wrote: 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 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 target for abuse and copyright claims as well.

If you want to reference resources securely, https://developer.mozilla.org/en-US/docs/Web/Security/Defens... is available and widely supported.

Re: IPFS Maintainers Winding Down

#7

Post by rhodey » Mon, Aug 24, 2026, 4:27 PM UTC

toomuchtodo wrote: post #6

rhodey wrote: 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 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.

Re: IPFS Maintainers Winding Down

#8

Post by timcobb » Mon, Aug 24, 2026, 4:28 PM UTC

Macha wrote: post #2

All those NFT holders where the NFT resolved to a ipfs.io link in shambles

Hahaha thanks for this. It's ok, the asset is the block chain entry duh

Re: IPFS Maintainers Winding Down

#9

Post by toomuchtodo » Mon, Aug 24, 2026, 4:29 PM UTC

rhodey wrote: post #7

toomuchtodo wrote: post #6

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.

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.

Re: IPFS Maintainers Winding Down

#10

Post by rhodey » Mon, Aug 24, 2026, 4:29 PM UTC

toomuchtodo wrote: post #6

rhodey wrote: 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 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…

Oh and sorry I missed your comment on "Subresource Integrity".

The deal here is Subresource Integrity will only help you if the index.html is considered trusted/authoritative. So you still need a way to get index.html to users and users need a way to say "is this the true index.html"