Hey HN,
I'm building a privacy-first messaging app in Flutter/Dart, developed with AI assistance (Gemini 2.5 Pro + Claude Opus 4.6). No phone number, no email, no account — no identity, nothing to track. Currently focused on Android.
*Six-layer defense architecture*
Layer 0 - Identity layer: Zero identifier. No account, no identity, nothing to track.
Layer 1 - Key exchange: X25519 + ML-KEM-768 hybrid. X25519 is Bernstein-designed, outside the NIST ecosystem. Even if ML-KEM has an NSA backdoor, X25519 still holds. The probability of both being broken simultaneously approaches zero.
Layer 2 - Key hardening (my original contribution): session_key = HKDF(shared_secret || Y), where Y = PQ_C(W(shared_secret)). Even if Layer 1 is fully compromised, the attacker still faces the Landauer thermodynamic lower bound + Margolus-Levitin operation limit. Physical law, not a mathematical assumption.
Layer 3 - Message encryption: ChaCha20-Poly1305, Bernstein-designed. High resistance to side-channel attacks. Retains 128-bit equivalent security strength post-quantum.
Layer 4 - Transport: SMP protocol reimplemented from scratch in Dart. No central server, P2P communication. Unidirectional queues — the server never knows who is talking to whom. No message retention on the server. Currently using SimpleX public relay.
Layer 5 - Endpoint: Android FLAG_SECURE screenshot prevention. Volume key triggers emergency wipe (messages + keys). Configurable wrong-password limit before irreversible wipe. Burn-after-reading on by default. Client-side encrypted backup, keys never leave the device.
*What is Layer 2*
Layer 2 is implemented from my Zenodo preprint. The core claim: a key derivation path passing through Product Quantization and Soft-ZCA whitening creates structure-induced quantum blindness against known quantum algorithm paradigms (HSP, Simon, Grover, etc.), making quantum attacks physically infeasible — grounded in physical law, not computational hardness assumptions.
Because Layer 2 is based on my public preprint paper, there is no closed-source issue. Anyone can implement their own encryption scheme using the paper as a foundation.
Paper: https://doi.org/10.5281/zenodo.19483649
Counterproofs welcome. If you can construct one, that result is itself a significant academic finding.
*Features*
- Contact establishment: QR code (in-person) or 10-character random code (remote) - Stickers: upload any image under 1MB, auto-converted to SVG vector format (in progress) - Local database: Hive - Languages: Traditional Chinese and English, both first-class - Code comments: bilingual beginner-level annotations throughout, written for readability
*Swappable GUI (in progress)*
Frontend/backend separation. Users can choose between WhatsApp-like, Telegram-like, WeChat-like, or Line-like interfaces. Non-commercial developers will be able to build their own GUI on top of the same backend in the future.
*Why Android first, not PWA*
PWA cannot control volume keys or implement FLAG_SECURE screenshot prevention. Both are necessary — not optional — for the device-seizure threat model.
*License*
Custom license. Commercial rights reserved to the author. Drafting terms that will prohibit MAMANGO(Meta, Amazon, Microsoft, Apple, Nvidia, Google, OpenAI) and their affiliates from commercial use or participation in development. Layer 2 licensing terms to follow separately.
*Current status*
Repo is public, README in progress. Landing page with waitlist opening soon. Will publish to app stores after v1.0.