> 2. The need to codify an incentives market which then lead to the creation of filecoin took a lot of effort and setting up a trustworthy org around that one and ipfs got even more challenging

I see this as a non-goal: HTTP is doing fine without an "incentives market", and that's the sort of core layer IPFS is suited for. When I switch off my HTTP servers, there's no expectation that the resources they're hosting remain accessible; and the same is true for IPFS. The advantage of IPFS is that it allows resources to remain accessible, e.g. if someone else cares enough to host it too, or if I happen to have copies buried on some old boxen (without having to coordinate some load-balanced shenanigans up-front).

For example, we can avoid "leftpad" fiascos if software companies could host their own dependencies (as in, contribute to ensuring their canonical URLs resolve; rather than current practice of re-hosting copies at myriad private URLs, or routing their network through caching proxies).

Good luck to other projects which want to work on such a thing (Filecoin, etc.), but it's mostly orthogonal to IPFS itself.

I bet IPFS could have gotten by with mirroring system. Sites publishes list of files that they want mirrored, and supporters could copy and host the files. I think IPFS could be more useful for software, and mirroring or caches would work well.

Also, IPFS was supposed to have clients host the file like Bittorrent does. My impression is that most users don't host, they just download. It is quite possible that adding money to system reduces people's desire to contribute. I also got the impression that flaws in client make it harder to host.

> The advantage of IPFS is that it allows resources to remain accessible, e.g. if someone else cares enough to ho...

I think there is a key point here. This exactly is the reason why incentives markets built around IPFS are so relevant. They democratize the act of saying "I care about that data". Nowadays you need to be a poweruser to express this but with the world's content being more and more digital media this isn't the realm of the poweruser any more.

> I think there is a key point here. This exactly is the reason why incentives markets built around IPFS are so relevant.

I fundamentally disagree. If someone wants to make filesharing easier, go ahead (personally I think dragging files into a "Shared" folder, like eDonkey/Kazaa/Limewire/etc. would be easier for non-"powerusers" than minting and securing a crypto wallet and trying to convince others of its value in exchange for storage space, but whatever).

To me, such projects seem about as relevant for IPFS as, say, Geocities is for HTTP.

I'm having difficulty following this train of thought. How is any of this related to consumer level users wanting to keep IPFS data alive?

> How is any of this related to consumer level users wanting to keep IPFS data alive?

I'm saying that "consumer level users wanting to keep... data alive" is unrelated to IPFS.

If someone wants to work in that space, they can do so in separate projects (there are already many). Such projects could make use of IPFS; but they could also use HTTP, Bittorrent, GNUNet, Dat/Hyperdrive, Freenet, ED2K, FTP, or whatever seems appropriate (ideally, all of the above and more).

Presumably such projects could encode their text using UTF-8, to 'democratise saying things outside of the Anglosphere'; but that shouldn't de-rail the Unicode consortium into a multi-year crypto pivot.

That's all fine but the fact of the matter is that a lot of web3 content is built on IPFS and not on all those other technologies (partially because IPFS is truly permissionless), so the "just use another tech" argument is quite moot/academic

> the "just use another tech" argument is quite moot/academic

What "argument"? I said that filesharing/storage-incentivising projects can build on whatever they like; and that they have been doing, for decades.

My "argument" is that the IPFS project/protocol is not such a project. It is a network protocol (or suite thereof; for peer discovery, data transfer, hash representations, etc.).

> the fact of the matter is that a lot of web3 content is built on IPFS and not on all those other technologies

So what? Hopefully those projects chose to use IPFS due to its technical features, its stated goals, etc. How's that working out for them?

Note that, in particular, those technical features and stated goals do not include getting other people to host your shit. If some "web3" projects have decided to build their crypto bullshit on top of such a fundamental misunderstanding, then that's hilarious! More realistically, I'm guessing they know full-well that's not how any of this works; and are just keeping the illusion going until their inevitable rug-pull.

Either way, that's not IPFS's problem (which, again, is a (suite of) network protocols).

Incentive markets aren’t “democratization”. Something like BitTorrent where people freely choose to contribute simply to help others is democratic.

An incentive market basically makes it a business.

What's not democratic in having the power to use and operate businesses?

I think this is the ideal way. Instead of limiting "democracy" to the power users you also include consumers this way.

Can you say a bit about using it for your business? Curious how people are using IPFS in the real world.

Apart from the obvious web3 stuff there are some interesting usecases for classical enterprise software.

Caveat, my experience is limited to clusters below 100 nodes.

You can run your private IPFS DHT if you want and the protocol has some cool load shedding features. There is also IPFS cluster which adds data availability features to your IPFS deployments. When we tried private IPFS networks the cluster project was relatively early and we found that managing DA in the application that owns the data ended up being more straight forward so we didn't use that but I've heard good things lately.

If you don't need to enforce access management across your internal data calls it can be an interesting alternative to stuff like minio or ceph. YMMV but my experience was that, running a private IPFS cluster can be easier and much more flexible than running a similarly scaled minio or ceph deployment. It can be seen as a shift left like DevOps is. Instead of having each internal app on your project depend on a Data team that manages Ceph or another data storage and access technology you run (most of) it yourself.

I’m actually using it for sharing enterprise components so that a document saved in one company can be sent to another company and the document loads content from IPFS. All this without needing a central server