Closed bobwith2bees closed 1 year ago
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.
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.
@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.
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.
@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.
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:
I'll go ahead and close this as too niche. But I did want to document where I was coming from. ;-)
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.
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:
Examples of data missing in PairingMetadata (compatibility challenges)
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.)