wiki: add Ethereum page #2233
wiki: add Ethereum page #2233
Conversation
| - Use **multiple providers**, even if one of them is your own full node. This | ||
| provides redundancy. Often a provider will fall behind or even stall, so | ||
| use of multiple providers adds robustness to your wallet. |
There was a problem hiding this comment.
I think most users would ignore (or just skip when reading) this recommendation and just go with single provider (and btw will also be annoyed by that need to configure it on their own unlike with Metamask) without fully realising the risks they are taking. Users might also ignore the recommendation about private API key because "it is just a recommendation, and requires additional effort".
Since ignoring these recommendations (providers go down, req limit could be reached) could result in failure to redeem (if all providers fail while user is trying to redeem), how about:
- (bad UX) require at least 2 providers to be configured by user instead of just 1
- (much better UX) allow just 1 provider, but have 2 or more hardcoded fallback providers (e.g.
https://rpc.ankr.com/eth) that will not affect current flow in any way except that these will be used as a measure of last resort when none of user-configured providers are available
Restarting dexc won't be of much help here too, if the user doesn't fully understand that he needs to reconfigure his Ethereum Providers in order for his Ethereum wallet to stay online (I think many users will expect wallet connectivity to recover automatically, and that's a very reasonable expectation to have imo).
thoughts ?
There was a problem hiding this comment.
- allow just 1 provider, but have 2 or more hardcoded fallback providers (e.g.
https://rpc.ankr.com/eth) that will not affect current flow in any way except that these will be used as a measure of last resort when none of user-configured providers are available
Seems reasonable. But what if I do not what those providers used? What if I'm trying to use one for whatever reason (privacy, security, etc)? I'm also wary about defaults like this because: they are an implicit endorsement, they may change and stop working, there may be legal issues about hard coding a provider into the software.
There was a problem hiding this comment.
But what if I do not what those providers used? What if I'm trying to use one for whatever reason (privacy, security, etc)?
Could potentially have additional opt-out flag "never use default providers" (with the description about this being more privacy-oriented). I think opt-in/out features are better suited to those people who like to configure their env exactly the way they want, not for average user who might not even want to understand why it is there (assuming DEX at least remotely tries to target such users) - they want defaults to take care of everything.
Here is a ticket to continue this discussion:#2246.
|
Is there a way to embed the link to this wiki page somewhere in UI (somewhere visible, like on create and reconfigure ETH/Token wallet forms highlighted with red) so that user is prompted to read this tutorial ? Expecting users to find it on their own is probably a set up for countless help-requests in decred support channels. |
We could introduce a help page that contains links to guides or content for each of the different assets supported in the UI but that would require careful planning and positioning so it fits the client design and is easily accessible. But this is a different issue altogether. A separate issue can be opened if need be to discuss how we can introduce a help page in the client or somewhere easily accessible by non-techy users. |
True, just seems like this doc is a prime example of this occasional need for user-guidance. Moving discussion to #2245. |
Resolves #2224
Click "View file" from the menu for docs/wiki/Ethereum.md to render Markdown.