Notes from discussion with Jeromy - path towards the IPFS npm's companion

[daviddias]

The IPFS npm companion is a way to cache, discover and install Node.js modules using IPFS

requirements/goals

• cache modules
• discover peers that have the module that we are looking for
• fetch and install the module

We can use registry-static and ipfs-blob-store with mfs to fetch the modules from the official registry, cache and install them from a mfs namespace, however since a mfs namespace is generated from the IPFS node key pair, other nodes won't be able to access it and therefore, install modules from other peers.

options

1. Instead of using the node key pair for the mfs namespace, generate on-demand key pairs to generate several mfs universes (this would imply sharing a key pair across nodes)

2. Built on top of node 1), but instead of sharing key pairs, the node that creates a mfs namespace would sign other key pairs in order to give a capability for other nodes to update those ipns records (by being able to sign records that can be also validated by the trust chain)

3. (simpler) have a main node to do the caching and deploy its pubkey with ipfs-blob-store, so that ipfs-blob-store instances could have access to that namespace. This would require to be able to understand how to 'mount' several mfs namespaces

//cc @whyrusleeping

[whyrusleeping]

okay, so the way i'm seeing it is this:

1. Implement abstract blob store using 'ipfs files' as the backend. This is doable today and should be fairly trivial. Worth noting: we should select a special path under the files root to write the blobstore to.
2. set up a registry-static backed by the ipfs blobstore. Difficult part here will be making it update the 'root' hash occasionally, based on ipns. Maybe do this only when prompted? eg. 'npmi update registry' or something.
3. integrate the registry-static from step 2 into npm in a nice user friendly way
4. set up a 'master node' to cache npm into its ipfs registry, and then make the clients periodically grab the newest hash (update command from step 2 maybe?)

[daviddias]

1. Implement abstract blob store using 'ipfs files' as the backend. This is doable today and should be fairly trivial. Worth noting: we should select a special path under the files root to write the blobstore to.

I'm onto this one :)

set up a registry-static backed by the ipfs blobstore. Difficult part here will be making it update the 'root' hash occasionally, based on ipns. Maybe do this only when prompted? eg. 'npmi update registry' or something.

integrate the registry-static from step 2 into npm in a nice user friendly way

set up a 'master node' to cache npm into its ipfs registry, and then make the clients periodically grab the newest hash (update command from step 2 maybe?)

If we add a feature to ipfs files to use a custom pubkey for namespace access (only for read operations, but would get the job done)

extra feature: if we enable for custom privkey as well, we can announce it in a local area network and mount LAN folders.

[jbenet]

This belongs in ipfs/notes I think

—
Sent from Mailbox

On Mon, Oct 12, 2015 at 6:56 AM, David Dias [email protected]
wrote:

The IPFS npm companion is a way to cache, discover and install Node.js modules using IPFS

requirements/goals

• cache modules
• discover peers that have the module that we are looking for
• fetch and install the module
  We can use registry-static and ipfs-blob-store with mfs to fetch the modules from the official registry, cache and install them from a mfs namespace, however since a mfs namespace is generated from the IPFS node key pair, other nodes won't be able to access it and therefore, install modules from other peers.

  options

  1. Instead of using the node key pair for the mfs namespace, generate on-demand key pairs to generate several mfs universes (this would imply sharing a key pair across nodes)
  2. Built on top of node 1), but instead of sharing key pairs, the node that creates a mfs namespace would sign other key pairs in order to give a capability for other nodes to update those ipns records (by being able to sign records that can be also validated by the trust chain)
  3. (simpler) have a main node to do the caching and deploy its pubkey with ipfs-blob-store, so that ipfs-blob-store instances could have access to that namespace
     //cc @whyrusleeping

  ---

  Reply to this email directly or view it on GitHub:
  Notes from discussion with Jeromy - path towards the IPFS npm's companion #38

[daviddias]

This belongs in ipfs/notes I think

FINE :D -> ipfs/notes#65