Hey everyone! Thanks a ton to everyone who's joined and supports us. We truly appreciate it! 🩵
What to expect here?
It's been quiet because we were focused on X. Starting now, we'll post development updates here. They may not be daily, but we'll highlight the important bits each week.
We'll also run polls - your votes help us move faster and gauge what you think.
What's on X?
More marketing-forward posts: memes, threads, and conversations. If you enjoy that format, jump in there too.
Follow us wherever works best for you.
What's next?
This week we’re wrapping the presentation and continuing protocol development. Expect our first devlog near the end of the week
No group chat yet, so if you have questions or suggestions, just message us via the chat button to the left of Subscribe.
Big thanks from the whole team! Stay tuned for updates 🩵
What to expect here?
It's been quiet because we were focused on X. Starting now, we'll post development updates here. They may not be daily, but we'll highlight the important bits each week.
We'll also run polls - your votes help us move faster and gauge what you think.
What's on X?
More marketing-forward posts: memes, threads, and conversations. If you enjoy that format, jump in there too.
Follow us wherever works best for you.
What's next?
This week we’re wrapping the presentation and continuing protocol development. Expect our first devlog near the end of the week
No group chat yet, so if you have questions or suggestions, just message us via the chat button to the left of Subscribe.
Big thanks from the whole team! Stay tuned for updates 🩵
👍5🔥3❤2👀1
Part I. The Background of the TON Messenger Protocol
We live in an era of rapid technological progress. Not long ago, decentralization and AI felt like something unusual, yet today they're part of everyday life worldwide. The next frontier is quantum computing.
What is PQC and why does it matter?
Post-quantum cryptography (PQC) is a new generation of algorithms designed to remain secure even in the presence of powerful quantum computers.
Work on both quantum computers and the mathematical foundations behind them has been ongoing for decades. Progress has been gradual due to scientific and engineering challenges, but as we've seen with AI, breakthroughs can shift the pace dramatically overnight.
In future posts, we'll take a closer look at ML-KEM (formerly known as Kyber), first introduced in 2017 and standardized by NIST as FIPS 203 in 2024.
Why do we need to transition?
Shor's algorithm (1994) can solve integer factorization and discrete logarithms in polynomial time on a large enough quantum computer - rendering RSA, DH, and ECC insecure.
For lattice-based schemes like ML-KEM, however, no effective quantum attacks are currently known.
TON Blockchain and Telegram still rely on these legacy algorithms, but it's safe to assume they're already considering a migration. According to recent NIST/NSA guidance, quantum-vulnerable algorithms at the 112-bit security level will be deprecated around 2030 and prohibited after 2035 in systems that handle national security data.
What’s the real risk?
It's the so-called "harvest now, decrypt later" scenario: attackers can intercept encrypted data today and simply wait until they have the computational power to break it. We believe people's private lives should never be left exposed in this way.
History has shown that decryption capabilities can remain classified and hidden from the public for decades - sometimes as long as 40 years. Whether those tools were just kept "in the right hands" is a matter of debate, isn't it?
We live in an era of rapid technological progress. Not long ago, decentralization and AI felt like something unusual, yet today they're part of everyday life worldwide. The next frontier is quantum computing.
What is PQC and why does it matter?
Post-quantum cryptography (PQC) is a new generation of algorithms designed to remain secure even in the presence of powerful quantum computers.
Work on both quantum computers and the mathematical foundations behind them has been ongoing for decades. Progress has been gradual due to scientific and engineering challenges, but as we've seen with AI, breakthroughs can shift the pace dramatically overnight.
In future posts, we'll take a closer look at ML-KEM (formerly known as Kyber), first introduced in 2017 and standardized by NIST as FIPS 203 in 2024.
Why do we need to transition?
Shor's algorithm (1994) can solve integer factorization and discrete logarithms in polynomial time on a large enough quantum computer - rendering RSA, DH, and ECC insecure.
For lattice-based schemes like ML-KEM, however, no effective quantum attacks are currently known.
TON Blockchain and Telegram still rely on these legacy algorithms, but it's safe to assume they're already considering a migration. According to recent NIST/NSA guidance, quantum-vulnerable algorithms at the 112-bit security level will be deprecated around 2030 and prohibited after 2035 in systems that handle national security data.
What’s the real risk?
It's the so-called "harvest now, decrypt later" scenario: attackers can intercept encrypted data today and simply wait until they have the computational power to break it. We believe people's private lives should never be left exposed in this way.
History has shown that decryption capabilities can remain classified and hidden from the public for decades - sometimes as long as 40 years. Whether those tools were just kept "in the right hands" is a matter of debate, isn't it?
🔥4
Part 2. Protocol
First, we'd like to note that we made an effort to use full names throughout. Our goal is for the protocol to be understandable not only to technical specialists but also to everyday users. That's why we explain everything in the simplest possible language while still preserving the correct terminology (perhaps not always perfectly, but we'll try)
We should also mention that we were inspired by the idea of MTProto, which we slightly modernized. Huge thanks to Nikolai Durov for creating it!
Connection Establishment
To enable communication between server and client, a secure end-to-end encrypted connection must be established. For this, we use ML-KEM to agree on a shared secret key.
To ensure that the session key truly originates from our server, each client comes with the server's public keys preloaded, which are used for signature verification. The signature itself is generated using ML-DSA, making it resistant to quantum attacks.
Request Sending
Requests can be sent similarly to MTProto using different transport protocols: HTTP/WS/TCP, or through our own protocol TONMP (WebSocket-like).
Since the connection is already encrypted, data can safely be transmitted even over HTTP without SSL/TLS. However, in most cases, requests will be sent via TONMP, routed through TON Proxy, which operates over an ADNL connection that also provides encryption.
Protocol Schema
We plan to use a system similar to gRPC, as in MTProto. TL-schemes are a powerful tool for optimizing request structures. However, we decided to move away from custom TL-schemes to improve DX (developer experience)
To make it easier for developers to build their own clients on top of the protocol, we simplified this stage. For data format optimization, we use CBOR/msgpack, which makes it possible to transform JSON into a compact binary form.
All of these design choices are applied in the first version of the protocol and may be improved in the future.
In the next part, we will describe end-to-end encryption between users.
First, we'd like to note that we made an effort to use full names throughout. Our goal is for the protocol to be understandable not only to technical specialists but also to everyday users. That's why we explain everything in the simplest possible language while still preserving the correct terminology (perhaps not always perfectly, but we'll try)
We should also mention that we were inspired by the idea of MTProto, which we slightly modernized. Huge thanks to Nikolai Durov for creating it!
Connection Establishment
To enable communication between server and client, a secure end-to-end encrypted connection must be established. For this, we use ML-KEM to agree on a shared secret key.
To ensure that the session key truly originates from our server, each client comes with the server's public keys preloaded, which are used for signature verification. The signature itself is generated using ML-DSA, making it resistant to quantum attacks.
Request Sending
Requests can be sent similarly to MTProto using different transport protocols: HTTP/WS/TCP, or through our own protocol TONMP (WebSocket-like).
Since the connection is already encrypted, data can safely be transmitted even over HTTP without SSL/TLS. However, in most cases, requests will be sent via TONMP, routed through TON Proxy, which operates over an ADNL connection that also provides encryption.
Protocol Schema
We plan to use a system similar to gRPC, as in MTProto. TL-schemes are a powerful tool for optimizing request structures. However, we decided to move away from custom TL-schemes to improve DX (developer experience)
To make it easier for developers to build their own clients on top of the protocol, we simplified this stage. For data format optimization, we use CBOR/msgpack, which makes it possible to transform JSON into a compact binary form.
All of these design choices are applied in the first version of the protocol and may be improved in the future.
In the next part, we will describe end-to-end encryption between users.
👍2👀1
Part 3. End-to-End Encryption, Privacy, and Decentralization
Let's start by pointing out the contradictory principles found in most popular messengers today:
- A messenger that claims to protect privacy should not require sensitive personal information, such as a phone number, to access its core functionality.
- If a messenger wants to filter out bots through phone number registration, it must provide users the ability to hide the private information they entrust.
- A user's country of residence or the country of phone number registration is also private information and must not be exposed to other users.
- Anonymous numbers are only truly anonymous if their use does not require revealing private data.
- End-to-end encryption must be cross-platform, and the source code should be open for independent review.
Since we've already run out of fingers to count contradictions, let's move on to the features that should not compromise privacy or end-to-end encryption:
- The messenger must have open-source code.
- End-to-end encryption should be available on all devices.
- No private information should be required to register.
- For convenience, private chats must be able to sync across devices without losing parts of the conversation.
- For convenience, private chats must retain the same functionality as the rest of the messenger, including useful features like reactions.
Decentralization can be achieved in 2.5 ways:
- P2P: though without proxies, this may compromise privacy
- Federation: the ability to run a fully functional messenger on your own server while staying synchronized with others
- Web3 application: this is not full decentralization, but when combined with the above points, it eliminates the centralization problem of Web2 apps
We decided to combine all these approaches, so you won't have to choose between different messengers to get the functionality you deserve!
That wraps up this week's news!
We've already implemented part of the prototype and continue development. The next update will be in a week. Stay tuned! 🩵
Let's start by pointing out the contradictory principles found in most popular messengers today:
- A messenger that claims to protect privacy should not require sensitive personal information, such as a phone number, to access its core functionality.
- If a messenger wants to filter out bots through phone number registration, it must provide users the ability to hide the private information they entrust.
- A user's country of residence or the country of phone number registration is also private information and must not be exposed to other users.
- Anonymous numbers are only truly anonymous if their use does not require revealing private data.
- End-to-end encryption must be cross-platform, and the source code should be open for independent review.
Since we've already run out of fingers to count contradictions, let's move on to the features that should not compromise privacy or end-to-end encryption:
- The messenger must have open-source code.
- End-to-end encryption should be available on all devices.
- No private information should be required to register.
- For convenience, private chats must be able to sync across devices without losing parts of the conversation.
- For convenience, private chats must retain the same functionality as the rest of the messenger, including useful features like reactions.
Decentralization can be achieved in 2.5 ways:
- P2P: though without proxies, this may compromise privacy
- Federation: the ability to run a fully functional messenger on your own server while staying synchronized with others
- Web3 application: this is not full decentralization, but when combined with the above points, it eliminates the centralization problem of Web2 apps
We decided to combine all these approaches, so you won't have to choose between different messengers to get the functionality you deserve!
That wraps up this week's news!
We've already implemented part of the prototype and continue development. The next update will be in a week. Stay tuned! 🩵
🔥3👍2
If you are not a developer or an advanced user, you have no way to report scammers
You cannot send any information about a person to @notoscam
Moderators may be able to view the profile of the message you sent, but most often your conversation will be immediately deleted
H.G. Wells
You cannot send any information about a person to @notoscam
Moderators may be able to view the profile of the message you sent, but most often your conversation will be immediately deleted
And I beheld, unclouded by doubt, a magnificent vision of all that invisibility might mean to a man - the mystery, the power, the freedom.
H.G. Wells
👀2❤1
Which languages should we support first with our SDK?
Anonymous Poll
23%
JavaScript / TypeScript
57%
Python
7%
Go
13%
Rust
10%
C#
17%
С++
13%
Kotlin
20%
Java
3%
Swift
23%
I'm not a programmer
👀2
The Story of TON Messenger
~10-minute read
This week, we'd like to share a brief story about how we came to create this project.
A long time ago, we discovered Telegram. Unfortunately, we can't recall exactly when that happened, but it was more than six years ago. After installing it, we were pleasantly surprised by how well-optimized the app was. It ran smoothly even on weaker devices. We were greeted by animated stickers, which in other apps would have caused noticeable delays.
Private, secure, fast, open, free, powerful - everything lived up to its promise. What attracted us most was that Telegram's source code was open, unlike most other messengers.
But that was before Telegram started to drift away from its original principles. A paid subnoscription appeared. Ads were introduced.
Like most users, we supported these changes - we're sure it wasn't an easy decision for the team, and they handled it well. But since then, things have slowly started to change for the worse.
At that time, we became interested in creating a modified Telegram client. Still, we didn't see much real need for users. Those were narrow, specialized solutions that never went public.
Years later, around 2023–2024, the idea of building our own messenger resurfaced. But it didn't differ much from Telegram back then, so we shelved it for the time being.
Meanwhile, scams kept spreading. Fraudsters found new ways to deceive people, and with each new update, they saw new opportunities. This trend continues to this day. Sadly, many of them succeed - which only encourages them to reinvest stolen resources into even more elaborate schemes.
With such a massive wave of malicious activity, Telegram simply couldn't keep up with processing millions of abuse reports - some of which were sent by the scammers themselves to confuse moderators.
In 2024–2025, we returned to the idea of building a messenger - this time with a clearer understanding of what it should be.
We analyzed modern technologies and user needs to identify key weaknesses. But we still faced one major problem familiar to many early-stage projects: growth.
We weren't public figures, had no blog, and hadn't built an audience. Buying arrogant, intrusive ads wasn't an option either.
So, we turned to community-driven ways of growing.
After creating a Telegram account, we immediately ran into its moderation limits. The automated system mistakenly froze our account after a large group's admin banned us.
Eventually, Telegram's support team reviewed our appeal and unblocked the account within a day. We understand how such algorithms work - but the experience itself leaves a bitter aftertaste.
Telegram is doing its best to fight both scammers and censorship. Without insight into its internal processes, we can't judge its actions. Everything written here reflects only our personal experience - one you might have faced yourself.
Telegram used to be open and free. Today, it's increasingly overrun by scammers chasing easy profit.
In their fight against fraud, ordinary users have begun charging for private messaging.
Lawlessness led to chaos - and chaos undermined the fundamental principle of communication.
Now, if you want to talk, you need money. You pay simply to prove you're not a bot.
That approach may work for influencers, but not for everyday people. The fact remains: it's not the best solution.
And due to its very structure, Telegram cannot adopt another one.
To tackle scammers and bots, we decided to create TON Messenger, while also building in the features users love most.
In August 2025, we began development despite the challenges of organic growth. We rely on community support and have no interest in building corporate walls.
~10-minute read
This week, we'd like to share a brief story about how we came to create this project.
A long time ago, we discovered Telegram. Unfortunately, we can't recall exactly when that happened, but it was more than six years ago. After installing it, we were pleasantly surprised by how well-optimized the app was. It ran smoothly even on weaker devices. We were greeted by animated stickers, which in other apps would have caused noticeable delays.
Private, secure, fast, open, free, powerful - everything lived up to its promise. What attracted us most was that Telegram's source code was open, unlike most other messengers.
But that was before Telegram started to drift away from its original principles. A paid subnoscription appeared. Ads were introduced.
Like most users, we supported these changes - we're sure it wasn't an easy decision for the team, and they handled it well. But since then, things have slowly started to change for the worse.
At that time, we became interested in creating a modified Telegram client. Still, we didn't see much real need for users. Those were narrow, specialized solutions that never went public.
Years later, around 2023–2024, the idea of building our own messenger resurfaced. But it didn't differ much from Telegram back then, so we shelved it for the time being.
Meanwhile, scams kept spreading. Fraudsters found new ways to deceive people, and with each new update, they saw new opportunities. This trend continues to this day. Sadly, many of them succeed - which only encourages them to reinvest stolen resources into even more elaborate schemes.
With such a massive wave of malicious activity, Telegram simply couldn't keep up with processing millions of abuse reports - some of which were sent by the scammers themselves to confuse moderators.
In 2024–2025, we returned to the idea of building a messenger - this time with a clearer understanding of what it should be.
We analyzed modern technologies and user needs to identify key weaknesses. But we still faced one major problem familiar to many early-stage projects: growth.
We weren't public figures, had no blog, and hadn't built an audience. Buying arrogant, intrusive ads wasn't an option either.
So, we turned to community-driven ways of growing.
After creating a Telegram account, we immediately ran into its moderation limits. The automated system mistakenly froze our account after a large group's admin banned us.
Eventually, Telegram's support team reviewed our appeal and unblocked the account within a day. We understand how such algorithms work - but the experience itself leaves a bitter aftertaste.
Telegram is doing its best to fight both scammers and censorship. Without insight into its internal processes, we can't judge its actions. Everything written here reflects only our personal experience - one you might have faced yourself.
Telegram used to be open and free. Today, it's increasingly overrun by scammers chasing easy profit.
In their fight against fraud, ordinary users have begun charging for private messaging.
Lawlessness led to chaos - and chaos undermined the fundamental principle of communication.
Now, if you want to talk, you need money. You pay simply to prove you're not a bot.
That approach may work for influencers, but not for everyday people. The fact remains: it's not the best solution.
And due to its very structure, Telegram cannot adopt another one.
To tackle scammers and bots, we decided to create TON Messenger, while also building in the features users love most.
In August 2025, we began development despite the challenges of organic growth. We rely on community support and have no interest in building corporate walls.
❤2
We share Telegram's fight for freedom of speech - that's why our messenger features end-to-end encryption by default and decentralized moderation.
We believe true strength lies within the community.
Freedom of expression and the ability to moderate reckless behavior belong in the hands of users themselves.
Communication is a fundamental part of human nature.
It must remain private.
It must remain free - not something you have to earn or pay for.
Blocking, monetizing, or surveilling communication is like forbidding people to breathe.
We're not trying to replace Telegram.
We see it as friendly competition - a technological race that can push both projects to improve.
If our messenger inspires Telegram to get better, that's a win for everyone.
Our goal is to strengthen the messenger ecosystem and bring it back to the principles the community once believed in.
We're deeply grateful that the community responded to our idea.
Special thanks to TON Monitoring for sharing the news about our launch.
We'll continue to publish our development progress and decision-making openly.
If you disagree with something, please tell us - we read every message and will always look for the most balanced solution.
Perhaps our story wasn't told as vividly as it could be, and maybe we missed a few details or links between events.
If you think so, give us a thumbs-down - we'll improve next time.
Next week, we'll talk about fighting bots and scammers.
Cryptocurrency: when your funds are in your hands.
TON Messenger: when your chats are in your hands.
We believe true strength lies within the community.
Freedom of expression and the ability to moderate reckless behavior belong in the hands of users themselves.
Communication is a fundamental part of human nature.
It must remain private.
It must remain free - not something you have to earn or pay for.
Blocking, monetizing, or surveilling communication is like forbidding people to breathe.
We're not trying to replace Telegram.
We see it as friendly competition - a technological race that can push both projects to improve.
If our messenger inspires Telegram to get better, that's a win for everyone.
Our goal is to strengthen the messenger ecosystem and bring it back to the principles the community once believed in.
We're deeply grateful that the community responded to our idea.
Special thanks to TON Monitoring for sharing the news about our launch.
We'll continue to publish our development progress and decision-making openly.
If you disagree with something, please tell us - we read every message and will always look for the most balanced solution.
Perhaps our story wasn't told as vividly as it could be, and maybe we missed a few details or links between events.
If you think so, give us a thumbs-down - we'll improve next time.
Next week, we'll talk about fighting bots and scammers.
Cryptocurrency: when your funds are in your hands.
TON Messenger: when your chats are in your hands.
❤3👍2🔥2
Fighting Scammers and Bots
To combat fraud, we built our protection system around an algorithm that includes not only a classic anti-spam model but also two key components:
1. Invitation System
Users can invite their friends, who can freely join the messenger.
Those who invite bots will be banned.
We don’t like spam bots. No one likes spam bots.
This forms a tree of users. Accounts that generate spam are like infected branches - and we'll prune them.
2. Proof of Humanity (optional and anonymous)
Only users who want to invite others need to complete this procedure.
Registration itself remains simple - it only requires an invitation link.
We use this mechanism to prevent spammers from recreating accounts.
Unlike KYC systems used by CEXs or Fragment, which require you to submit personal data, Proof of Humanity works as a zero-knowledge proof (ZKP)
That means you stay anonymous while spammers lose the ability to re-register.
We only know one fact - that you are a real human being.
We've chosen World ID (world.org) as our initial provider. Over 14 million real people already trust this service.
Its main advantage is that it runs on blockchain technology, which means even if a central server is compromised, verification data cannot be forged.
We plan to integrate other providers in the future.
As a small bonus, verified users will have a check mark next to their username. Verification is optional and can be completed anytime.
Once your group or channel reaches a certain size, it will also receive a verification check mark.
This will help users trust channels more, knowing that real people stand behind them.
If you think we'll stop at verification - you’re mistaken.
We're adding support for polls and giveaways limited to real, verified humans.
Sometimes, it's essential to ensure that only real people participate in a vote - especially today, when freedom is under threat and propaganda bots flood channels and polls with fake votes, misleading communities.
From now on, votes will truly carry weight - while still remaining anonymous.
If you want to thank your subscribers, the best way will be through giveaways.
We’ll share more details about polls and giveaways later, as we plan to base them on smart contracts for full transparency and verifiable fairness.
This will help unlock the full potential of decentralization within the messenger.
Now, back to anti-spam protection.
What if an account is mistakenly blocked?
To ensure fair resolutions, we plan to introduce a hybrid appeal system:
1. Centralized appeals review - works faster but may be subject to human error or algorithmic bias.
2. Decentralized appeals review - avoids these issues and has priority over centralized decisions.
Through community consensus, a user, group, or channel can be reinstated.
Consensus takes more time but produces fairer outcomes.
The reputation algorithm (or "vote weight") for consensus members won't depend solely on finances.
It will factor in account age, verification status, interactions, past decisions, activity, and more.
The exact participant-selection algorithm will be defined later - it requires careful tuning to maintain balance.
We can't rely purely on wealth, since scammers often control large sums of stolen funds.
Money alone doesn't equal fairness.
This system aims to eliminate spam accounts while keeping registration easy for ordinary users.
Without access to mass bot networks, most scammers won’t be able to operate as actively as they do now.
We estimate this system could neutralize over 70% of fraudulent activity.
If you have questions or suggestions, we'd love to hear them. You can share your thoughts using the button below.
Our next post will cover our weaknesses.
We'll be completely honest - because we believe transparency is the best way forward.
Some weaknesses we're already addressing. Others we still need to solve.
Perhaps you'll be among those who help us do it
To combat fraud, we built our protection system around an algorithm that includes not only a classic anti-spam model but also two key components:
1. Invitation System
Users can invite their friends, who can freely join the messenger.
Those who invite bots will be banned.
We don’t like spam bots. No one likes spam bots.
This forms a tree of users. Accounts that generate spam are like infected branches - and we'll prune them.
2. Proof of Humanity (optional and anonymous)
Only users who want to invite others need to complete this procedure.
Registration itself remains simple - it only requires an invitation link.
We use this mechanism to prevent spammers from recreating accounts.
Unlike KYC systems used by CEXs or Fragment, which require you to submit personal data, Proof of Humanity works as a zero-knowledge proof (ZKP)
That means you stay anonymous while spammers lose the ability to re-register.
We only know one fact - that you are a real human being.
We've chosen World ID (world.org) as our initial provider. Over 14 million real people already trust this service.
Its main advantage is that it runs on blockchain technology, which means even if a central server is compromised, verification data cannot be forged.
We plan to integrate other providers in the future.
As a small bonus, verified users will have a check mark next to their username. Verification is optional and can be completed anytime.
Once your group or channel reaches a certain size, it will also receive a verification check mark.
This will help users trust channels more, knowing that real people stand behind them.
If you think we'll stop at verification - you’re mistaken.
We're adding support for polls and giveaways limited to real, verified humans.
Sometimes, it's essential to ensure that only real people participate in a vote - especially today, when freedom is under threat and propaganda bots flood channels and polls with fake votes, misleading communities.
From now on, votes will truly carry weight - while still remaining anonymous.
If you want to thank your subscribers, the best way will be through giveaways.
We’ll share more details about polls and giveaways later, as we plan to base them on smart contracts for full transparency and verifiable fairness.
This will help unlock the full potential of decentralization within the messenger.
Now, back to anti-spam protection.
What if an account is mistakenly blocked?
To ensure fair resolutions, we plan to introduce a hybrid appeal system:
1. Centralized appeals review - works faster but may be subject to human error or algorithmic bias.
2. Decentralized appeals review - avoids these issues and has priority over centralized decisions.
Through community consensus, a user, group, or channel can be reinstated.
Consensus takes more time but produces fairer outcomes.
The reputation algorithm (or "vote weight") for consensus members won't depend solely on finances.
It will factor in account age, verification status, interactions, past decisions, activity, and more.
The exact participant-selection algorithm will be defined later - it requires careful tuning to maintain balance.
We can't rely purely on wealth, since scammers often control large sums of stolen funds.
Money alone doesn't equal fairness.
This system aims to eliminate spam accounts while keeping registration easy for ordinary users.
Without access to mass bot networks, most scammers won’t be able to operate as actively as they do now.
We estimate this system could neutralize over 70% of fraudulent activity.
If you have questions or suggestions, we'd love to hear them. You can share your thoughts using the button below.
Our next post will cover our weaknesses.
We'll be completely honest - because we believe transparency is the best way forward.
Some weaknesses we're already addressing. Others we still need to solve.
Perhaps you'll be among those who help us do it
🔥4❤2👍1👎1👀1
Your opinion on forums
Anonymous Poll
38%
I like forums on Telegram
17%
I don't like on Telegram
24%
I like forums on Discord
34%
Classic group chat is better
Official list of our domains
tonm.org / tonm.app
Main domain for the application
tonm.dev
Will host documentation and developer tools
tonm.cc / tonm.chat
Used for short links like
ton-messenger.ton
Web3 domain on the TON Blockchain
At the moment, all of these redirect to tonm.org
We reserved the .app domain to protect our users, since we use the username tonm-app on social media.
For other TLDs, we consider repeating this unnecessary.
The recent "rnicrosoft" case proves that scammers will always find ways to register similar domains, even targeting large companies.
Our project hasn't launched yet, but scammers may already try to misuse its name.
We'll update this channel if any domain information changes.
Be careful!
tonm.org / tonm.app
Main domain for the application
tonm.dev
Will host documentation and developer tools
tonm.cc / tonm.chat
Used for short links like
tonm.cc/draco or draco.tonm.ccton-messenger.ton
Web3 domain on the TON Blockchain
At the moment, all of these redirect to tonm.org
We reserved the .app domain to protect our users, since we use the username tonm-app on social media.
For other TLDs, we consider repeating this unnecessary.
The recent "rnicrosoft" case proves that scammers will always find ways to register similar domains, even targeting large companies.
Our project hasn't launched yet, but scammers may already try to misuse its name.
We'll update this channel if any domain information changes.
Be careful!
❤2👍2🎉1
— Weaknesses —
As promised, this week we will reveal the weaknesses of our project. We aim to be as honest as possible and will immediately describe how we plan to address these issues.
— Legal Matters —
We don’t have a legal department. We understand its importance, especially for a project entering the global market. For now, we rely on our own legal knowledge, which means mistakes are possible. We will strive to comply with all major laws that do not contradict our principles.
If you represent law enforcement, you can always contact us to report any violations.
We also want to emphasize that we strongly oppose actions aimed at harming people. That is why we have implemented an anti-fraud algorithm. As mentioned earlier, users can also participate in content moderation. These platform rules are constant.
- - Lack of Independent Audit
To increase user trust, independent security audits are essential. At the moment, we are not partnered with any such organizations. However, since our project is open source, anyone can act as an auditor.
— Lack of "Popularity" —
We often hear questions like:
- Who is developing this project?
- Is it worth our attention and time?
- What projects has the team worked on before?
You may have heard of us, or maybe not. We haven't had large public projects before, and information about other projects we've created is under NDA.
Two main doubts you might have:
1. Will the project reach release? Is it worth my attention now?
These are logical questions. Many good and unique projects never make it to launch. We can’t predict everything to give a 100% guarantee, but we have solid planning and time management. We’ve also anticipated most potential challenges, and we have a clear roadmap for the next year. We share our current progress here, confirming our determination to move forward.
2. Could my money or data be stolen?
Developers can easily verify a project's integrity, but what about regular users? In the era of AI (LLMs), anyone can review open-source projects, even without coding knowledge. This still isn’t an absolute guarantee, but such verification should be enough for most users. Later, we'll publish a detailed guide on how to check a project and stay safe online.
— Lack of Personnel —
Unfortunately, some members of our small team have left for personal reasons. There are currently two people on the team, which is not enough for active development. Maintaining three parallel clients (Desktop, iOS, Android) requires at least three developers.
Since we are an open-source project, anyone can join development. However, at early stages, it's hard to find active contributors. Therefore, we decided to build the foundation ourselves first to demonstrate capabilities before expanding the team.
Recruiting new members requires verifying their qualifications and work quality. We also need strict access control, which requires additional preparation. Selecting the right people demands careful screening from a large pool of candidates.
As a project focused on user trust and security, we treat this matter with special care. Even large companies sometimes employ dishonest workers. We intentionally limit the number of core team members to reduce such risks, as we are not yet fully equipped to monitor all work processes. Developing tools that balance oversight and employee freedom will take time.
We have efficiently distributed our current tasks so that the minimal team can handle them. At this protocol development stage, there is no need to expand the team yet.
But here's some good news: we already have a date for the first recruitment phase. After the beta release, we will open testing positions for anyone who wishes to participate.
As promised, this week we will reveal the weaknesses of our project. We aim to be as honest as possible and will immediately describe how we plan to address these issues.
— Legal Matters —
We don’t have a legal department. We understand its importance, especially for a project entering the global market. For now, we rely on our own legal knowledge, which means mistakes are possible. We will strive to comply with all major laws that do not contradict our principles.
If you represent law enforcement, you can always contact us to report any violations.
We also want to emphasize that we strongly oppose actions aimed at harming people. That is why we have implemented an anti-fraud algorithm. As mentioned earlier, users can also participate in content moderation. These platform rules are constant.
- - Lack of Independent Audit
To increase user trust, independent security audits are essential. At the moment, we are not partnered with any such organizations. However, since our project is open source, anyone can act as an auditor.
— Lack of "Popularity" —
We often hear questions like:
- Who is developing this project?
- Is it worth our attention and time?
- What projects has the team worked on before?
You may have heard of us, or maybe not. We haven't had large public projects before, and information about other projects we've created is under NDA.
Two main doubts you might have:
1. Will the project reach release? Is it worth my attention now?
These are logical questions. Many good and unique projects never make it to launch. We can’t predict everything to give a 100% guarantee, but we have solid planning and time management. We’ve also anticipated most potential challenges, and we have a clear roadmap for the next year. We share our current progress here, confirming our determination to move forward.
2. Could my money or data be stolen?
Developers can easily verify a project's integrity, but what about regular users? In the era of AI (LLMs), anyone can review open-source projects, even without coding knowledge. This still isn’t an absolute guarantee, but such verification should be enough for most users. Later, we'll publish a detailed guide on how to check a project and stay safe online.
— Lack of Personnel —
Unfortunately, some members of our small team have left for personal reasons. There are currently two people on the team, which is not enough for active development. Maintaining three parallel clients (Desktop, iOS, Android) requires at least three developers.
Since we are an open-source project, anyone can join development. However, at early stages, it's hard to find active contributors. Therefore, we decided to build the foundation ourselves first to demonstrate capabilities before expanding the team.
Recruiting new members requires verifying their qualifications and work quality. We also need strict access control, which requires additional preparation. Selecting the right people demands careful screening from a large pool of candidates.
As a project focused on user trust and security, we treat this matter with special care. Even large companies sometimes employ dishonest workers. We intentionally limit the number of core team members to reduce such risks, as we are not yet fully equipped to monitor all work processes. Developing tools that balance oversight and employee freedom will take time.
We have efficiently distributed our current tasks so that the minimal team can handle them. At this protocol development stage, there is no need to expand the team yet.
But here's some good news: we already have a date for the first recruitment phase. After the beta release, we will open testing positions for anyone who wishes to participate.
❤4
Self-Funding
We have designed a strategy that requires minimal financial input. The project can be funded by the team and future project revenue.
We also decided to decline offers from funds and investors for now to maintain user trust in our neutrality. If we ever decide to change this, we will hold a public vote.
After launching version two of the protocol (federation system), the project will be able to operate independently on users' private servers, remaining secure and global without central funding.
Our project is open source and aims for a decentralized approach, similar to blockchain. This adds technical complexity as it requires balancing security and architecture. We are introducing this feature gradually to ensure a well-thought-out and stable implementation. Our current priority is the core functions we previously announced: post-quantum protection, end-to-end encryption, wallet (client-side), and the anti-spam system.
Although some of this might discourage certain users, we believe honesty is essential. We hope this post was structured more clearly and did not create any false impressions. If you have doubts or questions, feel free to contact us via the "chat" button below.
We would love to hear what else you want to learn about the project. We currently have three ideas for upcoming posts:
- Opportunities for content creators
- Our opinion on Chat Control
- Hidden benefits for every user
We have designed a strategy that requires minimal financial input. The project can be funded by the team and future project revenue.
We also decided to decline offers from funds and investors for now to maintain user trust in our neutrality. If we ever decide to change this, we will hold a public vote.
After launching version two of the protocol (federation system), the project will be able to operate independently on users' private servers, remaining secure and global without central funding.
Our project is open source and aims for a decentralized approach, similar to blockchain. This adds technical complexity as it requires balancing security and architecture. We are introducing this feature gradually to ensure a well-thought-out and stable implementation. Our current priority is the core functions we previously announced: post-quantum protection, end-to-end encryption, wallet (client-side), and the anti-spam system.
Although some of this might discourage certain users, we believe honesty is essential. We hope this post was structured more clearly and did not create any false impressions. If you have doubts or questions, feel free to contact us via the "chat" button below.
We would love to hear what else you want to learn about the project. We currently have three ideas for upcoming posts:
- Opportunities for content creators
- Our opinion on Chat Control
- Hidden benefits for every user
👍1🔥1
For what Telegram 2.0?
Many people are understandably puzzled and ask: why enter the crowded messenger space?
Telegram is an excellent messenger with a huge feature set: bots, TMAs, a built‑in Web3 browser, Instant View. There are so many features that listing them all in one post would be difficult. It's a great platform, so why build a separate TON Messenger?
It comes down to privacy.
Telegram (MTProto 2.0 Part I Cloud Chats) uses client‑server encryption. This is not end‑to‑end (E2E), it's point‑to‑point (P2P) encryption. This means that your messages from private one‑to‑one chats, groups, and channels are in plaintext on Telegram's servers after receipt.
Messages are additionally encrypted on the server so that a database compromise without Telegram's keys would not let an attacker decrypt them. But this does not change the fact that Telegram already has the full context of your message.
E2E encryption is implemented in MTProto (Part II - Secret Chats), and according to the official source they are gaining popularity.
However, we looked for usage statistics for Secret Chats and found none.
Secret Chats have several drawbacks:
— No support in the desktop app on Windows and Linux, which together account for ~70-80% of desktop operating‑system market share
— No multi‑device sync
— No reactions and some other conveniences available in Cloud Chats
— Private group chats and channels still lack E2EE
Note: End‑to‑End encryption is on by default for one‑to‑one voice and video calls, which is great. It is absent for group calls.
To sum up: you can switch to end‑to‑end encryption, but you will lose many messenger advantages.
This is not an expose of Telegram, because everything cited from official Telegram public sources.
But many regular users are under the illusion that private one‑to‑one chats and Secret Chats are the same. We simply want to remind you that the classic mode of communication most people use in Telegram is not private and not fully secure.
Pavel Durov has already answered the question "why isn't end‑to‑end encryption on by default":
The phrase "encrypted in the same way" is the core sleight of hand/wording error here.
End‑to‑End encryption in the context of messengers means a message is delivered from one client to another without decryption on the server. In Telegram’s case, this rule is broken for Cloud Chats.
Many people are understandably puzzled and ask: why enter the crowded messenger space?
Telegram is an excellent messenger with a huge feature set: bots, TMAs, a built‑in Web3 browser, Instant View. There are so many features that listing them all in one post would be difficult. It's a great platform, so why build a separate TON Messenger?
It comes down to privacy.
Telegram (MTProto 2.0 Part I Cloud Chats) uses client‑server encryption. This is not end‑to‑end (E2E), it's point‑to‑point (P2P) encryption. This means that your messages from private one‑to‑one chats, groups, and channels are in plaintext on Telegram's servers after receipt.
Messages are additionally encrypted on the server so that a database compromise without Telegram's keys would not let an attacker decrypt them. But this does not change the fact that Telegram already has the full context of your message.
E2E encryption is implemented in MTProto (Part II - Secret Chats), and according to the official source they are gaining popularity.
However, we looked for usage statistics for Secret Chats and found none.
Secret Chats have several drawbacks:
— No support in the desktop app on Windows and Linux, which together account for ~70-80% of desktop operating‑system market share
— No multi‑device sync
— No reactions and some other conveniences available in Cloud Chats
— Private group chats and channels still lack E2EE
Note: End‑to‑End encryption is on by default for one‑to‑one voice and video calls, which is great. It is absent for group calls.
To sum up: you can switch to end‑to‑end encryption, but you will lose many messenger advantages.
This is not an expose of Telegram, because everything cited from official Telegram public sources.
But many regular users are under the illusion that private one‑to‑one chats and Secret Chats are the same. We simply want to remind you that the classic mode of communication most people use in Telegram is not private and not fully secure.
Pavel Durov has already answered the question "why isn't end‑to‑end encryption on by default":
So after some research we decided to introduce 2 kinds of chats – Secret chats and Cloud chats.
Secret chats are e2e-encrypted chats that never under any circumstances get backed up.
Cloud chats are encrypted in the same way, but also have a built-in cloud backup.
The phrase "encrypted in the same way" is the core sleight of hand/wording error here.
End‑to‑End encryption in the context of messengers means a message is delivered from one client to another without decryption on the server. In Telegram’s case, this rule is broken for Cloud Chats.
Unlike WhatsApp, criticized for data‑sharing practices, Telegram keeps its promises. But the privacy of your data depends solely on Telegram's own goodwill. After Telegram began moving away from some of its original principles promised to users, compliance with other principles also begins to be questioned.
Just as there is a claim about Signal being unsafe on iPhone, we are ennoscriptd to assume there may be an insufficient level of security for our Telegram messages, since we cannot independently audit this.
To clarify what kinds of encryption we are even talking about, consider this list:
- Telegram (Secret Chats): DH
- Signal: X3DH
- TON Blockchain: ECDH
Notice the similarity? Exactly.
Diffie–Hellman (DH) is a cryptographic key‑exchange protocol. On top of it, X3DH and ECDH were developed to improve security.
We chose to adapt PQXDH for our needs.
By this we mean that messengers use protocols from the same family.
But none of them meet all the rules of end-to-end encrypted chats.
We respect and value Pavel Durov's fight for free speech, so we believe our personal chats on Telegram's servers are kept safe.
But trust alone is not enough to prove that this is actually the case.
Secret Chats are limited in functionality. Private groups and channels still lack E2E encryption.
Back to the original problem, which is simple in essence: how to make cloud backups safe?
Our solution is to store private keys on the server in encrypted form.
At the user's discretion this option can be disabled, in which case access to a chat remains on a single device.
The robustness of this approach is comparable to the security of encrypted transaction comments in the TON Blockchain.
We have tried in this post to stick to facts, but please verify them independently. If you spot any error, you can notify us by tapping the "chat" button below.
We decided to create not just another messenger, but a messenger that truly adheres to these principles. If we say a messenger is private, it means it has end-to-end encryption for all chat types, open source, reproducible build and synchronization between devices with cross-platform client support.
This isn't the only reason, but it's a basic one.
Users shouldn't be misled.
Users should have privacy.
Just as there is a claim about Signal being unsafe on iPhone, we are ennoscriptd to assume there may be an insufficient level of security for our Telegram messages, since we cannot independently audit this.
To clarify what kinds of encryption we are even talking about, consider this list:
- Telegram (Secret Chats): DH
- Signal: X3DH
- TON Blockchain: ECDH
Notice the similarity? Exactly.
Diffie–Hellman (DH) is a cryptographic key‑exchange protocol. On top of it, X3DH and ECDH were developed to improve security.
We chose to adapt PQXDH for our needs.
By this we mean that messengers use protocols from the same family.
But none of them meet all the rules of end-to-end encrypted chats.
We respect and value Pavel Durov's fight for free speech, so we believe our personal chats on Telegram's servers are kept safe.
But trust alone is not enough to prove that this is actually the case.
Secret Chats are limited in functionality. Private groups and channels still lack E2E encryption.
Back to the original problem, which is simple in essence: how to make cloud backups safe?
Our solution is to store private keys on the server in encrypted form.
At the user's discretion this option can be disabled, in which case access to a chat remains on a single device.
The robustness of this approach is comparable to the security of encrypted transaction comments in the TON Blockchain.
We have tried in this post to stick to facts, but please verify them independently. If you spot any error, you can notify us by tapping the "chat" button below.
We decided to create not just another messenger, but a messenger that truly adheres to these principles. If we say a messenger is private, it means it has end-to-end encryption for all chat types, open source, reproducible build and synchronization between devices with cross-platform client support.
This isn't the only reason, but it's a basic one.
Users shouldn't be misled.
Users should have privacy.
TON Messenger Q&A
We would also like to address this week a misconception among users caused by the limited amount of publicly available information about the project.
This is our fault, as we should have published all upcoming features earlier. However, many of them are still pending approval or require additional verification, so we share updates gradually as they are confirmed.
Will messages be paid?
No. Quite the opposite. That would contradict the principles of free, basic communication between users.
Only the storage of large media files might become paid. Unfortunately, we do not have our own data center to be as generous with file limits as some major tech companies.
For transferring large media files, we recommend using dedicated storage services for big data.
Are polls available only for verified users?
No. We do not plan to force users to go through verification. That would restrict the actions of regular users, which we do not accept.
You can read more about this here.
Are you part of the TON Foundation?
No. Our project was not founded by representatives of the TON Foundation and is not funded by them.
We did register on TON Builders, but we do not participate in any partnership programs.
We wanted to take part in the project presentation sessions, but unfortunately, we currently don’t have a suitable speaker for such events.
You can read more about our origin story here.
Authentication via phone number?
No. You can start using our messenger immediately, as login is based on a mnemonic phrase - similar to creating a crypto wallet.
We decided not to use phone number authentication for several reasons:
- In most countries, phone numbers are linked to passports and reveal the user’s country - data unnecessary for messenger operation
- Dependence on telecom providers
- The method is not effective enough for bot protection
- Network and carrier issues may arise when changing countries
- Losing access to the number means losing access to the account
- Requires keeping the number active, and obtaining a new one for a new account
- If a SIM card is compromised, an attacker can gain access to the account without 2FA
We are ready to answer any further questions. We also always appreciate well-reasoned criticism and suggestions.
Additionally, we would like to thank everyone who has already shown initiative and supported us. We truly value it. 🩵
Thanks to you, we learn new things and better understand what matters across different parts of the community. We listen to every suggestion to create a comfortable space for everyone.
We would also like to address this week a misconception among users caused by the limited amount of publicly available information about the project.
This is our fault, as we should have published all upcoming features earlier. However, many of them are still pending approval or require additional verification, so we share updates gradually as they are confirmed.
Will messages be paid?
No. Quite the opposite. That would contradict the principles of free, basic communication between users.
Only the storage of large media files might become paid. Unfortunately, we do not have our own data center to be as generous with file limits as some major tech companies.
For transferring large media files, we recommend using dedicated storage services for big data.
Are polls available only for verified users?
No. We do not plan to force users to go through verification. That would restrict the actions of regular users, which we do not accept.
You can read more about this here.
Are you part of the TON Foundation?
No. Our project was not founded by representatives of the TON Foundation and is not funded by them.
We did register on TON Builders, but we do not participate in any partnership programs.
We wanted to take part in the project presentation sessions, but unfortunately, we currently don’t have a suitable speaker for such events.
You can read more about our origin story here.
Authentication via phone number?
No. You can start using our messenger immediately, as login is based on a mnemonic phrase - similar to creating a crypto wallet.
We decided not to use phone number authentication for several reasons:
- In most countries, phone numbers are linked to passports and reveal the user’s country - data unnecessary for messenger operation
- Dependence on telecom providers
- The method is not effective enough for bot protection
- Network and carrier issues may arise when changing countries
- Losing access to the number means losing access to the account
- Requires keeping the number active, and obtaining a new one for a new account
- If a SIM card is compromised, an attacker can gain access to the account without 2FA
We are ready to answer any further questions. We also always appreciate well-reasoned criticism and suggestions.
Additionally, we would like to thank everyone who has already shown initiative and supported us. We truly value it. 🩵
Thanks to you, we learn new things and better understand what matters across different parts of the community. We listen to every suggestion to create a comfortable space for everyone.
🔥7👍2❤1👀1