Вход как угодно: почему регистрация в Letopis стала отдельной архитектурой

В Letopis обычная регистрация довольно быстро перестала подходить. Не потому что мне хотелось сделать особенную auth-систему ради архитектурного спорта. Скорее наоборот: я пытался не усложнять, но продукт сам вытолкнул меня в это место.

Если Letopis должен жить и в вебе, и в Telegram, пользователь может начать с бота, потом открыть кабинет в браузере, потом вернуться к боту за кодом, потом зайти с другого устройства по ссылке. В такой модели вход перестаёт быть формой перед продуктом. Он становится частью продукта.

Я хотел простую на уровне ощущения вещь: человек должен иметь возможность попасть в свой аккаунт как угодно и откуда угодно. Через веб. Через Telegram. Через email-код. Через ссылку. Через пароль, если он любит пароли. Без пароля, если он не хочет заводить пароль прямо сейчас. И главное, без ощущения, что у него есть "веб-аккаунт" отдельно и "телеграм-аккаунт" отдельно, которые потом надо как-то склеивать молитвами.

Аккаунт отдельно, каналы отдельно

Первое нормальное решение здесь было разделить аккаунт и способы входа.

Аккаунт в Letopis один. Это не Telegram-пользователь и не email-адрес. Это запись человека, его будущая база знаний, его сессии, его настройки, его данные. А Telegram, email и пароль — это каналы, через которые этот аккаунт можно доказать и открыть.

Звучит почти очевидно, но без этого разделения всё быстро превращается в кашу. Telegram может быть способом зарегистрироваться. Email может быть способом подтвердить регистрацию. Пароль может быть фактором входа, но не самостоятельной личностью. Открытая браузерная вкладка может быть местом, куда прилетает код, хотя сама по себе она не является идентичностью в том же смысле, что Telegram или email.

Из-за этого экран входа должен начинаться не с набора красивых логотипов, а с выбора способа входа для одного аккаунта. Например, Telegram id может быть привязан к аккаунту как способ входа. А Telegram DM может быть местом, куда прилетит одноразовый код. В интерфейсе это не должно смешиваться в одну кнопку с непонятным смыслом.

Пользователь выбирает не абстрактный канал, а конкретный способ попасть в аккаунт: пароль, одноразовый код, magic link, Telegram-вход. А уже внутри выбранного метода система решает, куда можно доставить подтверждение: в браузер, на почту, в Telegram или в будущий канал вроде Slack и Signal.

Регистрация может начаться из веба или Telegram

Я не хотел, чтобы Letopis начинался только с веб-формы. Человек может прийти с лендинга, а может впервые написать боту. Оба пути должны вести к одному и тому же типу аккаунта.

В вебе человек вводит email и username, а пароль может задать сразу или пропустить. Если он пришёл просто посмотреть, что такое Letopis, странно начинать отношения с требования "придумай пароль, повтори пароль, пароль слабый, пароль не совпал". Достаточно подтвердить email кодом, войти и уже потом решить: жить на кодах и ссылках или добавить обычный пароль.

В Telegram логика похожая по смыслу: бот не должен автоматически плодить аккаунты. Если Telegram ещё не привязан, человеку дают два понятных пути: создать новый аккаунт из Telegram или войти в существующий и привязать этот Telegram к нему. В обоих случаях цель одна — не сделать "бот-аккаунт" рядом с "веб-аккаунтом", а привести человека к его одному Letopis.

Вход начинается не с пароля

Классический экран логина спрашивает email и password. Letopis сначала спрашивает идентификатор: username, email или Telegram. После этого система отвечает списком способов входа, которые есть у этого аккаунта.

Это важная деталь. Discovery ничего не отправляет и не создаёт. Оно только честно отвечает: вот какие способы входа можно выбрать сейчас. Отправка кода или письма начинается уже после выбора метода.

Если у аккаунта нет пароля, пароль не показывается. Если нет живой браузерной сессии, не показывается вход через открытую вкладку. Если Telegram не привязан, Telegram не притворяется доступным способом входа. Если identifier вообще не найден, система говорит, что аккаунт не найден, и предлагает регистрацию, а не заставляет человека гадать, что произошло.

Мне нравится этот компромисс: там, где человек выбирает путь, UI честный; там, где начинается отправка на внешний канал, безопасность остаётся аккуратной. Например, запрос magic link не должен превращать email в оракул существования аккаунта.

Код, ссылка и пароль — не одна и та же кнопка

Снаружи всё это часто называют "войти по email", но для пользователя это разные обещания.

Код удобен, когда ты уже стоишь в форме и не хочешь прыгать между вкладками. Ссылка удобна, когда нужно перенести вход между устройствами или почтовым клиентом и браузером. Пароль удобен тем, кто хочет привычный быстрый вход.

Это не три декоративные кнопки одного и того же. У каждого способа свой риск и свой нормальный сценарий. Поэтому пароль в Letopis не должен становиться центром мира только потому, что так исторически сложилось. Он полезен, но он не обязан быть первым шагом и не обязан существовать у каждого аккаунта.

Мне нравится в этой модели ещё и то, что она спокойно расширяется. Если завтра появится Slack, Signal или любой другой канал, не нужно придумывать новую сущность пользователя. Новый канал просто становится ещё одним местом, куда можно доставить доказательство, или ещё одним подтверждённым способом владения аккаунтом. Аккаунт остаётся тем же.

Telegram не второй сорт, а такой же вход

Telegram в Letopis — не уведомлялка сбоку. Это полноценный канал входа и будущий рабочий интерфейс.

Бот на /start не создаёт аккаунт автоматически. Сначала он проверяет: этот Telegram уже привязан, заблокирован или вообще неизвестен? Если Telegram неизвестен, дальше есть два сценария. Можно создать новый аккаунт прямо из Telegram. Можно доказать доступ к существующему аккаунту через email, пароль или другой доступный метод и привязать текущий Telegram к нему.

Здесь важно не доказывать владение аккаунтом тем Telegram, который мы только пытаемся привязать. Иначе получается круговая логика: "докажи, что аккаунт твой, через канал, который ещё не доказан". Поэтому Telegram может быть местом старта, но при привязке к старому аккаунту он проходит через уже доверенный способ.

После привязки Telegram становится нормальным каналом. Через него можно входить, получать коды и работать с продуктом. При этом бот не должен превращаться в маленький сейф с долгоживущими пользовательскими токенами. Его задача — быть разговором и доставкой, а не хранить внутри себя весь доступ к аккаунту.

Отвязка тоже не мелочь

Привязать канал легко. Безопасно отвязать канал сложнее.

Если Telegram можно отвязать одной кнопкой без свежего подтверждения, украденная сессия может тихо отрезать владельца от важного способа входа. Если требовать полноценный повторный вход прямо в боте на каждое действие, UX становится странным: человек нажал "выйти" в Telegram, а бот просит пройти лишнюю церемонию.

Поэтому для опасных изменений нужен свежий контекст, но без театра безопасности. В вебе это может быть пароль или одноразовый код. В Telegram — сам факт живого привязанного диалога для конкретной операции. Пользователь видит понятный шаг, а система всё равно не даёт менять каналы доступа на старой сессии без проверки.

И ещё есть простое правило: нельзя удалить последний стабильный способ входа и оставить человека с аккаунтом, в который он больше не может попасть. Это звучит банально, но такие банальные правила лучше держать в коде, чем потом объяснять в поддержке.

Почему это стоило сделать сейчас

Можно было бы сначала сделать обычный email+password, а Telegram прикрутить потом. Но тогда Telegram почти неизбежно стал бы пристройкой. Начались бы странные состояния: пользователь есть в боте, но не в вебе; аккаунты надо склеивать; восстановление доступа требует ручных исключений.

А Letopis по смыслу не веб-приложение с Telegram-уведомлениями. Это продукт, который должен нормально жить между каналами.

Я хочу, чтобы человек мог начать там, где ему естественно. Пишет мысли в Telegram — пусть начнёт в Telegram. Открыл лендинг с ноутбука — пусть начнёт в вебе. Не хочет пароль — пусть войдёт кодом. Хочет привычный пароль — пусть задаст. Потерял устройство — у него есть другие каналы.

В идеале пользователь вообще не думает об этой архитектуре. Он вводит то, что помнит, видит честные варианты, получает код туда, куда обещали, и попадает в тот же аккаунт. Для такой части продукта это лучший результат: всё работает, и почти ничего не видно.