WalletConnect integration

I cant seem to change the node used for the bridge, not sure if its a WalletConnect thing though. Initially used WC while connected to the HC1 public node but now trying to use the embedded in Syrius but HC1 seems to be the only one available to the bridge.

I noticed whichever address is selected in Syrius is reflected at the bridge app but should the bridge node update in the same way?

The bridge can’t use the embedded node because it can’t connect to it. The embedded node is running on your computer (localhost) and the bridge cannot connect to it for obvious security reasons (nobody should be able to access your internal network or connect to your computer from the Internet).

Since you’re not connected to a public node, the bridge uses a default public node to connect to.

1 Like

I’m not sure if this is correct.

explorer.zenon.network can connect to locahost nodes.

Only if you load it via http otherwise it throws the following error:

Mixed Content: The page at 'https://explorer.zenon.network/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint

I started getting this error when opening the Syrius that has WalletConnect. Can’t do anything after this, it’s just a blank screen showing the error after the start up animation.

Syrius with no WalletConnect works fine.

I’ll check.

@vilkris I’ve added persistent logging to pinpoint the error. Please download the latest build.

Trying to connect the latest syrius build from yesterday to walletconnect and get the following (see video). I cannot connect the two. Does not seem to produce an error. I’m running this on windows 10.

This is the release I’m testing

I’m on it.

@0x3639 can you check now please? Here is the latest release.

1 Like

Thank you for voting me!

I’ve created two payout phases (Phase 1/1 for the first project and Phase 1/2 for the second one). I’ll apply with Phase 2/2 for the second project after all bugs are fixed & feedback is properly implemented.

3 Likes

I can report this upgrade fixed the issue I was experiencing.

1 Like

I think you applied for phase 1 & 2. I just approved Phase 1

1 Like

After debugging this issue it turned out to be an obscure bug in the Shared Preferences library that the WallectConnect library is dependent on.

My shared preferences json file was corrupted and the shared prefs library could not read it.

My computer crashed unexpectedly yesterday while I had syrius running which likely caused the file to get corrupted.

The problem was resolved by removing the shared prefs json file.

3 Likes

New improvement: programmatically display the WalletConnect tab based on the availability of the projectId

1 Like

Update:

I just came across this: “think of a projectId as a public identifier”.

I think we can safely assign the WcProjectId with the actual String provided by @0x3639

I’ll make the necessary changes.

Is there a way for the WalletConnect integration to seamlessly sign messages without any copy/pasting? I understand that a signature has to be sent back to the dapp.

You don’t want this feature: a malicious dApp can trick you signing transactions and broadcast them on its own. The user must approve every action, including znn_info.

What do you want the user to sign?

If you want to sign account-blocks and broadcast them, use znn_send.

The dApp can only request certain actions that must be approved by the user inside Syrius.

1 Like

What’s the UX for znn_sign?

  1. App requests message to be signed, calls znn_sign
  2. Syrius is notified, displays signing prompt to user (Accept/Deny)
  3. User accepts, WC submits signed data back to the app

Is this right?

Yes. This is how it works. Test it by yourself.

1 Like

I’m going to integrate WalletConnect into the Syrius Mobile Wallet.

@aliencoder any special requirements for mobile? I see that the desktop implementation works flawlessly.

8 Likes

So key. Will enable us to market to mobile audiences.

1 Like