No number.
No footprint.
Just messaging.
ONYXCHAT is an Android messenger, built by Sednium, that never asks for your phone number and never keeps a copy of your messages. The relay routes an encrypted payload and forgets it existed.
Blind relay server
The backend's only job is moving an encrypted payload from one device to another over Firebase Cloud Messaging. It doesn't parse it, store it, or keep a message log. There's no database table it could hand over even if compelled to.
No phone numbers
Identity is a Routing ID derived from your Google Account, not a SIM card. It removes SIM-swap risk and contact-scraping entirely, and it means your telecom provider is never part of the trust chain.
Hybrid encryption, not homebrew
Encryption is layered from two audited, independent building blocks: libsignal's Double Ratchet and BouncyCastle's ML-KEM-768, combined with a standard HKDF construction. No custom cipher, no unverified primitives.
When you set up ONYXCHAT, nothing about your telecom carrier or SIM is involved. Instead the app generates a Routing ID: your public address on the network.
To message someone, you only need their Routing ID or their QR code. The network maps that ID to an encrypted delivery token behind the scenes, so the relay knows where to send a payload without knowing who's sending or receiving it.
Share it like a QR code, not a phone number
Your Routing ID can be scanned, copied, or shared as a link. Nobody can bulk-discover you through a contacts sync, because there's no phone number field to scrape in the first place.
The inner layer is stock, vetted libsignal (the same Double Ratchet construction used by Signal), providing forward secrecy and post-compromise security exactly as it does there. Nothing about that library is modified.
The outer layer is what's new: a static ML-KEM-768 key pair (BouncyCastle's PQC provider) is combined with the classic ECDH secret, fed through HKDF-SHA256 with a fixed info string, to derive an AES-256-GCM key that wraps the message before it enters the ratchet. This protects the initial handshake against "harvest-now-decrypt-later" attacks: an attacker recording today's traffic can't decrypt it later once quantum computers are viable, because the key material isn't classical-only.
Nonce handling
A fresh 96-bit nonce is generated with SecureRandom for every message and prepended to the ciphertext: no counter, no reuse risk across reinstalls or multiple devices.
Combiner function
Classic ECDH secret and the ML-KEM-768 shared secret are concatenated and run through HKDF-SHA256, matching standard practice for hybrid PQ key exchange.
What's ephemeral, what's not
The ML-KEM keypair is a long-term identity key, not a one-time prekey. It provides authentication and initial confidentiality. Forward secrecy for the conversation still comes from the Double Ratchet underneath.
No custom cryptography
Every primitive (AES-GCM, HKDF-SHA256, ML-KEM-768, the Double Ratchet) comes from an established, independently maintained library. Nothing here is a home-grown cipher.
Why this is worth explaining, not just claiming
Most apps market encryption with a single adjective. We'd rather show the actual construction, documented in full at sednium.com/onyxchat, so it can be reasoned about instead of taken on faith.
Chat history is encrypted on-device with AES-256 and synced to the hidden appDataFolder of your own Google Drive account, a space only ONYXCHAT can access, and only under your Google login. We never see it, and it doesn't pass through our relay.
The vault key itself is now protected by the same post-quantum layer (ML-KEM-768) used for messaging, rather than being derived solely from your Google Account ID. That closes the earlier gap where knowing an account ID alone could theoretically reconstruct the key. The backup key is now wrapped behind device-held post-quantum key material, not just a hash of a non-secret identifier.
Sednium is the studio behind ONYXCHAT. The full technical architecture (the hybrid encryption design, the blind relay model, the identity system) is written up in detail on our research docs, independent of the closed-source client.