5 ms·

"2019 Goal: The most used code and binary Package Managers are powered by IPFS." That's kind of stupid-ambitious for 2019 when another 2019 goal is "a producti

by fwip 8y ago

"2019 Goal: The most used code and binary Package Managers are powered by IPFS." That's kind of stupid-ambitious for 2019 when another 2019 goal is "a production-ready implementation" and IPFS has been around for 3 years already. This isn't a roadmap, it's a wishlist. And I'm someone who wants to see IPFS succeed.

StavrosK 8y ago
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.
- deleted 8y ago
  [deleted]
- threeme3 8y ago
  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.
  - dsswh 8y ago
    We live in the world of NATs that effectively prevents any p2p networks.
  - hecturchi 8y ago
    I kind of made this https://github.com/hsanjuan/ipfs-lite https://github.com/hsanjuan/ipfs-lite May not be ultralight (running a DHT node isn't, but it does remove a lot of crust).
- bradleyhb 8y ago
  When you say nice UI, do you mean a GUI?
  - StavrosK 8y ago
    Yes, to make it more accessible.
- johnisgood 8y ago
  What about Transmission? It seems much less bloated in comparison to uTorrent.
  - StavrosK 8y ago
    I mean an IPFS client, not a torrent client. There are hundreds of those.
gritzko 8y ago
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 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.
sideeffffect 8y ago
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-2018-2019.html#switch-from-ipfs-to-github http://www.haskellforall.com/2019/01/dhall-year-in-review-20... https://github.com/dhall-lang/dhall-lang/issues/162 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
- arianvanp 8y ago
  We conducted initial experiments with moving nix package manager to ipfs, but also ran into too many issues.
  - xwvvvvwx 8y ago
    Are these issues documented somewhere, would love to learn more. At first glance nix and ipfs seem like a perfect match
    - arianvanp 8y ago
      Sure thing. I think most of the discussions have been cross-referen ed in this issue: https://github.com/NixOS/nix/issues/859 https://github.com/NixOS/nix/issues/859
rnhmjoj 8y ago
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.
- xur17 8y ago
  Experiencing this performance issue with ipns was a major turn off.
- zinid 8y ago
  > 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.
sideeffffect 8y ago
also, Fury, the new Scala build tool by Jon Pretty, uses IPFS to distribute builds/build definitions https://fury.build/ https://fury.build/ https://github.com/propensive/fury https://github.com/propensive/fury https://youtu.be/Xti2I2Csww8?t=1620 https://youtu.be/Xti2I2Csww8?t=1620 it seems like people working on package management/distribution related things LOVE the idea of IPFS

by fwip 8y ago

StavrosK 8y ago

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.

deleted 8y ago
[deleted]
threeme3 8y ago
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.
- dsswh 8y ago
  We live in the world of NATs that effectively prevents any p2p networks.
- hecturchi 8y ago
  I kind of made this https://github.com/hsanjuan/ipfs-lite https://github.com/hsanjuan/ipfs-lite May not be ultralight (running a DHT node isn't, but it does remove a lot of crust).
bradleyhb 8y ago
When you say nice UI, do you mean a GUI?
- StavrosK 8y ago
  Yes, to make it more accessible.
johnisgood 8y ago
What about Transmission? It seems much less bloated in comparison to uTorrent.
- StavrosK 8y ago
  I mean an IPFS client, not a torrent client. There are hundreds of those.

gritzko 8y ago

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

sideeffffect 8y ago

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-2018-2019.html#switch-from-ipfs-to-github http://www.haskellforall.com/2019/01/dhall-year-in-review-20... https://github.com/dhall-lang/dhall-lang/issues/162 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

arianvanp 8y ago
We conducted initial experiments with moving nix package manager to ipfs, but also ran into too many issues.
- xwvvvvwx 8y ago
  Are these issues documented somewhere, would love to learn more. At first glance nix and ipfs seem like a perfect match
  - arianvanp 8y ago
    Sure thing. I think most of the discussions have been cross-referen ed in this issue: https://github.com/NixOS/nix/issues/859 https://github.com/NixOS/nix/issues/859

rnhmjoj 8y ago

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.

xur17 8y ago
Experiencing this performance issue with ipns was a major turn off.
zinid 8y ago
> 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.

sideeffffect 8y ago

also, Fury, the new Scala build tool by Jon Pretty, uses IPFS to distribute builds/build definitions https://fury.build/ https://fury.build/ https://github.com/propensive/fury https://github.com/propensive/fury https://youtu.be/Xti2I2Csww8?t=1620 https://youtu.be/Xti2I2Csww8?t=1620 it seems like people working on package management/distribution related things LOVE the idea of IPFS