How to onboard users?
Onboarding users to ByteFast Auth is very straightforward and similar to setting up 2FA. Just easier:
Either add a
public address or
pubkey field to your user database table or create a new table that stores bytewallet user profiles. For example:
CREATE TABLE `bf_fast_auth` (
`id` INT(10) NOT NULL AUTO_INCREMENT,
`email` VARCHAR(150) NULL DEFAULT NULL ,
`domain` VARCHAR(150) NULL DEFAULT NULL ,
`pubkey` VARCHAR(150) NULL DEFAULT NULL ,
`phone` VARCHAR(50) NULL DEFAULT NULL,
PRIMARY KEY (`id`) USING BTREE,
UNIQUE INDEX `email_domain_address` (`email`, `domain`, `pubkey`) USING BTREE,
INDEX `phone` (`phone`) USING BTREE
On a user's account page offer a "ByteWallet Setup" section. In this section simply generate a QR code for a webhook that will receive the user's public key. ByteWallet will send you a fully digitally signed message that allows you to verify the sender's public address is indeed belonging to a private key the user owns. Create an authentication string/token on the spot and attach it to this QR code as in the previous webhook examples.
Once the user scan's this QR code on his account page, your webhook will receive a request, verify the signature checks out (to verify its not someone else's public key) and then take the authentication token and look it up in your user database. When you find the authentication token, replace it with the user's public address.
And that's it - you are all set!
At this point your user's original account is linked to his ByteWallet.
For bonus points, think of a sign up process in which you do not require a user's username and password or phone number - simply present a QR code, let the user scan it and capture the incoming webhook to store that very public key as the "username". From now on, your user will be identified by this public address which was deterministically derived from your DOMAIN name and the user's PRIVATE key - a clear way to identify the user on your service henceforth in a secure, futuristic and decentralized fashion.