Application should fail gracefully if wrong network is used

[davisshaver]

As a user, if I accidentally login with the wrong network, I should see a more graceful failure.

• Prompting to change network would probably be best response
• Alternatively, could show a toast prompting user to change network themselves and then retry

Another idea is that since signatures should be cross-chain by default, maybe there's a way to login user and lookup their mainnet ENS no matter what network they have selected. Ownership of an address on one network is equivalent to ownership of an address on all networks, so maybe this mismatch can be abstracted away for XMPT client purposes.

[saulmc]

Great find and awesome submission!

since signatures should be cross-chain by default...

Indeed, as is the XMTP identity key bundle generated from the signature. AFAIK, ENS lookup is the only thing blocking the example app from being used with other networks. Prompting the user to switch to mainnet shouldn't be necessary. (Some indication of current network would be desirable).

Ownership of an address on one network is equivalent to ownership of an address on all networks, so maybe this mismatch can be abstracted away for XMPT client purposes.

It doesn't seem that a consensus has emerged yet whether ENS identities refer specifically to mainnet wallets or to all instances of that address across EVM networks. For example, the Uniswap app will only display an ENS domain when mainnet is selected, otherwise it falls back to displaying the wallet address.

[saulmc]

Adding note to consider indicating when the user is on a network that doesn't support ENS, as they will be unable to enter ENS addresses into the address bar.

cc @darickdang

[galligan]

@saulmc there should be no specific reason why the ENS domain shouldn't resolve, regardless of connecting network if the reverse record for the ENS domain points to an identical Ethereum address.

ENS doesn't need to be deployed to an EVM for the ENS domain reverse record address to still work and point to the same address across EVM chains.

[saulmc]

@galligan The specific reason why it doesn't resolve currently is that ethers depends on the wallet provider's RPC connection. If the wallet isn't connected to mainnet, then ethers isn't either, and the resolver method won't work.

It's certainly possible to work around this; we would get it for free if we used RainbowKit or ConnectKit.

[galligan]

@saulmc makes sense

It's certainly possible to work around this; we would get it for free if we used RainbowKit or ConnectKit.

Seems like this would be a valuable pursuit in both the example chat app, and later find some way to help solve for this case in a plugin to the SDK. Ultimately devs should be able to use any of the wallet connecting frameworks, and still have critical name resolution work as expected (thinking ENS, Lens, etc).

[elisealix22]

This came up in our bug bash today as well -- except using Polygon. I majorly agree and would I'd love to try to make this work since messages still send as expected without ENS. Right now it just feels broken.