Unable to resolve certain ENS-registered addresses

[wschwab]

Description While MetaMask can resolve .eth domains typed in the address bar of browsers, and retrieve/display content registered to .eth addresses, this does not seem to work for .xyz, an ENS-supported TLD.

To Reproduce: Unfortunately, my only evidence is anecdotal: I registered onion content on a subdomain of a xyz domain, and it won't load.

1. Ensuring MetaMask is installed and unlocked, attempt to resolve onion.wschwab.xyz in the address bar of a browser that can visit a onion website, most likely Tor.
2. You can verify the content is indeed linked in ENS here, and can even click on the content in Tor to see that it displays properly.

Expected behavior The address should resolve to the linked content as registered in ENS.

Screenshots If applicable, add screenshots to help explain your problem.

Browser details (please complete the following information):

• OS: Linux
• Browser Tor 9.0.6, 9.0.7
• MetaMask latest

Additional context (Error Messages, etc.) I originally thought this might be an issue with resolving v3 onion addresses, but is not, as the CIA link resolves normally when using the ENS link (ciagovtor.eth).

I suspect the issue is this line of code from /app/scripts//lib/ens-ipfs/setup.js :

const supportedTopLevelDomains = ['eth']

I've only started looking through the codebase today, but I suspect from this line that MetaMask will only resolve .eth addresses, whereas the address I was attempting to resolve is a .xyz address. If I'm right, the solution should be as simple as adding other supported TLDs to the supportedTopLevelDomains array. I'd make a PR, but I feel a bit weird doing so without checking in with you all first to see if I totally missed the boat on this.

Thanks!

[wschwab]

Would adding the other ENS-enabled domains to the array mentioned above mean that browsers would no longer be able to load traditionally-hosted content?

If MetaMask 'grabs' the URL before the browser tries resolving the DNS, would that mean traditionally-hosted sites in these TLDs would stop working?

[rekmarks]

If MetaMask 'grabs' the URL before the browser tries resolving the DNS, would that mean traditionally-hosted sites in these TLDs would stop working?

~The answer is "Yes." The reason we don't support resolution for .xyz content is because doing so would break existing websites. Our options are to...~

The problem is not that, but it does stem from .xyz being an ICANN TLD. We can/already ensure that we only attempt ENS resolution if the browser fails to resolve a URL. For .eth this is okay, because it's fine to assume that a MetaMask user attempting to navigate to an .eth URL is attempting to do something ENS-related.

For .xyz, on the other hand, we have no idea what the user's intentions are. We'd have to know whether the user is intending to navigate to an ENS URL in advance, and I do not see a viable way to accomplish that.

While I can imagine other solutions—for instance adding an address bar in our UI—this is not a high priority, and we are unfortunately are unlikely to fix this time any time soon. I will leave this issue open for tracking purposes.

cc: @Gudahtt

[jacobc-eth]

@wschwab this link might help you in the meantime: https://gen.xyz/ethereum

[cozmik70]

Can we escalate this? A major FTSO on songbird network by flare finance is using .xyz TLD (bestftso.xyz) I cannot access this site on mobile with metamask browser .

[Gudahtt]

@cozmik70 This repository is for the MetaMask Extension, not the MetaMask mobile app. The repository for mobile is here: https://github.com/MetaMask/metamask-mobile