I tried shortening the timeout to 500ms and performed some tests. I found that the selection strategy doesn't slow down the user's startup experience; instead, it might make it faster. The user's actual complete loading occurs when the "loading" state disappears, which is loadCashtabState in useWallet.ts. Through adding a timer for simple testing, taking my Hong Kong IP as an example, useWallet.ts:969 shows Cashtab startup duration: 2583ms. This is the time actually perceived by users. However, when using the "selection strategy" and changing the timeout from 1000ms to 500ms, the test result is 620ms for Cashtab startup duration. Therefore, finding a faster node within 500ms and establishing a connection is often faster than choosing a default one. Furthermore, this 500ms could potentially be adjusted to 400ms or 300ms, meaning "if we can't find a faster node within 300-400ms, it doesn't matter anymore." WebSocket connection establishment speed is 2-3 times that of ping, and it's easy to prove through testing that lower WebSocket latency means lower query latency.

My view is that this approach is worthwhile.

Build Bitcoin ABC Diffs / Diff Testing (preview-cashtab) passed.
Preview is available at http://51.68.37.192:41160 for the next 60 minutes.

@bot preview-cashtab

at the moment this is not worth implementing in cashtab

regtest handles basic cases for SLP and ALP now. Next up is cleaning up debug logs, function names, adding unit tests for untested functions.

rebase, get regtest working with SLP and ALP. NB we still have lots of cleaning up and other tests to add.

rebase on bugfix

rebase

Build Bitcoin ABC Diffs / Diff Testing (preview-cashtab) passed.
Preview is available at http://51.89.41.69:41339 for the next 60 minutes.

@bot preview-cashtab

see D18036

I see

@bot build-master

cleanup remaining issues from old draft

Rebase

Rebase