Forem: Anton Minin Baranovskii

Emotional Weight of Decisions: What Fibonacci Has to Do With It and How to Use It in Life

Anton Minin Baranovskii — Fri, 22 May 2026 04:47:04 +0000

Reflecting on how growth works in nature, it is easy to notice a repeating pattern: in many systems, new forms emerge as a continuation of previous ones. One of the most well known examples is the Fibonacci sequence, where each next value is formed by combining the two previous ones.

This observation leads to the idea that a similar logic may appear in human behavior. Not as a literal mathematical formula, but as a principle: every new state does not arise from nothing, it is assembled from what has already been and what is happening now.

If you look at decision making through this lens, it becomes clear that a person does not rely on their entire experience directly. Instead, they use a compressed and processed version of it, where some events almost disappear while others become amplified. And the key factor here is not the fact of the experience itself, but its emotional weight.

Main

We tend to believe that we make decisions rationally. That there are facts, knowledge, and logic, and a choice emerges from them. In practice, it feels different.

At the moment of making a decision, a person does not go through all past experience. Instead, they rely on a few internal sensations that feel obvious and right. These sensations are the result of already processed experience, where some events have lost their significance and others have been reinforced.

What gets reinforced is not what was objectively important, but what was experienced more intensely. Experience without emotional response barely participates in future decisions. It fades into the background. Meanwhile, emotionally charged events continue to influence behavior, even if a person is not consciously aware of it.

As a result, at any given moment, a person does not operate with their full experience, but with its current version, compressed, distorted, and amplified in certain areas. And this is what shapes the next step.

But the process does not stop there. The current state also affects how this experience is used. The same set of facts can be perceived differently depending on the state: in one case as a risk, in another as an opportunity. Not because the facts have changed, but because the point of view has.

In the end, each decision is formed by two parts: processed past and current state. And this result becomes a new layer that will take part in future steps.

If we draw a parallel with Fibonacci, the similarity is not in the exact formula, but in the principle itself: the new does not appear separately, it continues and transforms the previous. The difference is that there is no simple addition here. There is amplification, attenuation, and reinterpretation.

Conclusion and Application

If you treat this as a model, it gives a practical point of leverage.

At the moment of choice, you can notice that the decision is already colored. It contains not only facts, but also the feeling through which those facts are perceived. And that feeling is not always directly related to the current situation.

This creates an opportunity to step aside and look at the situation from the outside. Not to suppress emotions, but to see them as part of the input.

What is happening right now.
What state is influencing perception.
Which parts of past experience are likely being amplified.

Then ask a simple question: what would be a reasonable step if this were not my situation, but a problem to solve from the outside, given the same inputs.

At that point, a person becomes both an observer and an advisor to themselves. The decision does not disappear, but its density changes. It carries less random emotional coloring and more structure.

The practical value of this model is not in changing how decisions are formed, but in learning to see what they are already made of.

How I Accidentally Built an LLM Orchestration System in the Browser

Anton Minin Baranovskii — Sun, 17 May 2026 02:14:24 +0000

This article continues the ideas I started exploring in “About the Impostor Instinct, Superpower, and an Honest Pivot”.

Two years ago, I built Litseller.

At that moment, I was not thinking about LLM orchestration or the architecture of such systems. I was simply solving a specific problem: how to quickly generate structured content for a book catalog.

Looking back now, I understand that it was essentially a full LLM orchestration system. It was just implemented not on the backend, but directly in the browser.

What It Actually Was

It is important to frame this correctly.

Litseller was not an LLM service.

It was a classic web application with a catalog, on top of which I embedded an LLM as a data generation tool inside the admin area.

The entire orchestration happened in a simple flow: Editor UI, GPT API, JSON, validation, backend save.

No queues.
No workers.
No server-side orchestration.
No complex infrastructure.

Everything was built on React, prompts, and chains of requests.

Architecture

The system was split into three layers.

Frontend: Next.js admin area, editor, and all LLM logic.
Backend: .NET API, validation, and persistence.
Storage: SQL Server and S3.

The LLM logic did not live in the backend at all. Calls were made directly from the browser.

Generation Pipeline

Instead of one large request, I built a pipeline.

Check whether the model knows the book.
Clarify the title if needed.
Select a category.
Generate the main information.
Select content blocks such as summary, quotes, themes, and other sections.
Generate each block separately.
Assemble the JSON.
Translate the content into other languages.
Validate the result.
Save the final data.

This was already real orchestration, just without a separate orchestration service.

Why Blocks Worked Well

Generating content by blocks was one of the strongest decisions.

I did not ask the model to generate the entire book page at once.

Summary was generated separately.
Characters were generated separately.
Quotes were generated separately.
Themes were generated separately.

This gave me better quality control, the ability to regenerate individual parts, more stable JSON, and fewer errors.

In practice, it became a manual version control layer over LLM output.

Prompt Engineering

The prompts were simple, but structured.

Strict JSON format.
Clear instructions.
Minimal magic.

Context was passed explicitly: title, author, categories, language, and previous blocks.

No conversation memory.
No complex state.
No tool calling.

The Most Controversial Decision

The API key was stored in localStorage.

The reason was simple: the editor was not a public interface, there were very few users, the priority was to launch quickly, and backend orchestration would have made the system much more complex.

It was a conscious decision. The risks were understood and accepted.

Additionally, access was restricted and protected manually through Cloudflare.

Weaknesses

Looking at it honestly today, the weaknesses are clear.

API key on the client.
No centralized rate limiting.
No centralized control over calls.
No retry or backoff mechanism.
No proper schema validation.
Weak error handling.
No observability.
Too much complex logic in the browser.

It was a strong MVP, but not a production-grade LLM platform.

Strengths

At the same time, the system worked and produced real results.

Very fast development.
Minimal infrastructure.
High flexibility.
Full control through the UI.
Convenient manual refinement.
Modular generation.
Real production workflow.

The LLM was a tool, not the core of the system.

What I Would Do Differently Today

If I were building it again today, I would change the architecture.

Move LLM calls into a backend gateway.
Remove the API key from the client.
Add queues and retries.
Introduce strict JSON schema validation.
Add logging and tracing.
Implement rate limiting.
Separate orchestration from the UI.

Main Takeaway

The most interesting part for me is that I did not design an LLM system.

I was simply solving a problem.

Only later did I realize that I had built an architecture that is now called LLM orchestration.

Sometimes good engineering decisions first look like chaos and intuition. Only later do they become a clear architecture that can be improved consciously.

About the Impostor Instinct, Superpower, and an Honest Pivot

Anton Minin Baranovskii — Sat, 16 May 2026 23:56:55 +0000

Why it is important to develop your real strength instead of trying to do everything at once.

Two years ago I built Litseller, and at that time I did not fully realize that I had essentially created an LLM system orchestrating the GPT API.

Today, such systems are already considered a separate direction, but back then it was simply a way for me to solve a problem.

After that, Start4Drive, Toqen.app, and Allado.app followed.

Over this time, I realized one very important thing.

Every person has their own superpower.

This is not abstract. I have seen it many times in real life.

Throughout my career, I have worked with many different people and kept noticing the same pattern. A person can be average in one area, but in another they become completely different. Precise, fast, deep. As if it is their natural state.

There is a saying that if a person is talented, they are talented in everything. I no longer believe that.

Every person is talented in something of their own.

I have seen people do things that I looked at with genuine admiration, not understanding how it was even possible. At the same time, I heard the same from them about my work.

At that moment, it becomes obvious: it is not about being universal. It is about your zone of strength.

Trying to be a universal key to every door is a mistake.

The Impostor Instinct

The impostor instinct, for me, is not about weakness. It is an internal signal that you have entered a new territory. A place where not everything is clear yet, where you are a beginner again, where you need to grow.

That means you have hit the point. The direction you actually need.

This instinct is connected to an inner drive. Your real talent shows you the direction.

If at some point you feel like a master and it seems that everything in this area is already clear, that is also a signal.

No one knows everything.

No one can do everything.

There is only the path, growth, and continuous improvement.

If you start to feel a sense of completion, it means it is time to honestly look at your trajectory and find a new direction for growth.

My Real Strength

I can try as much as I want, read, experiment, push myself into marketing and sales, but my real strength is elsewhere.

I am an engineer.

I think in systems, build complex things, turn ideas into working products, and take responsibility for architecture, code, stability, and quality.

And that is what I want to keep developing.

AI Does Not Create Your Strength

Now, with GPT and other tools, there is an illusion that you can become stronger in everything at once.

Yes, they help you get knowledge quickly, understand new areas, and make decisions.

But I realized something important.

They amplify your superpower. They do not create it.

You will not become equally strong in everything, even with the most powerful tools.

Honest Pivot

That is why I am making an important pivot: I am focusing on where I can deliver the most value.

And I want to build business, marketing, and growth together with a partner whose superpower is in that domain.

I do not have that partner yet, but I am open to a conversation.

I have working products, a strong technical foundation, experience, and the drive to keep building. I take full responsibility for my domain.

The next post will be about the technical details of how I built the Litseller system.

I think engineers will find it interesting.

Originally published at: https://www.antonmb.com/en/blog/about-the-impostor-instinct-superpower-and-an-honest-pivot

Writing in the Age of AI: A Personal Essay

Anton Minin Baranovskii — Wed, 29 Apr 2026 16:42:36 +0000

Writing Means Researching

For as long as I can remember, I have always wanted to write.

Not just to put words into texts, but to share thoughts, reflect, analyze, and try to get to the essence of things. I have always been interested in not stopping at the first explanation, but going a little deeper. Looking at why something works exactly the way it does. Why people make certain decisions. Why some ideas seem obvious, while others only open up after a long inner journey.

At some point, I realized something interesting for myself: getting to the essence in a final sense is probably impossible.

At first, this does not sound very optimistic. As if you are moving toward some point, and then you realize that there will most likely be no final point. There is only movement and process. There are new questions, new connections, new doubts, and new levels of understanding.

I felt very sharply how small my knowledge is against the background of the enormous world. How much exists around me. How many topics, systems, people, and fields I know too little about. Even in the competencies I have, there is always another level and another depth.

I felt like a grain of sand in a huge world.

But later, this feeling became alive and inspiring for me. There was a kind of honesty in it. If it is impossible to know everything, then you can continue researching. If it is impossible to put a final point, then the path itself becomes more important.

After reading Nassim Taleb, this feeling became even clearer for me. His thoughts on uncertainty, randomness, the fragility of knowledge, and the limits of human forecasting helped me accept one simple thing more calmly: the world is much more complex than our explanations. We often want to see a clear system of causes and effects, but reality is wider. It contains a lot of the unknown, a lot of the random, and a lot of what cannot be calculated in advance.

And this does not make research meaningless. On the contrary, for me it makes it even more interesting.

Because then the answer is not the only thing that matters. The way of thinking matters. Honesty with yourself matters. The ability to doubt, check, return to your conclusions, and admit that you may have missed something matters.

Over time, I realized that research is what I truly want to do. Yes, in some sense it is strange to search for the essence while understanding that there may be no final essence. But for me, this is exactly where the beauty is.

The beauty is in the process.

In the moment when scattered thoughts suddenly form a chain. When facts, observations, doubts, and personal experience connect, and you begin to see the structure. When something complex suddenly becomes simple. So simple and obvious that you get goosebumps.

For me, this is one of the strongest feelings.

Perhaps this is close to the state of flow described by Mihaly Csikszentmihalyi. When you are fully immersed in the process, lose the sense of outside noise, and remain alone with the thought, the task, and the movement forward.

Writing in the age of AI

At the same time, for a long time I could not write the way I wanted to.

I am not the most patient person. It is difficult for me to hold my attention on one text for a long time. I often switch between things. Thoughts come quickly, but turning them into a coherent article has always been difficult.

And this is where the age of artificial intelligence changed a lot for me.

Today, there is a tool that helps work with thought differently. For me, GPT has become more than a text assistant. It has become a conversation partner. An editor. An opponent. Sometimes a mirror in which I can see my own thought from the outside.

I asked it myself to criticize me harshly.

Because at some point I realized: the goal is more important than the ego. If I really want to research a topic, I do not need confirmation that I am right. I need my thought to be tested. I need questions. I need objections. I need weak spots that I may not have noticed myself.

AI helps me analyze, argue with myself, search for arguments, see gaps, and formulate thoughts more clearly. At the same time, it can also make mistakes. And this is an important part of the process.

Every chat says that AI can make mistakes. And this is true. But AI is not the only one that can make mistakes. I can make mistakes too, especially when I start believing too quickly in the coherence of my own thought.

That is why a conversation with AI does not replace thinking for me. Rather, it helps keep thinking in shape.

How my articles come into being

You ask a question. You receive an answer. You do not agree immediately. You check. You doubt. You compare. You return to the original idea. Sometimes you realize that the thought was weak. Sometimes, on the contrary, you see that there is something important in it, it just has not yet been formulated precisely enough.

This is how my articles gradually come into being.

First, an inner thought appears. Often raw, emotional, and unformed. I dictate it as it is. Then I begin to discuss it. I receive criticism. I check facts. I clarify the idea. I remove what is unnecessary. Sometimes I completely change direction. Sometimes I realize that I need to dive deeper into the topic before writing further.

Only after that does the text appear.

Writing as research

For me, writing is increasingly becoming a form of research. To write an honest text, you need to walk the path inside the topic yourself. You need to face your own lack of knowledge. You need to let the thought mature. You need to be ready for the fact that a good comment or honest criticism can change your position.

I write not because I have final answers.

I write because I am interested in thinking out loud. I am interested in researching. I am interested in sharing how a thought appears, develops, and changes. I am interested in finding people who also care not only about the conclusion, but about the path toward it.

Comments, feedback, and criticism truly matter to me. Because often it is precisely in conversation that the next step opens up. Sometimes one precise question helps you see more than several hours of thinking alone.

Perhaps that is why I like writing so much.

It is a way to stay in the process. A way to think more attentively. A way to share what feels important right now. And a way to keep searching, even while understanding that there may be no final point.

Thank you for reading to the end.

I am currently open to new opportunities and collaboration

Anton Minin Baranovskii — Tue, 28 Apr 2026 21:55:35 +0000

Anton Minin Baranovskii

Apr 28

Open to Work and Collaboration

#career #webdev #softwareengineering #programming

Comments

1 min read

Open to Work and Collaboration

Anton Minin Baranovskii — Tue, 28 Apr 2026 03:10:37 +0000

Over the past years, I worked at Yandex and Sber, contributing to large scale production systems used by millions.

More recently, I independently built Toqen.app, an authentication infrastructure project developed from the ground up, including:

System architecture
Backend
Frontend
Mobile applications

This project became strong proof of my ability to build complex products from zero, learn new domains quickly, and deliver technically challenging systems independently.

I am currently open to new opportunities and considering:

Full time roles
Contract work
Project based collaboration
Early stage startup opportunities

My strongest areas include:

Frontend and Full Stack Engineering
System Architecture and Technical Leadership
Complex Product and Platform Development
Building Products at Any Stage, from MVP to Mature Systems

If you are building something and need an experienced engineer, I would be glad to connect.

CV / Portfolio: https://www.antonmb.com

OpenAI’s Superintelligence Vision and the Need for Access First Infrastructure

Anton Minin Baranovskii — Mon, 27 Apr 2026 19:50:33 +0000

OpenAI recently published its view on preparing society and institutions for the transition toward superintelligence. In the technical part of that discussion, several themes stand out clearly: AI trust stack, control of agent actions, verifiable operations, post deployment safety, auditability, accountability, and governance for agentic systems.

OpenAI: Industrial Policy for the Intelligence Age

These themes point to an architectural problem that will become increasingly important as AI systems move from answering questions to performing actions.

When AI systems become agents, the security question changes.

It is no longer enough to ask only who initiated a process. Systems also need to know what action is being requested, under which conditions, for how long, with which limits, and how this action can be verified later.

This is where access control becomes a primary architectural layer.

From authentication events to action level control

Traditional authentication systems are usually designed around a subject: a user, an account, an organization, a device, or a service identity.

That model remains important.

However, agentic systems introduce a second layer of complexity. A human, an AI agent, a robot, a service, or another automated process may request access to perform a specific operation in a specific context.

In this environment, the most important security object is often the action itself.

For example:

An agent wants to call an API.
A robot wants to execute a physical operation.
A system wants to delegate a task to another system.
A human wants to authorize an AI agent to act within defined limits.
A workflow needs temporary access to data, tools, or infrastructure.

Each of these cases requires more than a static permission. It requires a controlled access event with a clear scope, lifetime, verification mechanism, and audit trail.

Why this matters for AI trust stack

OpenAI’s AI trust stack direction describes the need for systems that help people trust and verify AI systems, the content they produce, and the actions they take. This includes verifiable signatures, provenance, privacy preserving logs, investigation mechanisms, delegation, monitoring, and escalation.

These are access layer problems.

A practical trust stack for agentic systems needs to answer several questions at runtime:

Who or what requested the action?
Which entity was allowed to perform it?
Was the authorization valid at execution time?
Was the action inside the allowed scope?
Can the event be verified later?
Can access be limited, expired, or revoked?
Can this be done with minimal data collection?

This is the space where access first infrastructure becomes relevant.

Access first as an architectural model

The access first model treats access as a first class object.

In this model, an authorization event can be represented as a cryptographically verifiable object with defined parameters:

entity identifier
requested action
scope
context
expiration
usage limits
signature
audit metadata
revocation status

The system does not need to turn every interaction into a broad identity profile. It can focus on the specific right to perform a specific operation under specific conditions.

This is especially important for AI agents and robotic systems, where the core question is practical and operational:

What is this entity allowed to do right now?

Where Toqen.app fits

Toqen.app is being developed as access first authentication infrastructure.

The current core is focused on issuing and controlling access. The same direction can be extended toward agentic systems, where access events become the main control unit for interactions between humans, agents, services, and automated systems.

The relevant parts of the Toqen approach are:

Access is treated as a separate verifiable event.
Access can be bound to an entity, such as a human, agent, system, service, or robot, through a key based model.
An operation can be confirmed, limited, expired, or revoked at execution time.
Audit data can be minimal and focused on verifiable events.
The model can support human to agent and agent to agent interactions.

This does not require replacing existing identity systems. It can work as an additional access layer for action level authorization.

Distributed agents and blockchain based coordination

Some agentic systems will operate across independent participants.

This is especially relevant for industrial automation, robotics, logistics, manufacturing, and multi organization AI workflows. In such environments, multiple systems may need to agree on access events without relying on a single internal database controlled by one party.

A blockchain or distributed ledger layer can be useful in specific cases as a synchronization and immutability mechanism for access events.

In this model:

Toqen manages access issuance and action level control.
A distributed ledger records selected access events, state changes, or revocation signals.
Independent participants can verify the state of permissions.
The system can preserve a shared record without exposing unnecessary private data.

This is not required for every scenario. For many applications, a conventional audit log is enough. But in distributed industrial and multi party environments, blockchain can provide a useful coordination layer.

The practical direction

The practical engineering direction is clear:

AI agents need controlled access to tools, data, APIs, and physical systems.
Those permissions need to be scoped, temporary, verifiable, and revocable.
Critical operations need runtime control.
Post deployment safety requires action level visibility.
Audit and accountability require verifiable chains of events.
Access first infrastructure is one possible way to build this layer.

The main shift is simple:

As AI systems become more autonomous, access control must move closer to the action itself.

Conclusion

OpenAI’s discussion of superintelligence highlights a broader infrastructure need: systems that can verify, limit, monitor, and audit the actions of AI agents after deployment.

This is a concrete engineering problem.

Access first infrastructure addresses that problem by treating access as a controllable, verifiable, time bound, and action level object.

For AI agents, robotic systems, and distributed workflows, this model can become an important part of the future AI trust stack.

Toqen.app is being built in this direction: access first authentication infrastructure for systems where secure, real time authorization becomes a core part of the architecture.

Sources

The Age of Trust, Part 2: The Global Network

Anton Minin Baranovskii — Mon, 27 Apr 2026 18:01:43 +0000

In the first part, I wrote about a simple shift: in the AI era, knowledge is no longer the main scarce resource.

When information becomes available almost instantly, the real value moves toward problem solving, judgment, responsibility, and trust.

This second part is about a broader idea I have been thinking about: a global trusted-contact network for finding people, specialists, and companies through real trust paths.

Not just who is visible online, but who can actually be trusted in a specific context.

The Problem with Finding People Today

Finding the right person has become easier on the surface and harder in practice.

We have search engines, professional networks, social platforms, marketplaces, communities, chats, and recommendation feeds. It seems like everyone is reachable.

But when the decision really matters, visibility is not enough.

Who can be trusted as a specialist?

Who is reliable as a partner?

Who can be safely introduced to someone?

Who has real experience in a specific context?

Who should receive access, attention, money, or responsibility?

These questions are rarely answered by public profiles alone.

Public Signals Are Not Enough

The internet mostly evaluates people through public signals.

Followers.

Likes.

Reviews.

Ratings.

Badges.

Comments.

Public recommendations.

These signals can be useful, but they are too shallow for many important decisions.

Reviews can be manipulated. Ratings often miss context. Social profiles show packaging more than real interaction history. Public recommendations may reflect politeness, marketing, or social pressure.

Real trust usually lives somewhere else.

In private conversations, personal networks, previous work, shared experience, and quiet recommendations.

Real Recommendations Are Fragmented

The strongest recommendations are often not public.

They are scattered across private chats, calls, introductions, small communities, old projects, and personal memory.

When someone needs a reliable specialist, investor, founder, lawyer, designer, developer, consultant, or local contact, the process usually starts with a simple message.

Do you know someone reliable for this?

This works, but it works slowly, randomly, and only inside the networks that are immediately visible to us.

A lot of valuable trust already exists. It is just not structured.

A Global Trusted-Contact Network

The idea is a global trusted-contact network for finding people, specialists, and companies through private trust paths.

A person could add a rough location, areas of expertise, short profile information, and the kinds of contexts where they are open to interaction.

Other people could create or remove private trust connections with that person in specific contexts.

I trust this person as a frontend engineer.

I can recommend this person as a designer.

I know this person as a reliable local contact.

I can confirm this person’s experience with fundraising.

I would route a security-related request through this person.

The result is not a public popularity score. It is a private network of contextual trust.

Private Trust Paths

The most important part of this idea is not the profile. It is the path.

When someone needs to reach a specialist, partner, investor, company, or local contact, the system would not only show public search results. It would help route the request through a private chain of trusted people.

The full chain would not be exposed.

Each person in the path can approve the request.

Each person can stop the request.

The requester does not see the full chain.

If the request stops, the requester does not see where it stopped.

The target person receives only the request that passed through the trusted path.

This keeps the process human, private, and respectful.

A Simple Example

Imagine I need a reliable tax specialist in another country.

I can search online and find dozens of profiles. Some have reviews. Some have polished websites. Some have strong public content.

But the real question is different.

Who can confirm that this person is reliable for my specific situation?

In a trusted-contact network, I could see that there is a private trust path to a specialist.

Maybe I do not know the specialist directly. But someone I trust knows someone who worked with them. The system can route the request step by step without revealing the entire network.

If people along the path approve the request, the contact can happen. If someone decides it is not appropriate, the request simply stops.

Why the Network Must Be Private

A trust network becomes dangerous if it turns into a public map of personal relationships.

Public relationship graphs can create pressure, manipulation, unwanted exposure, social debt, and uncomfortable expectations.

That is why privacy is not an extra feature. It is part of the core design.

The full chain should not be visible.

Private connections should remain private.

People should be able to stop requests quietly.

Rejections should not become public signals.

The system should reveal only what is needed for the next step.

The goal is to make discovery more honest and safer, not more socially aggressive.

Controlled Disclosure

The network should work through controlled disclosure.

A person should not need to reveal their full network, full history, full identity, or every reason behind a decision.

The system should provide only the minimum necessary signal for a specific action.

There is a trusted path.

The request can be passed forward.

The context is relevant.

The person is reachable through trusted connections.

The request was accepted or stopped.

This is the same principle that I see as important in access systems: disclose only what is necessary for the action being performed.

This Is Not a Rating System

A global trusted-contact network should not reduce people to universal scores.

Trust is too contextual for that.

Someone may be excellent in one role and unsuitable for another. Reliable in one context and unknown in another. Strong in one country, industry, or type of work, and still unverified elsewhere.

The system should not answer the question “Is this person good?”

It should help answer: who can confirm this person for this specific request?

Where This Could Be Useful

This kind of network could be useful in many areas where trust matters more than visibility.

Hiring specialists.

Finding contractors.

International relocation.

Local services.

Investment and fundraising.

B2B partnerships.

Legal, tax, and financial introductions.

Professional communities.

Founder and investor discovery.

Private clubs and expert groups.

Human-to-agent and agent-to-agent access flows.

In each of these areas, the problem is not only finding someone. The harder problem is understanding whether interaction is appropriate and safe.

How This Connects to Toqen.app

I am building Toqen.app as access-first authentication infrastructure designed for secure, real-time authorization.

Toqen.app solves a specific access problem: how to authorize a person quickly, securely, and with the minimum necessary amount of data.

A user opens a website, scans a QR code in the mobile app, confirms the request, and the service receives a verifiable authorization event.

The trusted-contact network is a broader idea, but it follows a similar principle.

For a specific action, the system should ask for and reveal only what is truly necessary.

Access and trust are different problems, but they are connected by the same direction: more precise digital interactions with less unnecessary exposure.

The Global Network

The global network I imagine is not a public social graph and not a popularity contest.

It is a private infrastructure layer for routing trust: from one person to another, from one company to another, from one context to another.

The internet has already made people searchable.

The next step is making trusted interaction easier, safer, and more precise.

That is the direction I see behind The Age of Trust.

Why access-first auth matters?

Anton Minin Baranovskii — Fri, 24 Apr 2026 11:01:05 +0000

In this article, I briefly explain why Toqen.app is built around an access-first authentication infrastructure.

1. Where fast access matters

There are scenarios where filling out forms gets in the way:

one-time website visits
Smart TVs
events and webinars
admin panels and systems where ownership must be confirmed frequently
systems where services, agents, or bots interact with each other

In these cases, email and passwords slow things down and increase risk.

Toqen.app provides access instantly through confirmation, without entering unnecessary data.

2. Access without unnecessary data

Instead of creating and managing accounts:

open the website
scan a QR code
confirm access

Access is confirmed at the moment of request, not stored in advance.

It does not matter where you are or what device you use everything happens in just a few steps.

3. Access control at the moment of use

With Toqen.app, every access can be:

confirmed
restricted
revoked

This gives control not only at login, but during actual usage.

4. Simple and predictable security

Most authentication issues come from human error:

forgotten passwords
password reuse
phishing
input mistakes

With Toqen.app:

no passwords to enter
no unnecessary steps
every access is confirmed on your device
device-bound cryptographic keys are used

This reduces mistakes and makes the process predictable.

Even in stressful situations, there is only one action confirm access.

It follows modern approaches similar to WebAuth, with a more straightforward user experience.

5. Less data, lower risk

Traditional systems store:

emails
passwords
tokens

With Toqen.app:

only data required for access is used
no unnecessary personal information is stored
each access request is single-use

This reduces the impact of mistakes and data leaks.

6. Simple and fast integration

For developers, speed of integration matters as much as security.

Toqen.app:

does not require complex setup
does not require identity-centric user profiles
allows collecting data required by business logic
integrates as an access layer on top of existing systems

This makes it possible to introduce secure access without redesigning the architecture.

Summary

Toqen.app is an approach where:

access is confirmed in real time
unnecessary data is not required
users stay in control
the system remains simple and clear

You do not remember access you confirm it when you need it.

P.S.

The app is available on the App Store. Closed testing on Google Play is ongoing message me if you want to try it.

The client app is open source, so you can review how access confirmation works and what data is actually used: https://github.com/toqenapp/mobile-react-native

Forgot your password again? QR Man is here to help.

Anton Minin Baranovskii — Wed, 22 Apr 2026 13:14:31 +0000

Friend: "So, what’s this Toqen.app thing anyway? Just another password manager? I have everything saved in my browser, I’m good."

Me: "That’s the thing - it’s not. Browsers remember your passwords. Toqen.app makes them unnecessary."

Friend: "What do you mean 'unnecessary'? How am I supposed to log in? Magic?"

Me: "Think of it this way: a standard login is like a door with a cheap lock. Anyone with a copy of the key-your password-can walk right in. Toqen.app turns your smartphone into a universal digital key. You don’t have to type anything. You just walk up to the 'door' (open the website), scan a QR code, and your phone tells the site: 'Everything’s good, this is the owner, let him in.'"

Friend: "Wait, so I don’t have to remember anything? That sounds like a security nightmare. Okay, what if I’m sitting in a cafe and someone else tries to log in using my name from the other side of the world?"

Me: "That’s the main 'wow' effect. An attacker gets nowhere because there are no reusable credentials on the server. Unlike a password, which can be stolen and used again, the server only holds your public key. To log in, your phone creates a unique device signature for that specific moment. The server only verifies the signature - it never sees or stores your actual 'secret.' Even if someone intercepted the data, they couldn't use it to log in later. Your 'master key' stays physically on your phone and nowhere else."

Friend: "Right, but what if I lose my phone? Or worse, what if it gets stolen?"

Me: "That’s the key part. It’s like the keys to a modern car: no one else can even start the 'engine' without your specific biometrics. If you lose it, you restore access via a backup. It’s stored in an encrypted format that is mathematically impractical to crack without your master key. Meanwhile, your lost device remains useless to an intruder because it's protected by multiple layers of hardware-level security."

Friend: "So... it’s basically like FaceID for the entire internet?"

Me: "Exactly. It makes your digital life seamless. You move through websites like you’re walking through your own home, where all the doors open automatically as you approach. No stress, just access."

Toqen.app Mobile is Now Open Source

Anton Minin Baranovskii — Wed, 22 Apr 2026 03:29:35 +0000

I have made the Toqen.app mobile application publicly available.

This is a deliberate decision to move toward transparency and independent technical review.

The mobile client is the part of the system that users directly interact with during authorization.

It is now open for inspection so anyone can verify how access is processed on the device.

What is Toqen

Toqen is an access-first authentication infrastructure designed for secure, real-time authorization.

Each access request is:

created in real time
explicitly approved by the user
cryptographically signed by the device
verified by the backend

The mobile app acts as a secure execution layer for these decisions.

What the open source mobile app actually does

The mobile client has a very narrow and well-defined responsibility:

scan or receive an access request
fetch request context from the backend
show the user what is being requested
collect explicit approval or denial
sign a short-lived challenge using a device key
send the signed result back for verification

The app does not grant access on its own.

All final decisions are verified by the server.

What data the app collects

This is the key point.

You can verify it directly in the code.

The mobile app stores only what is strictly required to perform cryptographic authorization:

device_private_key (generated on device, never leaves it)
device_id
app_instance_id

That is the full set of stored sensitive data.

There is no storage of:

passwords
session tokens
refresh tokens
reusable credentials
backend secrets

Sensitive data is stored using OS-level secure storage (Keychain / Keystore).

What is NOT inside the system

Toqen is built around strict data minimization.

QR codes do not contain secrets
authorization requests are short-lived
requests are single-use
no reusable tokens exist in the flow

Even if a QR code is intercepted, it cannot be used to gain access.

Authorization always requires:

user confirmation
device signature
backend verification

How authorization actually works

All flows follow the same pattern:
request → context → user decision → signature → verification → result

This guarantees:

no silent approvals
no implicit trust
no background authorization

Every access is intentional and verifiable.

Security model (short version)

The system assumes a hostile environment:

network is untrusted
QR codes can be intercepted
requests can be replayed

Security is achieved through:

device-bound cryptographic keys
challenge-response authorization
short-lived requests
server-side verification

Private keys never leave the device.

The backend never has access to them.

Why only the mobile app is open

The mobile client is the most critical part to verify from a trust perspective.

By open-sourcing it, I allow:

independent security review
verification of data handling
inspection of cryptographic flows
validation of what is and is not collected

The backend remains closed, but its behavior is fully defined through:

API contracts
documented flows
security model
threat model

This keeps the system verifiable without exposing operational infrastructure.

Build transparency

The build and release process is also documented.

Each build includes:

version
commit hash
tag
CI reference

This allows anyone to trace how a distributed app was produced.

What this means

You do not have to rely on claims.

You can:

inspect the code
verify storage behavior
review cryptographic operations
confirm data handling

The mobile app is fully transparent by design.

Repository

https://github.com/toqenapp/mobile-react-native

Product access:

iOS (App Store): search for “toqen.app”
Android (closed testing): https://forms.gle/f9FcbHyHJiajmFWV7

Typical use cases include:

SaaS platforms
gated digital content
memberships
online education environments
event access systems
other products requiring time-bound and policy-defined authorization

Building continues.

The Paradox: The More Secure the Product, the Less People Trust It

Anton Minin Baranovskii — Tue, 14 Apr 2026 00:45:51 +0000

Over the past few days, early feedback on the Toqen mobile app has been coming in.

The reaction was not what you might expect.

Not curiosity.

Not technical questions.

But hesitation.

People are reluctant to install it.

First reaction defines everything

The moment a product is perceived as:

a password manager
a security tool
something that controls access

it is immediately placed into a high-risk mental category.

From there, the default response is simple:

“Better not touch it.”

This happens before any technical understanding.

Architecture is invisible

This is where things become interesting.

Toqen is designed around a few strict principles:

minimal data involvement
device-first trust model
no reliance on centralized sensitive storage

At a system level, this means:

cryptographic keys are generated on the device
secrets are not transmitted or stored centrally
access is verified through signed challenges

But none of this is visible to the user.

Architecture does not communicate itself.

Meanwhile, in other products

Users regularly:

share personal data
allow tracking
grant broad permissions

in applications that are perceived as:

social
entertainment
“harmless”

Even when those systems process significantly more data.

The asymmetry

This leads to a consistent pattern:

systems designed to protect are treated with suspicion
systems that collect data are treated with trust

Not because of their architecture.

But because of how they are perceived.

Trust is not a technical property

Security does not automatically produce trust.

Correct architecture does not automatically produce trust.

Trust depends on:

perception
clarity
predictability
ability to verify

Without these, even a strong system remains opaque.

What actually helps

If trust cannot be assumed, it must be built differently.

Not through statements.

Through verifiability.

One practical step is making the system inspectable.

The Toqen mobile app is being prepared for open source release.

This allows anyone to:

review how the system works
understand data flows
validate design decisions

Simplified flow (high level)

The authentication model is based on a challenge-response approach:

A login request is created (QR contains a temporary challenge)
The device scans the QR
The challenge is signed using a device private key
The server verifies the signature using the stored public key
Access is granted

Key properties:

no reusable tokens
no shared secrets in transit
short-lived challenges
device-bound authorization

Core principle

Data is involved only within the scope required to complete an access operation.

Critical elements:

are generated on the device
remain on the device
are never exposed in raw form

The server operates only as a verifier.

Better to see than to hear

There is a simple idea:

“Better to see once than hear a hundred times.”

Trust improves when systems can be explored directly.

The app is currently:

in testing on Google Play (access available on request)
available in release form on the App Store

Search: toqen.app

Final thought

Security alone is not enough.

If a system is not understandable, it will not be trusted.

The direction forward is clear:

build systems that are not only secure,

but also transparent, inspectable, and predictable.