3 ms·
jbenet here. We're all very excited about the dev interest in gx and ipfs! thanks! we did not expect attention on it this soon! Please check it out, try it, and
by _prometheus 11y ago
jbenet here. We're all very excited about the dev interest in gx and ipfs! thanks! we did not expect attention on it this soon! Please check it out, try it, and give us feedback!
Please know though that things are still super early, and very rough! We do not think our pkg mgment efforts are UX ready for end users who want something strictly better today. But they are ready for early adopters who want to think or hack on them with us. In fact, we are now self-hosting go-ipfs in gx! https://github.com/ipfs/go-ipfs https://github.com/ipfs/go-ipfs
Something to bear in mind: we are building infrastructure you can rely on long term, with decentralization, flexibility, and futureproofing from the ground up. We want our protocols and tools to survive independent of fragile organizations or fragile routing. We can't take many shortcuts (like depending on centralizing agents), because we want something rock solid to last for decades. This means it takes us a lot longer to build high perf and high quality UX, because there's a lot more to do. More work, but it is all achievable. The rough edges will disappear as we improve the tooling. Even today, gx is amazingly simple and powerful, and already does much for dependability.
It's worth mentioning other package management tooling we're working on too:
* NPM + IPFS - https://github.com/diasdavid/registry-mirror https://github.com/diasdavid/registry-mirror and other repos. This is an effort to improve how NPM works with IPFS
* pacman + ipfs - https://github.com/ipfs/notes/issues/84 https://github.com/ipfs/notes/issues/84 - this is a super rough way to show how to add ipfs support to a package manager through FUSE. it's not the best way, but it works!
* also, we <3 nix, and cool stuff coming in the future there :)
We have LOTS in development and store for the package manager communities. It's a very exciting time. Please join us at https://github.com/ipfs/ipfs https://github.com/ipfs/ipfs and #ipfs and #gx on freenode IRC. And, if anyone wants to work on "Hypermodular Programming" with us, see https://github.com/jbenet/random-ideas/issues/27 https://github.com/jbenet/random-ideas/issues/27 and ping me :)
- tlrobinson 11y agoGreat work on this stuff. Question about package managers built on ipfs, and ipfs in general: how do you ensure the packages/files you depend on will always be available? Is the idea that there would be at least one entity pledging to host every package for eternity, or if you depend on obscure packages would it be wise to run your own mirror of the packages you use? Or something else?
- _prometheus 11y agoThanks! Many answers: - storing is super cheap. seeding not v expensive. i think the entire npm reg is <1TB? - (soon can ship entire registries in USB keys!) - many individuals and orgs should keep/replicate what they depend on - tools like ipfs-cluster will help organize nodes like a RAID array - can pay services to back things up (on service infra in vogue) - can pay _the network_ to back things up -- see http://filecoin.io http://filecoin.io
- kefka 11y agoWhen I want files available on IPFS, I just pin them to the appropriate machines. Ipfs pin add [key] And my material now has another seed machine. It works, and is clean and efficient. One thing: I share everything in a directory, so the root directory name gets clobbered with the multi hash, and all the files in it retain their pretty names.