-
Notifications
You must be signed in to change notification settings - Fork 97
Notes from discussion with Jeromy - path towards the IPFS npm's companion #38
Comments
okay, so the way i'm seeing it is this:
|
I'm onto this one :)
If we add a feature to extra feature: if we enable for custom privkey as well, we can announce it in a local area network and mount LAN folders. |
This belongs in ipfs/notes I think — On Mon, Oct 12, 2015 at 6:56 AM, David Dias [email protected]
|
FINE :D -> ipfs/notes#65 |
requirements/goals
We can use
registry-static
andipfs-blob-store
withmfs
to fetch the modules from the official registry, cache and install them from a mfs namespace, however since amfs
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
Instead of using the node key pair for the
mfs
namespace, generate on-demand key pairs to generate severalmfs
universes (this would imply sharing a key pair across nodes)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)(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
The text was updated successfully, but these errors were encountered: