We prepared a detailed description of transitions between the main required modules, coordinated between our departments (UX/UX, iOS, Android, backend), received approval from the client and documented all of it.

We’ve put together a map of the product’s features. Each major section of the application is a branch of the diagram, and then there are details: lists, cell states, buttons, types of content display, features of errors or queries, and so on.

After that together with the client we’ve used the feature map to identify he MVP (minimum viable product) scope so that we could launch the first version of the messenger in the shortest time possible. Then we prioritized the remaining features: features to refine in the first sprints after launch and backlog features.

Nowadays all the messengers on the market look almost identical. Ours was no exception. We feel that it’s more important to keep the interface familiar and easy to get used to, convenient and rather than striving for uniqueness.

Therefore, we have relied on familiar UX patterns similar to what is used in mainstream messenger apps, directing extra attention at Facebook Messenger which has its largest user base in Vietnam.

And for uniqueness, recognition and style, we expanded the brand palette (made it more suitable for screens, added saturation and gradient transitions), painted the main elements in bright orange, embedded branded numbers in the application, designed juicy icons.

MCU (multipoint control unit) allows to significantly reduce the consumption of user traffic in comparison to FM (Full Mesh — all participants are connected so they send and receive audio in pairs) and SFU (Single Forwarding Unit — participants send their audio to the server once and receive incoming audio from all other participants through a separate channel) and make it independent from the quantity of conference participants.

For MCU scheme there are only 2 audio channels per subscriber, outgoing and incoming, mixed from other participants' channels. The server does extra work to decode, mix, and encode the streams, but each participant’s traffic is constant and independent of the size of the conference. This allows creating audio conferences with any number of contacts.

Our research also showed that using modern codecs for the number of participants over 8, the load on the server is even lower than when using SFU.

We wanted to give our users the highest level of privacy in their correspondence and decided that we needed to implement Perfect Forward Secrecy (PFS) methods. PFS means that long term key information stored on users' devices is not used to encrypt messages and documents. Instead, a temporary (ephemeral) key is created between users that changes with each new message, and long-term keys are only used for mutual authentication.

Thus, the leakage of long-term keys can compromise the correspondence of users, which will take place after the fact of leakage, but will not allow an intruder to decrypt the traffic generated before the leakage of keys.

The problem of PFS is the need for two users to be present at the moment when the communication starts in order to agree on the ephemeral key according to the Diffie-Hellman method. Obviously, mobile device users may sometimes be unavailable (so, for example, if you use Telegram secret chats, then, when creating such a chat, you see the message "Waiting for the recipient to be online" - this is due to the fact that the application needs to agree on an ephemeral key).

To solve this problem, we applied the technique of "breaking" the Diffie-Hellman procedure in time. Each user publishes his "partial" keys (which under the standard procedure he has to send in response to the matching request) in advance on the server (providing them with his signature and lifetime, of course), and, if we want to create a secure session with a new contact, we take the "partial" key and consider it the user’s "response" to our matching request, that is we can form a full key and start sending messages and documents.

The recipient of the session, being online, will download a request from the server to create a session and "complete" it to an ephemeral key (the essence of the Diffie-Hellman protocol is that this ephemeral key will be the same as the one received by the initiator of the session) and can decrypt incoming messages.

Since all messages are encrypted and the server cannot decrypt them (only the sender and the recipient have the plaintext of each message), the entire correspondence history is stored locally. This creates a lot of technical challenges to maintain consistency, optimizing requests to such local storage. But on the other hand, our users get to keep their access to the entire message history even without access to the Internet!

As we use an app a huge number of events occur that we want to notify users about instantly. For example, if another user starts typing, changes their avatar, changes their name, or sends us a new message, or maybe they’re just online.
Delivering such notifications is a serious load on the server. There are many approaches, and we have chosen the one that will allow us to serve large pools of users and scale horizontally with the growth of the audience — the so-called Weak Messaging.

If the session time (duration of user interaction with the application) is short and amounts to 10−20 minutes per day, the approach with periodic request for changes is acceptable. In this case, updates are delivered "pseudo-asynchronously", this creates a rather large parasitic load on the network, the device battery and the server.
Applications that require "honest" asynchronous delivery of updates use two approaches: Strong Messaging and Weak Messaging. The difference is that in Strong Messaging, any state of the application can be updated to the current actual state. This approach is much easier to implement on both the client and the server, but it has a user-base limit because it places a heavy load on the server database.

Weak Messaging, on the other hand, allows updating the user to the current state only in a certain (small) time interval, so it distinguishes between cold-start synchronization, which is performed by requesting the current state, and hot-start synchronization, which is performed by sending updates. This approach has the advantage of String Messaging — asynchronous delivery of atomic updates — and does not create a high load on the disks/database of the server, because "weak" updates exist only in RAM (this is what causes the time limit on the synchronization window). If the client application for some reason went outside the synchronization window, it will be forced to re-run the "cold" synchronization in order to return to the "hot" updates.