Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add advanced settings to "Node Config" #2170

Open
Darth-Coin opened this issue May 2, 2024 · 3 comments
Open

Add advanced settings to "Node Config" #2170

Darth-Coin opened this issue May 2, 2024 · 3 comments

Comments

@Darth-Coin
Copy link

Darth-Coin commented May 2, 2024

Describe your enhancement idea

This enhancement is for "Embedded node"

Doing some intensive testing with restarting several times the node and also recovering it I notice that is not so handy to wait to start the node, go to settings, make the changes and restart again, just because you need to switch a setting in the node config.

Some node startup options I think will be better if are moved to the Main "Node Config" screen, at startup:

  • Set neutrino peers
  • Set persistent mode
  • Reset graph sync

All these options could still stay where are now inside the "Embedded node - advanced" as it is.

Why this?

  1. For example, user want to restore a previous Zeus node and knows that the default neutrino peers could have a big impact in the restore process. So could set from the beginning a bunch of neutrino peers that knows will have a good ping, also testing them before it start the node.
  2. The persistent mode at startup will help noobs in a restore process that could close the app and break the restore and scan process. Also it is recommended to be ON when you start a restoring process
  3. Reset graph sync is useful at startup to be able to switch it on without having to enter into the node, and do the additional steps and restart again.

node-config

@Darth-Coin Darth-Coin changed the title Move advanced settings to "Node Config" Add advanced settings to "Node Config" May 2, 2024
@myxmaster
Copy link
Contributor

Hm yeah, the problem is, that you simply cannot access those specific settings (neutrino peers, persistent mode, reset graph sync) when no embedded node is configured yet. And that is always the case when you are at the point where you are restoring an old embedded node in Zeus.

I fully agree that it makes sense to let users pick specific neutrino peers before the embedded node is started for the first time. It should be covered behind "Advanced options" or something, but it can definitely be a very important option for users who know which neutrino peers work good for them (low ping). This might become less relevant in the future, when neutrino protocol is more tolerant to higher ping, but until then this can be very helpful.

To keep the process as easy as possible, we should not add too many options though, so I would go 1 step further: I don't see why Zeus should not turn on persistent mode always (automatically) until restore process is fully done (including first sync). The higher battery drain is irrelevant here, because it would only be enabled for the first sync and then disabled automatically again (user can still enable manually of course).

About the "reset graph sync" option I am not sure. When restoring, we are at the point where no embedded node exists, so the graph is not existing yet and will be synced freshly, right? That means resetting doesn't make any sense at this point.

@Darth-Coin
Copy link
Author

The reset graph is not for the "restore process". Is in general when you already have the node functioning.
Yes, agree, persistent mode should be on by default, at least for the recovery process.

@myxmaster
Copy link
Contributor

Hmm I see, well but not sure how useful it is to reset the graph even before trying to start the embedded node?

Maybe it should be automated to reset the graph, in case zombie channel count is too high? What is "too high" though?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants