How to capture the registry listing information for the wallet the user selected?

[bobwith2bees]

Dealing with various wallets, I have found I cannot trust the wallet to populate the same data in the peer PairingMetadata as they do in the WalletConnect registry listing. I am looking for a way to capture the registry listing that was tapped by the user in the WalletConnectModel

Ask Ideally:

• The registry metadata that was called
• The type of link (URI/Native) that was successfully launched so I can launch the wallet consistently.
• Even nicer if the plugin could save/restore that so I don't have to... but that's another story.

Examples of data missing in PairingMetadata (compatibility challenges)

• No app icons (empty list returned)
• No redirect URIs (optional field)

I had hoped I could just start the app, and read in all the connected Peer's information from the plugin. Now I can only prioritize that, and fallback/supplement with the original listing. (Or the latest listing if I needed to fetch by appId and there was a easy Explorer service apI to do that.)

[bobwith2bees]

Due to #11 - I am not sure even the listing Id from the v1 api is compatible with the published v3 api "id" for explorer. Challenges of multiple teams running fast I suppose.

[Luzzotica]

Yeah, the discrepancies were frustrating for me as well.

The library should already provide solutions to number 1 and number 2 in your list. That's what the launchCurrentWallet function is for. Maybe that only responds to problem 2 that you listed. Perhaps I can create something for the metadata as well so you can query the image and other data.

[bobwith2bees]

@Luzzotica - If you could make a variant of launchWallet that takes a topic and calls the correct wallet - you can support the case of 1 DApp connected to multiple wallets.

[Luzzotica]

Just adding the session topic to the launchWallet function wouldn't resolve the issue completely. There are other issues with multiple wallets.

For example, what address should I provide when the user requests it?

It's not as simple as just putting a topic in there. There are multiple other changes that would need to take place. How many use cases are there for connecting with multiple wallets from one dApp?

I feel that it's such a niche use case, that if someone really wants it, they can just use the base library and implement custom things. This library isn't really built for it.

[bobwith2bees]

@Luzzotica

No worries if it is out of scope. I was building my app based on the capabilities of the protocol as compared to V1. I believe I have all I need to do this on my own.

Use case that I am currently looking at next: A DAPP for DAO members.

• Voting may occur on chain 1 (i.e. snapshot)
• Proof of membership on chain 2 (i.e. Ethereum NFT owner)
• Authority granted within the DAO / Reputation on chain 3
• Interact with other DAPPs (based on authority provided) on chain 4 (i.e. Gnosis treasury approval) (...oh and the WalletConnect Roadmap)
• Sign in on chain 5 with public name
• Chat with other DAO members

There is no guarantee there will be a single wallet to support all chains required. (And projects are often funded by grants, so there easily could be another blockchain tomorrow with it's own wallet.)

Re address ambiguity:

• In my case - I don't need to provide a specific address when opening an app, just open the app (i.e. launch rainbow:// )
• There is the general ambiguity when sending a request we chatted about here: https://github.com/WalletConnect/WalletConnectFlutterV2/issues/131 .
• I still have to handle two wallets having the same address and deciding (perhaps on tested compatibility with my app) which one to send the the request (and open.)

I'll go ahead and close this as too niche. But I did want to document where I was coming from. ;-)

[Luzzotica]

I see the logic now.

This is something I will keep in mind. I'll see if there is a simple way to tackle all of these issues.