Improve wallet filtering

[ligi]

Currently the wallet filter looks like this:

I see room for improvement here. First of all the IMHO most important criteria is missing "The Wallet is fully libre software / open source"
Also I am really missing a filters like

• a filter for which chains are supported (especially important in the upcoming L2 world)
• which platform is supported (Android, Linux, iOS, mcOS, windows, browser)
• hardware wallet support
• supports WalletConnect
• supports Sourcify

And I see that from a UX perspective there should not be too many filters - but I also see a lot of filters that IMHO can be dropped as these things are IMHO things that should happen on the dApp level - not on the Wallet level. It is even a security benefit if you reduce the stuff that the wallet is doing to things that are core of a wallet.
IMHO what can be dropped:

• decentralized token swaps (should be on L2 like on uniswap and just communicate with the wallet via WalletConnect)
• Buy crypto with credit card
• Access to financial tools
• Withdraw to a bank
• High volume purchase

What should stay for sure is:

• Multi-signature accounts
• Limits protection
• maybe Explore dapps

I know this is a big change (especially the non-binary filters like supported platforms/chains) - maybe it is best to start small and for now just add the new filter "Fully libre software" that is IMHO really missing here.

[jzaki]

I feel filters like "Buy crypto with credit card" are useful for on-boarding new users.

I'm in support of the filters you list, but see them as "Advanced" filters (or some other division). E.g. knowing the licensing, networks supported, hw wallet... even broad categories of these seem too technical for new users. Or at least less actionable by users looking to try a wallet.

There is probably a meaningful divide of filters somewhere: new user capabilities, vs software capabilities.
And agree it would be good to surface "Fully libre software" somehow.

[ligi]

Thanks for joining the conversation!

TBH I am not really sure if they should be hidden behind "Advanced"
especially the networks - IMHO it is really important to know for the users which networks are supported. Also the platform should not be hidden behind "advanced". Especially in the L2 aera we are about to enter.
About the license and HW-Wallets we can talk. But IMHO the availability of the source-code is really important. I even think if you use a closed-source wallet you are practically using a custodial one - because you do not know if it sends the keys home. Would even go so far to say the foundation should not list such wallets - but I am being pragmatic here for the time being as the list of wallets would be very small then ;-)
But yea the actual license might be hidden under "Advanced" (really hope Richard Stallman does not read his though :)
Maybe another option could also be (to not have too many complex filters that lead to bad UX) to have warnings like "Source code not available" or "not libre software" next to the wallets.

[jzaki]

Looking back at the path to get to that filter screen (find-wallet), it's a screen beyond /wallets already, so I take back the need for yet another layer (/wallets/find-wallet/advanced not needed).

I really like the idea of a top-level signal of the benefit of the source openness (or not): eg "Openly maintainable", "(No) Tech Lock-in", "Anti-fragile fallback"/"Single point of failure", ... Or simply the signal: "Open(/Closed) App", "Proprietary"...

Can imagine this as an icon next to each wallet with hover-over text.

[samajammin]

Thanks for the input @ligi @jzaki - lots of good ideas here.

It's certainly a balance between serving new & more advanced users but I agree, ultimately we should make the relevant information available for the folks who are looking for it.

Our team will be mapping out Q2 goals shortly & wallet page improvements are likely on that list. Together they make ~20% of site pageviews. In the meantime, I welcome input on content / design from anyone. One major area we could certainly use help with is the data collection for the wallets! You can find the source file here:
https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/wallets.csv

[ligi]

@samajammin thanks for the reply and great to hear you are open to changes here and might add it to the roadmap!

regarding the WalletData I opened #2730

would also like to add things here (e.g. my favorite wallet: http://walleth.org :) - but I think it makes sense to change the format first to reduce the amount of work afterwards

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[ligi]

commenting so the bot is not closing it - I think the issue is still very relevant. @samajammin seems this issue did not make it to the Q2 goals - maybe Q3? I think it is quite important.

[ligi]

In the context of EIP-1559 it would also be nice to have a filter if the wallet supports it. So users will know if they overpay and it is an incentive for the wallet to support it. Some wallets like TREZOR need some convincing to support 1559.

[timbeiko]

@ligi I like that idea. This is also true for EIP-2930 transactions.

[ligi]

Do you know a wallet that has 2930 support implemented or on the agenda?

[timbeiko]

No idea - I haven't really looked into it.

[ryancreatescopy]

I personally disagree with introducing filters that reference specific EIPs like 1559... this is a step further down the rabbit hole than I'm comfortable with. This page is intended to support new Ethereum users getting started in the space. I see 1559, at this stage, being a choice for more advanced users. However, if we re-label 1559 as something the user might understand intuitively it could work: what's the benefit of 1559 to end users?

Ultimately we probably need to refresh the filters soon but these should all reflect tangible user benefits and not require existing knowledge of anything Ethereum-based, ideally.

cc @wackerow @samajammin

[wackerow]

@ryancreatescopy I do agree that we should be careful how technical we get with this page.

"what's the benefit of 1559 to end users?"

That being said, EIP-1559 is supposed to be a UX improvement for users. The short-term volatility in gas fees is what this addresses, and users are going to want to benefit from it.

"However, if we re-label 1559 as something the user might understand intuitively it could work"

100%

Could use some marketing/branding.

[jzaki]

I think a top-level signal of EIP-1559 explained simply (eg "Transaction fee stability") would be good.

Akin to open-source as, say, "Development transparency".

[ligi]

@jzaki I agree - we need a better name/branding for EIP-1559 when it hits end-users. Not yet sure about "Transaction fee stability" though as the fees are still moving and are not stable - that could message a wrong message to the users. E.g. when they see their transfer costs 1$ today and 2$ tomorrow - then they wonder "is this stable fee feature broken"? I would throw "simple fees" into the ring for a new term.

I can get behind "Development transparency" and cannot yet imagine a better term. Although there might be one out there that captures more properties that arise like user freedom (e.g. to modify the code) or also product transparency and security improvements coming from that aspect.

[AFDudley]

I think a top-level signal of EIP-1559 explained simply (eg "Transaction fee stability") would be good.

Akin to open-source as, say, "Development transparency".

In this context I prefer "fee optimization" and a reference to the fork, not the EIP.

[timbeiko]

Perhaps another option is "Excess Fee Refund" or something similar. One of the nice things about 1559 is that you get a refund for the difference between your maxFee and what was paid in the baseFee + priorityFee. I really like "fee optimization" too, but you could argue that a non-1559 wallet could provide good estimations.

[wackerow]

"Smart fees"

?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[timbeiko]

In the spirit of not letting this go stale and "shipped is better than perfect", does anyone oppose @AFDudley's "Fee Optimization"?

[wackerow]

Not against that at all... do we have any idea which wallets are updated to fully support EIP-1559 yet?

[FrederikBolding]

https://app.mycrypto.com/ will support EIP 1559 at launch

Trackable here: MyCryptoHQ/MyCrypto#4045

[carlfairclough]

To echo @ryancreatescopy's comment, I'm not sure whether referencing specific EIPs is useful to end users. Questions that matter for new users regarding transactions (especially when this is viewed as an onboarding resource) might be:

• are fees low?
• do transactions get processed?

Information about fee variability and steps taken to mitigate that belongs elsewhere, unless this page is to become a comprehensive wallet-feature-matrix.

I'm also anti-"Fee Optimization". It's very generic—grandfathered transactions can still be highly optimised.

Regardless, https://status.im will be supporting 1559 and work is trackable across multiple branches:
https://github.com/status-im/status-react/tree/wallet/eip1559-ui
https://github.com/status-im/status-desktop/tree/feat/eip1559
https://github.com/status-im/status-go/tree/feature/suggest-fees

[timbeiko]

@carlfairclough what do you think about "Excess Fee Refund"? It really is what 1559 provides, but I'm concerned it is just too weird of a label. Any other suggestions?

[carlfairclough]

@timbeiko I'm much more for saying exactly what it does like your suggestion. It's possibly worth noting that there is an existing 1559 explainer page too, which this could connect to: #3104

[ligi]

I think the talk by vitalik buterin at ethCC "Things that matter outside of defi" is also very much relevant in this context and plays to the point I initially wanted to make here.
Currently the filtering is very much DeFi centric - 5/8 filters are around DeFi - but Ethereum is about so much more than DeFi and IMHO the ethereum.org website should reflect that!

[samajammin]

I personally disagree with introducing filters that reference specific EIPs like 1559... this is a step further down the rabbit hole than I'm comfortable with. This page is intended to support new Ethereum users getting started in the space.

I tend to agree with @ryancreatescopy on this. A filter for EIPs seems like unnecessary complexity to be pushing onto users who are new to Ethereum.

One alternative route may be to add EIPs to our listing policy:
https://ethereum.org/en/contributing/adding-products/
This might be an extreme stance but we could just make EIP 1559 support (& any other EIPs) a requirement for wallets in order to get listed on the site. We could simply remove wallets that don't support it. What do folks think about that as an approach?

If that isn't a feasible approach, I suppose I could get behind @timbeiko's suggestion around a "fee refund" feature, given that doesn't require too much pre-existing knowledge to understand the value prop.

[timbeiko]

I'd be in favor of simply not listing non-1559 supporting wallets if that's easier, but you probably want to wait ~6 months before you do that to give everyone the chance to add support.

[ligi]

I would also be fine with just removing wallets that do not support EIP1559 - would even make a shorter period like 3 months
My main intention behind this issue are removing these DeFI centric filters in favor to the other ones I mentioned initially anyway ..-)

[samajammin]

Hey folks - following up here - we made the tough decision as a team to not prioritize this issue this quarter (you can find our priorities in our roadmap here: #3446). This will for sure be something we (particularly @minimalsm) dedicate time towards before the end of the year.

Thank you for your patience on this! Please feel free to share ideas & weigh in on what you think the best approach forward is.

[github-actions]

This issue is stale because it has been open 45 days with no activity.

[corwintines]

Removing stale tag, we will be looking at this during Q4

[github-actions]

This issue is stale because it has been open 45 days with no activity.

[corwintines]

Hey @ligi, we are looking at the wallets section of ethereum.org as part of our Q1 roadmap, and part of that will be coming up with a plan to improve the wallet filtering. Appreciate the input and these are some great options. Would like to chat about this some more now that the ball is rolling.

[ligi]

Great! Happy to chat

[github-actions]

This issue is stale because it has been open 45 days with no activity.

[github-actions]

This issue is stale because it has been open 45 days with no activity.

[samajammin]

Is this complete @corwintines? I believe we solved as part of #6274 but LMK if I'm wrong.

[corwintines]

I would say we addressed this issue with the revamp. @ligi I'm going to close this issue now that #6274 has been finished. Please reopen another issue if you disagree :) Thanks again for this suggestion, it helped shape a lot in the redesign.