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.
Walletconnect v1.0 uses non-standard socket implementation which needs to be handled effectively on following scenarios:
Low-end devices, like most Android devices in India
Devices with low-batteries
On sleep mode devices
Having multiple connections for each DApp is an inefficient way of handling sockets where optimization is essential.
Solution
Use the MQTT standard with QoS=2 instead of custom socket implementations: https://mqtt.org/
The bridge will work as MQTT broker and maintain only one connection per device.
Benefits for using MQTT over custom socket implementation:
Optimized for low-end devices and sleep mode
Single socket connection per client
Library/SDKs are available in different languages out of the box (no need to create the same custom socket implementation in each language). Less code, fewer bugs (in theory)
Message caching when devices are offline when QoS=2. No need to write custom queueing for each device at bridge side
Production ready
The text was updated successfully, but these errors were encountered:
We can't just break WalletConnect backward compatibility at this point in time and need to offer a migration path.
Perhaps we use the 2.0 initiative where pluggable transports are planned to do this change - but just changing it for 1.0 and breaking existing workflows is no option IMHO - perhaps @pedrouid has some ideas here.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Problem
Walletconnect v1.0 uses non-standard socket implementation which needs to be handled effectively on following scenarios:
Having multiple connections for each DApp is an inefficient way of handling sockets where optimization is essential.
Solution
Use the MQTT standard with
QoS=2
instead of custom socket implementations: https://mqtt.org/The bridge will work as MQTT broker and maintain only one connection per device.
Benefits for using MQTT over custom socket implementation:
QoS=2
. No need to write custom queueing for each device at bridge sideThe text was updated successfully, but these errors were encountered: