(Context: new people we don’t know on GitHub, opening PRs for code that would be kredited.)
As we haven’t solved the onboarding friction yet (the currently deployed code still requires a wallet address), and also any onboarding done for Ethereum Rinkeby would require some amount of explanation and help for a mainnet migration to e.g. RSK, I’m wondering how to best handle new contributors until then.
After considering alternatives, I think it might be best to simply create fresh wallets for them, store the seed phrases somewhere safe, but accessible to @Ops or @Core, and manually create the contributor records on Rinkeby via Kredits Web.
This way, they could start collecting kredits via our normal integrations, but without us having to onboard them during this experimental phase, or even telling them about it yet. After the mainnet migration, we could then onboard them properly, and let them authenticate with either the seed phrase or an external account to configure their actual wallet.
@Kredits What do you think? Agree, disagree, other ideas?
hmmm. we had experimented with brain wallets before. What do you think about that? people can generate a wallet using a password (which generally should be discouraged as people are bad with password), but this would work in this case. People have to remember the password and we do not have to store any keys.
The way I see it, the friction comes from having to deal with any wallets, passwords, or the entire idea of kredits at that point. Only when they want to interact with the contracts themselves do they actually need to have a wallet.
But either way, brainwallet or not, my question is not about a solution for if we spend time implementing something new. I’m trying to deal with the currently deployed code and the wish not to lose kredits for new contributors before onboarding them to an actual (mainnet) solution. My goal is to have a couple of new accounts that can record kredits today, but without having to explain to someone that they have to go to some website and set a password for a wallet there first, and that otherwise I cannot merge the PR.
OK, so I just added a new profile with the address of a newly generated wallet. And then I realized, as long as we generate a fresh wallet address, we don’t even need to store any keys for anyone, until they want or need to interact with the contracts.
So that’s what I’ll do for now. Just generate an empty new wallet, then throw away the private keys. And later, we update the profile with a real wallet from whatever we decide to implement, or even just manually with core permission until we’ve implemented that.