Why is nothing happening (there is no event and a transaction that needs to be signed)? I've reviewed a lot of the project's source code and didn't really understand what was wrong

Code:

Behavior:

Development environment:
"react-native": "0.70.6"
"@walletconnect/auth-client": "^2.0.2"
@walletconnect/react-native-compat": "^2.2.1"

Context

• Aligns with spec change: WalletConnect/walletconnect-docs#601
• A wallet receiving an auth_request needs the ability to look up which paired peer issued the request.
• Providing the pairingTopic as part of PendingRequest and emitting pairingTopic .on("auth_request", ...) allows the receiver to do so.

Implementation

• Adjust the onAuthRequest handler to write the topic parameter to the client.requests store and emit it for the auth_request event: https://github.com/WalletConnect/auth-client-js/blob/main/packages/auth-client/src/controllers/engine.ts#L335

If you install both auth-client and qrcode-modal, @walletconnect/types is set to v1.8, which causes:

Error: node_modules/@walletconnect/auth-client/dist/types/types/client.d.ts:2:10 - error TS2305: Module '"@walletconnect/types"' has no exported member 'ICore'

My workaround was to explicitly install @walletconnect/[email protected]

Resources

• Auth Spec
• Auth Client API

Critical Path

This is intended as an overview of critical path work to get to an alpha state with the JS Auth SDK, from which we can break out concrete and more detailed individual issues. The list may change and reorder as we see necessary during the development process.

• Set up AuthClient class
• Pull in @walletconnect/core
• Set up logging
• Set up AuthEngine and AuthEngine.init
• IAuthClient interfaces and types
• IAuthEngine interfaces and types
• Specify RPC method types
• Set up Relayer events handling
• Storage handling and storage key namespacing via Core.Store (e.g. pairing, pending_request, settled_request)
• #2
• #4
• Implement associated event handlers (on("auth_request",...), on("auth_response",...)
• #7
• Implement getters (AuthClient.getPendingRequests, AuthClient.getRequest)
• Implement expirer logic
• Update implementation to reflect these adjustments in spec once this is merged: WalletConnect/walletconnect-specs#104
• Implement metadata (#17)
• #15
• Handle existing pairing flow #22
• Implement initial validation logic (#18)
• Implement error codes according to spec
• Implement client.getPairings #36
• Implement client.disconnect #36
• Implement client.ping #40

Context

• Similarly to how Sign's session_proposal and session_request now use the Verify API's context, we need to implement the same for auth_request to be aligned with the spec.

References

• Specs PR: WalletConnect/walletconnect-docs#436
• Implementation PR for Core + SignClient integration: WalletConnect/walletconnect-monorepo#1921
• Follow-up PR for exposing in web3wallet: WalletConnect/walletconnect-monorepo#2211

After looking at the source code, I did not find the answer to this question

According to the documentation, I did not understand how to do this

I tried to substitute different parameters into the function and it didn't work out either

Hello. Have you plans to support auth for non-evm blockchains like Tron, Solana, BTC and etc?

• Create a pairing + URI as part of AuthClient.request
• Send wc_authRequest as part of AuthClient.request (i.e. this.sendRequest(pairingTopic, "wc_authRequest",...)). Can use dummy payload for now.
• Implement AuthClient.pair on responder side to process URI input and subscribe to pairing topic

Goals

• Requester can generate URI as part of AuthClient.request and return it, so it can be shared with the responder out-of-band.
• Responder can process a URI input and subscribe to the provided pairing topic
• Responder can receive the wc_authRequest issued by the requester via the pairing topic.
• We are able to validate this behaviour via the unit tests.

• Domain binding
• Support EIP-1271
• Pairing API integration - WalletConnect/walletconnect-monorepo#1477

Initial Requirements

• Allows us to run two demo clients side by side, one as requester (i.e. dapp) and one as responder (i.e. wallet)
• Can showcase user flow 1 from spec's user flows:
  • Full pairing + authentication (user flow 1)

Implementation

• We can leverage ethers.Wallet as the de facto wallet/external signer on the responder side.
  • Detailed implementation example from our example react wallet: https://github.com/WalletConnect/web-examples/blob/main/wallets/react-wallet-v2/src/lib/EIP155Lib.t

Followups

• Can showcase user flows 2 & 3 from spec's user flows:
  • existing pairing + auto-revalidate session from previous authentication request that is still valid (user flow 2)
  • existing pairing + expired session/previous auth request -> trigger fresh auth request on known pairing (user flow 3)

Steps

1. B constructs message to be signed from request and signs it. - Optional for now, i.e. we can just send a mock string like "signature" back at first. We still need to figure out how to best do the EIP-191 signing (most likely ethers.js)
2. B generates their own keyPair Y - i.e. const responderPubKey = await this.client.core.crypto.generateKeyPair()
3. B uses sendResult for auth_request on response topic with the TYPE_1 option, which generates shared symKey R via crypto.encode and encrypts the message with it - Example use of TYPE_1 here

Goals

• Responder can receive incoming auth request
• Responder can send a type 1 envelope response containing a (mock) signature

Describe the bug
Reported by user Moneta on Discord. When initializing a request from the dapp, the chainId is not updating the response received by the wallet.

SDK Version (if relevant)

• Client: JavaScript
• Version: @walletconnect/auth-client": "^2.0.0

To Reproduce
Steps to reproduce the behavior:

1. Clone the react-dapp-auth repo
2. Set the chainId to "eip155:5". Run locally
3. Connect to an auth wallet. Tested with Web3Wallet and Auth Wallet
4. The connect modal still includes chain information for mainnet (1)

Expected behavior
The chainId should be updated as per the request

Desktop (please complete the following information):

• OS: iOS
• Browser: Chrome
• Version: 108.0.5359.124

Additional context
If the chainId key is removed from the request object, the dapp will still connect to the wallets.

The Sign Client calls the pairing.create() function to create the pairing correctly with the expiration and proper subscriptions.

The Auth Client doesn't do this, and appears to attempt to create a pairing manually if a pairingTopic isn't provided.

Is this intentional?
I feel like if you would like to use the Auth API without the Sign API, it would be riddled with bugs due to this fact.

It's likely that not many people use JUST the Auth API though, so it hasn't been a prevalent issue.

Context

• Our sample auth dapp provides a testing ground for wallets integrating Auth.
• Once Verify API is part of the AuthClient, we should ensure it's exposed and configured properly to help the entire web3wallet team dogfood their implementations of Verify API.

Dependencies

• Depends on:
  • #72
  • Publishing updated version of @walletconnect/auth-client containing the Verify API changes

Related Resources

• ChainAgnostic/CAIPs#74
• https://eips.ethereum.org/EIPS/eip-191
• https://eips.ethereum.org/EIPS/eip-4361#example-message
• https://github.com/spruceid/siwe/blob/main/packages/siwe/lib/client.ts - SpruceID's SIWE (Sign in with Ethereum) client implementation

Steps

Responder (Client B)

• On incoming auth_request, the responder constructs a full CACAO object from the payload's PayloadParams (which is a partial CACAO object)
• Responder writes pending request with full CACAO object to persistence
• Responder constructs a EIP-4361 message
  • How spruceID's SIWE client handles this for reference: https://github.com/spruceid/siwe/blob/main/packages/siwe/lib/client.ts#L105
• Responder emits auth_request event via client.emit with the ID of the pending request and previously constructed EIP-4361 message as arguments, i.e. {id: number, message: string}
• (Outside of the AuthClient: Implementing wallet performs EIP-191 signing of the provided message (e.g. via signer.signMessage)
• Implementing wallet calls authClient.respond with the ID of the pending request and the signature wrapped as a CacaoSignature

Requester (Client A)

• Requester receives full Cacao object ({"header": CacaoHeader, "payload": CacaoPayload, "signature": CacaoSignature}) as payload via result call for wc_authRequest
• Reconstructs the full EIP-4361 message from the payload
• Validates the signature via utils.verifyMessage
• Emits auth_response event via client.emit with either the full Cacao object or an error, depending on validation result.

https://github.com/WalletConnect/auth-client-js/blob/main/packages/auth-client/src/controllers/engine.ts

The current implementation request function will send two requests if the provided topic is a known pairing.

Is this intentional?
It feels redundant.