Skip to content

Add w3 name get <keyId> command #1835

@nvrabii

Description

@nvrabii

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 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.

Code changes

  1. Add the command to w3/bin.js
  2. Add the handler to w3/name.js
  3. Update w3/README.md

How to test

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/enhancementA net-new feature or improvement to an existing featurepi/w3name

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions