We have not published progress updates for a while. Time to fix that.
Even though we are not moving as fast as we would like, we can still share some of what has been done.
If you are not a developer, you can skip the first 2 points.
1. Multiple Cryptography Types
We had a problem: post-quantum cryptographic algorithms are not fast enough in the browser environment.
Since the first public release is planned for browser and desktop, it was important for us to support JavaScript, which is relatively weak for heavy cryptography.
We decided to allow both users and developers to choose between different options in the protocol:
- ECDH for browser / weaker devices, or post-quantum ML-KEM
- Ed25519 or post-quantum ML-DSA
This will apply both to the connection itself and to the messages.
2. JavaScript SDK
Right now we are working on the SDK for the web application.
This will include modules such as:
@tonm/core – shared core utilities@tonm/client – for convenient client development@tonm/bot – for the future Bot API, structured similarly to @tonm/clientThe modules will provide:
- Auto-generation of types and code from schemas, so client code updates instantly when the API version changes
- 3 transport layers: HTTP, WebSocket, TONMP
- All required cryptographic functions
- TONMP requests serialization and deserialization
- Handle events with automatic decryption and message signature verification
We care about DX, so the SDKs will feel familiar. If you have worked with libraries like grammy or openai you already understand the experience we aim for.
3. Backend
Right now we are working on the protocol, including schema serialization and deserialization, sharing and versioning.
Previously we designed a custom architecture for our needs and the utilities required to support it.
We also worked on optimizing certain parts of the pipeline to reach maximum throughput. Our current estimate is that even the first version will be able to handle millions of RPS (requests per second). This is only a projection and will require benchmarking once we have the final version.
4. Documentation
We evaluated many options and narrowed it down to two: VitePress and Mintlify.
We currently prefer VitePress because it is fully open source.
In the future we may mirror the documentation in Mintlify.
The primary language of the documentation will be English. We also plan to use an LLM for automatic translation into other widely used languages to improve developer accessibility.
5. Fundraising and NFTs
Most of the points above are technical and not very transparent to non-technical users. So for everyone else we decided to just show a concept of the fundraising flow and NFT previews.
6. What’s next?
After we complete the JavaScript SDK and backend parts, we plan to start building the application interface and SDKs for Rust/Go or Python.
We're also planning to work on optimizing the processes needed to counter restrictions on free speech.
Even though the federation system is set for late 2026, we can already use ADNL as a decentralized network.
Right now, the issue to fix is latency.
🤍 Stay with us!