Syrius Improvements

Development ╰ Funding | Staging
23

Discussed in telegram, figured I would add it here for reference.

Feature to disable s y r i u s automatic behavior of receiving all transactions in order to filter out unsolicited inbound transactions.

Relevant with what’s happening in ETH with Tornado’s eth.

2 Likes
24
  • address whitelisting for auto receive
2 Likes
25

I’m also trying to build Syrius in Ubuntu, but couldn’t. I opened an issue on GitHub and would appreciate any help.

26

@DrBlaze_21 can you share how you did it?

1 Like
27

Ability to hide/unhide addresses and sort them by ZNN / QSR balance

28

Hi Amin,
I’ve responded to your issue on Github with some tips for compiling Syrius on Linux.
If you’re interested in developing on Windows, I’ve made a post here.
Hope it helps!

This whole time, it was Wakelock’s lack of Linux support that was causing the error. We can either patch it out for Linux or find an alternate solution.

4 Likes
29

Now that we’ve figured out how to setup the development environment (thank you @sol for breaking it down), we can work on some of the items on the list. I figure we would need to fork the repository in order to setup a team of contributors.
We could also break down the list in work items under the GitHub repository and use DoWork for bounties?

30

I’ve updated the main post with all of the suggestions to date

2 Likes
31

Thanks to @sol straightforward explanation, I could run Syrius on Ubuntu. It would be nice to have a release of Syrius on Snapd. I hope the team considers it.

2 Likes
32

Given I’m more of a visual person and I like seeing progress being displayed on a board, @0x3639 has setup an instance of Mattermost for us.

I’ve started populating the Syrius board with the suggestions from this thread and we’ll be tackling them one at a time.

Feel free to contribute by:

  • submitting tasks/bugs
  • updating the contents of any ticket
  • taking on a ticket and seeing it through

Your help is most appreciated!

https://mm.0x3639.com/boards/workspace/bjqwiwqxqtnb8xf1mab1fnu8ua/bdw6atoqxgirqjcuuz5ckxu3naa/vqsgy3jdce7f3bcqapjnstz86xh

4 Likes
33

Would like to help out, see you guys on Mattermost!

2 Likes
34

Possibility to add multiple addresses simultaneously
Possibility to switch between networks (netid)

1 Like
35

Hi everyone, I’ve made some changes to the syrius code and I’m requesting community testing for these branches:

Some notes about each branch:

  • dynamic_netId and add_message_field require you to manually supply the Zenon library files in the build output directory. Some info about this can be found here.
  • linux_poc has an updated build process for Windows and Linux, automatically sourcing those ^ libraries and dropping them in the build output directory. I’m still working on the MacOS build process with @0x3639.
  • dynamic_netId allows you to switch between any Zenon network automatically, depending on the node you’ve connected to.
    If you want to try the netId branch, you may use these nodes:
    • netId 1 == wss://node.zenon.fun:35998
    • netId 321 == ws://node.zenon.fun:36998
    • DM me your 321 test address and I’ll fund you with some tZNN/tQSR
  • add_message_field updates the transaction widget to allow users to submit optional messages with their tx.

I’ve tested all these and am satisfied with the results, but I’d like community feedback in case I made a mistake.
After a brief period of time, I’ll submit each of these as a PR to the official git repo.

4 Likes
36

I plan to continue my work on this Saturday & Sunday between kid stuff.

1 Like
37

@sol do you happen to have a http adres for the devnet node to connect the Zenon Explorer? http://node.zenon.fun:35997 does not seem to work.

38

Since I haven’t enabled HTTPS/WSS for the devnet node, we’ll need an HTTP explorer.

You may use: http://explorer.zenon.fun
With node: http://149.56.108.141:36997

2 Likes
39

Dynamic netid is cool, but it would be also very helpful to be able to manually set it. I would make a separate Settings card with all options (Add/edit netid and dynamic netid).

1 Like
40

Is there a reason for a Client-Node netId mismatch scenario? I don’t think this would really work for anything…

Example: Syrius connects to node with netId 1, but I’ve statically set netId 321 in Syrius, I won’t be able to interact with either netId 321 or netId 1. Syrius will still be able to see netId 1 chain data.

41

Zenon uses ChainIdentifier and netId, while Ethereum uses chainId and networkId. You can find a list with chainId information here.

chainId is used to prevent replay attacks and neworkId is used in the p2p communication and you usually want both to be the same value and different from other networks (localnet/devnet/testnet/etc).

In syrius:
Zenon Node network identifier: generalStats.frontierMomentum.chainIdentifier.toString()
Client network identifier: netId.toString()

We definitely don’t want Client-Node chainId mismatch (because the Client will sign tx only valid for that specific chainId when sending them for broadcast to the node that is connected to) and netId is really used only by the node to connect to other nodes from the p2p network and we should just inform the user.

It’s a bit misleading and I think this is a confusion that we should address in the next update. More info on this over here.

2 Likes
42

@sol sending transactions with an optional message seems to work.

The UI doesn’t enforce any limitation on the maximum data length. So when entering a very large message the the API creates an exception based on two conditions.

"JSON-RPC error -32000: account-block data field is too big"
When sending an account-block with data larger than 16384 characters

"JSON-RPC error -32000: forbidden parameter"
When the account doesn’t have the required plasma.

// MaxDataLength defines limit of account-block data to 16Kb
MaxDataLength = 1024 * 16

Would be nice if the UI prevents large messages. Maybe even limiting the max allowed data size of 16Kb?

1 Like