Handling of ADA handles and possible debouncing

[MyEnlightenmint]

Hello,

I believe there is an issue with how the UI for the wallet handles HTML input - which specifically effects ada handles. I first noticed this issue as I send hundreds of promo assets from my minter to my Nami wallet, then distribute from my Nami wallet to users. I thought I was losing my mind when multiple people stated they had not received, but I had proof of send to the copy/pasted or typed handle provided.

This became a larger issue when a friend sent an important asset to let's say $wallet1. He, as was I with my issue, 100% certain the address was input correctly. There is a forced double check. His asset ended up in $wallet2. An example of this was he wanted to send to $tangerine but the system only recognized $tan and sent to the $tan wallet instead.

I believe there is an issue with how the wallet is converting HTML text inputs to UTF-8 (as an update here likely when the wallet reads and does not double check, rather than a UTF conversion issue - UTF conversion seems fine it is just finding the wrong wallet.. The wallet thinks the user is done typing when it finds a wallet that matches $wallet2 and doesn't check again - does not seem to happen on every send). I am not sure if the issue is simply an interface issue, has something to do with UTXOs, or something else - but there is something wrong. I switched to CC Vault and have not had the issue since. Unfortunately my buddy is down an asset.

Please look into this ASAP. I am not familiar enough with your source code to find the issue.

I guess this is spreading around some. If you are reading this this is NOT an ada handle issue and I have not been able to replicate on other wallets..

[MyEnlightenmint]

One thing that is important to note - this is not an issue with ada handles. This is on the wallet side.

[cjkoepke]

This, to me, sounds like a possible debouncing issue where an address may be resolved mid-type, but not finalized on sending (i.e. refetch the address when the user actually hits send). I would also recommend some level of resolution feedback to the user, such as the last 6 digits of the address.

[CaffinusMaximus]

Yes, please look into this. This happened to me, via a mac using chrome with Nami. I'm certain it wasn't mistyped.

[alessandrokonrad]

Sorry I'm not able to replicate the issue. Please let me know how you got there exactly

I believe there is an issue with how the wallet is converting HTML text inputs to UTF-8

I'm not sure what you mean with this. You already type in UTF-8 aka human readable format.

An example of this was he wanted to send to $tangerine but the system only recognized $tan and sent to the $tan wallet instead.

This is definitely not happening. There is no fallback. Either the handle matches and it finds an address or simply not. $tan and $tangerine is a huge difference.

You can check for yourself. This is what happens:
The raw input in UTF-8 from the html input field is taken, then converted into hex, which represents the asset name of the token. Then you concatenate the policy id with the token name and look it up on blockfrost, which returns to you the owner address of that asset.
If it doesn't return any result, null is returned and an error occurs on the user side.

https://github.com/Berry-Pool/nami-wallet/blob/11fcd502504f9ce0fa22ef8f108892e2f3828aa8/src/api/extension/index.js#L1448-L1452

[cjkoepke]

This is definitely not happening. There is no fallback. Either the handle matches and it finds an address or simply not. $tan and $tangerine is a huge difference.

In the event of debouncing (which it looks like you're wrapping in a timeout, here: https://github.com/Berry-Pool/nami-wallet/blob/5ea49233fc86d0502df86952ebaa193998748bae/src/ui/app/pages/send.jsx#L928), it is perhaps possible that a user could pause typing just long enough (300ms) at the point of $tan that it resolves that address while they finish typing the rest of $tangerine.

In truth, this has been reported multiple times within our community and only from users of Nami. My hunch is that something is happening in the actual code linked above and it is not an issue with actually fetching the Handle location, but rather how the timeout is handled on the input.

[cjkoepke]

Another theory on this:

What happens if a user stops typing, a fetch is initiated, but the request is slow (slow internet) or Blockfrost times out? Further, what happens if the user continues typing during this slow response time? Unless the original fetch is terminated, it could inadvertently overwrite a second request's resolved address when the first one finally does resolve.

[alessandrokonrad]

This is definitely not happening. There is no fallback. Either the handle matches and it finds an address or simply not. $tan and $tangerine is a huge difference.

In the event of debouncing (which it looks like you're wrapping in a timeout, here:

https://github.com/Berry-Pool/nami-wallet/blob/5ea49233fc86d0502df86952ebaa193998748bae/src/ui/app/pages/send.jsx#L928

), it is perhaps possible that a user could pause typing just long enough (300ms) at the point of $tan that it resolves that address while they finish typing the rest of $tangerine.
In truth, this has been reported multiple times within our community and only from users of Nami. My hunch is that something is happening in the actual code linked above and it is not an issue with actually fetching the Handle location, but rather how the timeout is handled on the input.

Yeah right. I'm wrapping it in a setTimeout and clear the timeout when the input is changed. I was under the impression the whole call is canceled especially because it worked for me that way perfectly. First after simulating the connection under very bad 3G internet connection, it's possible to see a bad effect of my approach. That was hard to find out, but thanks for the tip! I have a solution already. Using some React debouncing libraries which keep track of all the async calls and always only use the last call.

[cjkoepke]

Awesome! Also check out AbortController, which is a native browser API. It lets you abort a fetch call mid-execution: https://developer.mozilla.org/en-US/docs/Web/API/AbortController

[jrafsantos]

in order to resolve the address what is being used by blockfrost? is it dbsync? if so what happens if dbsync database stops syncing? how does blockfrost garantees dbsync database integrity?

[alessandrokonrad]

in order to resolve the address what is being used by blockfrost? is it dbsync? if so what happens if dbsync database stops syncing? how does blockfrost garantees dbsync database integrity?

You have to rely on them, until you can run your own blockfrost instance. But if their dbsync stops, their whole service is likely down anyway, so address resolution won't happen anyway until their service is back up and fully synced.

[MyEnlightenmint]

This is definitely not happening. There is no fallback. Either the handle matches and it finds an address or simply not. $tan and $tangerine is a huge difference.

In the event of debouncing (which it looks like you're wrapping in a timeout, here:

https://github.com/Berry-Pool/nami-wallet/blob/5ea49233fc86d0502df86952ebaa193998748bae/src/ui/app/pages/send.jsx#L928

), it is perhaps possible that a user could pause typing just long enough (300ms) at the point of $tan that it resolves that address while they finish typing the rest of $tangerine.
In truth, this has been reported multiple times within our community and only from users of Nami. My hunch is that something is happening in the actual code linked above and it is not an issue with actually fetching the Handle location, but rather how the timeout is handled on the input.

I really appreciate you chiming in here. I did not know how to word it exactly and am happy to learn more on this from folks like you. I knew something was off - thanks for clarifying it.

[MyEnlightenmint]

Sorry I'm not able to replicate the issue. Please let me know how you got there exactly

I believe there is an issue with how the wallet is converting HTML text inputs to UTF-8

I'm not sure what you mean with this. You already type in UTF-8 aka human readable format.

An example of this was he wanted to send to $tangerine but the system only recognized $tan and sent to the $tan wallet instead.

This is definitely not happening. There is no fallback. Either the handle matches and it finds an address or simply not. $tan and $tangerine is a huge difference.

You can check for yourself. This is what happens: The raw input in UTF-8 from the html input field is taken, then converted into hex, which represents the asset name of the token. Then you concatenate the policy id with the token name and look it up on blockfrost, which returns to you the owner address of that asset. If it doesn't return any result, null is returned and an error occurs on the user side.

https://github.com/Berry-Pool/nami-wallet/blob/11fcd502504f9ce0fa22ef8f108892e2f3828aa8/src/api/extension/index.js#L1448-L1452

Apologies on my lack of understanding on exactly what was going on - but it seems there is acknowledgement of an issue here. I've lost dozens of assets to this issue like I said and there was no possible way I had type in that many addresses poorly.