Two similar user names, one without any proofs, is kind of obvious.

The current implementation allows the creation of an account using an email address and a passphrase. Since those are so easy to come by, this invites imposters to create several accounts to leverage the (illusory, in this case) trust that keybase offers. It's bad for keybase, and it's bad for the imposter's victim. I propose a solution.

The form that asks for the email address, username, and password could also indicate that the account will NOT be live until one proof has been provided, and once that happens, it will be live for some relatively short duration during which a second proof should be submitted. It's easy enough to make a PGP key, and some other proofs are relatively easy, so they should only buy the new account holder a little bit of time. Public accounts like FB, Twitter, Github, and Reddit are a bit more obvious, so they can buy more time. A website is pretty good because it requires the owner to pay hosting fees, so a proof of that nature

These various proofs can be used to enable features of the platform.

Perhaps this filter can be disabled until someone claims that their username has been spoofed. For example, a friend in Las Vegas has a username, let's say it's GamblinGent, and an imposter has taken the username GamblinGent_lv. The imposter should get to have a hard time unless he can make it obvious that he isn't GamblinGent.

The issue names no files or tests. Start by reviewing the account-creation form and proof-verification flow, then clarify the proposed timing, proof requirements, and feature restrictions. Done requires an agreed design for unverified accounts, first-proof accounts, and accounts with multiple proofs.

Written by the indexing model from the issue text.