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