Quasar Messenger — private communication without central storage
Development of the new messenger of the Quasar ecosystem begins. The first client is being built for Linux in C++ and Qt 6.
The idea
Personal correspondence must not sit in a central server database. Not “sit there encrypted”, not “sit there until collected” — not sit there. The project grew out of that requirement: if the server does not store the correspondence, it cannot hand it over either, no matter who asks and on what grounds.
It follows that delivery has to be built differently from the usual way — and that is where most of the work goes.
When both are online
The devices establish a direct protected connection, a message or a file goes straight to the recipient, and the history is kept only by the participants of the conversation. The server helps to find the other party and to introduce the devices, but never sees the plain text.
When the recipient is offline
A conversation must not depend on whose computer happens to be on. So a message does not wait on a server: it is encrypted on the sender's device, split into fragments with redundancy and temporarily spread among the participants of the network. When the recipient appears, their client collects the fragments from the nearest available nodes and assembles the message — it is decrypted on their device only.
A node holding a fragment knows neither its contents, nor the key, nor the whole message.
The wording matters here. We say “no central storage of personal correspondence”, not “nothing is stored anywhere”: the fragments do exist, they are encrypted and temporary, and promising their absence would be a lie.
Why Linux first
The first client is being built for Linux only: C++, Qt 6, an RPM package. The terminal was built the same way — one system first, where the architecture, the core and the network protocol are debugged, then a native build and verification on the rest.
Mobile versions will come later as a separate stage: iOS and Android have their own limits on background work and networking, and those are worth taking into account once the protocol has settled, not while it changes every week.
What is done and what comes next
The architecture is settled: the direct delivery model, the model of the temporary distributed store, the basic life cycle of a message. Next come a formal threat model, the protocol specification, the choice of cryptographic primitives and a prototype of the network transport.
The project page and the public roadmap — seven stages, with the count of what is done taken from the list itself. There are deliberately no dates on it: the architecture is complex, and a date on a public page turns into a commitment made before anyone knew what it costs.