1. 29
  1.  

  2. 5

    A point that the author doesn’t make (because the post is about setting up usernames for a new site) is that you can have requirements for new registrations that are stricter than for existing usernames, although it will be less efficient.

    You can forbid new usernames looking similar to the existing ones, even if there are false positives (well, one name from each cluster can still exist). You can forbid new usernames that are different only in case from the existing ones, even if there are some confusing username pairs in your DB. You can even allow logging in with a username in a different case unless there are two usernames that match.

    Even if you do not solve a problem, you can freeze its scale, and prevent it from later becoming a noticeable load on support (or from being unexpectedly abused).

    1. 2

      Asking for an email-address as an ID and then also a “tag” or username is a way to use this three-pointed identity without having it be cumbersome to the user. Everyone knows no one will share an email publicly, so it gets the point across that one is internal and one is external. You don’t even have to validate that the email is really an email.

      1. 2

        email addresses have been reused. Also people change email addresses. Having the internal id not be email makes that migration easier to implement. The ID ideally is an implemention detail the user never sees.

        1. 2

          Yeah I’m suggesting the email is used to login, a hash is used as the internal id, and a username is used for the public.

          1. 1

            Ah I think I had misunderstood you.