Forem: Anton Minin Baranovskii

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.

Access-First Authentication with QR + Device Signatures

Anton Minin Baranovskii — Mon, 13 Apr 2026 10:36:29 +0000

Toqen.app is now live on the App Store.

This is an attempt to rethink authentication from an access-first perspective: instead of managing identities and credentials, focus on granting access in real time, per request.

Why rethink authentication

Most systems still rely on reusable credentials:

passwords
session tokens
API keys

These introduce predictable problems:

credential leaks
replay attacks
uncontrolled sharing

Even with MFA, the core model remains static.

Core idea

Each access request should be:

short-lived
single-use
bound to a device
cryptographically verifiable

Instead of storing secrets, the system verifies a signed challenge.

Flow

User opens login page
↓
Server generates request
↓
QR code is displayed
↓
Mobile app scans QR
↓
User confirms access
↓
Device signs challenge
↓
Server verifies signature
↓
Access granted

QR format

QR does not contain secrets.

Example:

toqen://auth?request_id=91f2d&challenge=8fa92c1a&expires=1710000000

Properties:

expires in 30–60 seconds
single-use
cannot be replayed

Device model

On first launch:

device generates key pair
private key → stored in secure storage
public key → registered on server

Signing:

signature = sign(challenge, device_private_key)

Verification:

verify(signature, device_public_key)

Security properties

no reusable credentials
no secrets in QR
replay protection via TTL + single-use
device-bound authorization
server stores only public keys

Vault model

Sensitive data is encrypted client-side:

encrypted_vault
AES-256-GCM
vault_key stored in secure storage

Server never has decryption capability.

Where this fits

admin access
internal tools
high-risk operations
temporary access flows

Current status

iOS app is live on the App Store
Android version is in testing

Open for feedback

If you are working on authentication, security, or access control systems — feedback is welcome.

Contact: https://www.toqen.app/about#contacts

Android early access: https://forms.gle/f9FcbHyHJiajmFWV7

Building continues.

Access without passwords — short demo

Anton Minin Baranovskii — Wed, 08 Apr 2026 06:15:55 +0000

Toqen.app mobile testing is now live on iOS

Anton Minin Baranovskii — Tue, 07 Apr 2026 17:18:34 +0000

I am glad to share that Toqen.app mobile testing is now live on iOS.

If you would like to try how access-first authentication works in real usage before the official release, please fill out a short form and we will open access (link below).

For Android users, testing is already ongoing on Google Play.

Two scenarios are currently available:

Sign in via the mobile app — open the “Services” tab, tap “Sign in”, and you are you are instantly signed in in the browser
Sign in via QR — open Toqen.app or Litseller.com on your desktop, scan the QR code or enter the OTP in the app, and confirm access

The idea is simple: access is confirmed at the moment of login. No separation between sign up and login. The session is created securely and has a limited lifetime.

👉Join: https://forms.gle/5LhYEyj87aNLuKpN9

👉Honest feedback is highly appreciated: https://forms.gle/S7mmzji5ftGKZZys9