The shit hit the fan once filecoin became intertwined with IPFS. So DOA long time ago.
IPFS Maintainers Winding Down
131–140 of 226 posts
Re: IPFS Maintainers Winding Down
#132Sad 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…
Iroh is great! As is ATProto! Both build on DASL ( https://dasl.ing/bdasl.html ) - which specifies the core content addressing layer of IPFS. However - important clarification about the Shipyard post that I think a lot of folks are confused by: While its sad to see the Shipyard team sunset, the IPFS project is decentralized & robust to a single party moving on. IPFS the project/network is not sunsetting or shutting d…
You are describing Protocol Labs' plans in the first person, as "current focus". If you work there, please say so in the comment. On a thread about Protocol Labs ending the maintainers' funding, that context matters to anyone weighing the reassurance.
DASL specifies CIDs, CAR and deterministic CBOR. It deliberately does not specify UnixFS, and it has no way to chunk a file into blocks. UnixFS is what ipfs add has produced since 2015, and what Kubo, Boxo, Helia and the gateways address today. So DASL is the naming layer, not "the core content addressing layer of IPFS". Writing a new format is easy. The stability people built on came from not rewriting this one, and from someone shipping it in the software they already run.
I run Kubo and Helia in production. "Robust to a single party moving on" would be easier to accept with answers to these:
- Who triages vulnerability reports and ships fixes for Kubo, Boxo and Helia after September? Does the contact in https://github.com/ipfs/community/blob/master/SECURITY.md still reach a person? - Will anyone cut releases, or should operators pin current versions and plan around that? Should we expect a community fork? - Who operates ipfs.io, dweb.link and delegated-ipfs.dev day to day after September, and with what experience running public infrastructure at that scale? - What happens to the Service Worker Gateway at https://inbrowser.link ? - What happens to Badbits at https://badbits.dwebops.pub ? Does it stop being updated when Shipyard turns the lights off?
A grant to an individual maintainer is not the same as a named owner with commit rights and a release process.
On the Service Worker Gateway as decentralized public infrastructure: the subdomain gateway spec requires a wildcard TLS certificate for the ipfs and ipns subdomains, plus a Public Suffix List entry so each CID gets its own origin. You also need a denylist, or you end up serving phishing. Very few people reading this thread can self-host that, and the ones who try will meet the abuse problem next.
The same questions are open on discuss.ipfs.tech. A direct answer there would help more than reassurance here.
Re: IPFS Maintainers Winding Down
#133Wasn't the problem with IPFS always that it allowed random strangers to put data on your machine, which could make you an accessory in crime?
IPFS doesn't fetch or store content that the user has not explicitly requested. If your application allows strangers to request arbitrary IPFS objects, this might be a concern. Otherwise, no, simply running a node doesn't expose you to this risk.
Re: IPFS Maintainers Winding Down
#134Earlier quoted context omitted.
I could (sort of) see why you might get this upset if people were required to have a Google account themselves to submit this Google form, but that's not the case. Who are you to tell an underfunded opensource dev company that just lost their biggest project what tools they should use? That email you hypothetically sent will probably get delivered to an account in their Google Workspace, how on earth is that any diff…
I've run into a lot of Google forms for projects that do in fact require me to log in with a Google account in order to submit, which I think might be related to Google detecting that I'm using a VPN and treating the submission as higher-risk. I just have this reflexive assumption that if something is presenting me with a Google form, it's not gonna work unless I log into a Google account on my local machine. Which i…
It's not their job to cater to your nitpicking. Even if this Google form didn't work over a VPN (which it totally does), you're capable of turning the VPN off if you really want to submit feedback. But it doesn't even sound like you have any feedback, so what's your problem?
Re: IPFS Maintainers Winding Down
#135Wasn't the problem with IPFS always that it allowed random strangers to put data on your machine, which could make you an accessory in crime?
You can choose what you pin when you run a node, no one can force you to host stuff you don't want to host.
Re: IPFS Maintainers Winding Down
#136This 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…
My go to example: IPFS is Plan9 to bittorrent's UNIX. Some achingly beautiful design, willingness to completely disregard existing messy conventions(for example: The ipfs unified url format) and, like you said, still not enough better for people to want to change.
Re: IPFS Maintainers Winding Down
#137Earlier quoted context omitted.
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 :-(
I always thought that they should have used ENS instead of whatever coin they ended up making. GNS is cool but IIRC (years ago) it had no incentive mechanism which is I think where a lot of these solutions fall down. Even imaginary "ratio points" that p2p file sharing sites have being using for years work better than "donate your resources out of the goodness of your heart".
Half baked comment but I feel like many of these efforts are too purist. Sure they need to think more carefully about incentives from a systemic angle but also why not accept a hybrid design that doesn't depend on those in the first place? For example plenty of people operate their own nameservers for their own websites to use, or spin up a VPS to support [thing] they make use of. So at a minimum I'm sure webring-style infra where you cover for your friends and they cover for you would work quite well.
For a real world example of a hybrid approach that works see bittorrent where torrents can optionally contain urls that point to alternate download sources in order to speed up the initial seeding phase.
Re: IPFS Maintainers Winding Down
#138Earlier quoted context omitted.
there are a lot of completely free file sharing services for authentic activity (e.g. github, google drive) inauthentic activity seems to move from one product space to another. in 3 years we'll be hearing about stripe shutting down openrouter for example.
please define "authentic activity" and "inauthentic activity"
Legitimate. Legal.
IPFS, Freenet, and experiments like that mainly serve as a place for people to store and distribute pirated copyrighted material, child porn, hit lists, terrorism manifestos and plans, and the like.
Scratch a libertarian and, nine times out of ten, you'll find someone who advocates for no or minimal government because they want to do something the government legitimately bars them from doing. Scratch a libertarian decentralized P2P E2EE communication project and you'll find... well, this kind of material nearly every time.
Re: IPFS Maintainers Winding Down
#139Wasn't the problem with IPFS always that it allowed random strangers to put data on your machine, which could make you an accessory in crime?
IPFS doesn't fetch or store content that the user has not explicitly requested. If your application allows strangers to request arbitrary IPFS objects, this might be a concern. Otherwise, no, simply running a node doesn't expose you to this risk.
Ok, then I misremembered, thanks.
(Couldn't it be that the caching behavior of intermediate nodes still make it a possibility?)
Re: IPFS Maintainers Winding Down
#140The post here is pretty confusing (so no blame to anyone who reads this as "IPFS the project" shutting down instead of just a single maintainer team, it's totally misleading) - but this is actually just a sunset announcement for _Shipyard_ - one of many IPFS implementation maintainers. *The IPFS Project is not sunsetting or shutting down* - just switching to individual maintainer grants instead of centralized impleme…
one of many, or the main maintainers? seems like they run a lot of the well known public infra too.