I agree. Personally I've had similar thoughts but instead of viewing it as a signal of their lack of talent, I viewed it.. sadly, as a signal for their lack of attention to IPFS.

From a largely outsiders perspective, it has felt like FileCoin was the thing they wanted to do. Either that, or they just don't have enough bandwidth to take on all of these projects.

Regardless, it doesn't feel to me as if IPFS has had the attention it deserves from ProtocolLabs. I love the idea of FileCoin, but I'd at least like ProtocolLabs to get one thing finished before they chase the next shiny project. Hard to imagine the "next internet" being created with such floaty attention spans.

Hey there! I’m one of the first developers to work on IPFS, and was the maintainer of the project for around three years. I’ve since been pulled into working on Filecoin, which has definitely taken away from the time I can spend pushing IPFS forward. That said, the IPFS Project has a really solid team and OSS community still pushing the project forward, and there is an entire team working on just libp2p (the network stack used by IPFS and other projects like Livepeer, Ethereum 2.0, OpenBazaar, and more). There’s been a ton of progress made recently, and the network has grown significantly. We’ve gone from nearly 30k peers last year (this is hard to estimate accurately, but best guess) to around 400k peers on the network today — roughly 13x growth. This massive influx in usage has taken a lot of our attention up, things catching fire that we didn’t expect to catch fire, and other bugs popping up that need to be fixed now. All this detracts our attention from things like docs and website publishing, but we recognize it’s a really important area we need to make time for and step things up. For example, there’s an overhaul of ipfs-cluster docs: https://github.com/ipfs/ipfs-cluster-website/issues/89#issue... We also put a lot of effort into our new docs website: https://docs.ipfs.io/ And we’ve been pushing a lot of specs for everything we build: https://github.com/libp2p/specs https://github.com/ipfs/specs https://github.com/filecoin-project/specs https://github.com/ipld/specs

I feel that is vice versa, the goal has always been IPFS. However I thought it would be quickly apparent that with no incentive structure to do the actual hosting to a significant scale, it is a dead in the water project. The idea is great however it comes with multiple pain-points that exist at the same time, and honestly jumping in the ICO craze at the point that they did was a smart business decision because imo something like Filecoin is absolutely necessary.

I mean for success you need to achieve ample storage capacity, strong financial incentives that strengthen the network, and scaling. Major issues here being that following the ICO they need to release something that matches what investors wanted to some degree (more focus on Filecoin) and that a lot of scaling/tooling needs to come from outside Protocol Labs. They are heavily relying on Ethereum to successfully scale in a way that is friendly to the Filecoin protocol and that is an issue that has been dragging out for at least the last two years on how to do it properly.

This is exactly the impression I've formed as well. I'm sure they have super smart people (and I've talked to many of them), it just doesn't seem they're interested enough in improving IPFS.

The "canary in the coal mine" for me is that pinning API ticket, which has been open for years and amounts to "please put an async UI over pinning". If something that simple and useful doesn't get fixed quickly, I'm not optimistic about the future of the project.

It's too bad, because I think it's an extremely useful idea.

Doing this right is not simple. It requires an entire task management system internally, which (as you know) i've sketched up here: https://github.com/ipfs/go-ipfs/issues/3114

Sure, we could hack this together quickly, but we're trying hard to avoid adding technical debt at this point. Adding every feature requested would put us in a bad spot.

Prioritizing this over the countless other things people continually ask for is hard, but we hear you. We welcome pull requests, and since you needed this for the service you were building, helping us out here would be fantastic.

I hear you, it's just that the current way the daemon does pinning is unacceptable. For example, I can't tell my customers how much of their file I've pinned, or, in some cases, if I've pinned it at all.

Maybe I'm in a small minority of people who are interested in this feature, but how do people pin things without it? Do they just `screen ipfs pin <hash>` and leave that terminal there for ever? Wouldn't it be in the project's best interest to make pinning work well?

Unfortunately, I don't know Go at all, or I would at least take a stab at this...

So, at a high level you want more than just the backgrounding the pin task, you also need to be able to tell what the progress is, periodically. This probably means we need to do something with the api endpoint output (i was initially thinking 'just throw it away and mark completion').

> 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.

> you also need to be able to tell what the progress is

That would be nice, but not really required.

> I assume your service is a server side app that is making requests to the ipfs node, right?

Yes, exactly.

> You could set some background task in that application that just waits on the `ipfs pin add --progress` call

I did that, there were problems with the fact that you can't have too many pinning calls waiting due to resource constraints. I can't just have 100k requests open and waiting, they time out, I need to restart the server, things happen. At that point, every single task needs to fire up again and make an API call to the server.

I did the same thing with batching, but then long-running pins (files not in the network) would block and new files that were on the network wouldn't work. This happens with IPFS Cluster too, I just don't have to write my own code to worry about it.

Believe me, I've spent lots of time on working around this, and the workaround can only be so good with the current system.

The problem is they have both: lack of interest towards IPFS and $300 million weight to keep control over IPFS development. So doing all the necessary work to give up control and encourage quality independent implementations is out of the question.