Hey community
We are facing a choice and we need your help.

As you already know, the key features of our messenger are:
- End-to-end encryption
- No spam bots
- Integration of blockchain functions
- Decentralization

Let us briefly explain which core development components these features involve:
- End-to-end encryption is part of the protocol (completed)
- The absence of spam bots is a characteristic of the registration system (in development)
- Integration of blockchain functions is implemented on the client side (planned after server-side completion)
- Decentralization is an application architecture that implies high availability and cryptographic verification of the integrity of distributed data (current stage)

We have made progress in developing the protocol, and the next stage for us is developing the backend.

While working on the server-side architecture, we realized that we have two paths:
1. Follow our original plan and, for v1, build a centralized solution with partial decentralization (using Web3 TON DNS), and after launch proceed to implementing v2.
2. The new plan: implement a fully decentralized solution right away.

Advantages of the new plan:
- The first decentralized messenger in the world - this will attract significant attention to the TON ecosystem and to the project itself
- True decentralization: while TON DNS increases availability, it does not eliminate the possibility of blocking or failure of a centralized system
- Open source: this will allow other developers to contribute not only to the client-side development but also to the server-side
- Increased user control over future releases: similar to how TON validator consensus accepts updates. Anyone will be able to run a part of the messenger themselves
- Eliminating double work: in the v1 -> v2 scenario we would have to heavily modify the architecture built in v1
- Interesting features: new developers also bring spontaneous brilliant ideas

Disadvantages:
- Time. This will shift our deadlines: the launch of the first client will be postponed. However, in the future this should positively affect the parallelization of client application development (more on this below)
This is likely the main disadvantage, as we do not want to break initially promised deadlines or disappoint user expectations.

Our main challenges:
At the moment, our primary difficulty lies in developing client applications, particularly designing a pleasant UI/UX experience aligned with each platform.
In fact, we specialize more in backend development rather than in software development as a whole.
Because of this, we encounter a paradox: it is easier for us to build a sophisticated server architecture than to create relatively simple or traditional interface layouts.

If we follow the second plan and deliver a robust backend architecture, it may attract more experienced frontend/software open-source developers. This should improve the future interface quality and therefore increase competitiveness.
Let us put it somewhat bluntly: do not try to do what you are not sufficiently good at.
It is better to join forces with other talents than to build everything on your own.

For comparison, take Telegram: the development was led by the Durov brothers. Nikolai Durov created the protocol, and Pavel Durov handled everything else.
We are inclined toward the second option, because we believe that product quality > marketing. We are competing with giants and geniuses, so we cannot afford to be "not good enough"
But we will trust your choice: the direction of our development is in your hands!