Design for the issue #80

from hathor-wallet.

I like the design, I just have some comments

Inactivity threshold state

I don't see any downsides of this being a redux state but I feel that this could be a constant in our constants.js file.

Inactivity checker

Where should we implement this checker? Should we create a clearInterval as well, or maybe just accept that this will be running until the wallet application is closed.

Apart from that, I think the wallet checker should lock the wallet only if the wallet is loaded. Imagine if you are starting a new wallet and while you are writing down your seed (it took you some minutes to get a pen and paper), then the screen changes automatically. So it's a simple check that we have in the lib wallet.loaded() that would prevent any problems on that case.

Also the hardware wallet is a bit tricky because we don't have a PIN (and a locked wallet for that), but we can send the user back to the wallet type selection screen.

from hathor-wallet.

I don't see any downsides of this being a redux state but I feel that this could be a constant in our constants.js file.

Sure! I though to initialize the state with a constant DEFAULT_INACTIVITY_THRESHOLD, it can be set in the constants.js indeed. What do you think? We can set value 300 meaning 300 seconds (5 minutes).

Where should we implement this checker? Should we create a clearInterval as well, or maybe just accept that this will be running until the wallet application is closed.

Apart from that, I think the wallet checker should lock the wallet only if the wallet is loaded. Imagine if you are starting a new wallet and while you are writing down your seed (it took you some minutes to get a pen and paper), then the screen changes automatically. So it's a simple check that we have in the lib wallet.loaded() that would prevent any problems on that case.

I agree we should trigger the inactivity checker only after the wallet be loaded.

But I have a question: what is the difference between when the wallet is loaded for when the wallet is ready?

Also the hardware wallet is a bit tricky because we don't have a PIN (and a locked wallet for that), but we can send the user back to the wallet type selection screen.

Oh! Thank you for this context, I was totally unaware. But yep, this works fine.

However I would like to propose in this case a page in which the user can insert their passphrase and we validate, if it matchs with the wallet we have saved, then it is unlock to be used. What do you think?

from hathor-wallet.

I like the design, but what are the downsides of using a simpler setTimeout to lock and any interaction just re-schedules the timeout? This would eliminate the need for a checker and the "multiple of 5" requirement.

from hathor-wallet.

But I have a question: what is the difference between when the wallet is loaded for when the wallet is ready?

They are the same. The wallet loaded/ready means that the user is interacting with a specific wallet, not importing/creating one.

However I would like to propose in this case a page in which the user can insert their passphrase and we validate, if it matchs with the wallet we have saved, then it is unlock to be used. What do you think?

I didn't understand this. We don't have passphrase when using the hardware wallet.

from hathor-wallet.

I like the design, but what are the downsides of using a simpler setTimeout to lock and any interaction just re-schedules the timeout? This would eliminate the need for a checker and the "multiple of 5" requirement.

I like this approach. I agree!

They are the same. The wallet loaded/ready means that the user is interacting with a specific wallet, not importing/creating one.

Got it.

Also the hardware wallet is a bit tricky because we don't have a PIN (and a locked wallet for that), but we can send the user back to the wallet type selection screen.

Ok, understood. I need to get more context about the hardware wallet.

We don't have a passphrase when using the hardware wallet.

Humm. Ok. Let's use your suggestion. But why we do not have a passphrase in this case? There are any material I can read about this decision?

Summary

Inactivity checker (drop)

We can drop it as suggested by @r4mmer in favor of a setTimeout with a lock function to be run after elapsed the inactive treshold from the lastInteractionAt.

Hardware wallet lock

The lock function in this context will redirect the user to the screen wallet type selection.

We agree with the change in the Summary? If yes, I will proceed with the Reference-level explanation for these topics.

from hathor-wallet.

We agree with the change in the Summary? If yes, I will proceed with the Reference-level explanation for these topics.

For me it's good.

But why we do not have a passphrase in this case? There are any material I can read about this decision?

Are you talking about the passphrase or the password? The passphrase is set in the ledger when using the hardware wallet.

from hathor-wallet.

But why we do not have a passphrase in this case? There are any material I can read about this decision?

It is not a decision on our part, the Ledger is a device which holds the seed and no external software can access it we have methods to confirm addresses by their index (to check they are from the wallet), sign transactions (we send the transaction and it comes back signed) and other methods, but the pin is on the Ledger device and not on our wallet.

The user unlocks the device with the pin then connects to our desktop wallet (so that it can make requests to it), so we don't have the need for pin and password on the desktop wallet. In other words, the desktop wallet becomes a GUI for the Hathor app on the Ledger device.

If you want to learn more, theres a Ledger developer portal and to a lesser extent there's the Ledger academy but the academy is just a group of posts explaining web3 and the crypto concepts, the developer portal is more focused on the device itself.

from hathor-wallet.

For me this is approved.

from hathor-wallet.

✅ Approved.

from hathor-wallet.