Open alexauroradev opened 1 month ago
@alexauroradev Where would you expect to find this command?
It sounds like a good candidate for a dedicated near-ledger
CLI, what do you think?
As a workaround, you can use add-key
command:
near account add-key devhub.near grant-full-access use-ledger
It will ask for HD Path, and then in the further steps, it will create a transaction for you to sign where the public key will be printed.
@frol
The current menu of the near-cli-rs does not have a proper place for this command (and maybe other ledger-related commands in the future). The closest is account
section.
Having a separate near-ledger
CLI might be an option, but installing additional tools is a nightmare.
Can we somehow utilise extension
zone? At the moment it's only self-update
there. I think this might be a good option. And in the future there might be other hardware wallets there or some 3rd parties extensions for, for example, pre-running of txs to check the outcome... WDYT?
@alexauroradev We already have CLI extensions support, so when you install near-validator-cli-rs
, it is automatically available as near validator
subcommand: https://github.com/near-cli-rs/near-validator-cli-rs
We may consider adding extensions installing command in the future as well
Is there any progress on this? Are you considering adding this feature to the NEAR CLI RS (or a separate extension) in the future?
There is no capacity at the moment to address this feature request, sorry. I also cannot find a good place for this functionality in near-cli-rs, so a separate extension might be justified.
Also, old near-cli-rs 0.1.16 actually had "helpers" section:
./near-cli utils ledger-public-key
Consider installing the old version for the time being: https://github.com/near/near-cli-rs/releases/tag/0.1.16
At the moment, NEAR CLI RS does not have the way to display the public key corresponding to a specific Ledger HD Path. However, this might be helpful, especially in cases when managing ledger keys of the existing contracts / accounts:
Such functionality is usually missing for other protocols, so not limiting HD paths to "44'/397'/0'/0'/*'" may be appreciated by people who use other protocols, especially Aurora developers.