Next-generation private messenger

Private today. Private after the quantum computer.

Balsso is an end-to-end encrypted messenger built on hybrid post-quantum cryptography. Every message, file and call is sealed on your device with keys that neither we nor a future quantum computer can recover.

How it works Follow development
ML-KEM · FIPS 203X25519 hybridDouble RatchetZero third parties

Why now

Harvest now. Decrypt later.

Encrypted traffic is being recorded today to be broken tomorrow. Classical key exchange based on elliptic curves falls to a sufficiently large quantum computer. Anything sealed with it alone has an expiry date you don't control.

Protocol

Hybrid by design. Two locks, one key.

Every session is established with two independent key agreements. An attacker has to break both the classical and the post-quantum primitive at the same time, which is a stronger guarantee than either alone.

  • ML-KEM-768 + X25519 Keys from the lattice-based KEM standardised in FIPS 203 are combined with an elliptic-curve exchange through a key-derivation function. Neither secret is used on its own.
  • Double Ratchet A fresh key for every message. Compromising one key reveals neither past messages (forward secrecy) nor future ones (post-compromise security).
  • Signed prekeys Identity and prekeys are signed with Ed25519 today, with the signature layer ready to move to ML-DSA (FIPS 204).
  • Sealed envelopes Servers route opaque ciphertext. They do not hold message keys, cannot read content, and delete envelopes once delivered.
Alicedevice Bobdevice X25519 · classical key agreement ML-KEM-768 · post-quantum encapsulation HKDF ( ss₁ ‖ ss₂ ) Root keyDouble Ratchet · per-message keys a fresh key for every message

What Balsso is

Everything encrypted. Nothing collected.

Messages, files, calls

Text, attachments, voice and video share one end-to-end encrypted session. There is no "secret chat" mode, because every chat is one.

Your number stays yours

Contacts discover each other through hashed identifiers. Your phone number is never shown to the server-side profile or to people you message.

Minimal metadata

Servers see sealed envelopes and a delivery queue. Envelopes are deleted after delivery, logs are short-lived and never leave our own machines.

Every device, its own keys

Each phone or desktop holds its own identity and prekeys. Linking a device never copies secrets through the server.

Calls that stay sealed

Media is relayed through our own servers only when a direct path is impossible, and the relay is designed never to hold the frame keys.

Independent infrastructure

No hyperscalers, no third-party SDKs, no ads, no analytics. The servers are ours, the clients are open to inspection, and this page loads nothing from anyone else.

Status

In development, built in the right order.

Security work cannot be rushed. We finish the cryptographic core and have it reviewed before any public release.

  1. Infrastructure

    Dedicated servers, encrypted storage, monitoring and backups are running.

  2. Server API

    Authentication, devices, prekeys, discovery, sealed envelopes and calls are being built and tested.

  3. Hybrid protocol

    Implementing the ML-KEM + X25519 session layer and the Double Ratchet in the clients.

  4. iOS and Android

    First-party apps built on the protocol library.

  5. Independent audit

    External review of the protocol and the clients before launch.

  6. Public launch

    Early access first, then open registration.