Would like to help out, see you guys on Mattermost!
Possibility to add multiple addresses simultaneously
Possibility to switch between networks (netid)
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.
I plan to continue my work on this Saturday & Sunday between kid stuff.
Since I haven’t enabled HTTPS/WSS for the devnet node, we’ll need an HTTP explorer.
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).
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.
netId, while Ethereum uses
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).
Zenon Node network identifier:
Client network identifier:
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.
@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?
I’ve created a new branch for the Dart SDK with distinct fields for
Maybe we’ll have only
chainId in the SDKs as
netId === chainId and
netId is a variable bounded to the node. What do you think?
Thanks for the feedback! I agree, we can leverage client-side validation to avoid RPC errors.
- enforces a MaxDataLength limit for the message field
- displays a notification error if PoW Plasma max limit is reached for a transaction
Users will no longer see those JSON-RPC errors.
That’s awesome! I wouldn’t merge this in to syrius until the Dart SDK is officially updated.
What does the tooltip display when the node is added but offline? Example: wss://peers.zenon.network:443
Will you be submitting a PR for your SDK changes?
- New branch with updated links in the Information widget
- Updated linux_poc branch with two .sh scripts to package a .dmg file after generating a Release build. Thank you @ZNNAYIID for the new background image!
I’d appreciate anyone with a Mac to give the new build process a try. Please provide feedback if you run into any issues.
Instructions 1. git clone -b linux_poc https://github.com/Sol-Sanctum/syrius.git 2. cd syrius 3. flutter build macos --release 4. brew install create-dmg 5. cd macos 6. ./generateDmgRelease.sh - or ./generateDmgRelease-new.sh 7. Navigate to /path-to-syrius/build/macos/ and double-click the .dmg
Future syrius update process could involve package managers, but at least now we have an end-to-end process for devs to produce Release builds for each OS.
Windows - chocolatey?? Mac - brew Linux - brew or snap
1. Press the Update button in syrius 2. download latest Release file from git 3. shutdown the app 4. replace files and re-launch syrius ??
Note: the Linux build does not have an icon for the ELF file. We’ll almost certainly need to support a package manager like
snap in order to have that.
Yes, I can handle that, thank you!
I think we should revive this thread.
I’m working with a friend on some improvements for the Syrius wallet and wanted to ask for some feedback regarding the following features:
- Tray manager
- Desktop notifications
- Launch on startup
- Deep linking
Are those available in a release or branch? Is the tray manager code working?
They are available here: cicd branch. Still work in progress.
Are you asking us to test this or give an opinion on the features?
- Tray manager is a great idea. Would be nice to add
- Desktop notifications would also be great to add
- Launch on start up is good so long as we can disable the feature
- What is “Deep linking”?