You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose adding the w3 name get <keyId> command, to retrieve and reuse the signing key associated with an IPNS name. Currently, the revision can be updated only from the environment where the IPNS name was initially created.
I took the initiative and already implemented the solution here. If the feature proposal is approved, I'm open to taking further guidance on how to contribute to the project.
Why add this command?
I was building my website, intending to deploy it on IPFS (Web3.Storage). From an article, I learned how to deploy changes in 3 commands, but I thought I could do better.
When I was trying to update the CID associated with the taken IPNS name via a GitHub action, I could not do that without providing the corresponding signing key. I searched on Internet how to retrieve the key, but I could not find another solution as to modify the w3's code, in order to console.log the signing key. Once I retrieved the key, I added it to the repo's secrets, so that my workflow adds the new build to IPFS with a followed update of the IPNS revision.
I don't think that my use case is unique in its kind. Many developers who would like to automate their deployments will have to "move" the signing key from the local to the deployment context.
Why not add this command?
Maybe there is another way to retrieve the signing key, and this feature is not as useful as I thought.
Proposed solution
Add the w3 name get <keyId> command to the w3 CLI.
From what I've seen in the repo, w3 name ... commands are not tested. The code for Name.getKey(keyId) reuses the key presence check from Name.publish().
Risks
There are no reasons to "hide" the signing key in the config because it can be easily retrieved by adding a console.log either in the publish or create functions (as a workaround to the existing limitations in the CLI).
Backward compatibility will be respected because the changes only extend the interface.
The text was updated successfully, but these errors were encountered:
TLDR
I propose adding the
w3 name get <keyId>
command, to retrieve and reuse the signing key associated with an IPNS name. Currently, the revision can be updated only from the environment where the IPNS name was initially created.I took the initiative and already implemented the solution here. If the feature proposal is approved, I'm open to taking further guidance on how to contribute to the project.
Why add this command?
I was building my website, intending to deploy it on IPFS (Web3.Storage). From an article, I learned how to deploy changes in 3 commands, but I thought I could do better.
When I was trying to update the CID associated with the taken IPNS name via a GitHub action, I could not do that without providing the corresponding signing key. I searched on Internet how to retrieve the key, but I could not find another solution as to modify the
w3
's code, in order toconsole.log
the signing key. Once I retrieved the key, I added it to the repo's secrets, so that my workflow adds the new build to IPFS with a followed update of the IPNS revision.I don't think that my use case is unique in its kind. Many developers who would like to automate their deployments will have to "move" the signing key from the local to the deployment context.
Why not add this command?
Maybe there is another way to retrieve the signing key, and this feature is not as useful as I thought.
Proposed solution
Add the
w3 name get <keyId>
command to thew3
CLI.Code changes
How to test
From what I've seen in the repo,
w3 name ...
commands are not tested. The code forName.getKey(keyId)
reuses the key presence check fromName.publish()
.Risks
There are no reasons to "hide" the signing key in the
config
because it can be easily retrieved by adding aconsole.log
either in thepublish
orcreate
functions (as a workaround to the existing limitations in the CLI).Backward compatibility will be respected because the changes only extend the interface.
The text was updated successfully, but these errors were encountered: