For the upcoming registration of user-friendly VKontakte names

    I’m not a fan of habrasuicide, and therefore VKontakte is only a catalyst for this thought outburst, and the described methods can be applied to absolutely any social network, forum and other places where user registration is somehow made. It will relate specifically to the nickname distribution system, and the related problem of "who first got up - that and slippers."

    In principle, problems can be avoided. Not always and not everywhere, but it is possible. It is about the method of avoiding "social cybersquatting" for social network developers that I want to tell.

    It has been a joke on the Internet for a long time that our generation has registered all the beautiful nicknames, and our children will have to be content with something like megadestroyer66613wow. And if the urgency of the problem remains within the framework of the e-mail system (which, however, is compensated by the ability to create your own domain on which to start mail with any nickname), since the mailing address is the primary identifier of the user, then this is not so in social networks.

    Developers have long known that most sites and forums after registration communicate with the user through his identifier (user ID). Most often, this is a number that is the primary key in the database table. Often this key is an auto-increment field, which eliminates the problem of generating identifiers for new users.

    Thus, in 99% of cases, the user is technically determined not by his registration data, but by some unique identifier generated by the system during registration.

    What follows from this? It follows the simple fact that, technically, the username does not have to be unique. And even on some forum where users know each other only by nicknames, it is technically quite acceptable for several users to use the same nickname.

    However, on many sites, a nickname, in addition to performing the main function, is also used for authorization. And here there are problems - if you allow several users to use the same nickname, and they accidentally choose the same password - who should log in?

    VKontakte (and many others, I must say, for example, Google), due to the lack of mandatory nicknames, bypass this problem using email as one of the elements of an authorization pair. It is known that an email address is unique, while its uniqueness is supported by external mechanisms, which eliminates problems with user identification. Other sites can use a pair of "login - display name", require the uniqueness of the first in the absence of uniqueness of the second.

    However, it was all a saying. Now let's move on to our root problem.

    So, let's say we are Pavel Durov and decided to allow users not to pay us a stop message SMS-ok for the subdomain and symbolic name. What are our actions?

    1. The obvious way is "be like everyone else." We are announcing that "boys, fly on, register a name, a unique name, who first got up and slippers" and allow this action for a limited circle of privileged users. Privileged users grab the original names, which in the process can be profitably sold to someone. Paradise for the cybersquatter.

    2. Another way is “be like Wikipedia”. We are announcing that "boys, do it, register a name, the name does not require uniqueness," after which we begin to resolve the ambiguous name problem.

    How is this problem resolved? We recall that our names are not user identifiers, and if several users apply for one subdomain - we simply instead of a direct redirect show a list of all users who are registered under this nickname, along with information about the user, so that was to find "his". Thus, a lot of users will accumulate on popular nicknames, making them useless for identification, and users themselves will resolve to others that satisfy their requirements.

    To solve the users-flood problem (when a lot of users are purposefully registered under one nickname in order to “score” it and make it unusable), you can use the SMS confirmation mechanism. In this case, this action will be much more problematic. Or, as an option, to return the possibility of a complete "redemption" of the domain for the most afflicted, who may be involved in this business (are there such?)

    But then - everything is fair, and no fights.

    Also popular now: