-
Notifications
You must be signed in to change notification settings - Fork 570
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
[7.5][TBD] Better node management #1521
Comments
Possibly amount of history & bucket sizes offered too? (although I have started a discussion in telegram to standardize bucket sizes offered for uniformity) |
Totally agree, include with the ping all button that I somehow forgot in my last PR... |
Knowing bucket sizes requires us to make an api call to the node. The amount of history is not available AFAIK. |
This is useful especially when a node is having issues. Easier to contact the node admin. |
- refactoring of SettingsStore and AccessSettings - prepare routerTransitioner to support a more sophistiaced node dictionary Signed-off-by: Stefan Schiessl <stefan.schiessl@blockchainprojectsbv.com>
During working on #1672 and refactoring I realized that this issue is probably gonna be solved on the. Can this be rated please? @startailcoon @wmbutler |
During my work on this I found a bug in the SettingsStore. If any default values change (removing nodes, changing faucet), the user does not get those changes due to local storage having old values. Will include a fix for that as well |
Is there a way to not trigger chrome warning when one of the nodes has a bad SSL certificate? |
No, that can only be deactivated by the user. Even if the UI wanted to evaluate certificates itself (and not connect if invalid) the user would still get a notification. |
Requesting feedback for visualization and configuration options @bitshares/ui-dev Title is Region - Country - Location (Optional), Operator is right aligned. An entry in apiConfig.js looks like this then: bitshares-ui/app/api/apiConfig.js Lines 117 to 123 in 3412357
|
I really like that @sschiessl-bcp ! |
Thanks @clockworkgr I just commited a more extensive refactoring of SettingsStore and AccessSettings. Filtering I will add next week. |
I am calling out to all node operators, please provide me with the additional information to be able to give the user a more sophisticated selection process and filtering options. Please simply comment in here with your updated node configuration in the same style (so I can copy and paste). Use the old configuration like seen here and add the new configuration. Expectancy of a post:
If the url has not changed, mentioning the old config entry can be ommitted. Short explanation:
Failure to provide detailed information on your node will result to be listed as "Unknown" in the reference wallet. Unknown nodes might be removed later on. |
{ |
Listing emails in pages in their native structure mailbox@domain.com will end up in Search Engines, and eventually become just an open-invite for crawlers, bots, spam and unusual activity over https://wallet.bitshares.org so no, I don't agree with adding emails as contacts. I would also added line entry that is saying is the node standard/full so we can end that endless question of users "is there any full node". Rest is fine. |
After DL's comment I suggest a history_ops entry specifying amount of history. 0 for full node, or number for max ops held. Updated my comment accordingly |
@clockworkgr 0 for mini node with no history. |
|
Actually I think UI can detect number of By the way, how about enabled plugins / apis? Version? Compile-time options(bitshares/bitshares-core#1099)? Will the UI code detect them automatically? |
@abitmore Yes, after connecting to the node that could be evaluated, but the main spirit of this update is to give the user filtering before connecting. All meanwhile the user should not be able to discriminate on facts other than location and operator. Users like bigger numbers, running a full node is already more expensive and I want to avoid that traffic focuses there then. That's where ES come into sight. After connection has been established I am hoping to get bitshares/bitshares-core#626 to provide more intel on the node. Also in the spirit of said issue I want to avoid putting down any hardcoded information that would be excluded in such a server info API due to security risks. |
|
- askToReconnectAfterSeconds in footer increased to 10 seconds - remove duplicate doQuickLatencyUpdate - beSatisfiedWith is now a map according to AccessSettings display - remove bug that you dont connect to your selected one if not autoselction Signed-off-by: Stefan Schiessl <stefan.schiessl@blockchainprojectsbv.com>
{ One more from Openledger |
Just FYI I've pinged elmato,rnglab and owner of btscharts, all responded but no action here yet. |
{ |
Added |
- askToReconnectAfterSeconds in footer increased to 10 seconds - remove duplicate doQuickLatencyUpdate - beSatisfiedWith is now a map according to AccessSettings display - remove bug that you dont connect to your selected one if not autoselction Signed-off-by: Stefan Schiessl <stefan.schiessl@blockchainprojectsbv.com>
{ |
@sschiessl-bcp is all nodes updates so we can close this issue? |
Nodes missing:
|
{ |
{ |
{ |
Is this ready to get closed out and paid? |
And testnet
|
apiConfig has been updated, this issue is completed. |
The next step is laid out in #1901, please evaluate |
As we gain more and more nodes from both witnesses, businesses, regular joes and worker programs, the list has grown quite long. Nodes all around the globe is in one single list, and mixed with testnet nodes, just to make the matter worse.
I propose we make a UX for a better node management.
A user should be able to filter/find/sort nodes on flags like these, but not limited:
The goal of this would be to make the list of nodes more manageable.
The text was updated successfully, but these errors were encountered: