Can you please elaborate on what this means exactly?
Right now, with the mobile and desktop app, you can only import or create one wallet, that can hold cryptocurrencies for you. If you want to create another wallet and manage your assets, you will need to delete the current wallet and create a new one.
With the multi-wallet support you will be able to manage more easily your assets from different wallets. In one app session, you could create a wallet for holding ZNN, one for ETH and one for BTC, for example.
2 Likes
Great feature! That would be super helpful.
2 Likes
I’m more interested in holding the assets, but I don’t have a clear strategy for generating rewards long term. I haven’t thought that long in advance
What I like most about the Zenon project is the decentralized philosophy: behind the project there is not one, or a few people, but a community. The dual coin system, the fee-less transfers and the reward distribution are other things that I found appealing.
The main reason that I offered to work on Syrius is that I have the right skills to help the project grow, and the things that I proposed for implementation will benefit the community and the ends users. I’m passionate about Flutter, and I enjoy working on a diverse set of Flutter projects.
9 Likes
Yes, especially for Pillar owners that will be able to import the producer keystore and vote AZ projects while holding funds and transacting on a separate keystore.
Multi-wallet is also helpful for privacy oriented individuals that want to keep separate wallets for EVM chains (not sharing the same address for Supernova and Ethereum for example).
2 Likes
What’s the reasoning for wanting to unify the Desktop and Mobile repos? What benefit will it bring to the users?
As pointed out by others, the current UI uses a deprecated widget which needs to be replaced in order to use the latest Flutter version. This replacement could impact the way the current layout functions. It also offers a good oppertunity to rethink the current design.
While I agree mostly with your suggested points from a developer perspective. Adding unit testing, documentation, more maintabable code and clean material UI elements. From an user perspective the community is paying 3-4 AZ projects for BTC and EVM support. I don’t think users care much about whether the code base is modular or not.
I would rather see a collaboration take place on redesigning the layout and make parts of the code more manageable in the proces rather treating the above mentioned improvements as a primary goal.
Otherwise this proposal is just you saying I’m going to solve all your technical debt for a shitload of Zenon. Trust me it’s going to be geat.
Don’t get me wrong, I think it’s great that you want to work fulltime on this project. I just don’t think it will help the community get involved and be part of the development proces.
How will your proposed improvements help us improve collaboration and involve more developers in the development process? It’s only a matter of time before technical debt piles up again, because there’s no one involved or incentivized for helping out.
I think you’re asking quite a lot here without further defining the details.
Adding support for multiple wallets shouldn’t be too difficult. It mainly requires an addition to the UI to select between the different wallets and to be able to unload/reload the hive state.
I would like to see a high level overview of the features you think might be ported between both Desktop and Mobile version.
Will you be available and open to collaborate before the work?
7 Likes
@CryptoFish brings up a lot of great points.
@john.maxwell maybe a compromise between your preferred work style and the community’s preference for collaboration you could break up the proposal into more segments?
So instead of two large initiatives, it’s more like 4-5 with a corresponding AZ ask for each initiative sequenced by which ones you would tackle first.
1 Like
This proposal got me thinking about the vested pillar discussions. To date we have mostly been discussing vested pillars with regards to KOLs. I would agree this is a great initiative and working on it full time is a massive benefit. I also agree with others that you are asking for a shit ton of ZNN (my words). If we had vested pillar + redirected some of pillar rewards to AZ to perpetually fund it I think larger ask for larger pieces of work like this would be easier to digest… just a thought. At a minimum would be interested in hearing your response to fish + hoping you continue the convo here
2 Likes
Just want to give everyone a heads up that in order to get my support on this AZ we need to collaborate with the other the developers in the community. @CryptoFish and others have been trying to scope syrius improvements and get other developers involved. He has an active SIG to do this. CF has been here for years busting his ass consistently delivering high quality work. He has earned our trust.
I strongly encourage @john.maxwell to join the SIG and start working on the scope with other developers and with support from the community. Please!
2 Likes
Unifying the two repos will mean that we will have less code to maintain and it will be easier to develop features for desktop and mobile. Giving the fact that now we have two repositories, EVM and BTC support is only available for mobile. Further more, if I want to create multi-wallet support, without a common repo, then I will have to develop for mobile, and then for desktop.
The end users will profit by having a wider selection of features available and block chains. I do understand that end users don’t care about code bases, and maybe I have put to much focus on the code aspects, and didn’t quite explain what the users gain.
In just a few works: the desktop users will have EVM, BTC, local authentication, secure storage, WebView and much more smaller features. For example, I want to use Dart isolates so that the UI won’t freeze anymore when you enter your password to access the application. I also want to fix the problem with preserving state across tabs: now you enter an amount in the Transfer Tab, navigate quickly to the Settings Tab to copy an address, and the amount in the Transfer tab is gone.
Here is in more details what I want to do on the development side:
- refactor the code according to the bloc architecture - Architecture | Bloc - and essential step in creating a modular code base with business logic components that can also be consumed by the mobile app
- replace Hive library with drift, as Hive was replaced by Isar, but Isar itself had it’s last update 17 months ago
- audit the current packages that we use: those that are not constantly updated should be replaced by other ones, or check if they can be replaced by features from the Flutter SDK; if not, build the functionality that the library offers myself, if it makes sense in terms of time and effort; this is an important task because, as other developers have noticed, an outdated library can block you from upgrading the Flutter version that the project uses
- create flavors for apps (prod, test, dev) so that when testing the app, you can skip, for example, the unlocking of your wallet
- use the new Dart language features created in the last 3 years
- establish Dart analyzer rules that developers should follow
- use isolates for the UI blocking operations
- write unit tests and documentation
So I don’t think that I am just solving technical debt. I bring a change and with it improvements.
You say that there are no developers to continue working on the project. In the mean time, I offer to work full time on bringing features for the desktop app and make the entry of new developers easier, and somehow, my ideas won’t help the community. Although I have done some work for the benefit of it already.
I think a developer chooses his projects largely on the present quality of the repo. Why would a developer get involved into projects with technical debt? And will a new developer get involved without a proper documentation? Without unit tests to sustain his development?
I dare ask you myself: how is redesigning the layout help bring more developers to the project? What actual value does it brings to the present users? Or how will it bring more users?
You have to understand that I also need to be incentivized to work on this project. Development cost money, you can’t only pay for the part of development that the users sees and interacts with. That’s not how it works. Developers don’t spent all of their time coding features for users. They write documentation, tests, fix technical debt because one outdated library can block you from upgrading to a new Flutter version: and that version might bring new UI render engine, for a smoother experience, or new widgets, or a faster Dart compiler.
Regarding the asked budged: if I am not mistaken, the EVM support plus other features for the mobile app got 2 AZ projects. I propose EVM and BTC support, local authentication, secure storage, WebView , at least, for the desktop app, plus code base improvements, and 3-4 AZ projects is a lot.
You have to understand that if I deliver a product that you are satisfied with, then I should also be satisfied with what I get back. Ultimately I am willing to deliver the product, the community can analyze it and be paid what you think it’s worth it.
Regarding the second project, I will bring further details in another post. But as a developer, you should know that very often something that seems easy, takes a lot of time and effort. We don’t have the 90/90 rule for nothing in programming (Ninety–ninety rule - Wikipedia). That’s the exact reason why I asked for 3 or 4 AZ projects: some things might take more time and effort than anticipated.
I am open for collaborations, but ask yourself this: if you have a modular code base, like in the bloc library fashion, don’t you think it would be easier for some developers to work on the UI and others on the business logic?
I hope that, at least, for the first project, it’s more clear for everybody the scope of the work that I want to do.
8 Likes
I can split the proposal in other smaller projects, as I already has a technical sketch that I want to follow. I will discuss more on the SIG chat with the others developers.
@0x3639 I will send you my ID for SIG shortly
6 Likes
Thank you for your detailed explanation. You seem to have a lot of knowledge about Flutter/Dart and how to bring this project to the latest standards. In that respect I am actually very enthusiastic about your proposal. I also think that your proposed improvements will improve the conditions for new developers, but I think more is needed to get new developers to actually working on the project and reward them. The AZ mechanism is not ideal for paying small tasks that are taken up by several developers. Especially testing and writing documentation are often difficult to measure. The SIG groups are an attempt to improve the conditions for collaboration. Not all developers know what is needed to bring the project to a new level and/or do not have the time available to work on it. You seem to have the time and knowledge to take on the role of chair for the Syrius SIG group.
More explanation about the concept of the SIG groups can be found here, HC1: SDLC SIG - Zenon Wiki.
Whether the mechanism of the SIG groups is something you only want to work with after you have laid a foundation or whether it can be applied immediately is up to you to decide. We can best discuss that within the group. At the very least, you take us along on your journey and the process is recorded for future reference.
8 Likes
I support this initiative
2 Likes
For anyone looking to track the progress of the syrius improvements please follow this matrix room: https://matrix.to/#/#sig-syrius:hc1.chat
Sounds like John is going to get going today or tomorrow on the upgrading Flutter and rearchitecting the app. That will be a solitary task but he has agree to collaborate with other developers where it make sense.
6 Likes
John’s explanation makes a lot of sense to me. Unifying the two Flutter codebases is almost mandatory to properly leverage the cross platform benefits of the framework.
It’s a lot of code. I know because I learned how to properly touch type using the syrius codebase 
. There’s definitely some Bloc used already, but I’m guessing it can be expanded to cover more parts of the syrius logic.
I look forward to the SIG discussions, and being able to contribute, even if it’s just a locale translation early on!
3 Likes
It would be very helpful to have things seperated into smaller projects where it makes sense to do that.
Thank you for the contributions
1 Like
Hello!
Here is a technical sheet with what I want to do for the repo unification part:
- refactor the code according to the bloc architecture - Architecture | Bloc
- use cleaner Material UI elements, like in the mobile app, to make the code more maintainable - the design will, largely, be unmodified
- integrate the mobile codebase with the desktop codebase
- enable EVM and BTC support for desktop app
- bring more safety features into the desktop app (secure storage and local authentication, for a start)
- replace Hive library with drift, as Hive was replaced by Isar, but Isar itself had it’s last update 17 months ago
- replace walletconnect_flutter_v2 with reown_walletkit, because the former has been discontinued
- audit the current packages that we use: those that are not constantly updated should be replaced by other ones, or check if they can be replaced by features from the Flutter SDK
- create flavors for apps (prod, test, dev) so that when testing the app, you can skip, for example, the unlocking of your wallet
- use the new Dart language features created in the last 3 years
- establish Dart analyzer rules that the code pushed into the repo should follow
- use isolates for the UI blocking operations
- write unit tests
- write comments for the code that will be a part of the documentation
- bug fixing
If somebody wants to help with any of the tasks, let’s discuss on the SIG matrix chat. Please specify how many hours per week you can dedicate for your desired task.
From what I understood chatting with the others developers on the matrix chat, they are okay with me doing the whole project. Please correct me if I’m wrong. I am also okay with integrating others in my effort. I can provide documentation and guidance for the mentioned tasks.
I haven’t posted here as often as I hoped, but I want to inform the community that work on the refactoring has already started. After this step is done, I will be able to work also on proper end user features, like EVM and BTC support. In the meantime, I was able to make some changes to the current codebase in order to support the latest Flutter version. Details here: Upgrade dependencies by maznnwell · Pull Request #128 · zenon-network/syrius · GitHub
11 Likes
Thank you for this update. My hope for this upgrade was for it to be open, transparent and in collaboration with other devs. I hope others have time to help out, but if not, I don’t see any reason for you to slow down.
Thanks for joining matrix and keeping us up to date!! Excited to see this come together.
Please request for review if you want these changes to be reviewed and merged.
1 Like
OK. I will.
1 Like