Would like to help out, see you guys on Mattermost!
2 Likes
Possibility to add multiple addresses simultaneously
Possibility to switch between networks (netid)
1 Like
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
I plan to continue my work on this Saturday & Sunday between kid stuff.
1 Like
@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.
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
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
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.
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
@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
I’ve created a new branch for the Dart SDK with distinct fields for chainId and netId.
From my research both chainId and netId fields should be equal and different from mainnet (Alphanet) where both are hardcoded to 1.
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?
2 Likes
Thanks for the feedback! I agree, we can leverage client-side validation to avoid RPC errors.
I’ve updated my add_message_field branch:
- 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.
2 Likes
@sol I’ve combined your dynamic chainid with my previous Dart SDK commit and also displayed additional info in the Node Management tab.
1 Like
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?
1 Like
Quick update
- 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.
Check out @0x3639’s thread to setup the MacOS dev tools.
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
or
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.
2 Likes
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 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”?