You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 13, 2021. It is now read-only.
Similar to subproviders normally used with web3-provider-engine and other libraries that handle web3 / ethereum providers. These signing modules can be stacked inside the WalletConnect SDK to handle incoming call requests.
The main different would be that instead of modularizing these modules by which JSON RPC methods they handle, they would be modularized by accounts. This way a wallet could expose its accounts and hook different signing modules to handle signing methods for each account.
This feature would be more easily introduced with the WalletConnect v2.0 protocol with the introduction of the DID-based session requests (#7). Where you could semantically describe which protocol is being used to sign the requests, therefore supporting multiple chains and even non-blockchain authentication methods. Yet it would also allow for different signing protocols within Ethereum, for example, this would allow for delegate key signing removing the requirement to transport requests to the Wallet’s device for a specific account, or even better allow the Wallet to generate a new key for message signing in-browser for state channels and hooking it up to a state channel signing module.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Similar to subproviders normally used with web3-provider-engine and other libraries that handle web3 / ethereum providers. These signing modules can be stacked inside the WalletConnect SDK to handle incoming call requests.
The main different would be that instead of modularizing these modules by which JSON RPC methods they handle, they would be modularized by accounts. This way a wallet could expose its accounts and hook different signing modules to handle signing methods for each account.
This feature would be more easily introduced with the WalletConnect v2.0 protocol with the introduction of the DID-based session requests (#7). Where you could semantically describe which protocol is being used to sign the requests, therefore supporting multiple chains and even non-blockchain authentication methods. Yet it would also allow for different signing protocols within Ethereum, for example, this would allow for delegate key signing removing the requirement to transport requests to the Wallet’s device for a specific account, or even better allow the Wallet to generate a new key for message signing in-browser for state channels and hooking it up to a state channel signing module.
The text was updated successfully, but these errors were encountered: