IPFS, Again

P2P systems historically have dealt with the problem altruistically, or with limited tit-for-tat, which both work in many cases, but have so far failed to work for large scale long-term resilient systems.

This is where Bitcoin managed to do something remarkable: achieve high uptimes typical of the best centralized systems, through a very clever, but still open and permissionless, economic incentive structure. Markets have been shown to be extremely useful to create a robust Open Services. More on these ideas here: https://www.youtube.com/watch?v=IfLIoOr4p0A -- we think this kind of thing is going to lead to extensive, global, public utilities run w/ internet-native money.

But it will take a while-- this stuff is extremely difficult to build right now-- it feels similar in nature to very early Web, or pre-unix systems. Lots of hand-rolled primitives, many with the capacity to cause serious failure (not very old cryptography, and complex security questions). Perhaps better programming languages will help us build these systems dramatically faster/easier. For now though, you can see the entire blockchain space wrestling with these problems.

You can check out our roadmap

> IPFS is unworkable... making it usable in the next few years

Absolutely not.

The OP brings up a lot of great, useful feedback for us, and we'll respond to it.

But the OP is also simply wrong in saying it's "not usable". There are millions of end users benefiting from IPFS, 100Ks of libp2p nodes, we see PBs/mo of traffic in the infrastructure that we run, and millions of daily requests to our gateway. Look to fully decentralized applications and systems like OpenBazaar, Textile, Dtube, and others.

Beyond that, we're well aware of the many shortcomings, and working on them. We're unfortunately spread thin across a lot of projects (IPFS, libp2p, filecoin, ipfs-cluster, etc), but each is seeing significant growth and improvement.

You can see the long-term IPFS roadmap here https://github.com/ipfs/roadmap

Rather than wade into the self-taught vs pedigree debate, I want to point out that based on my experience working on the project, I think technical challenges are actually not the biggest challenges.

Much of the challenge has to do with process -- managing a huge issue tracker, tracking a giant project that lives in multiple repos with many interlocking components, benchmarking a system that is quite hard to benchmark, developing an effective release process, developing systematized ways to collect community feedback, etc.

IPFS needs solid product focus and team direction. From what I’ve seen, the folks at Protocol get this. That’s why they have started focusing on achievable priorities like hosting package managers. The technical problems are complicated but not insurmountable-- not beyond the scope of what many talented senior programmers can solve. I think IPFS would be improved by strong team leadership and process, not more whiz kids, and I see Protocol taking steps to insure this happens.

> in some cases, if I've pinned it at all.

What cases would those be? If the file is pinned it should always show up in an `ipfs pin ls $CID`.

In the short term, I assume your service is a server side app that is making requests to the ipfs node, right? You could set some background task in that application that just waits on the `ipfs pin add --progress` call and keeps track of the progress for that pin, that way, when a customer queries it, and its in progress, you can return that information. Agree this should be built into ipfs at this point, but that seems like a reasonable workaround for now.