Allow users to customize API keys from the UI

[ilmotta]

Feature Issue

This issue should not be picked up for development. It's here mostly as a point of reference for future discussions.

User Story

As a privacy-minded user, I want to be able to use my own API* keys without having to rebuild the mobile app myself, so that I'm not as dependent on the Status infrastructure.

We understand the majority of users won't care about setting up their own Infura or Grove API keys, so if we do invest in this feature, it's very important to devise a simple solution to justify the cost of development.

Context

In Status v1 users could configure their own Ethereum-compatible endpoints. In Status v2 this won't work, but we still want to provide some flexibility to users.

In v2 there will be a proxy server managed by Status CCs https://github.com/status-im/infra-proxy, mediating requests to Web3 infra providers to help deliver a solid default UX to all users. This is a point of failure and an extra point of centralization that not all users desire.

We believe that we should facilitate the lives of power users.

Description

Open for debate

• The user should be able to input/configure API keys before logging in.
• The feature should not confuse users who don't care about this advanced use case.
• As much as possible, the feature should not impact the onboarding funnel.
• The user may want to input the Infura key, but not Grove, but to simplify the use case, the user should either rely on the proxy entirely or input all keys manually. If keys are manually used, then the proxy won't be used.
• The feature should be available at the early onboarding stage, but also customizable in the profile settings.

[86doteth]

In Status v1 users could configure their own Ethereum-compatible endpoints. In Status v2 this won't work

just out of curiosity but why wont it work in v2 as opposed to v1? what made it possible then and what makes it not/less possible now?

[ilmotta]

@86doteth, the primary reason for this decision is a matter of resources and cost-effectiveness for Status at the moment. Supporting custom networks would require allocating more development and QA time to ensure they work seamlessly for users, alongside centralized providers like Infura. The new wallet in Status v2 was designed with centralized providers in mind, which allowed us to reduce the scope of our work (a must right now) to deliver a minimally functional product.

This GH issue isn't our ultimate goal. This issue should be seen as a quick-win of sorts, but we know it's not ideal. We don't want to overpromise, but I personally do hope we can keep improving in this area and eventually support custom networks as first-class. Btw, initial discussions around this topic have been around for more than 6 years #3994.

[ilmotta]

Hey @xAlisher, I have heard a handful of times already about the desire to allow users to skip the proxy altogether and use their own Infura/Grove keys. This feature can also be handy to unblock a user in the case the proxy is down or if the API keys managed by Status are rate limited.

This feature is definitely not a priority, but I would like the investigation to be more open, that's also why I opened this issue. I'm curious about the feasibility in terms of UX and how much it could affect onboarding for the majority of users who won't bother setting up their own API keys. Technically, if no UI was required it wouldn't be difficult, so the challenge is more around UX and if there's a way to not make the onboarding more complicated than it already is.

If you find this issue interesting and eventually find some free time to brainstorm I would love to hear your thoughts. Of course, after the dust settles from the current release process 🦾

[86doteth]

@86doteth, the primary reason for this decision is a matter of resources and cost-effectiveness for Status at the moment. Supporting custom networks would require allocating more development and QA time to ensure they work seamlessly for users, alongside centralized providers like Infura. The new wallet in Status v2 was designed with centralized providers in mind, which allowed us to reduce the scope of our work (a must right now) to deliver a minimally functional product.

This GH issue isn't our ultimate goal. This issue should be seen as a quick-win of sorts, but we know it's not ideal. We don't want to overpromise, but I personally do hope we can keep improving in this area and eventually support custom networks as first-class. Btw, initial discussions around this topic have been around for more than 6 years #3994.

thanks for the clarifications. i completely understand the mobile team having a lot on their plate already so its unfeasible to expect them to work on this without delaying releases for users.

i feel like the nimbus team should step up and work more proactively on filling in gaps like these for wallet just like waku has been doing for messaging. the use of nimbus in any status related product has been teased for years but nothing concrete has ever come from it to the point where i wonder why nimbus is funded by ico funds while waku supposedly is ‘self-funded’ by the founders since recently even tho waku is much more integral to the app.

[ilmotta]

• Linking with the PR that removed support on the UI for custom networks chore(wallet): remove legacy network settings options #18955

@Samyoul, as we can see, the PR was merged on March 6, but I couldn't find any discussion about the impact of the removal of custom networks. Interestingly, I relied on this feature while developing support for wallet account selection to join communities around the same time.