In theory, there are incremental paths to achieve that objective, while serving clients all the way along.

1. Define a P2P ready data model and protocol (which they have, Merkle forest and everything)

2. Run a single server/cluster, make a very lightweight client library for that

3. Expand the server to a makeshift CDN (start simple, e.g. rsync like mirrors)

4. Federate the CDN (still in a hierarchical fashion, so you always know whom you are talking to). Also, look for peers on the local subnet (broadcast is simple).

5. Expand that to a friend-of-a-friend network, use PEX like peer finding (PEX is shockingly simple https://en.m.wikipedia.org/wiki/Peer_exchange)

6. Go full P2P, talk to strangers on the Net, use DHT or anything.

The only trick is to start with a data model that can go all the way to (6). So backward compatibility/ installed base issues do not stop you at earlier stages. Think globally, act locally.

The dangerous thing is deploying an untested complex codebase to serve the most hardcore use case for live customers on Day#1. That may not work. Because even all these shockingly simple steps will turn quite long and tedious in practice. There will be "issues". Advancing one step a year is quite impressive if done under the full load.

The IPFS client is such an untunable memory hog that I turn it off whenever I'm not using it (which, of course, defeats the entire purpose). I would be ecstatic if we had something like the old uTorrent, but for IPFS. A nice UI, easy configuration, an ultralight implementation. It would be a dream come true.

Exactly this: such an ultralight, accessible implementation would make it better suitable to run on embedded devices and mobile phones. And since we still live in as fairly disconnected world this is probably an area where IPFS can accelerate.

I kind of made this https://github.com/hsanjuan/ipfs-lite

May not be ultralight (running a DHT node isn't, but it does remove a lot of crust).

We live in the world of NATs that effectively prevents any p2p networks.

What about Transmission? It seems much less bloated in comparison to uTorrent.

I mean an IPFS client, not a torrent client. There are hundreds of those.

When you say nice UI, do you mean a GUI?

Yes, to make it more accessible.

I would love to see IPFS used in projects like Nix, but in the current state it's downright impossibile.

I have seen IPNS taking between 5-10 minutes to solve a single address and go-ipfs with a few pinned files taking more that 5GB of memory after running for a day.

> go-ipfs with a few pinned files taking more than 5GB

Yeah, I don't understand the hype around IPFS when it performs so badly. After reporting the issue and having a conversation with the devs I had an impression that they are just dilettantes.

Experiencing this performance issue with ipns was a major turn off.

It's a bit sad, that Dhall (programmable configuration language for YAML & co.) used to use IPFS for its source/packages, but stopped, because of reliability :( (I'm wondering if there are/were others?)

> Early on in the language history we used IPFS to distribute the Dhall Prelude, but due to reliability issues we’ve switched to using GitHub for hosting Dhall code.

http://www.haskellforall.com/2019/01/dhall-year-in-review-20...

https://github.com/dhall-lang/dhall-lang/issues/162

I wish IPFS the best, because at least in theory this seems like a perfect use case

We conducted initial experiments with moving nix package manager to ipfs, but also ran into too many issues.

Are these issues documented somewhere, would love to learn more. At first glance nix and ipfs seem like a perfect match

Sure thing. I think most of the discussions have been cross-referen ed in this issue: https://github.com/NixOS/nix/issues/859

also, Fury, the new Scala build tool by Jon Pretty, uses IPFS to distribute builds/build definitions

https://fury.build/

https://github.com/propensive/fury

https://youtu.be/Xti2I2Csww8?t=1620

it seems like people working on package management/distribution related things LOVE the idea of IPFS