zenon-network / syrius Goto Github PK

After installing flutter successfully and setting up linux environment according to official documentation, still get the following error when I run fluttter build linux

💪 Building with sound null safety 💪

No Linux desktop project configured. See
https://docs.flutter.dev/desktop#add-desktop-support-to-an-existing-flutter
-app to learn about adding Linux support to a project.

This was reported by George when he was consolidating assets to one address.
Creating a ticket in order to gather community feedback.

The example he provided:

• he sent 1000 PP (confirmed via explorer)
• the notification informed him that he sent 1000 ZNN
• Wallet: Syrius v0.0.7
• did not attempt multiple times

Description

There is an issue in the validation process when editing an already added node in the Syrius application. The inputValidators.node function is correctly invoked when adding a new node, but this regex control can be bypassed during the direct editing of an existing node.

Details

The issue is observed in the following widget structure:

Widget _getNodeSelectionExpandableChild() {
  return Column(
    children: [
      _getNodeTiles(),
      _getConfirmNodeSelectionButton(),
    ],
  );
}

It appears that the intended input validation is not being triggered in the edit flow. The related code snippet where validation is expected in node_management.dart:

Expanded(
  child: SettingsNode(
    key: ValueKey(node),
    node: node,
    onNodePressed: (value) {
      setState(() {
        _selectedNode = value;
      });
    },
    onChangedOrDeletedNode: () {
      setState(() {});
    },
    currentNode: _selectedNodeConfirmed,
  ),
),

However, I have not been able to locate the specific widget with the edit icon that is supposed to invoke the inputValidators.node during the edit flow.

Expected Behavior

When editing an already added node, the input should be validated through the same regex as used when adding a new node.

Actual Behavior

The regex validation is being bypassed, allowing for invalid input during node editing.

Steps to Reproduce

1. Add a new node with valid input, triggering the regex validation.
2. Edit the added node and input an invalid address (i.e excluding the port).
3. Observe that the invalid input is accepted without triggering the regex validation.

Additional Information

• What the input validator looks like in input_validators.dart:

  static String? node(String? node) {
    if (node != null &&
        RegExp(r'^(wss?://)([0-9]{1,3}(?:.[0-9]{1,3}){3}|[^/]+):([0-9]{1,5})$')
            .hasMatch(node)) {
      return null;
    }
    return 'Invalid Node';
  }

• Syrius version: Latest

My understanding is that this input validation is checked because znnd out of the box is using those ports. However, I think it's a better user experience to manually auto-complete the node address, as it's currently the case when using explorer.zenon.network. In the explorer, I just type "https://node.atsocy.com" and it automatically adds the :35997 port. It seems we have 35997 for HTTP, and 35998 for websocket, couldn't we do the same thing inside syrius and autocomplete 35998?

Describe the bug
After updating to v0.2.0 I get a white screen on syrius and nothing loads
Same happens with v0.2.1

To Reproduce
Steps to reproduce the behavior:

1. Launch syrius

Expected behavior
Syrius to launch

Actual behavior
White screen

Workaround
None.

Screenshots

Desktop (please complete the following information):

• OS: windows 11
• Syrius Version: 0.2.0 and 0.2.1
• Commit hash:

Additional context
Add any other context about the problem here.

Bounty program

• Zenon Address:

Pillar owners have no easy way of filtering phases that needs voting. Currently, you need to go hunt for the “phase needs voting” tag. The voting opened filter only works for projects.

When the user moves the mouse on the Seed Phrase Enter Screen in Syrius 0.0.7 the program will close.
This does not occur when the fields are blank, but as soon as a word is typed in and the mouse is moved the crash will occur.

This has occurred on a PC running Windows 11 Pro, Version: 22H2, Build: 22621.2134

This bug prevented the restoration of the wallet.
The workaround was to use a previous Version of Syrius (0.0.6) to restore the wallet.

Describe the Feature
Would be great to have a flatpak build for Syrius, and have it on Flathub.

The request is based on making it available to several linux users and all dependencies are baked in to prevent users from getting errors as there are several linux distros out there.

Describe the bug
Disabling the auto-receiver and rejecting to receive a pending transaction with a Ledger causes the auto-receiver to stop working.

To Reproduce
Steps to reproduce the behavior:

1. Start Syrius with a Hardware Wallet
2. Disable auto-receive feature
3. Goto Transfer
4. Manually receive a pending transaction
5. Reject receive confirmation on the Ledger
6. Enable auto-receive feature or manually receive the pending transaction again

Expected behavior
The pending transaction is either automatically received or manually after accepting the receive confirmation on the ledger.

Actual behavior
The auto-receiver does not automatically receive the pending transaction and manually does nothing.

Desktop (please complete the following information):

• OS: Windows
• Syrius Version: v0.2.0-rc.0

Describe the bug
After resetting and importing a different private key, the previous WC pairing and session are still active.

To Reproduce
Steps to reproduce the behavior:

1. Use WC to create a pairing and acknowledged session.
2. Go to Settings > Wallet Options > Reset Wallet
3. Import a different seed
4. Check that the pairing is active
5. Connected dApp frontend reacts to address 1/address 2 wallet changes.

Expected behavior
The pairing should have been deleted.

Actual behavior
Pairing seems to still be active.

Workaround
If I reset the wallet and import the previously used seed that was used to create the pairing, the pairing is still there. However, it seems to not work anymore in the dApp.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: MacOS Big Sur v11.7.10
• Syrius Version: 0.2.0-rc.6
• Commit hash: 720f28d

Additional context
As I was going through the test cases, I deleted cache first, checked that pairing was deleted correctly. Then, I created a new pairing and resetted the wallet.

Bounty program

• Zenon Address: z1qq3yu9ra3fxpp2z6hckn0r3efr4rcrmpjatlc6

The disable auto-receive feature (see #46) has recently been introduced and to maintain compatibility with previous versions, the auto-receive feature has been kept enabled by default.

What’s the problem?
The auto-receive will be enabled whenever you initialize or reset your wallet. This means that it is possible for the wallet to automatically start receiving pending transactions in the time between starting syrius and disabling the auto-receive feature.

The feature to disable the auto-receive is a great function and it's worth to prevent auto-receive on initialization, but enabling privacy by default would probably cause a lot of friction.

How do we fix this?
Firstly, the connection to the node has to be delayed until confirmed on the onboard node-management screen. This has recently been solved in the following PR.

Secondly, present the user with the option to disable the auto-receive feature while onboarding before a connection to the node is confrimed.

The most logical location for this option would be on the onboard node-management screen.

With the Ledger support for the CLI finished, the Ledger implementation for Syrius can begin.

Much of the groundwork has already been done during the implementation of the CLI. The implementation for syrius is mainly concerned with UI rather than communication with the Ledger device. The later part has already been taken care of by the znn_sdk_dart, ledger_ffi_rs and znn_ledger_dart libraries.

The total work can be divided into the following parts.

Wallet abstraction

Replace the specific KeyFile wallet implementation with the wallet abstraction from znn_sdk_dart v0.0.6.

Backup wallet

Syrius has some features that are specific to the KeyFile wallet. These features are Backup and Dump Mnemonic. Obviously these features cannot be implemented when using a Ledger wallet. Therefor the features Backup and Dump Mnemonic will be disbaled in the UI when using a Ledger wallet.

Signing arbitrary message

The sign feature is not yet supported by the Ledger Embedded App. The features Sign and Sign File will not be disabled in the UI, but will raise an UnsupportedError exception by the underlying LedgerWalletAccount implementation and display the message "Signing an arbitrary message is not supported." to the user.

Hive DB

The Hive DB uses the private key as the cipherkey. This implementation needs to be harmonized to always use syrius's password as the cipherkey instead of the private key.

This implementation change has three implications:

1. When the password is changed the Hive DB has to be copied and recreated with the new cipherkey.
2. If the user forgets their password then the Hive DB can't be opened anymore and all history is lost and needs to be reset. Note: this behaviour is similair to the Ledger Live application.
3. Need to add migration code to convert the existing privatekey cipherkeys into password cipherkeys.

Onboarding UI

The onboarding workflow when using a Ledger Wallet consists out of the following steps.

1. Connect device
2. Create password
3. Node management
4. Access wallet

The Hardware wallet workflow only differs on step 1 compared to the Create wallet workflow.

When the device is conencted in step 1 it will retrieve the primary address, ask for confirmation and initialize Syrius to the address.

Although not strictly necessary Syrius will use the address to check and validate the same Ledger device is used when signing transactions.

The Ledger device won't be necessary to open the wallet once the wallet is initialize. The device will only be required when a transaction needs to be signed.

A file will be used in similair way as the KeyFile to store the password together with an indication whether the wallet is a hardware or a KeyFile wallet.

Signing transaction UI

When using a Ledger wallet a dialog box will appear whenever Syrius needs to sign a transaction. The dialog box will handle all fault cases and guide the user to interact with the Ledger device in order to accept or reject the transaction.

Fault cases include:

• Connect/unlock device
• Open Zenon app
• Invalid public key (does not match with initialized address)
• Unexpected errors

Adding new address

When using a Ledger wallet adding a new address will ask for confirmation on the Ledger device.

Describe the bug
When you activate a sentinel in syrius and then revoke it, syrius still shows the sentinel as still active.

To Reproduce
Steps to reproduce the behavior:

1. Create sentinel in syrius
2. Revoke sentinel in syrius
3. Try to recreate a sentinel in syrius on the same address
4. Syrius returns "Sentinel detected on this address"

RPC returns false with embedded.sentinel.getByOwner

curl -X POST https://my.hc1node.com:35997 -H 'Content-Type: application/json' -d '{"jsonrpc": "2.0", "id": 4, "method": "embedded.sentinel.getByOwner", "params": ["z1qps9rgvgmtu9vsukdek2uhwye0t5zpcez4hju5"]}'

Expected behavior
User should be able to create a sentinel on the address

Workaround
Move funds to a different address and enable Sentinel.

Screenshots

Desktop (please complete the following information):

• OS: Windows 10
• Syrius Version: v0.1.1
• Commit hash

Additional context
Potential source of issue

if (snapshot.hasData) {
  return _getAlreadyCreatedSentinelBody(context);
} else {
  return _getCreateSentinelBody(context);
}

Describe the bug
Coins list having some strange GUI bug
bug.webm

To Reproduce
Steps to reproduce the behavior:

Go to 'Tokens'
Scroll under Token map.

Workaround
None

Screenshots
See attached video recording.

Desktop (please complete the following information):

OS: Fedora 39
Syrius Version: v0.2.0-rc.6
Commit hash:

Bounty program

Zenon Address: z1qraerrq4w6sy775md2wq4tsxvfm02q3v9xqdrn

Describe the bug
Unable to transact when starting Syrius 0.2.0 the first time when using my existing wallet.

To Reproduce
Steps to reproduce the behavior:

1. Restore backup of existing wallet by copying to znn directory
2. Start Syrius 0.2.0
3. Unlock wallet
4. Send transaction

Expected behavior
A notification message indicating that the transaction has been sent.

Actual behavior
Send button keeps spinning.

Workaround
Lock/unlock wallet or restart Syrius.

Desktop (please complete the following information):

• OS: Windows 10
• Syrius Version 0.2.0-rc.0
• Address: z1qqa8fgqmy6g0k9xujudeeyarqdv6j7fynrjr88

Is your feature request related to a problem? Please describe.
When Syrius establishes a connection with a WalletConnect app, it passes some data to the app automatically.
This data is defined as part of the wallet's namespace.

Currently, Syrius passes the following on session approval:

• accounts: list of accounts with the following format zenon:1:<address label>
• methods: znn_sign, znn_send, znn_info
• events: chainIdChange, addressChange

I've encountered three issues with the current implementation.

1. _generateAccount() accepts a chainId but doesn't apply it correctly
2. _getWalletAccounts() creates a list of accounts based on kAddressLabelMap instead of kDefaultAddressList.
3. There are four occurrences of chainId: 'zenon:1' in wallet_connect_service.dart.
   The numerical value should be dynamic.

Describe the solution you'd like
Addressing the points above:

1. It's a simple change to accurately inform a webapp that the wallet is indeed connected to mainnet or not.

2. This design decision requires a webapp to submit an additional znn_info request to the wallet in order to gather any information about Syrius accounts, creating friction for users.
   Consider the EVM happy path: wallets pass accurate chain:chainId:address account information upon establishing a session without requiring any additional user interaction.
   Also, we can/should limit the amount of data that Syrius exposes to webapps. Webapps only need to know the current activate address.

3. The numerical value should reflect the wallet's currently selected chainId, not a hardcoded value for mainnet.
   This will inform webapps without having to call znn_info for the same data.

Describe alternatives you've considered
2. If there's a privacy concern for passing accurate account information, please address it in this ticket.

Not a very reassuring message to see upon starting the wallet
v0.1.0-alphanet

Describe the bug
Top Navigation "Dashboard" Highlight Box overlaps the rounded edge of the top nav.

To Reproduce
Steps to reproduce the behavior:

1. Click "Dashboard" in the top nav and zoom into the highlight box

Expected behavior
Highlight box should not overlap the rounded edge.

Workaround
None

Screenshots

Desktop (please complete the following information):

• OS: MacOS
• Syrius Version https://github.com/zenon-network/syrius/releases/tag/v0.2.0-rc.2
• Commit hash

Additional context
NA

Bounty program

• Zenon Address: z1qrztagl9rukq3ltdflnvg4zrvpfp84mydfejk9

Describe the bug
When you disconnect your Leger device and plug it into a new USB port the ledger device cannot be found by syrius on a macOS.

To Reproduce
Steps to reproduce the behavior:

1. Plug in the Ledger and active the app
2. Open syrius and the device is found
3. Close syrius and unplug the ledger device
4. Plug the ledger device into a new USB port and activate the app
5. Open syrius and perform any action that required the ledger

Expected behavior
I would expect syrius to find the ledger device on anyUSB port.

Workaround
Reset the wallet in settings. Open and close syrius. Scan for the ledger and connect the hardware wallet. Proceed through the setup prompts and the device is found.

Screenshots

Desktop (please complete the following information):

• OS: macOS
• Syrius Version: https://github.com/zenon-network/syrius/releases/tag/v0.2.0-rc.2
• Commit hash

Additional context
It appears the macOS creates a new UID for the ledger when it is plugged into a new port. I believe syrius assumes the UID does not change once it's connected.

I evaluated all devices with diskutil info -all

Ledger in Port 1 = disk3s1
The UUID for disk3s1 was C779D85A-0260-4B39-BC37-77B65C0E839D

Ledger in Port 2 = disk3s1s1
The UUID for disk3s1s1 was 8332C4C2-7563-4F36-90D8-C937085E1701

Bounty program

• Zenon Address: z1qrztagl9rukq3ltdflnvg4zrvpfp84mydfejk9

Is your feature request related to a problem? Please describe.
I want to re-order the Settings card, relocating some widgets to the Info tab.
The goal is to remove clutter from Settings, improve navigation and visibility.
Node Management is clunky to access and should be made more prominent.

Describe the solution you'd like
Settings: General and Peers >> Info card

"The ordering could be for example Addresses, Account-chain Stats, Security, Node Management, Display (vertically expanded), and then Wallet Options and Backup as small cards" --Vilkris

This issue was migrated from HyperCore-One and originally issued by @sol-znn on May 25, 2023

We are getting spammed with shitpost proposal. Let's please make the submitter pay for this fun. Can we increase the submission cost to 10 ZNN until we find a better solution?

https://forum.zenon.org/t/holo-network-amm-better/246

Request for feedback from the community
https://forum.zenon.org/t/increase-znn-proposal-submission-from-1-znn-to-10-znn-nonrefundable/247

S Y R I US v0.2.0-rc.3 Does not work on Fedora 39.

1. Do get error: libayatana-appindicator3.so.1: cannot open shared object file: No such file or directory

Expected behavior
Should work, works just fine on Ubuntu 22.04

Actual behavior
Does not start.

Desktop (please complete the following information):

• OS: Fedora 39, kernel 6.7
• Syrius Version: 0.2.0-rc.3

Bounty program

• Zenon Address:z1qraerrq4w6sy775md2wq4tsxvfm02q3v9xqdrn

Describe the bug
The auto-receiver creates two identical notifications when it fails to receive a tx.

To Reproduce

1. Connect to a node and set the correct chain id
2. Disable the auto-receiver
3. Send a tx to a derived address
4. Set the chain id incorrectly (creating a chain id mismatch)
5. Enable the auto-receiver

Expected behavior
The auto-receiver should create one notification for each failed transaction.

Actual behavior
The auto-receiver creates two identical notifications for each failed transaction.

Screenshots

Desktop (please complete the following information):

• OS: All
• Syrius Version: v0.2.0-rc.3

Additional context
This bug could be related to this issue were sometimes no error notifications are shown.

Description
After upgrading to 0.2.0 - on every launch of SYRIUS the node doesn't successfully initialize and shows a Zenon SDK exception error. The embedded node doesn't commence/continue its synch.

Steps to Reproduce
Steps to reproduce the behavior: Launch SYRIUS 0.2.0 with the embedded node the last previously used node.

Expected behavior
The embedded node should start synching automatically

Actual behavior
On every launch of SYRIUS the node doesn't successfully initialize and shows a Zenon SDK exception error. The embedded node doesn't commence/continue its synch.

Workaround
On the node selection screen, press confirm on the already selected Embedded node to resolve the issue. It's not necessary to switch to a public node and back to the embedded.

Screenshots

Desktop (please complete the following information):

• OS: Windows 11 Pro Version 10.0.22631 Build 22631
• Syrius Version: 0.2.0
• Commit hash: 77e082e

Additional context
Multiple users have advised they are experiencing this issue on Telegram

Bounty program

• Zenon Address: Donate to AZ if applicable

A user recently tried to initiate a P2P swap. Here is the transaction

https://zenonhub.io/explorer/transaction/c5dc7308c223973508b4b1cdd15d4fd7bd264abd547439f0d5ac83ba6f76183f

After 30 minutes syrius has not produced a Deposit ID. Here is what the user is seeing.

1. Can we get the Deposit ID from the .json data?
2. What additional information can we provide to trouble shoot this?

Describe the bug
A pending transaction was auto received during the initial flow when reinitializing a wallet.

To Reproduce
Steps to reproduce the behavior:

1. Disable auto-receive. Receive a pending transaction.
2. Reset and reinitialize the wallet.
3. At the Node Management screen, the transaction will be automatically received (check screenshot).

Expected behavior
Transaction should remain unreceived until the user confirms his settings by clicking 'continue'. Alternatively, start with the wallet options to auto-receive disabled, and process then transaction when user checks the auto-receive setting checkbox.

Actual behavior
As soon as the Node Management screen appears, a notification with 'Transaction received on Address 1' also appears.

Workaround
None found.

Screenshots

Desktop (please complete the following information):

• OS: Windows 11 Enterprise Eval 22H2
• Syrius Version: 0.2.0-rc.3
• Commit hash: ba8e838

Additional context
is a connection to synced znnd not needed to receive a transaction? I ask because this was processed when 'embedded node' was the default selection. Unless syrius has some sort of cache for the previously used node.zenonhub.io remote node, the transaction should have not been received.

Bounty program

• Zenon Address: z1qq3yu9ra3fxpp2z6hckn0r3efr4rcrmpjatlc6

Describe the bug
Notifications are not displayed in the az project phase screen. For example when voting a phase.

To Reproduce
Steps to reproduce the behavior:

1. Go to AZ tab
2. Click on a project with a 'phase needs voting' tag
3. Vote on the phase

Expected behavior
A notification indicating whether the account-block was successfully published or not.
Or in case of a ledger wallet a notification asking for confirmation.

Actual behavior
Notifications are created but remain hidden by the phase dialog.

Workaround
The notifications are displayed when the phase dialog is closed.

Desktop (please complete the following information):

• OS: Windows 10
• Syrius Version: v0.2.1
• Commit hash: 7e9c440f7e5e368efbade77ca900efa1219af0d4

Describe the bug
ZTS coins are flickering while scrolling under "token map"

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Tokens'
2. Scroll under Token map.
   flickering.webm

Expected behavior
Should not flicker.

Actual behavior
Flickering

Workaround
None

Screenshots
See attached video recording.

Desktop (please complete the following information):

• OS: Fedora 39
• Syrius Version: v0.2.0-rc.4
• Commit hash:

Bounty program

• Zenon Address: z1qraerrq4w6sy775md2wq4tsxvfm02q3v9xqdrn

Describe the bug
When testing the latest Syrius v0.2.0-rc.4 #5 I added (2) new addresses and rejected them from the ledger device (per the requested test case).

syrius produced the following error message in the address window Ledger.Error.responseError(statusWord: deny and the message could not be dismissed. In order to dismiss the error the user needs to navigate to a different tab and then navicate back.

To Reproduce
Steps to reproduce the behavior:

1. Connect Ledger Hardware device, unlock it, open the Zenon App
2. Add two new wallet addresses in syrius. It instructs you to approve the addresses in the Ledger device
3. REJECT the creation of the new wallets in the Ledger.
4. syrius returns an error message Ledger.Error.responseError(statusWord: deny in the wallet dialogue box

Expected behavior
Produce a message in syrius indicating the wallet creation was rejected with the ability to dismiss the message without navigating away. We should consider making the error human readable.

Actual behavior
syrius returns an error message Ledger.Error.responseError(statusWord: deny in the wallet dialogue box that cannot be dismissed.

Workaround
Navigate to a different tab in the top nav and then back to the settings tab and the waller creation error is removed.

Screenshots
NA

Desktop (please complete the following information):

• OS: macOS M1
• Syrius Version: Syrius v0.2.0-rc.4 #
• Commit hash:

Additional context
NA

Bounty program

• Zenon Address: z1qrztagl9rukq3ltdflnvg4zrvpfp84mydfejk9

Describe the bug
In the "Confirm your seed - drag & drop the words in the correct order" page, when setting up a new wallet. Once you've dragged the word into a slot, the user is unable to deselect it.

To Reproduce

1. Delete .znn folder
2. Launch Syrius
3. Select Create wallet
4. Confirm checkboxes and select continue
5. Drag & drop a word in the incorrect order

Expected behavior
The word can be dragged to another empty word slot or will be removed after verifying.

Actual behavior
The incorrect word cannot be removed and is not removed after verifying.

Desktop
Syrius version: v0.1.0
OS: any
Commit hash: 267950f

Workaround
After verifying the seed, the incorrect word will become available again in the unassigned word list. The incorrect word can be overwritten by dragging & dropping another unassigned word over it.

Perhaps you’ve noticed that recently some $PP have been transferred to your address.

This is an interesting and fun experiment, except when coupled with Syrius’ autoreceive feature it could be used for tracking addresses owned by the same user.

What’s the problem?
When a transaction is sent to an address, that transaction remains unreceived until the recipient decides to receive it.

However, the recipient might not get a chance to make that decision. When syrius is opened, as soon as it connects to a synced node, it starts scanning all addresses in the wallet and starts receiving all the unreceived transactions, without giving the user any options.

Similar to how dust attacks work on Bitcoin, this situation could provide a way to track which addresses belong to the same user.

How do we fix this?
The solution is quite straightforward, however this doesn’t mean it’s just as easy to implement as it is to articulate it.

Syrius should provide the user with the option to disable the auto-receiver and a way for the user to manually decide which transaction to be received.

Its bothered me for a while that characters of seedphrase and passwords are visible while typing them into syrius. This seems like a glaring security risk if anyone has remote access to your system or are someway able to invade your privacy during wallet imports or signing in.
Almost every other service for password input generally hides these characters from view during input, is there some reason why you can see the last inputted character in syrius? seems like an easy fix to remedy to increase security and make users feel confident and protected from prying eyes while inputting their most sensitive data.

Describe the bug
WalletConnect pairings/sessions are not deleted when deleting the cache or resetting the wallet.

To Reproduce
Steps to reproduce the behavior:

1. Start Syrius
2. Setup a valid WC pairing
3. Goto settings
4. Scroll down to Wallet Options/Reset Wallet
5. Click on Delete Cache/Reset Wallet
6. Start or reinitialize Syrius
7. See WC pairing are not deleted

Expected behavior
All WalletConnect pairinigs/sessions are deleted.

Actual behavior
Existing WalletConnect pairinigs/sessions are not deleted.

Desktop (please complete the following information):

• OS: All
• Syrius Version: v0.2.0-rc.1
• Commit hash: c875636

Description
The syrius window is not visible on start if syrius was previously shut down while minimized.

Steps to reproduce (Windows)

1. Launch syrius
2. Minimize window
3. Right click on the syrius icon in the taskbar and close syrius
4. Launch syrius again

Expected behaviour
syrius window is visible.

Actual behaviour
syrius window is not visible.

Device info
Windows 10

Version
0.0.5

Describe the bug
I recently upgraded to syrius v0.2.0. I connected syrius to the bridge (https://bridge.mainnet.zenon.community/) without any issues. I realized I connected on the wrong wallet. I tried to change the wallet in syrius to a different wallet without disconnecting / reconnecting walletconnect. After doing that balances under bridge history were not accurate.

I then disconnected and tried to reconnect and got the following error in the console and walletconnnect timed out and never connected.

index.ts:5 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://verify.walletconnect.com') does not match the recipient window's origin ('https://bridge.mainnet.zenon.community').

To Reproduce
Steps to reproduce the behavior:

1. Upgrade to syrius 0.2.0
2. connect to mainnet bridge with walletconnect
3. change wallet addresses without disconnecting / reconnecting the wallet
4. disconnect from the bridge
5. reconnect to the bridge
6. received the following error

index.ts:5 Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://verify.walletconnect.com') does not match the recipient window's origin ('https://bridge.mainnet.zenon.community').

I tried this in Brave without shields up and chrome. I tried to clear cache in Chrome. In Chrome I tried to : Right click > Inspect Element > Application tab > Storage > Clear site data

Expected behavior
Connect to syrius to the bridge

Actual behavior
Walletconnect times out and does not connect syrius with the bridge.

Workaround
None

Screenshots
NA

Desktop (please complete the following information):

• OS: Windows 10
• Syrius Version: 0.2.0
• Commit hash:

Additional context
NA
Add any other context about the problem here.

Bounty program

• Zenon Address:

Is your feature request related to a problem? Please describe.
Path: Syrius > AZ tab > Donate
Users require a ZNN balance to be able to donate funds to the mothership.
This doesn't consider addresses with 0 ZNN / >0 QSR

Describe the solution you'd like
We can change the requirement to an OR operator:
account has >0 ZNN or >0 QSR
File: https://github.com/zenon-network/syrius/blob/develop/lib/widgets/modular_widgets/accelerator_widgets/accelerator_donation_stepper.dart

This issue was migrated from HyperCore-One and originally issued by @sol-znn on Jun 3, 2023

For an an active pillar when you navigate to the "Pillars" tab and then find your active pillar, the time to revoke in the red box wraps unexpectedly.

Describe the bug
The address input field of the receive widget is positioned differently in expanded mode compared to normal mode.

To Reproduce

1. Launch Syrius
2. Select Transfer tab
3. Expand receive widget

Expected behavior
The address input field is positioned above the amount input field in both expanded and normal mode.

Actual behavior
The address input field is positioned below the amount input field in exapnded mode and above in normal mode.

Desktop
Syrius version: v0.1.0
OS: any
Commit hash: 267950f

Describe the bug
Users are currently able to add "x" addresses in the "Options" tab, but are unable to remove them unless they clear the cache of the wallet.

These addresses will also show up in the "Dashboard" tab, which the user is unable to hide if they want.

To Reproduce
Steps to reproduce the behavior:

1. Go to "Options" tab
2. Click on 'add x addresses'
3. See error

Expected behavior
The ability to remove/hide addresses at will.

Actual behavior
Missing feature.

Workaround
Clearing the cache of the wallet.

Screenshots
"Options" tab

"Dashboard" tab

Desktop (please complete the following information):

• OS: Windows 10
• Syrius Version: 0.1.0
• Commit hash: 267950f

Additional context
N/A

Bounty program
N/A

I saw a vague error in the Flutter build logs when sourcing the ZNN SDK from disk.
The build process works well if the package is sourced from Github, but fails otherwise.

Creating this ticket to track the issue. Should confirm behavior on Linux, as well.

Repro
Update pubspec.yaml reference for znn_sdk_dart

  znn_sdk_dart:
    path:
      ../znn_sdk_dart

Current solution: syrius/windows/CMakeLists.txt

# Leveraging flutter to identify dependency locations
file(STRINGS "${SYRIUS_PROJECT_DIRECTORY}/.dart_tool/package_config.json"
  ZNN_SDK_DART_PATH REGEX "(rootUri).*(znn_sdk_dart).*(\/|)\"," )

string(REPLACE "\"rootUri\": \"" "" ZNN_SDK_DART_PATH "${ZNN_SDK_DART_PATH}")
string(REPLACE "file:\/\/\/" "" ZNN_SDK_DART_PATH "${ZNN_SDK_DART_PATH}")
string(REPLACE "/\"," "" ZNN_SDK_DART_PATH "${ZNN_SDK_DART_PATH}")
string(REPLACE "\"," "" ZNN_SDK_DART_PATH "${ZNN_SDK_DART_PATH}")
string(STRIP "${ZNN_SDK_DART_PATH}" ZNN_SDK_DART_PATH)

I tried to combine some of these REPLACE lines with more complex regex but cmake wasn't producing the expected result.

Describe the bug
When connecting to a node that has a different chain ID than the one that is set for Syrius, a Chain identifier mismatch dialog is shown prompting the user to either Cancel or Proceed anyway. When pressing Cancel the connection to the new node is still established. The Node Management list then shows that Syrius is still connected to the previously selected node when it's not.

To Reproduce
Precondition 1: you need access to two different nodes that are not the Embedded Node.

1. Navigate to Settings > Node Management
2. Make sure you're connected to a node that is not the Embedded Node
3. Open Client chain identifier selection and set the identifier to a random number, like 999 for example.
4. In Node selection connect to another node that is not the Embedded Node
5. You should see the Chain identifier mismatch popup. Press Cancel.

Expected behavior
The connection to the node is not established.

Actual behavior
The connection to the node is established. On the UI this can be seen by the momentum height card updating.

Desktop

• Syrius version: v0.0.6
• OS: any
• Commit hash: hypercore-one@c996cc4

This issue was migrated from HyperCore-One and originally issued by @vilkris4 on May 7, 2023

Describe the bug
Upon launching Syrius, users may encounter a situation that prevents them from unlocking their wallet.
The remaining unlock attempts count does not decrement and no error is displayed.

To Reproduce

1. Launch Syrius
2. Attempt to unlock the wallet

Expected behavior
Correct password: the wallet unlocks
Incorrect password: the remaining attempts count decrements

Actual behavior
Nothing happens, preventing users from accessing their keystore.

Desktop

• Syrius version: v0.1.0
• OS: any
• Commit hash: 267950f

Workaround
Users have discovered that they can unlock their wallets if they disable network connectivity before launching Syrius.
This may be related to an unhandled result when WalletConnect is initialized or if Syrius cannot establish a connection with its default node.

Note
One user informed me that they corrected their wallet state after they switched from wss://secure.deeznnodez.com:35998 to a different node.
This aforementioned node was recently taken offline.

Describe the bug
When fusing plasma, entering a large amount causes a FormatException: Positive input exceeds the limit of integer.

To Reproduce

1. Launch Syrius
2. Navigate to the Plasma tab
3. Enter 11111111111111111 as the amount

Expected behavior
The amount can be entered without causing a FormatException.

Actual behavior
The amount causes a FormatException and the fuse button becomes unavailable.

Desktop
Syrius version: v0.1.0
OS: any
Commit hash: 267950f

Describe the bug
After creating a new wallet, I requested funds from the testnet faucet and got stuck in a plasma generation loop. Auto-receiving was enabled. Funds are never received.

To Reproduce
Steps to reproduce the behavior:
Check description, and attached screenshots. I did check/uncheck auto-receive a couple of times and added the testnet faucet node during the Node Management window. No other special steps were taken.

Expected behavior
I expect at most two `Plasma will be generated in order to receive transaction' notifications, one per pending transaction, and for transactions to eventually be received and shown in my balance. Additionally, if auto-receive is enabled, I expect the green down arrow buttons for manually receiving the transactions to not be shown or be grayed out.

I expect that during the Node Management window in the initial wallet creation flow, for the chain id warning to show up when adding a new node with a different chain id, as it happens when you do in the settings tab.

Workaround
After trying to fuse some plasma from another wallet, I was getting Error while generating plasma. Turns out chain id is not automatically changed to '3' even though you get the notification when adding the node. I went back to check if this was the cause of the issue, and it was. After manually changing the chain id to '3', the account blocks were published after plasma generation and both transactions were successfully received.

Screenshots
If applicable, add screenshots to help explain your problem.

Auto-received is enabled. These are unreceived transactions. Should these icons be shown/clickable at all?

Desktop (please complete the following information):

• OS: Windows 11 Enterprise Eval 22H2 (VM)
• Syrius Version v0.2.0-rc.2
• Commit hash: a369f65

Additional context

Should the client chain id be automatically set by syrius after the user clicks "proceed anyway" ?

Describe the bug
Syrius fails to start without a working internet connection.

To Reproduce
Steps to reproduce the behavior:

1. Disable all internet connections
2. Start Syrius

Expected behavior
Syrius starts as normal but cannot connect to the node

Actual behavior
Syrius starts and shows a white screen

Screenshots

Desktop (please complete the following information):

• OS: any
• Syrius Version: 0.2.0+
• Commit hash:

On the Transfer > Send section, should the "Send payment" button be reworded to "Send tokens"?

I don't believe that all send transactions are payments.