Content
@
https://warpcast.com/~/channel/walletbeat
0 reply
0 recast
0 reaction
polymutex
@polymutex.eth
Wallet interoperability is what makes this very scenario not a nightmare for users. If interoperability is lost, then web3 just created a new form of lock-in. /walletbeat will do its part to preserve wallet interop. 🫡
2 replies
2 recasts
16 reactions
Zenigame
@zeni.eth
What are the forces working against wallet interoperability?
1 reply
0 recast
1 reaction
polymutex
@polymutex.eth
The push for embedded wallets as a promise for better onboarding UX. The push for payment processor JavaScript libraries that favor some wallets over others. And protocols like WalletConnect that act as intermediary in the wallet connection process, and sit in a position that can selectively block wallet connections. None of these are problems on their own; they are actually useful and positive things. Where it gets pernicious is the over-reliance and over-acceptance of these solutions as a substitute for the real thing, and the fault for that lies mostly on wallet users.
2 replies
0 recast
3 reactions
Zenigame
@zeni.eth
Appreciate you laying things out for me. What do you mean that the fault lies mostly on wallet users? I feel like relying on end-users for alignment with anything that doesn't affect them directly and immediately is a losing battle, but perhaps I'm misunderstanding your argument.
1 reply
0 recast
1 reaction
polymutex
@polymutex.eth
Ultimately it's users' usage patterns that dictate where development effort/ecosystem standards goes. Some users can't/won't use external self-custodial wallets, so embedded wallets become a thing, at the cost of interop - a cost that the user choosing to use an embedded wallet may not realize they are incurring in the moment, and which in the aggregate has externalities beyond the user making that choice due to its effect on development efforts and standards. Walletbeat is an effort to make users care about such things that don't directly/immediately affect them, so that wallet development efforts are affected by more than just pure "utility in the moment"-type choices. Perhaps you're right that it is a losing battle! Won't stop us from trying 🫡
1 reply
0 recast
0 reaction
Zenigame
@zeni.eth
Interesting perspective! Nico showed us walletbeat in Taipei (we were making https://ethglobal.com/showcase/how-doxxed-am-i-ftbux). Really, really like the project. I'm definitely a novice when it comes to the wallet landscape, but I think asking the question of "what upstream changes make self-custodial wallets tenable" (and similar questions) are the direction I'd go in. A future without wallet interop sounds terrible, but user UX preferences (aka human nature) are pretty tough to change without a corresponding carrot.
1 reply
0 recast
1 reaction
polymutex
@polymutex.eth
I love that hackathon project, it's a great idea. Kind of the same thing as what walletbeat is trying to avoid by looking for things like IP address/wallet address correlability, but it sure is more visceral when actually shown with your own wallet address. On "what upstream changes make self-custodial wallets tenable"... I'm not sure. Smart wallets and permissions delegations may get us to a level of UX that matches that of embedded wallets, or perhaps exceeds it. I don't have all the answers, but I hope that shining a light on the problem also helps directionally light the path towards solutions. Also, I like @danfinlay's ERC-7763 (https://ethereum-magicians.org/t/erc-7763-app-keys-for-fully-embedded-accounts/20958) though I'm not sure it would be sufficient on its own to solve the embedded wallet problem at scale.
1 reply
0 recast
2 reactions
