Predictable RPC Provider Selection for System Chains

[helixstreet]

Issue Description:

Currently, when a user selects a specific RPC provider for a relay chain (e.g., Kusama), Polkadot.js appears to randomly select RPC providers for the necessary system chains (people, coretime, etc.). This can lead to an inconsistent and sometimes unreliable user experience, as the randomly chosen providers for the system chains may not be as stable or performant as the user's chosen relay chain provider.

For example, a user might explicitly choose "Provider A" for the Kusama relay chain. However, behind the scenes, Polkadot.js might connect to "Provider B" for the kusama-people chain and "Provider C" for the kusama-coretime chain. This randomized mixture of providers can sometimes fail or lead to performance issues.

Here is a visual illustration of this behavior:

In this case, IBP.network was selected for Kusama, but Polkadot.js independently chose polkadot.io for kusama-people and stakeworld.io for kusama-coretime.

Proposed Solution:

To improve predictability and reliability, it would be beneficial to adjust the RPC selection logic for system chains.

If a user selects an RPC provider (e.g., "Provider A") for the relay chain, Polkadot.js should first check if "Provider A" also offers an RPC endpoint for the required system chain. If it does, this endpoint should be prioritized and used.

Only if the chosen relay chain provider does not offer an endpoint for the specific system chain should Polkadot.js revert to the current random selection logic.

This approach would likely lead to a more stable and consistent experience for users who have a preferred RPC provider.

Thank you for considering this enhancement.

[ap211unitech]

Thanks for pointing that out! We already have some plans to improve this UX. Right now, the chain selection flow isn’t very intuitive — especially for new users, who are required to choose a provider every time after selecting a chain. We're actively exploring ways to make this smoother. Your suggestion is valuable, and we’ll definitely consider it when we start working on the improvements.

[helixstreet]

Thank you for the quick and positive response! I appreciate you're already looking into improving the UX.

To clarify my original point, my main concern wasn't about the initial chain selection flow for new users, but rather the automated, "under-the-hood" RPC selection for system chains that occurs after a provider for the relay chain has already been chosen.

My understanding is that when I'm connected to a relay chain (like Kusama) with a specific provider I've selected, Polkadot.js needs to make queries to system chains (like kusama-people). The issue is that the RPC endpoint for these system chain queries is chosen randomly. I believe this is handled by logic similar to:

const randomEndpoint = endpoints[Math.floor(Math.random() * endpoints.length)];

This random selection can cause significant performance problems. If I've chosen a fast, local RPC for the relay chain, but the application randomly selects a geographically distant or slow RPC for a background system chain query, the entire user experience becomes sluggish or even unusable. The user has no control over this background selection.

My proposal is specifically to address this "under-the-hood" random selection. Before choosing a random endpoint for a system chain, could Polkadot.js first check if the provider the user selected for the relay chain also offers an endpoint for that system chain? If it does, that corresponding endpoint should be preferred. This would create a much more consistent and reliable connection experience.

Thanks again for looking into this!

[ap211unitech]

I understand. I just wanted to clarify that we will address this issue as part of the upcoming UX improvements.

To explain further: if the user selects HelixStreet for the Relay Chain, the system will check whether a HelixStreet provider is also available for the other system chains it needs to connect to, such as People or Asset Hub. If it's not available, only then will it fall back to selecting a random endpoint. This will be the updated logic after the improvements.

[helixstreet]

Excellent. Thanks. The issue came up in a discussion in the Decentralized Nodes Matrix Chat.