-
Notifications
You must be signed in to change notification settings - Fork 33
Defer input of a private key when adding account just to view the balance #532
Comments
Thanks for the issue. There's indeed no easy / non-hacky way to achieve this for now. |
I would suggest considering addnig some sort of priority on this feature request: Your project is unique in that it ostensibly does not depend on any backing server and your users are those that are careful with whom they entrust their private keys. Asking for private keys upfront in Fether make us feel uneasy. :) |
Good point. If you import an account from Parity Signer, then Fether doesn't ask for the private key, as it is managed by Parity Signer. If managing the account with Parity Signer is out of the question for you (e.g. private key stored elsewhere, or you want to monitor an account you don't have access to), there is still a workaround: you can generate the QR code of the address and scan it in As an example, if you want to monitor |
Thank you. Is there a possibility of using this walkaround on a notebook that does not have a camera? I can install a virtual camera, but that seems too much hassle. In theory, once you already have a QR reader embedded in the code, it might be relatively easy to give an option to type the encoded text manually. Just like a when you checkout in the shop, there is an option to enter the digits encoded in the barcode using the numerical keyboard. |
(hacky workaround)You can open the Electron/Chromium Developer Tools (Ctrl+shift+I) inside Fether, navigate to the Console tab, paste the following line (replace address and name as desired) and hit enter: Yes, I agree it would be pretty easy to add the option to import an address. If anyone feels like implementing this, feel free to submit a PR! |
Hey @adamryczkowski, I've been working a little bit on implementing this in my branch here. It's pretty easy to call |
Use case: I want to use the Fether just to view the balance.
If there is already a way to use Fether to monitor the balance, then please point me to the relevant part of the documentation and close the issue.
You may implement it by allowing two types of accounts: authorized (i.e. with private keys) and non-authorized. I hope it will not require too much refactoring...
The text was updated successfully, but these errors were encountered: