ipfs-cluster
ipfs-cluster copied to clipboard
Share IPNS keys and pin value from each node
Describe the feature you are proposing
It would be helpful if IPFS-Cluster could also share IPNS keys and their current pin value between nodes and implement the relevant parts of the IPFS API to generate new shared keys (ipfs key *) and change the value of existing one (ipfs name publish). Since receiving a copy of the private key (required to publish data on it) allows the given peer to publish arbitrary data on that name this facility should be restricted to trusted peers only.
Additional context
I host some websites (OK, only 2 at the moment) using IPFS and the IPFS-Cluster stack allows me to add some data locally and have it pop up on the server as well. However I still need to manually SSH into the server to copy the used IPNS keys there (first time only) and run ipfs name publish -k <key-name> <cid> after each content update to ensure that they key's data stays available. I think IPFS-Cluster would likely be the right place to handle updates to this piece of information as well.
Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:
- "Priority" labels will show how urgent this is for the team.
- "Status" labels will show if this is ready to be worked on, blocked, or in progress.
- "Need" labels will indicate if additional input or analysis is required.
Finally, remember to use https://discuss.ipfs.io if you just need general support.
I still need to manually SSH into the server to copy the used IPNS keys there (first time only) and run
ipfs name publish -k <key-name> <cid>after each content update
You could use the IPFS API (put it behind nginx if exposed?). But yeah cluster could provide something akin to ipfs-cluster-ctl ipfs gc. However, I am not sure that running name publish with the same key from several nodes at once has any value vs doing that from one node only. And you could that from a local ipfs node as well (no need to ssh to the remote node(s)).
I like that we are discussing to allow "trusted peers" to make changes to IPNS entries. (I hope I got this right)
What about allowing "trusted users" on another layer(blockchain?) to make changes to an IPNS like entry? Given that IPFS does not have a notion of a user at all, has there been any solid libraries built to do this job? Could this help @ntninja 's problem?
cluster could provide something akin to ipfs-cluster-ctl ipfs gc. However, I am not sure that running name publish with the same key from several nodes at once has any value vs doing that from one node only. And you could that from a local ipfs node as well (no need to ssh to the remote node(s)).
My experience with that has been that only publishing content from my local (not well-contected) node has caused issues, such as the remote node not picking it up, being slow to resolve the key or “forgetting” about the key's value. Publishing it on the remote node as well fixes all of these.
My theory is that the published record either simply expires (24h) or is not well-distributed from my node due to limited connectivity, causing key resolution on the server being slow.
With IPFS-Cluster already distributing metadata about IPFS pins, distributing metadata about IPNS keys as well seems like a natural extension to me.
@0zAND1z: I'm not sure what you're trying to say with that “trusted peer” vs “trusted user” distinction? Trusted peers in IPFS-Cluster are peers allowed to update the content of a cluster (vs other peers that only may observe such changes), neither IFPS-Cluster nor IPFS itself has any notion of “users” afaik (although IPFS-Cluster nodes could also be considered cluster “users” depending on your definition). You are right in that an alternative to what I'm proposing here would be a blockchain thing like ENS where I can set up a domain that points at some IPFS hash, but as of now I find that setup to be pretty inconvenient as compared to DNSLink+IPNS and I think there is definitely a case to be made for sharing IPNS state between nodes without involving a blockchain. Also, the blockchain “solution” doesn't handle serving a HTTPS fallback at the given DNS name for the other 99% and paying each time I want to update my website to forever record the change is not something I'm actually interesting in or even want.
I'll try to take this up.
So if I understood it correctly an aim is to allow cluster to publish a CID to IPNS with a key. So should we have a wrapper command which takes in the key name and a CID so it can contact the peer having the CID pinned, create a key there and publish the CID using that key? Or we can implement the things independently and use them managing any required transfer i.e. having cluster create keys on peers and track, and also allow publishing CIDs to IPNS with any key created?
Please let me know if I misunderstood anything.
@omkarprabhu-98: I think we're on the same page, yes.
I tried to write it down more like a specific below:
Core proposal: The idea is to have the equivalent of
ipfs name publish -k {key_name/id} {ipfs_hash} for ipfs-cluster-ctl where:
key_name/idis a key somehow registered withipfs-cluster-service– note that not all service instances will know the private keys but they should still be able to publish if they are trustedipfs_hashcan be any allowed IPNS content or possibly also a pin name known to the IPFS cluster for convenience
Running that command would:
- Store the key-value mapping in the cluster state
- Execute the equivalent of the above
ipfs-command on each node that has a copy of the key
Each cluster node must ensure that its connected IPFS node is aware of the most recent IPNS value. (Publishing the value on startup and whenever it is updated should suffice I think.) This should include cluster nodes that only become aware of the corresponding private key at a later time, as well as nodes added to the cluster after publishing the key's value through the cluster.
Key distribution: The original proposal also asks for a way to add (or generate) a key in such a way that it will be automatically copied to all trusted nodes. This would be convenient for setting up new content on small clusters such as mine where every node is fully trusted and closely monitored. But for anything else I don't even know if IPFS cluster has any provisions for sharing secrets with only some nodes but not others, so I'm not sure if this part of the proposal is all that well thought out.
What I'm trying to say is: If in doubt, this could be moved to secondary discussion once the primary feature for which it exists is in place.
@hsanjuan thoughts? Also shouldn't running the publish command from only the single node that has the key and cid be sufficient rather than from all nodes?
@omkarprabhu-98 please choose another (easier) issue.
This needs extra scope about which I am not yet sure, like whether to distribute keys, whether to track IPNS entries in pins metadata, whether this could be exploitable in bad ways etc.
Hello! Has there been any progress on this issue lately? Or any other solutions for the use case of updating IPNS from a remote computer?