Scope: Architecture, Cryptography, and Implementation Guide for Secure Nostr Clients.

1. Executive Summary

Building a modern Nostr web client in 2026 requires a stack that balances performance, developer experience, and advanced cryptographic security. The recommended architecture utilizes Deno for the runtime, React for the UI, Vite for bundling, and the Nostr Development Kit (NDK) for protocol logic.

To address modern threats, specifically “harvest now, decrypt later” attacks, this documentation details the integration of Post-Quantum Cryptography (PQC) using @noble/post-quantum (specifically ML-KEM-768) alongside the standard nostr-tools library. It further outlines the implementation of ratcheted protocols to achieve Forward Secrecy and Plausible Deniability.

“Harvest now, decrypt later.”
Adversaries are already collecting encrypted data today, waiting for quantum computers powerful enough to break it tomorrow.

2. Technology Stack & Libraries

2.1 Core Runtime & Framework

• Runtime: Deno (v2.8+). Provides native TypeScript support and secure-by-default permissions.
• Framework: React (v19+). Component-based UI library.
• Build Tool: Vite. Fast HMR and optimized production builds.
• Language: TypeScript. Strict typing for cryptographic operations.

2.2 Nostr Protocol Libraries

• nostr-tools: The fundamental library for cryptographic primitives (secp256k1), event signing, and relay communication.
• @nostr-dev-kit/ndk (NDK): The high-level client recommended for 2026.
• @nostr-dev-kit/ndk-react: React hooks for seamless integration.
• snort: Excellent reference implementation for high-performance Nostr clients.

2.3 Cryptographic Dependencies

• @noble/curves + @noble/hashes
• @noble/post-quantum: ML-KEM-768 and future signature schemes
• @noble/hybrid: Hybrid classical + post-quantum handshakes

3. Project Initialization

3.1 Setup Commands

# Create project
deno init --npm vite my-nostr-app --template react-ts
cd my-nostr-app

# Install dependencies
deno add npm:@nostr-dev-kit/ndk npm:@nostr-dev-kit/ndk-react
deno add npm:@noble/curves npm:@noble/hashes npm:@noble/post-quantum

# Start dev server
deno run dev

3.2 Architecture Overview

1. Provider Layer — <NDKProvider> for global relay management
2. Hybrid Crypto Module — Custom layer for post-quantum key exchanges
3. UI Layer — React components powered by useNDK() hooks

4. Cryptographic Security Model

4.1 Limitation: No Post-Quantum Security

• Risk: A quantum computer could derive the private key from the public key (npub), compromising identity and decrypting all past/future messages.
• Solution: Hybrid Key Encapsulation.
  • Combine classical secp256k1 ECDH with ML-KEM-768.
  • Why ML-KEM-768? It offers NIST Security Level 3 (~192-bit security), balancing robust security against key size (1,184 bytes public key). It is the industry standard (adopted by Signal, Apple, Cloudflare).
  • Implementation: The shared secret is derived from both the classical and PQ secrets via HKDF. If either algorithm remains unbroken, the communication is secure.

4.2 Limitation: No Forward Secrecy

• Risk: If a key is compromised, all past conversations can be decrypted.
• Solution: The Double Ratchet Algorithm (or MLS/NIP-104).
  • Keys are “ratcheted” (changed) with every message.
  • Old keys are immediately deleted from memory.
  • Compromise of the current key does not reveal previous message keys.

4.3 Limitation: No Post-Compromise Security (PCS)

• Risk: If a key is compromised, all future conversations can be decrypted until the key is manually rotated.
• Solution: Diffie-Hellman Ratchet Updates.
  • The protocol periodically performs new ephemeral key exchanges within the message stream.
  • The session “self-heals,” locking out attackers after a few message exchanges.

4.4 Limitation: No Deniability

• Risk: Recipients can cryptographically prove to a third party that a specific user sent a message (due to event signatures).
• Solution: Unsigned Gift-Wrapped Events (NIP-17 & NIP-59).
  • Direct messages are not signed by the sender’s identity key.
  • They are encrypted and “gift-wrapped” (sealed) so only the recipient can open them.
  • Since the inner event lacks a signature, the recipient cannot prove the sender’s identity to a third party (plausible deniability).

5. Implementation Guide: Hybrid PQC with nostr-tools

5.1 Hybrid Handshake Logic (TypeScript)

import { getSharedSecret } from 'nostr-tools/nip44';
import { ml_kem768_x25519 } from '@noble/post-quantum/hybrid';
import { hkdf } from '@noble/hashes/hkdf';
import { sha256 } from '@noble/hashes/sha256';

export async function deriveHybridConversationKey(
  senderPrivateKey: Uint8Array,
  recipientPublicKey: Uint8Array,
  recipientPqPublicKey: Uint8Array
): Promise<Uint8Array> {
  
  const classicalSecret = getSharedSecret(senderPrivateKey, recipientPublicKey);
  const pqResult = ml_kem768_x25519.encapsulate(recipientPqPublicKey);
  
  const combinedSecret = new Uint8Array([...classicalSecret, ...pqResult.sharedSecret]);
  
  return hkdf(sha256, combinedSecret, {
    salt: new TextEncoder().encode('nip44-hybrid-v1'),
    info: new TextEncoder().encode('nostr-hybrid-chat')
  });
}

5.2 Key Distribution

Publish ML-KEM-768 public key alongside their standard npub.

• Storage: Add a field pq_kem_768 to the Kind 0 (Metadata) event or publish a dedicated Kind 30078 event.
• Size: ~1.2 KB (negligible for profile data).

5.3 Encryption Flow

1. Fetch: Retrieve recipient’s npub and pq_kem_768 key.
2. Derive: Run deriveHybridConversationKey.
3. Ratchet: (Optional but Recommended) Pass the hybrid key into a Double Ratchet instance to generate the specific message key.
4. Encrypt: Use the ChaCha20-Poly1305 primitive (from @noble/ciphers or nostr-tools internals) with the derived key.
5. Wrap: If using NIP-17, wrap the encrypted payload in a sealed event (NIP-59) without signing the inner content.

6. Comparison of Solutions

Limitation	Standard Nostr	Advanced 2026 Setup	Standard
Quantum Security	❌ Vulnerable	✅ Hybrid ML-KEM-768 + secp256k1	Modified NIP-44
Forward Secrecy	❌ Static keys	✅ Double Ratchet	NIP-104 / MLS
Post-Compromise Security	❌ Persistent	✅ DH Ratchet self-healing	NIP-104
Deniability	❌ Signed events	✅ Unsigned Gift-Wrapped (NIP-59)	NIP-17 + 59

7. Conclusion & Best Practices

• Adopt hybrid cryptography today — don’t wait for quantum computers.
• Implement ratcheting for forward secrecy.
• Leverage NDK but wrap crypto primitives.
• Default to unsigned DMs (NIP-17) for maximum privacy.

This architecture gives you a Nostr client that is not only modern and performant but genuinely future-proof against both classical and quantum threats.

Building post-quantum Nostr clients is more than code — it’s a stand for digital sovereignty in an era of mass surveillance and emerging quantum threats. Gleez is committed to privacy-first technologies, strong cryptography, and tools that put users back in control. ✨