Hedgehog Ethereum wallet: Build DApps like apps, without centralized keys

The approach we've taken at Audius on initial funding is to avoid funding the wallet entirely - we use EIP-712 signatures combined with a trustless transaction relay service that pays gas / submits EIP-712 signed transactions on-chain on behalf of users. In this way, the user wallet never holds any tokens but is still used to secure access to their account. We'll be open-sourcing our contracts and infrastructure code soon, but here's a good public example of this model in action: https://github.com/hellobloom/core/tree/master/contracts

That said, other folks may decide to use Hedgehog differently - perhaps you integrate with something like Wyre (https://www.sendwyre.com/) to help users fund their wallet client-side without knowing that crypto is there.

There are tons of helpful resources online though, as lots of folks write tutorials and other things. Googling most problems you face will yield good results.

This was documented only indirectly - we should add a specific note / example for this. The model here is that the ethereumjs-wallet object returned by Hedgehog (eg. by getWallet https://audiusproject.github.io/hedgehog-docs/#getwallet ) follows this API https://github.com/ethereumjs/ethereumjs-wallet which, when used in tandem with this package https://github.com/ethereumjs/ethereumjs-tx can do everything a normal Ethereum wallet would.

We are also thinking about offline ways to share the key such that the centralized side is not required - eg. a QR code displayed on one device and scanned by another to propagate the wallet. This creates a problem if a user loses all of their devices though.

Here's the key section of code that makes this Ethereum-specific: https://github.com/AudiusProject/hedgehog/blob/master/src/au...

You could replace the use of 'ethereumjs-wallet/hdkey' with any other chain wallet library if it is compatible with the BIP-39 style HDWallet structure. Bitcoin and many other blockchains have compatible libraries that could be substituted easily!

There is not - this is the biggest deficiency of Hedgehog today. Without centralized custody of keys, it's not possible to have someone prove their ownership of a given key to a centralized party in order to unlock it. The key is encrypted, so the application provider nor anyone else can decrypt it without the user's username/password combination. This tradeoff is both a good thing and a bad thing in our view.

That said, there is a mechanism for changing your password if you are already signed in.

We are considering some mechanisms for fallbacks, eg using a threshold cryptosystem with multiple private keys and a 1 or 2 of n requirement, such that if a user forgets the way to generate one of the n keys they may still remember a way to generate the other(s). If you're curious, more on these schemes here: https://en.wikipedia.org/wiki/Threshold_cryptosystem

We feel these tradeoffs make sense to enable more mainstream adoption of cryptocurrencies, but they are tradeoffs; for certain types of applications the cost of losing control of an account is too high for this approach to make sense.

See: https://audiusproject.github.io/hedgehog-docs/#important-los...

This is why we recommend that you audit all 3rd-party Javascript in your app for accesses to localstorage, and avoid sourcing 3rd-party javascript from uncontrolled origins (the code could be switched out from under you if it is not baked into your application)

The post message model is an interesting one - we looked into designing Hedgehog in that way, but decided it ultimately did not help solve this issue and created unnecessary complexity. If you include Javascript from libraries or other origins on your page, eg. Google Analytics, that Javascript could still post-message into your iframe.

Perhaps we are wrong here though! Is FinneyFor open-source? Would love to see how this is implemented.