What NOONE protects against, what it doesn't, and why. Honest assessment.
Relay operators have no useful data. All message content is E2E encrypted. Sender identity is hidden behind ephemeral keys (NIP-59). Recipient identity is encrypted inside the envelope. A compelled relay operator can hand over only: encrypted blobs, approximate timestamps, and IP addresses (mitigated by Tor).
The SPA mirrors to GitHub Pages, Cloudflare Pages, and IPFS. Service Worker caches the complete app offline after first load. Relay lists are gossiped in-band. If one domain is blocked, users switch to another or load from IPFS. The app works fully offline for local operations.
The out-of-band emoji confirmation (6 emoji from a 45-emoji alphabet = 8.3 billion combinations) detects any key substitution during the pairing handshake. A MITM who intercepts the pairing link and substitutes their key will produce a different visual confirmation code that both parties can verify verbally.
Every message uses a fresh ephemeral keypair as the outer pubkey. The real sender and recipient are sealed inside the encrypted envelope. No persistent key appears in any outer event field. Relay operators cannot build a social graph from message metadata.
E2E encryption is independent of relay trust. A compromised relay sees only encrypted blobs. It can delay or drop messages but cannot read, modify, or forge them (signatures prevent forgery).
The Double Ratchet state advances monotonically. Each message key is used exactly once. Old ciphertexts cannot be replayed because the ratchet state has moved forward.
WASM clients use hybrid X25519 + ML-KEM-768 encryption. An attacker who records ciphertext today and later obtains a quantum computer cannot decrypt messages sent between WASM clients. Lite-to-lite messages use classical X25519 only and are not quantum-resistant.
An adversary observing network traffic (ISP, state actor) can infer when communication occurs, even without reading content. Message timestamps are randomized +/-5 minutes, but active chatting produces observable WebSocket traffic patterns. Mitigation: Use Tor or VPN. Dummy traffic mode is planned but not implemented.
The WebAuthn PRF extension is required for full security. Devices without platform authenticators (older Android, some Linux) cannot enroll with hardware-bound keys. Lite mode uses PBKDF2 with user-entered passphrase only, which is weaker. Mitigation: Use devices with Face ID, Touch ID, or Windows Hello.
If direct P2P connection fails and TURN relay is used, the TURN operator sees encrypted UDP packets and the IP addresses of both parties. Mitigation: Self-host your own TURN server. Run it over Tor for maximum anonymity.
The browser itself may leak identity through fingerprinting (canvas, WebGL, fonts, etc.). Two users on the same relay with the same browser fingerprint can be correlated. Mitigation: Use Tor Browser for maximum anonymity.
Group calls use full mesh (each pair has a direct connection). This scales to ~6 participants before bandwidth becomes problematic. Beyond that, an SFU (Selective Forwarding Unit) is needed. An SFU can preserve E2E encryption via SFrame but requires a trusted relay operator.
Device certificate revocation is not implemented. A compromised device's cert remains valid until its expiry timestamp. Planned: In-band revocation events published to Nostr relays.
Group messages use per-message random session keys wrapped individually for each member. This means: (1) adding a new member doesn't give them access to past messages, and (2) removing a member requires all remaining members to be online. There is no group ratchet -- forward secrecy in groups is per-message, not per-DH-ratchet-step.
The Lite client (pure JavaScript, no WASM) does not support ML-KEM-768. Messages between two Lite clients use X25519 only. An attacker with a quantum computer could decrypt these messages. WASM-to-Lite messages also fall back to classical when the Lite client has no KEM key.
If an attacker has root access to your device, they can read IndexedDB, capture screenshots, or keylog your PIN. No E2E encryption can protect against a fully compromised endpoint. This is true of all messaging systems.
If the deployed JavaScript/WASM is replaced by a malicious version (supply chain attack on GitHub Pages or Cloudflare), the attacker could exfiltrate keys. Mitigation: Reproducible WASM builds (verified in CI), Subresource Integrity, multiple deployment mirrors.
If a user skips the emoji verification during pairing, they may pair with an attacker instead of their intended contact. The emoji confirmation step is critical and cannot be automated -- it requires human verification over an out-of-band channel.
| Property | NOONE | Signal | Telegram | |
|---|---|---|---|---|
| E2E encrypted | Always | Always | Always | Opt-in |
| Sealed sender | NIP-59 | Yes | No | No |
| Server sees metadata | No | Minimal | Yes | Yes |
| Decentralized | Nostr | No | No | No |
| Phone number required | No | Yes | Yes | Yes |
| Open source | 100% | Client | No | Client |
| Post-quantum | Hybrid | PQXDH | No | No |
| Censorship resistance | Mirrors | Medium | Medium | Easy to block |
| Works offline | PWA | Partial | Partial | No |
This threat model is a living document. If you find an issue not listed here, please report it.