Я не поклонних хабрасуицида, а потому ВКонтакте является лишь катализатором данного мыслеизлияния, а описываемые методы могут быть применены совершенно к любой социальной сети, форуму и прочим местам, где так или иначе производится регистрация пользователя. Оно будет касаться именно системы распределения ников, и связанной с ними проблемы «кто первый встал — того и тапки».
В принципе, проблемы можно избежать. Не всегда и не везде, но можно. Именно о методе избегания «социального киберсквотерства» для разработчиков социальных сетей я и хочу рассказать.
По интернету уже давно ходят шутки, что наше поколение зарегистрировало все красивые ники, и нашим детям придется довольствоваться чем-то вроде megadestroyer66613wow. И если в рамках системы электронной почты актуальность проблемы остается (что, впрочем, компенсируется возможностью создать собственный домен, на котором завести почту с любым ником), так как почтовый адрес является основным (primary) идентификатором пользователя, то в социальных сетях это не так.
Разработчикам давно известно, что большинство сайтов и форумов после регистрации общаются с пользователем через его идентификатор (user ID). Чаще всего — это число, которое является основным ключом (primary key) в таблице БД. Нередко этот ключ является автоинкрементным полем, что избавляет от проблемы генерации идентификаторов для новых пользователей.
Таким образом, в 99% случаев технически пользователь определяется не своими регистрационными данными, а неким уникальным идентификатором, сгенерированным для него системой при регистрации.
Что из этого следует? Из этого следует тот простой факт, что, технически, имя пользователя вовсе не обязано быть уникальным. И даже на каком-нибудь форуме, где пользователи знают друг друга только по никам, технически вполне допустимо для нескольких пользователей использовать один и тот же ник.
Однако, на многих сайтах, ник, кроме выполнения основной функции, используется еще и при авторизации. И тут возникают проблемы — если дать возможность нескольким пользователям использовать один и тот же ник, а они случайно выберут один и тот же пароль — в кого логиниться?
ВКонтакт (и многие другие, надо сказать, например, гугл), ввиду отсутствия у них обязательных ников, обходят эту проблему с использованием электронной почты в качестве одного из элементов пары авторизации. Известно, что адрес электронной почты является уникальным, при этом уникальность его поддерживается внешними (external) механизмами, что избавляет от проблем с идентификацией пользователя. Другие сайты могут использовать пару «логин — отображаемое имя», требовать уникальности первого при отсутствии уникальности второго.
Впрочем, это все была присказка. Теперь перейдем к нашей корневой проблеме.
Итак, допустим, мы — Павел Дуров и решили разрешить пользователям не платить нам стопицот смс-ок за поддомен и символическое имя. Каковы наши действия?
1. Очевидный путь — «будь как все». Мы даем объявление о том, что «пацаны, налетай, регистрируй имя, имя уникальное, кто первый встал — того и тапки» и разрешаем данное действие для ограниченного круга привелегированных пользователей. Привелегированные пользователи расхватывают оригинальные имена, которые в процессе можно будет кому-нибудь выгодно продать. Рай для киберсквоттера.
2. Другой (another) путь — «будь как Википедия». Мы даем объявление о том, что «пацаны, нателай, регистрируй имя, имя уникальности не требует», после чего начинаем разрешать проблемы ambiguous name.
Как разрешается эта проблема? Мы вспоминаем, что имена у нас не являются идентификаторами пользователя, и в случае, если на один поддомен претендует несколько пользователей — мы просто-напросто вместо прямого редиректа показываем список всех пользователей, которые под данным ником зарегистрировались, вместе с информацией о пользователе, чтобы можно было найти «своего». Таким образом, на популярных никах будет скапливаться масса пользователей, делая их бесполезными для идентификации, и пользователи сами собой рассосутся на другие, которые удовлетворяют их требованиям.
Для решения проблемы users-flood (когда целенаправленно регистрируется множество пользователей под одним ником, чтобы «забить» его и сделать непригодным для употребления) можно использовать механизм смс-подтверждения. В этом случае, данное действие будет гораздо более проблематичным. Либо, как вариант, вернуть возможность полного «выкупа» домена для самых страждущих, у которых на это может быть завязан бизнес (есть такие?)
Зато — все честно, и никаких драк.
В принципе, проблемы можно избежать. Не всегда и не везде, но можно. Именно о методе избегания «социального киберсквотерства» для разработчиков социальных сетей я и хочу рассказать.
По интернету уже давно ходят шутки, что наше поколение зарегистрировало все красивые ники, и нашим детям придется довольствоваться чем-то вроде megadestroyer66613wow. И если в рамках системы электронной почты актуальность проблемы остается (что, впрочем, компенсируется возможностью создать собственный домен, на котором завести почту с любым ником), так как почтовый адрес является основным (primary) идентификатором пользователя, то в социальных сетях это не так.
Разработчикам давно известно, что большинство сайтов и форумов после регистрации общаются с пользователем через его идентификатор (user ID). Чаще всего — это число, которое является основным ключом (primary key) в таблице БД. Нередко этот ключ является автоинкрементным полем, что избавляет от проблемы генерации идентификаторов для новых пользователей.
Таким образом, в 99% случаев технически пользователь определяется не своими регистрационными данными, а неким уникальным идентификатором, сгенерированным для него системой при регистрации.
Что из этого следует? Из этого следует тот простой факт, что, технически, имя пользователя вовсе не обязано быть уникальным. И даже на каком-нибудь форуме, где пользователи знают друг друга только по никам, технически вполне допустимо для нескольких пользователей использовать один и тот же ник.
Однако, на многих сайтах, ник, кроме выполнения основной функции, используется еще и при авторизации. И тут возникают проблемы — если дать возможность нескольким пользователям использовать один и тот же ник, а они случайно выберут один и тот же пароль — в кого логиниться?
ВКонтакт (и многие другие, надо сказать, например, гугл), ввиду отсутствия у них обязательных ников, обходят эту проблему с использованием электронной почты в качестве одного из элементов пары авторизации. Известно, что адрес электронной почты является уникальным, при этом уникальность его поддерживается внешними (external) механизмами, что избавляет от проблем с идентификацией пользователя. Другие сайты могут использовать пару «логин — отображаемое имя», требовать уникальности первого при отсутствии уникальности второго.
Впрочем, это все была присказка. Теперь перейдем к нашей корневой проблеме.
Итак, допустим, мы — Павел Дуров и решили разрешить пользователям не платить нам стопицот смс-ок за поддомен и символическое имя. Каковы наши действия?
1. Очевидный путь — «будь как все». Мы даем объявление о том, что «пацаны, налетай, регистрируй имя, имя уникальное, кто первый встал — того и тапки» и разрешаем данное действие для ограниченного круга привелегированных пользователей. Привелегированные пользователи расхватывают оригинальные имена, которые в процессе можно будет кому-нибудь выгодно продать. Рай для киберсквоттера.
2. Другой (another) путь — «будь как Википедия». Мы даем объявление о том, что «пацаны, нателай, регистрируй имя, имя уникальности не требует», после чего начинаем разрешать проблемы ambiguous name.
Как разрешается эта проблема? Мы вспоминаем, что имена у нас не являются идентификаторами пользователя, и в случае, если на один поддомен претендует несколько пользователей — мы просто-напросто вместо прямого редиректа показываем список всех пользователей, которые под данным ником зарегистрировались, вместе с информацией о пользователе, чтобы можно было найти «своего». Таким образом, на популярных никах будет скапливаться масса пользователей, делая их бесполезными для идентификации, и пользователи сами собой рассосутся на другие, которые удовлетворяют их требованиям.
Для решения проблемы users-flood (когда целенаправленно регистрируется множество пользователей под одним ником, чтобы «забить» его и сделать непригодным для употребления) можно использовать механизм смс-подтверждения. В этом случае, данное действие будет гораздо более проблематичным. Либо, как вариант, вернуть возможность полного «выкупа» домена для самых страждущих, у которых на это может быть завязан бизнес (есть такие?)
Зато — все честно, и никаких драк.
