Skip to content
This repository has been archived by the owner on Dec 13, 2021. It is now read-only.

WCIP-13: Use MQTT standard for peer communication #13

Open
abhriyaroy opened this issue Dec 3, 2019 · 3 comments
Open

WCIP-13: Use MQTT standard for peer communication #13

abhriyaroy opened this issue Dec 3, 2019 · 3 comments

Comments

@abhriyaroy
Copy link

abhriyaroy commented Dec 3, 2019

Problem

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
@ligi
Copy link
Collaborator

ligi commented Dec 3, 2019

Thanks for the proposal - but as far as I see this WCIP needs more details like considerations on the upgrade path and backward compatibility.

@abhriyaroy
Copy link
Author

I am not sure how to go about it without losing backward compatibility, but this is a necessary change. So, I am open to comments.

Current version needs to fix this one way or another when users start to use walletconnect with multiple DApps at once.

@ligi
Copy link
Collaborator

ligi commented Dec 4, 2019

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 free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants