This looks super cool Dani đ
Iâm not totally sure, but middleman looks lIke Itâs a custodial wallet. Could you talk a bit about the threat model youâve been thinking through? Do you have any assurances that the creator of the wallet is the only one who is able to spend?
Thanks @andrew_breck! There are two security models I am thinking about. The first is how to safeguard private keys. The second is how to guard against malicious developers who can request transactions on a userâs behalf.
For private keys, Iâm currently storing them encrypted in a database but clearly more can be done to protect them. One option I started to explore yesterday is to use Keybase as a backend as they have a smart security team already solving this challenge.
As far as malicious developers go, I donât believe I introduce anything new. Developers already get access to user passwords, messages, and payment information depending on the type of app so users already implicitly trust developers.
Iâm very open to ideas on both. Feel free to reach out: Iâm mayor@dani.town.
Very interesting project, wallet connection is a major issue for dApp adoption, while there are things like WalletConnect standards in the pipeline, this approach could be even more user friendly. A few points of my understanding of it, pls correct me if i am wrong.
1. dApps can use your API to create wallet for users instead of rely on web3 connection to existing wallets like metamask. So the wallets shifts from current solution of integrate with browser/as a plugin to integrate directly with the dApp.
2. since private key is stored with you and managed via API, it is up to the dApp to authenticate user and to give them access to their wallet.
3. when user is authenticated, they have full control of their user wallet thus if dApp end auth is compromised, user's wallet is compromised.
Hyper Online
Jam
Berkey