Sign in however you want: why registration in Letopis became its own architecture
Ordinary registration stopped fitting Letopis pretty quickly. Not because I wanted a special auth system for the sake of architecture. Almost the opposite: I was trying not to overbuild it, but the product kept pushing me into this problem.
If Letopis lives both on the web and in Telegram, a person can start with the bot, open the cabinet in a browser, return to the bot for a code, then sign in from another device with a link. In that model, sign-in is no longer a form before the product. It becomes part of the product.
The thing I wanted to feel simple was this: a person should be able to get into the same account however and from wherever it makes sense. Through the web. Through Telegram. With an email code. With a link. With a password, if they like passwords. Without a password, if they do not want to create one right now. And without the feeling that they have a separate “web account” and “Telegram account” that later need to be glued together.
Account separately, channels separately
The first sane decision was to separate the account from the ways to sign in.
A Letopis account is one thing. It is not a Telegram user and not an email address. It is the person’s future knowledge base, sessions, settings, and data. Telegram, email, and password are ways to prove and open that account.
That sounds obvious, but without the split everything turns into mud. Telegram can be a way to register. Email can confirm registration. A password can be a sign-in factor, but not a separate identity. An open browser tab can be a place where a code arrives, although it is not an identity in the same sense as Telegram or email.
Because of that, the sign-in screen should not begin with a row of pretty logos. It should begin with the methods available for one account. A Telegram id can be attached to an account as a way to sign in. Telegram DM can also be a place where a one-time code arrives. Those two ideas should not collapse into one button with an unclear meaning.
The user is not choosing an abstract channel. They are choosing a concrete way to enter the account: password, one-time code, magic link, Telegram sign-in. Then, inside the selected method, the system decides where proof can be delivered: to the browser, to email, to Telegram, or later to Slack, Signal, or another future channel.
Registration can start on the web or in Telegram
I did not want Letopis to begin only with a web form. A person may come from the landing page, or they may first write to the bot. Both paths should lead to the same kind of account.
On the web, a person enters email and username, and can either set a password immediately or skip it. If they came just to see what Letopis is, it feels strange to start with “invent a password, repeat the password, the password is weak, the passwords do not match.” It is enough to confirm email with a code, enter the product, and decide later whether to live with codes and links or add a password.
In Telegram, the meaning is similar: the bot must not automatically create accounts. If the Telegram account is not linked yet, the person gets two clear paths: create a new account from Telegram, or sign in to an existing account and attach this Telegram to it. The goal is not to create a “bot account” next to a “web account”, but to bring the person to their one Letopis.
Sign-in does not start with a password
A classic login screen asks for email and password. Letopis first asks for an identifier: username, email, or Telegram. After that, the system returns the sign-in methods this account actually has.
That detail matters. Discovery does not send anything and does not create anything. It only answers honestly: these are the methods you can choose right now. Sending a code or an email starts only after the method is chosen.
If the account has no password, password is not shown. If there is no live browser session, sign-in through an open tab is not shown. If Telegram is not linked, Telegram does not pretend to be an available method. If the identifier is not found at all, the system says the account was not found and offers registration instead of making the person guess.
I like that compromise: where the person chooses a path, the UI is honest; where delivery to an external channel begins, security stays careful. For example, requesting a magic link should not turn email into an oracle for whether an account exists.
Code, link, and password are not the same button
From the outside, all of this is often called “sign in with email”, but for the user these are different promises.
A code is convenient when you are already standing in the form and do not want to jump between tabs. A link is convenient when you need to move sign-in between devices or between an email client and the browser. A password is convenient for people who want the familiar quick path.
These are not three decorative versions of the same button. Each method has its own risk and its own normal scenario. That is why password should not become the center of Letopis just because that is how web apps historically worked. It is useful, but it does not have to be the first step, and it does not have to exist on every account.
I also like that this model expands calmly. If tomorrow there is Slack, Signal, or any other channel, we do not need to invent a new user entity. The new channel simply becomes another place to deliver proof, or another confirmed way to own the account. The account remains the same.
Telegram is not second class
Telegram in Letopis is not a side notification channel. It is a full sign-in channel and a future work interface.
The bot does not create an account automatically on /start. First it checks whether this Telegram is already linked, blocked, or completely unknown. If it is unknown, there are two scenarios. A person can create a new account directly from Telegram. Or they can prove access to an existing account through email, password, or another available method, and then attach the current Telegram to it.
The important part is not to prove ownership of an account through the same Telegram we are only trying to attach. That would be circular logic: “prove the account is yours through a channel that has not been proven yet.” Telegram can be the starting place, but when it is being attached to an existing account, it goes through an already trusted method.
After linking, Telegram becomes a normal channel. You can sign in through it, receive codes, and work with the product. At the same time, the bot should not become a small vault full of long-lived user tokens. Its job is to be a conversation and a delivery channel, not to keep the whole account inside itself.
Unlinking is not a small detail either
Linking a channel is easy. Unlinking it safely is harder.
If Telegram can be unlinked with one click and no fresh confirmation, a stolen session can quietly cut the owner off from an important way to sign in. If every action in the bot requires a full repeated login ceremony, the UX becomes strange: the person pressed “log out” in Telegram, and the bot asks them to perform extra ritual.
So dangerous changes need fresh context, but without security theater. On the web, that can be a password or a one-time code. In Telegram, it can be the fact of a live linked dialog for this exact operation. The user sees a clear step, and the system still does not allow access channels to be changed from an old session without a check.
There is also a simple rule: you must not remove the last stable way to sign in and leave the person with an account they can no longer access. It sounds banal, but banal rules are better kept in code than explained later in support.
Why it was worth doing now
We could have started with ordinary email+password and bolted Telegram on later. But then Telegram would almost inevitably become an attachment. Weird states would begin: a user exists in the bot but not on the web; accounts need to be merged; recovery requires manual exceptions.
Letopis is not really a web app with Telegram notifications. It is a product that should live normally between channels.
I want a person to start where it feels natural. Writing thoughts in Telegram? Start in Telegram. Opened the landing page on a laptop? Start on the web. Do not want a password? Use a code. Want a familiar password? Add one. Lost a device? There are other channels.
Ideally, the user does not think about this architecture at all. They enter what they remember, see honest options, receive the code where it was promised, and land in the same account. For this part of the product, that is the best result: it works, and almost nothing is visible.