Web3Modal API v2 spec

[bkrem]

Context

• (Supersedes #228 to fix Git LFS on main base branch) 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

• [x] Move current (v1) spec into a separate markdown file where we can back-reference it
• [x] Account for the endpoints that were added previously without updating the v1 spec
• [x] Tie up action items from: https://www.notion.so/walletconnect/Spec-Finalization-Call-a4be73ca50a640eab61a398197708f3c
• [ ] Finalize spec

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
walletconnect-specs	⬜️ Ignored (Inspect)	Visit Preview		Aug 8, 2024 8:46pm

[Cali93]

It'd be great to get an answer to this question. At the end of the day, you're consuming this API so anything we can do to improve your DX should be tackled here too.

[glitch-txs]

Hello, since we are moving WalletConnectModal to AppKit we need a way to filter wallets that support the WalletConnect protocol. e.g Rabby wallet is an extension wallet so we won't need it in the response. However those wallets that are extension but also support mobile (WalletConnect) should be in the response. Coinbase would be another example as they don't support WalletConnect.

cc @enesozturk @tomiir

[bkrem]

Hello, since we are moving WalletConnectModal to AppKit we need a way to filter wallets that support the WalletConnect protocol. e.g Rabby wallet is an extension wallet so we won't need it in the response. However those wallets that are extension but also support mobile (WalletConnect) should be in the response. Coinbase would be another example as they don't support WalletConnect.

cc @enesozturk @tomiir

@glitch-txs but this doesn't require explicit breaking changes to the API I presume? Seems like either a dedicated endpoint or an additional query parameter so wouldn't have to be settled right now for us to move ahead on implementing the v2 spec.

[glitch-txs]

A query parameter would be great

[bkrem]

Can we specify caching behavior for these endpoints? I propose:

• response: Cache-Control: public, max-age=43200 (same as current)
• response: ETag: <hash of content>
• request: If-None-Match: <value of ETag header>

The request will return a 304 Not Modified if the hash matches, saving bandwidth needing to respond with duplicate data, and renewing the Age of the resource.

Yeah would be great to add this as an optimisation.

Also it's non-breaking so not strictly a v2 issue, we could in theory already do this right now and clients update their fetch behaviour.

@Cali93 any objections to the ETag as an optimised query flow?