Archive repository

[NatoBoram]

I has become clear that ipfs-npm is unmaintained since the last commit is from June 2019, the latest release is still impossible to install and attempting to install it throws exactly 49 deprecation warnings. I suggest archiving the repository to not give false hope to anyone trying to use it.

[mithray]

:-(

That's a pity this project is a really nice idea.

[mithray]

I wonder if I should just try updating the dependencies and see what happens. curiosity intensifies

[NatoBoram]

Just do it ✔️

[autonome]

@achingbrain is lead maintainer, so is the one who can speak to whether or not to archive, as I believe it's more experiment than product.

But yes, definitely helping update deps and fixing is much appreciated either way :)

[achingbrain]

This repo lives in ipfs-shipyard which is a place for experiments and demos, and projects here sometimes don't see as much attention as they perhaps deserve.

That said, this is still a pretty interesting idea but it's tough to find time to work on all the interesting ideas so some help would be appreciated.

I wonder if I should just try updating the dependencies and see what happens.

Please do and submit a PR with the updates!

[mithray]

I thought IPFS had a stated goal to focus on increasing the usefulness of IPFS for things such as code repos/cdns?

[resynth1943]

No, I honestly don't believe archiving this project will solve anything. In fact, it may harm the project (we really need this project 😛). I would be open to helping, but I'm definitely going to need to learn more about IPFS before I jump in...

[mithray]

No, I honestly don't believe archiving this project will solve anything. In fact, it may harm the project (we really need this project stuck_out_tongue). I would be open to helping, but I'm definitely going to need to learn more about IPFS before I jump in...

Would be amazing if you did this :+1:

[resynth1943]

Apologies, I've been super busy with my blog and college 😅

So, after a quick thonk, would it be better to create a stub registry that interfaces with IPFS, instead of maintaining a wrapper for the CLI?

[NatoBoram]

@resynth1943 What would be best is to make a mirror of the registry, pin and sync it using IPNS and use it with a localhost:8080/ipns address. This way, you wouldn't need to create a new package, all you'd need to do is change your local registry address for the IPNS hash and it would automatically work with your local node.

That's something I wanted to do with Ubuntu packages (offline proof of concept here), but it's quite expensive in terms of storage. The NPM registry is about 8 TB or something and you'd need at least double that to store it on IPFS and then you need room to support its continuous expansion. Just to be safe, one would need to start with 32 TB of SSDs to store it on IPFS. About 4 of these, totalling 3'863.96$ 3'705$ 2'719.88$.

I would totally do it if I could afford that for my side projects :D

[bertrandfalguiere]

@NatoBoram what about seeking funds from the IPFS grant program, then ? 😇

[mithray]

I would honestly love to maintain this project if I received a grant for it. Otherwise, I cannot afford the time. I LOVE the idea of this project.

[mithray]

I thought IPFS had a stated goal to focus on increasing the usefulness of IPFS for things such as code repos/cdns?

This was, one year a stated a goal of IPFS. I know they have been working with Nixos integration, which is very very cool. But I would love to see NPM decentralized.

[mithray]

@resynth1943 What would be best is to make a mirror of the registry, pin and sync it using IPNS and use it with a localhost:8080/ipns address. This way, you wouldn't need to create a new package, all you'd need to do is change your local registry address for the IPNS hash and it would automatically work with your local node.

That's something I wanted to do with Ubuntu packages (offline proof of concept here), but it's quite expensive in terms of storage. The NPM registry is about 8 TB or something and you'd need at least double that to store it on IPFS and then you need room to support its continuous expansion. Just to be safe, one would need to start with 32 TB of SSDs to store it on IPFS. About 4 of these, totalling 3'863.96$.

I would totally do it if I could afford that for my side projects :D

I don't think that storage space on one physical system is the right approach, it also very much does not take advantage of the power of the IPFS ecosystem and its distributed nature. Ideally, we should have very powerful sponsored nodes, just for speeds sake. But the basic operation of the system should not depend on this kind of centralized node. I think the algorithm should be more like this:

1. A developer needs an NPM package, they query the metadata of that from NPM, or a third party(maybe ipfs hosted) source. This is only for metadata. For the hash
2. The developer takes this hash, and queries ipfs for this content
3. a. If the content exists on IPFS, it is downloaded from IPFS b. If the content does not exist on IPFS, it is downloaded from NPM.
4. After the content is downloaded, it is by default served on IPFS so that other users can now download this package from you.

This way, packages can be managed incrementally. There isn't a requirement for the entire repo on one machine. Possibly it would help to widely mirror all of NPMS metadata on the IPFS network. Maybe even to each machine. I wonder how heavy that metadata is? It would be great to have all of NPMs metadata on IPFS network, pinned by every machine and also frequently updated. If the metadata was too heavy, pinning it would be disabled by default, and only more powerful nodes, such as IPFS would install it. Having the metadata locally I think would speed up the process of finding the packages to download.