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 was archived by the owner on Dec 13, 2021. It is now read-only.
Currently we have a Push server infrastructure that subscribes to topics received by a Bridge server as a third-party that provides a Webhook that will trigger notifications on the user's Wallet.
There is however certain payloads, more concretely Ethereum read JSON-RPC requests and WalletConnect session related JSON-RPC requests which shouldn't require to notify the user of the incoming requests.
We should only trigger these notifications whenever the user is required to sign/authenticate these requests from the Wallet side. Hence I would like to propose an additional parameter to the SocketMessage payloads that are to be received by the Bridge server.
This additional parameter would be named silent and it would be a boolean value with default to false in order to maintain backwards compatibility with previous iterations. For future versions, all payloads would have a value of true except for signing requests which in the case of Ethereum would be eth_sendTransaction, eth_signTransaction, eth_sign, eth_signTypedData and personal_sign.
Currently we have a Push server infrastructure that subscribes to topics received by a Bridge server as a third-party that provides a Webhook that will trigger notifications on the user's Wallet.
There is however certain payloads, more concretely Ethereum read JSON-RPC requests and WalletConnect session related JSON-RPC requests which shouldn't require to notify the user of the incoming requests.
We should only trigger these notifications whenever the user is required to sign/authenticate these requests from the Wallet side. Hence I would like to propose an additional parameter to the SocketMessage payloads that are to be received by the Bridge server.
This additional parameter would be named
silentand it would be abooleanvalue with default tofalsein order to maintain backwards compatibility with previous iterations. For future versions, all payloads would have a value oftrueexcept for signing requests which in the case of Ethereum would beeth_sendTransaction,eth_signTransaction,eth_sign,eth_signTypedDataandpersonal_sign.