[02:03:53] @aguycalled @prole I've commented in github about the issue with shutting down a node [02:04:06] I found some PRs in upstream that seem to address the issue [02:04:38] As well as optimize the sync process (Because of optimizing the src/net.* logic) [02:07:42] The optimized sync speed is as follows for dashpay: new = patched with this PR. old = running #9289. client / server old / old: 100000 in 8:05 new / old: 100000 in 3:24 new / new: 100000 in 2:16 [02:10:20] So abour ~72 decrease in sync time on average [02:10:44] So i think it might be worth backporting the changes into navcoin codebase [08:30:15] @mxaddict that sounds super good [08:31:54] Not sure of we could get the same uplift in performance [08:32:04] But I think it's worth a shot [08:32:19] But the changes are quite extensive though [08:32:34] Might need to be broken into several PSs [08:33:36] @aguycalled , check out the links in the issue if you can. [08:33:54] There are some good details in those [08:50:06] sure ill check [08:50:12] the new pivx wallet ui is beautiful [08:52:09] https://www.youtube.com/watch?v=qEt6i_baHRM [09:00:16] the prs look reasonable @mxaddict [09:00:34] where do you see the major difficulties? [09:06:00] I think in the changes required to serialize, block and merkle [09:06:31] Those would need some thorough review and testing once ported [09:06:48] But the other net.* stuff should be fine [09:07:29] Wow that new pivx wallet is amazing [09:14:25] can't see the serialize references [09:14:28] could u point me to them? [15:10:47] is it a qt wallet? [16:33:55] yes [18:14:47] Basically current upstream updated the serialize logic, they deprecated the passed int nType and int nVersion, so we would need to update serialize.* and anything that uses it [18:23:40] or we could adapt it, isnt it only a interface thing [18:36:38] I think it makes more sense to backport those changes as well (They make sense) [20:35:15] @aguycalled should I create a github issue about this? [20:35:27] yes i will add a high bounty [20:35:34] So we can discuss it on issue and keep better track of ideas [20:36:20] If we get the same performance uplift, then bootstrap can be completely obsolete [20:36:40] As loading from peers will be faster than a bootstrap I think. [20:37:05] Assuming we get similar performance uplift [20:37:32] Also, i think the other PRs for refactor should be merged into this one as well. [20:38:04] The Q_FOREACH and BOOST_FOREACH changes [20:38:25] As well as the change for include "" to include <> [20:55:47] @aguycalled I've created the issue here https://github.com/navcoin/navcoin-core/issues/573 [20:55:53] And added as much info as I could gather [20:58:36] @aguycalled Seems a bit odd to me why one would choose Qt, if it limits what you can do on the front-end. [20:58:59] @anquii performance limitation [20:59:05] Current wallet uses 1.6GB of ram [20:59:29] If we replacet QT with something that runs a browser to run JS/CSS/HTML ui code [20:59:45] It will add about ~1GB more ram usage (Just an estimate) could be less [20:59:58] But compared to the QT ram consumption which is like 100mb [21:00:04] It's huge % increase [21:00:17] I see, so it wouldn't be able to be run on the Pi e.g? [21:00:31] Well on PI it would not matter [21:00:32] Or that's a different architecture anyway I guess [21:00:36] As it does not run the GUI wallet [21:00:40] It runs the daemon [21:00:44] yeah true [21:01:06] But it would limit the wallet usage to machines with more than 3 GB free ram space [21:01:14] Like IE you have an 8GB machine [21:01:17] And run chrome [21:01:24] And chrome is using 6 GB [21:01:28] Then you wanna run the wallet [21:01:34] It will slow down the system to a crawl [21:01:42] If you do that now, it will still work [21:01:49] Ok I see [21:01:56] is there a big difference between Qt and Electron? [21:02:01] Yes [21:02:17] Electron runs a browser that renders the GUI [21:02:19] NAV had a wallet on electron before right? [21:02:28] I think it still has one [21:02:32] I think NEXT wallet uses it [21:02:38] @sakdeniz can you confirm? [21:04:02] In terms of performance, is there a huge difference there? [21:04:40] Just asking because it'd seem that there's a ton more possibilities UI wise if a browser is rendering. [21:05:14] the possibilities are the same [21:05:25] it's just it's easier to find someone able to do nice uis on html/css [21:05:30] rather than using qt [21:05:43] Yeah, PIVX has a really nice UI [21:05:48] They use QT I think still [21:05:49] Well. [21:06:00] So it's totally doable, just need to find someone to do it 😄 [21:06:02] They're UI is good relative to NAVs. [21:06:10] But it's not good from a general point of view. [21:06:32] Like take Ledger Live. It's so much better, not even comparable. [21:06:46] And it's run on Electron. [21:06:47] https://github.com/LedgerHQ/ledger-live-desktop [21:07:07] Can't really compare a UI for a multi coin wallet with a single coin wallet They don't even have the same feature sets [21:07:21] The ledger live UI looks nice because it's simple and sleek [21:07:35] But you can only make a core wallet so simple, because it needs features [21:08:00] And features/functionality come first and pretty ui come second 😢 [21:08:07] We're not on the same page here I think. [21:08:36] I'm not talking about the how the UI is constructed relative to being a multi coin wallet vs. a single coin wallet. [21:09:04] I'm speaking about the UI components itself. [21:09:17] I know that is what you mean, but I mean like in terms of limitations, IE some parts of the UI on core wallet can just not be changed [21:09:26] Because they need to be a certain way to work [21:09:44] You can change the colors, the padding the borders, but that's about it [21:09:58] well i like to think limits do not exist. you can change whatever you want [21:10:03] what is unchangeable ? [21:10:45] only the functionality stays. send, receive, see transactions [21:10:48] I'm talking about like the send and receive pages, they look they way they do cause we need that functionality [21:11:08] yeah but it can be done in many ways, we could have navpay's flow [21:11:22] But the theme can totally be cleaned up, we just need to put in the time and effort [21:12:01] We can make it look like anything we want [21:12:14] Just that we don't have the resources as of the moment [21:12:20] It's not done just by putting in the time and the effort. [21:12:25] But I think we are moving in the right direction [21:12:31] New dao page looks nice [21:12:34] We'd need professional designers to come up with it. [21:12:45] The developers shouldn't handle that part. [21:12:58] yes you are right [21:12:59] And the new menu and layout I worked on also looks nice [21:13:00] completely [21:13:24] @anquii that's what I meant by "not having the resources" [21:13:25] 😄 [21:13:30] Everything's relative @mxaddict. [21:13:31] i'd be 10x times more happy if i only have to work on the backend [21:13:37] We don't have a designer as of now 😄 [21:13:51] #anquii [21:14:41] If a designer comes onboard I will be more than happy to implement the designs [21:14:44] But let's say that a designer made the UI simple and sleek in a similar fashion to the Ledger Live. [21:14:54] Would you be able to implement these changes with Qt? [21:14:56] I can code the qt for it, as long as I know how it should look [21:15:11] Or would we switch to React? [21:15:21] Yeah, it's totally possible in qt [21:15:41] I think switching to react would be a whole large scale project [21:15:58] As that would mean re implementing all the UI functionality [21:16:07] Well, that's exactly what prole wants to do with the Kauri wallet anyway no? [21:16:28] If we just make the QT code look like the design, then it should be less work as it would mainly involve just styling and moving things around [21:16:30] Qt doesn't seem like a long-term solution. [21:17:33] I don't see why qt would not be good for the long term, please illaborate. [21:17:52] Kauri is not going to be a full node I don't think [21:18:02] I think it will be a layer ontop of the daemon [21:18:34] i would not let hypothetical kauri features influence core dev [21:18:38] core is core [21:19:34] I'm not a web-developer, but I've never heard of Qt. [21:19:41] core is a living thing, kauri does not exist as of today more than as an idea [21:19:46] Would it be fair to say that React is being more widely used than Qt? [21:19:48] I still think that the performance aspect of the core wallet is more important that flexibility that comes with a web based UI [21:20:00] yes @anquii, it's more widely used [21:20:12] Yes, it's very popular [21:20:15] but Qt is prob the most straightforward and better way to add a GUI to a C++ codebase [21:20:31] I see. [21:20:38] I agree that react is easier to work with for UI [21:20:55] But it will be slightly limited with integration into the c++ core (daemon) [21:21:10] As it will use an HTTP API instead of raw function calls [21:21:21] So integration will be limited that way [21:21:30] I guess it all comes down to pros and cons [21:21:53] And right now I feel that performance and ease of integration of new core features still outway the ease of ui development [21:22:28] Actually while we are on the topic [21:22:35] A good QT replacement would be vala [21:22:45] I think it's important for me to fully grasp what the goal of core wallet is. [21:22:49] It's native c/c++ code and is nice to use for UI development [21:22:51] More so that QT [21:23:13] But then again, we fall into the question of do we have people to work on it if it's vala [21:23:25] Vala is used in the elementary os codebase [21:23:34] And they have some very sleek looking apps using it [21:23:52] Let me just ask this please before talking about vala. [21:23:56] Just need to clarify. [21:24:06] As I understand now from your comments, the Qt wallet is supposed to be a full node wallet with limited interaction. [21:24:50] And beyond that, we'd have light wallets where the options for great UI/UX is not limited in the way. [21:24:55] Yes, as it's the core wallet Basically it has these goals: 1. Have all core functionality 2. Use as little system resources as possible 2. Look pretty [21:24:58] And in that order [21:25:04] @aguycalled would you agree on that list? [21:25:23] i would add Easiness of use between 2 and 2 [21:25:54] So I get that core is focused on performance. [21:26:06] Not necesarily [21:26:18] If a core feature causes less performance, it will still be implemented [21:26:22] If the feature is required [21:26:23] and functionality, because is the reference client. you need access to many things a regular user will never use [21:26:34] Yeah. [21:26:41] everything building on top of nav will use core [21:26:55] a merchant gateway, a light wallet, a exchange integration, etc [21:27:06] But I wouldn't say that necessarily equals large compromises on UI/UX. [21:27:19] I think it does [21:27:35] UI means nothing if the core wallet can't do everything that is required of it [21:28:07] I'm not saying to not include all options in the core wallet. [21:28:43] we still need to maintain the ui/ux part somehow because we cant expect from our userbase (stakers mainly) a high technical knowledge. delivering just a headless client would not work in our case [21:28:49] Then again we get back to resources, we only have like 3 people working on the wallet as of now, and focus is in the order of that list [21:29:05] So we spend most our time on Numbers 1-3 and 4 is getting neglected sadly [21:29:19] Yeah, I fully understand about resources. [21:30:22] IE also features are added in this order: 1. Daemon 2. QT 3. Light wallets [21:30:24] Switching to React rather than Qt might bring in more resources later on. [21:30:40] Yes, that would do it [21:30:58] But that means we first need to port the entire wallet and skip step 2 [21:31:49] And the resources used by the wallet increase with each new block added to the chain [21:32:00] This is the main reason for focus on the performance aspect [21:32:10] As the wallet only get's heavier over time [21:32:31] It's just, nowadays, design plays a huge part and brings legitimacy to a project. [21:32:56] i agree, i would love to have a better looking and easier to use wallet [21:32:57] NAV is doing technical wonders, but we have no focus on design. I fully understand the reasons why, I'm just saying. [21:33:11] Therefore, many people will tend to look the other way. [21:33:32] I don't think that has as much impact as you think [21:33:41] It does impact perception [21:33:58] And we won't gather the attention. I'm not bashing or anything, but the wallet looks like it was designed more than 10 years ago. [21:34:01] But not to the degree that people will not use the wallet cause it's not pretty [21:34:37] aesthethics do matter, i'm on that side. the current wallet is only attractive for nerds [21:34:39] I think it has a much larger impact than what you think. [21:34:58] I digress 😄 [21:35:02] Functionality and performance definitely comes first. [21:35:09] Have you seen core bitcoin wallet? 😄 [21:35:14] Looks like it's from 1997 [21:35:25] Atleast our wallet looks like it's from 2009 [21:35:28] yes, but their ecosystem is bigger [21:35:32] But there's a reason why Apple's design guidelines are the ones held in the highest regard. [21:35:49]