improvement(walletconnect): return the pairing_topic in new_connection response

[mariocynicys]

Currently when creating a new WalletConnect connection, you get back only the pairing url. It's now made so it returns also the pairing topic along.

The flow from the GUI would be like this:

• hit new_connection -> receive { "url": "wc:40923091...", "pairing_topic": "40923091..." }
• keep hitting get_session till the user has established the session:
  • request { "topic": "40923091...", "with_pairing_topic": true }
  • keep requesting till getting a non null response. Only then, the session has been established.
• any subsequent requests to get_session should use the session_topic instead of pairing_topic (the pairing_topic should be discarded really at this point). And "with_pairing_topic" should be set to false (or left out to default to false) for performance reasons.

I initially thought that there was actually no way for somebody who initialized 2 connections simultaneously to know which connection is which because they never knew an identifier for the connection. But this turns out to not be true, since the "url" field returned from new_connection encodes the pairing_topic inside it.
This PR just makes the pairing topic more accessible by having it in a different field in the response.

cc @KomodoPlatform/qa

[onur-ozkan]

@KomodoPlatform/qa Check the PR header.

[shamardy]

We’ve tagged @KomodoPlatform/gui in this PR, but at this stage, it’s primarily for the QA and documentation teams, as the GUI hasn’t begun work on WalletConnect yet.

[shamardy]

Please open a docs issue @mariocynicys

[shamardy]

keep hitting get_session till the user has established the session:

This should be done using the streaming interface as well but not currently, streaming interface for walletconnect is needed IMHO. We need an issue for this.

[smk762]

@KomodoPlatform/qa Check the PR header.

Please ping me directly and/or add QA tag to PR in future, as often I dont see this until I actually enter a PR thread to read.

[smk762]

Confirming output for wc_new_connection returns the pairing topic in response.

{
    "mmrpc": "2.0",
    "result": {
        "url": "wc:06f522fd6bc1515119f71d992017fd7d25f5ec2c0a6817c9c452890730b9e912@2?symKey=b738abf2ac12d354ba2ce38824fed36de201b91eecd3a5485dfcf13ea9023890&relay-protocol=irn&expiryTimestamp=1753324272",
        "pairing_topic": "06f522fd6bc1515119f71d992017fd7d25f5ec2c0a6817c9c452890730b9e912"
    },
    "id": null
}

This was successfully used in get_session with "with_pairing_topic": true for both ETH/MetaMask and Cosmos/Keplr activation.

Note: there are cases where the qr code scanning app rejects the request, and this is not apparent beyond the console logs like:

• from Keplr, when ETH is included in the connection request
  24 02:25:13, kdf_walletconnect:342] INFO [8bfe3063e927d40b6aa780ea0cb349d1dce0917a782ba491e5c57170d5e4b583] Inbound message payload={"id":448850916819713,"jsonrpc":"2.0","error":{"code":1,"message":"\"params.requiredNamespaces.eip155\" is not allowed"}}

• from bifrost, when tendermint is in the request
  kdf_walletconnect:342] INFO [ce3b8f80105f58e1312249e1efb5ffa934d1d51a09db2efb41bf31bc2ce11065] Inbound message payload={"id":448850818379008,"jsonrpc":"2.0","error":{"code":4001,"message":"Requested chains are not supported"}}

Though these errors have been returned, get_session response remains null. Ideally, it should return the same error as in the console so user is aware and has actionable info to overcome the error. Is this possible without converting these methods to task:: based?

[mariocynicys]

@smk762 aha i see.
yeah this is ofc possible without making the method task:: abased but will require us to store an error (last error) response so to flash it to the user on the next call.
which for that reason i would much prefer integrating this method into the task:: system we have to handle that on its own (+ we get free SSE streaming via that task-rpc).