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.