search

status-im / status-desktop

Status Desktop client made in Nim & QML
https://status.app
Mozilla Public License 2.0
303 stars 79 forks source link

ENS name is not recognised across chains #16427

Open anastasiyaig opened 1 month ago

anastasiyaig commented 1 month ago

Bug Report

Description

Using ens name is chain-agnostic, when it should be the other way round

Steps to reproduce

https://github.com/user-attachments/assets/803279e0-10cd-4b21-aa07-3fa76d3dd196

Actual behavior

We introduced a new feature of sending in chat https://github.com/status-im/status-desktop/pull/16424 And when i use a name that is registered to mainnet, then send modal does not show me anything, but if the name is registered for other chain, then we should display an error "cannot resolve ens username on this chain"

@benjthayer could you please design something for us?

Additional Information

anastasiyaig commented 1 month ago

cc @virginiabalducci @Khushboo-dev-cpp

virginiabalducci commented 1 month ago

This is marked for 2.32 but since this feature will be released on 2.31 is it worth taking a look if it can be fixed?
I'm not sure how important it is for the specific flow of ENS usernames should be compared to just wallet addresses that may justify a fix on 2.31 or keep it in 2.32, please advice how to proceed thanks!

cc @Khushboo-dev-cpp

https://github.com/user-attachments/assets/54e2d88b-0b72-4d42-9585-e3dbdb01718c

ERR 2024-10-22 15:32:54.367Z rpc response error                         topics="rpc" tid=70817042 file=core.nim:36 err="\nstatus-go error [methodName:ens_publicKeyOf, code:-32000, message:no contract code at given address ]\n"
ERR 2024-10-22 15:32:54.367Z error doing rpc request                    topics="rpc" tid=70817042 file=core.nim:39 methodName=ens_publicKeyOf exception="\nstatus-go error [methodName:ens_publicKeyOf, code:-32000, message:no contract code at given address ]\n"
DBG 2024-10-22 15:32:54.367Z NewBE_callPrivateRPC                       topics="rpc" tid=70817042 file=core.nim:27 rpc_method=ens_addressOf
ERR 2024-10-22 15:32:57.785Z rpc response error                         topics="rpc" tid=70817042 file=core.nim:36 err="\nstatus-go error [methodName:ens_addressOf, code:-32000, message:no contract code at given address ]\n"
ERR 2024-10-22 15:32:57.785Z error doing rpc request                    topics="rpc" tid=70817042 file=core.nim:39 methodName=ens_addressOf exception="\nstatus-go error [methodName:ens_addressOf, code:-32000, message:no contract code at given address ]\n"

EDIT: This is only happening for ENS that were purchased in testnet , the ENS purchased in Mainnet actually load the Send information. No need to address this issue in 2.31

anastasiyaig commented 1 month ago

@virginiabalducci it is pending designs as well

benjthayer commented 1 month ago

Bug Report

Description

Using ens name is chain-agnostic, when it should be the other way round

Steps to reproduce

Screen.Recording.2024-09-30.at.10.32.28.mov

Actual behavior

We introduced a new feature of sending in chat #16424 And when i use a name that is registered to mainnet, then send modal does not show me anything, but if the name is registered for other chain, then we should display an error "cannot resolve ens username on this chain"

@benjthayer could you please design something for us?

Additional Information

  • Status desktop version: commit 2e249f9
  • Operating System: any

Thanks @anastasiyaig I actually wasn't aware that ENS names couldn't be used on all L2's - so thanks for letting me know! Ideally we would find a way for the address to be resolved irrespective of the chain selected but in the meantime we could use the existing validation we have:

Successful ENS resolution flow for reference: https://www.figma.com/design/FkFClTCYKf83RJWoifWgoX/Wallet-v2?node-id=25437-166304&t=wcklTydPG9dZj20w-4

Address validation which we could use for unsuccessful ENS resolution: https://www.figma.com/design/FkFClTCYKf83RJWoifWgoX/Wallet-v2?node-id=25982-306022&t=wcklTydPG9dZj20w-4

Image

@Khushboo-dev-cpp WDYT? cc @xAlisher

Khushboo-dev-cpp commented 3 weeks ago

Bug Report

Description

Using ens name is chain-agnostic, when it should be the other way round

Steps to reproduce

Screen.Recording.2024-09-30.at.10.32.28.mov

Actual behavior

We introduced a new feature of sending in chat #16424 And when i use a name that is registered to mainnet, then send modal does not show me anything, but if the name is registered for other chain, then we should display an error "cannot resolve ens username on this chain" @benjthayer could you please design something for us?

Additional Information

  • Status desktop version: commit 2e249f9
  • Operating System: any

Thanks @anastasiyaig I actually wasn't aware that ENS names couldn't be used on all L2's - so thanks for letting me know! Ideally we would find a way for the address to be resolved irrespective of the chain selected but in the meantime we could use the existing validation we have:

Successful ENS resolution flow for reference: https://www.figma.com/design/FkFClTCYKf83RJWoifWgoX/Wallet-v2?node-id=25437-166304&t=wcklTydPG9dZj20w-4

Address validation which we could use for unsuccessful ENS resolution: https://www.figma.com/design/FkFClTCYKf83RJWoifWgoX/Wallet-v2?node-id=25982-306022&t=wcklTydPG9dZj20w-4

Image

@Khushboo-dev-cpp WDYT? cc @xAlisher

@benjthayer think thats a good quick resolution for this.