#
Overview
Inkey is embedded by your app in an iframe, and messages are sent back and forth between the iframe using the PostMessage API.
When a user creates an account, only they have access to it. This means they can do whatever they want to with their account – unlike a custodial account — but it comes with one important caveat:
Users cannot recover accounts if they forget the password or lose the mnemonic.
This hybrid structure — created by us, managed by them — is a nice happy medium between placing the entire responsibility of wallet management on users, which makes it very difficult.
#
Why use Inkey?
The primary use for Inkey is to onboard users that have no previous blockchain (or Algorand) experience, and may not already possess a wallet. It makes onboarding relatively painless by mimicking how username & password authentication works in web2.
#
Ease-of-use
Customers can connect to your dApp and sign transactions without having to scan QR codes or manage a separate browser extension. No installation needed.
#
Portability
The same Inkey account can be used between devices to access the same dApp. All the user needs is the username & password.
#
Security
TODO: A bit about encryption
TODO: A bit about FIDO support
#
Customization
Inkey is themeable — all you have to do is pass query params to the iframe src, e.g. https://inkey.app/?text=f00&link=0f0
. Check out the guide below:
#
Decentralization
While we currently store encrypted user accounts on a central server (Firebase), our roadmap includes a plan to store these accounts on the Algorand blockchain. Because they are encrypted, and only the user knows the decryption phrase (their password), public storage of the accounts is possible.