Both Trust Wallet and MetaMask inject providers that self identify with “isMetaMask” and “isTrust” fields - perhaps other do as well. I’ve noticed some d’apps are developing if/then logic based on these fields to prompt the user to connect to the detected injected wallet (or trezor, ledger, etc).

Would it be appropriate for these injected providers to expose a generic interrogation api to determine ‘wallet name’ and ‘wallet icon url’ so as more wallets come online these d’apps need not maintain separate logic for each?

Agreed, @MicahZoltu - that is the intention of adding generalized identifiers. From what I’m seeing the d’apps are just switching on the is field in order to display a friendly menu of wallet connection options that includes the injected web3. If the injected provider can self-identify in a general sense, then the d’app will not need to switch to provide this.

I think this could make sense - kind of like a user agent string. But I agree with @MicahZoltu here that it should not really be used for switching. Perhaps it is better to not even expose it in the first place - otherwise people will switch on this information. But then things like isTrust, isMetamask are emerging - which is even worse.
What would IMHO really make sense is that wallets expose the features they support. So dApps don’t switch on a particular wallet - but on a feature-set.

The reason for these methods specifically is to discourage switching for the simple identification use-case - and yet to allow d’apps to provide users a sense of assurance that the d’app has connected with their wallet. Without this, in order to provide an initial connection menu, the d’app would have to say “Would you like to connect with the injected wallet, Trezor or Ledger?”. In that use case it’s useful to be able to say “Would you like to connect with MetaMask, Trezor or Ledger?” Right now d’apps are switching on isMetaMask just to provide that indication (e.g. totle.com). We could certainly discourage switching on the name in the documentation / standard - but right now there is no other way to identify the wallet software that is injected.

I think the converse is also likely true - that the wallet might like to display a friendly name for the d’app that is sending a transaction or currently active/connected. Hence the functions allowing the d’app to self-identify to the provider would be good.