Web3Modal API v2 spec

[bkrem]

Context

See: https://www.notion.so/walletconnect/Web3Modal-API-v2-Proposal-a2fc6323156d49f79d8092f5c39b8cda

Scope

• Problem 4 & 5 from the proposal are out-of-scope for the spec, since they are implementation details.

TODO

• Move current (v1) spec into a separate markdown file where we can back-reference it
• Account for the endpoints that were added previously without updating the v1 spec
• Finalize spec

[bkrem]

@chris13524 I added an affordance for granular image size control as discussed/added by you to the proposal doc 👍

[tomiir]

We'll need to have a new format for this when we introduce the multichain refactor as it might include multiple libraries. If a user decides to use SolanaWeb3JsAdapter AND EVMWagmiAdapter then what would library have?

We could maybe include an extra query param libraries ? What would be best for analytics also cc @dnul

[bkrem]

From AppKit versions that support multi-chain onwards, could we do e.g. react-solanaweb3js;evmwagmi-5.0.0, where the library parameter can be a ;-separated list (or via some other separator)? Maybe will relabel to {adapters} given this.

We could maybe include an extra query param libraries ?

I suspect introducing a separate parameter will create more complicated parsing:

• need to check for the positional library value still for implementations up to version X that have sv= as${framework}-${library}-${version}
• need to check for explicit libs= query param for implementations beyond version X, where sv= is only ${framework}-${version}

[tomiir]

Okay, let's not overcomplicate things. I believe the ; separated values would work (though they def look ugly 😭 ).

[ignaciosantise]

should we add appkit here?

[ignaciosantise]

Recently we had a case in web were we needed the universal_link only, nowadays the api returns the deeplink by default, and universal_link as a fallback.

Should we consider sending both again?
https://github.com/WalletConnect/web3modal/pull/2352/files

[bkrem]

Yes definitely 👍 I think the API shouldn't be internalising this logic and the clients should be deciding on which one to use.

If we only want to use deep_link happy days, but it shouldn't be returning ambiguous values (sometimes deep link sometimes universal) where clients have no choice in the matter.

[ignaciosantise]

something like this?

"mobile_link": {
   "deep_link": string | null,
   "universal_link": string | null
} | null

[bkrem]

Yes, I think we should basically mirror what was already the standard in Explorer API, e.g.

"mobile": {
  "native": "trust://",
  "universal": "https://link.trustwallet.com"
},

But we can keep the deep_link/universal_link keys and not go back to native/universal

One less difference to deal with between the response schemas that way.

Will incorporate into the new PR 👍

[quetool]

If we are gonna send platform: ios|android param, should we need both app_store and play_store values in the response object? I mean, if I request platform: ios there's no point for me to have play_store URL, right?

[bkrem]

Good point, so:

• by default it still returns both since the platform param is optional
• if platform is provided we could narrow the response down to omit what isn't needed for platform

[bkrem]

Superseded by #239