Private communication

Quasar Messenger

Private by design. Powered by the network.

A private messenger where personal correspondence is not stored on a central server. The data belongs to the people in the conversation, and the network helps deliver it while the recipient is away.

Linux-firstC++Qt 6P2P / Swarm

Architecture settled · work on the Linux client is starting

Who may enter the network

Quasar Messenger is a closed network for registered users. Guests and anonymous nodes cannot access peer discovery, relays, delivery or shard storage.

A person's identity is their account at www.quasargen.com. Every device creates its key locally, registers the public part with the account and enters the Mesh with a Quasar-signed credential. The private key is not uploaded to the website and is not derived from the account password.

www-prod stores accounts, device associations, public keys, revocations and access rights, but not plaintext, private keys or complete conversation history. During a temporary website outage, previously trusted devices may continue operating until their credentials expire; new login and device enrolment require the trust authority.

How it works when both people are online

  1. The devices establish a direct, secured connection.
  2. The message or file goes straight to the recipient.
  3. History is kept only on the devices of the people in the conversation.
  4. The server helps find the other person and bring the devices together, but never receives plain text.

When the recipient is offline

A conversation should not depend on whose computer happens to be switched on. So the message does not wait on a server — it spreads across the network:

  1. The message is encrypted on the sender's device.
  2. The encrypted data is split into fragments.
  3. Redundancy is added, so the message can be reassembled even when some nodes disappear.
  4. The fragments are temporarily distributed among network participants.
  5. When the recipient appears, the client collects fragments from the nearest available nodes.
  6. The message is reassembled and decrypted only on the recipient's device.
  7. The network fragments are marked ready to be replaced by newer data.

The wording matters here. We say “no central storage of private correspondence”, not “nothing is stored anywhere”: fragments do exist, they are encrypted and temporary, and claiming otherwise would be untrue.

Storage contributed by participants

By default each client offers the network up to 200 MB of temporary encrypted storage. Anyone who wants to can raise it — to 500 MB, to a gigabyte, or more.

As the number of active devices grows, so do the network's raw capacity and ability to transfer data. Safe usable capacity is lower than the sum of quotas: some nodes are offline, while redundancy and repair need reserve space. The network therefore accounts separately for physical, currently available and safely usable capacity.

A node holding a fragment:

  • does not know its contents;
  • has no decryption key;
  • does not know the whole message;
  • may hold only one of the redundant parts;
  • automatically replaces delivered and expired fragments.

Private chats and public rooms are different things

Private chats

  • end-to-end encryption;
  • a direct connection while the other person is online;
  • network delivery while they are not;
  • history lives with the participants;
  • the server stores no plain text.

Public rooms

  • a separate protocol and its own policy;
  • signed blocks of history;
  • distributed storage;
  • owner and moderator rights;
  • removal of posts through signed moderation events;
  • blocking of participants and devices;
  • the current state of the room applied on the client side.

This is architecture under study, and we say so plainly: distributed storage, guaranteed deletion of every copy and full moderation are physically in conflict with one another. Presenting the unsolved as solved is the worst thing one can do on a question about privacy.

Voice and video

Two different modes, and they must not be confused.

Live calls — a direct secured stream with the lowest latency we can manage. When a direct connection cannot be established, Quasar's own relay network is used.

Voice and video messages — recordings that are encrypted and travel through the same distributed mechanism as messages and files.

A live conversation is never carried through distributed storage: it is a different kind of thing. The network helps deliver a recording; it does not replace a connection.

Roadmap

Seven stages

The “done out of all” count is computed from the list itself, not typed by hand.

T0 — Mesh architecture contract

6 / 13
  • Quasar Messenger is a standalone project and a distributed network of user devices
  • Linux-first, with a portable C++ core and a separate Qt 6 client
  • Private messages travel directly; offline delivery uses encrypted shards stored on participant devices
  • www.quasargen.com is the account and trust authority, not a conversation store
  • There are no guest or anonymous nodes: only authenticated accounts and registered devices may enter the Mesh
  • Integrations with Trading Terminal and Quasar AI are deferred until the core and standalone application are stable
  • Formal threat model and an honest account of visible metadata
  • Specification of Account ID, Device ID, keys, credentials and device revocation
  • Specification of message envelopes, versions, replay protection, duplication and reordering
  • Selection of reviewed cryptographic designs and libraries; no home-grown cryptography
  • Contract between the www-prod control plane and the independent Mesh
  • Specification of shard format, erasure coding, placement, TTL, repair and deletion
  • Test plan for loss, duplication, reordering, node failure, device revocation and attacks

T1 — headless Linux core

0 / 8
  • Portable Messenger Core library independent of the GUI
  • Quasar account login and registration of a locally generated device key
  • Verification of Quasar-signed device credentials and proof of private-key possession
  • Reject guests, unregistered, revoked and blocked nodes at every network boundary
  • End-to-end encrypted text messages between two CLI nodes
  • Protection against replay, duplication, loss and reordering
  • Encrypted local history
  • Revoke one device or block all devices belonging to an account

T2 — network transport

0 / 6
  • Discover trusted nodes through the Quasar control plane
  • Direct connections on LAN and across the Internet
  • NAT traversal and hole punching
  • Limited relay when a direct route is impossible; relays do not store conversation history
  • Reconnection, network changes and operation during temporary www-prod outages
  • Measure latency, loss, throughput and relay load

T3 — distributed offline delivery

0 / 9
  • Encrypt data before splitting it into shards
  • Erasure coding with measured redundancy parameters
  • Place shards with independent holders without storing the complete object on one node
  • Storage receipts, TTL, replacement and repair when nodes disappear
  • Reassemble and decrypt only on the recipient device
  • Safely replace delivered and expired shards
  • Voluntary storage quota from 200 MB, with separate physical, available and safe-capacity accounting
  • Protection against Sybil attacks, spam, forged receipts and exhaustion of other users' quotas
  • Test rig that removes 10%, 30% and 50% of holders without losing deliverable data

T4 — standalone Linux application

0 / 7
  • Qt 6 client over the completed Messenger Core
  • Quasar account login and management of the user's registered devices
  • Contacts, private conversations and precise delivery states
  • Management of local history and Mesh storage quota
  • Keyboard and screen-reader accessibility
  • RPM package, updates and crash recovery
  • Public application name and brand; Quasar Messenger remains the working name

T5 — files and media messages

0 / 5
  • Direct and distributed file transfer
  • Streaming encryption, resume and integrity verification
  • Voice and video messages
  • Safe previews
  • Quota, traffic, battery and free-space controls

T6 — groups, channels and public rooms

0 / 6
  • Closed groups with a dedicated group cryptographic design
  • Channels and public rooms use a protocol separate from private conversations
  • Roles, permissions and signed moderation events
  • Block participants and devices
  • Remove content from current state without falsely promising erasure of every copy ever held
  • Protection against spam, forged history and hostile takeover

T7 — calls

0 / 6
  • Audio calls
  • Video calls
  • Screen sharing
  • Quality adaptation and connection recovery
  • Reviewed media transport and cryptographic foundations; Quasar owns signalling, identity and UX
  • Quasar-operated limited relay nodes

T8 — other platforms

0 / 6
  • macOS
  • Windows
  • iOS
  • Android
  • Synchronise multiple registered devices using the model designed in T0
  • Mobile constraints for background work, battery, traffic and storage

T9 — integrations after Messenger stabilisation

0 / 5
  • SDK/API without a second protocol or separate message history
  • Messenger conversations inside Quasar Trading Terminal
  • Typed Terminal attachments without making Messenger Core depend on trading
  • Quasar AI as an explicitly added participant or assistant with separate permissions
  • No automatic AI access to the plaintext of all conversations

There are no dates here on purpose: the architecture is hard, and a date on a public page becomes a commitment made before anyone knew what it would cost.