If you’ve ever used a Nostr client and tapped “New Message,” you might wonder: how does a private chat work on a network where every event is public? The answer is clever encryption that happens entirely on your device. This guide will walk you through the magic of Nostr Kind‑4 DMs (NIP‑04), from key exchange to decryption, with clear visuals along the way.
1. The Nostr Universe in a Nutshell#
Before we dive into messages, let’s quickly recap what Nostr is.
Nostr is a decentralised protocol built on three simple building blocks:
- Users have a cryptographic key pair (a public key and a private key).
- Events are JSON objects signed by a user’s private key and sent to relays.
- Relays are dumb servers that accept and forward events – they don’t interpret content, they just pass data around.
Because every event is signed and public by default, you might ask: how do we get private conversations? The answer is end‑to‑end encryption bolted onto that public infrastructure.
2. What Is a Kind‑4 Event?#
Every Nostr event has a kind number that tells clients what type of event it is. Kind‑4 is the special code for Encrypted Direct Messages. Here’s the raw structure of a Kind‑4 DM:
{"id": "abc123...","pubkey": "3e6be6b0...","created_at": 1712345678,"kind": 4,"tags": [["p", "7c8a6f9b..."]],"content": "AesEncryptedBase64String...","sig": "signature..."}
- kind = 4 tells clients to handle this as a DM.
- The p tag contains the recipient’s public key.
- content is not plain text – it’s a base64‑encoded, AES‑256‑CBC encrypted blob.
- The signature verifies that the sender really authored this event.
The beauty is that any relay can store these events, but without the correct keys, the content looks like gibberish. This is how private messages travel over a public network.
3. The Encryption Magic: How It Stays Private#
Now the cool part: how that content becomes unreadable to everyone except you and your chat partner.
3.1. Deriving the Shared Secret
Nostr DMs use Elliptic Curve Diffie‑Hellman (ECDH) over the secp256k1 curve (the same one used by Bitcoin). Here’s the step‑by‑step:
- Sender takes their own private key and the recipient’s public key.
- Using ECDH, they compute a shared secret – a value that is identical to what the recipient would compute using their private key and the sender’s public key.
- This shared secret is then hashed with SHA‑256 to create a symmetric encryption key (the exact key material used by AES).
- The sender picks a random 16‑byte initialisation vector (IV).
Only the two chat participants can ever compute this same shared secret. Relays, observers, even the developer of the app – nobody else can do the maths.
3.2. Encrypting the Message
The sender:
- Concatenates the IV with the encrypted text.
- Encrypts the plaintext message using AES‑256‑CBC with the shared secret as key and the random IV.
- Applies PKCS#7 padding so the message fits AES’s block size requirements.
- Encodes the whole thing (IV + ciphertext) in base64.
The result is a string like: "A1B2C3D4...eQ==" – which is what goes into the content field of the Kind‑4 event.
When the recipient receives this event, they:
- Decode the base64.
- Extract the IV (first 16 bytes) and the ciphertext (the rest).
- Recompute the same shared secret using their private key and the sender’s public key.
- Decrypt the ciphertext using AES‑256‑CBC, the shared secret, and the IV.
- Remove the PKCS#7 padding to get back the original message.
All of this happens locally on your device. Your nsec never leaves your browser/app.
4. A Real Chat Journey, Step by Step#
Let’s follow a message from Alice to Bob.
- Alice opens her Nostr chat app and types “Hey Bob, coffee?”
- The app takes her private key (which she unlocked with her password) and Bob’s public key.
- It computes the shared secret, generates a random IV, and encrypts the message.
- It creates a signed Kind‑4 event containing the encrypted blob and a p tag pointing to Bob.
- The event is published to several relays that Alice and Bob both use (or to all of Alice’s configured relays).
- Bob’s client is subscribed to those relays. When it sees a new event with kind=4 and a p tag matching Bob’s public key, it downloads the event.
- Bob’s app decrypts the content using Bob’s private key and Alice’s public key, and Bob sees “Hey Bob, coffee?”
The entire process is fast (usually a fraction of a second) and completely transparent to the user.
5. What Kind‑4 DMs Do (and Don’t) Protect#
✅ What’s protected
- Message content – only you and your partner can read it.
- Integrity – the signature ensures the message wasn’t tampered with.
❌ What’s NOT hidden
- Who you talk to – the p tag reveals the recipient’s public key.
- When you talk – timestamps are public.
- Message frequency – an observer can see how often you exchange DMs.
This is often called “metadata leakage.” It’s a trade‑off: you get fully decentralised, censorship‑resistant messaging, but at the cost of visible social graphs.
6. The Future: Better Encryption in Nostr#
Nostr developers recognised the limitations of NIP‑04 and have created newer standards:
- NIP‑17 (Sealed Direct Messages) – wraps encrypted DMs inside another event, hiding even the metadata (who is talking) from relay operators.
- NIP‑44 – uses modern AEAD encryption (like XChaCha20‑Poly1305) with forward secrecy, so a key compromise doesn’t expose past messages.
NostrChat currently uses Kind‑4 (NIP‑04) because it’s the most widely supported, but support for NIP‑17 and NIP‑44 is coming soon!
7. Wrapping Up#
Now you know exactly what happens when you press “Send” in a Nostr chat. It’s a beautiful combination of public infrastructure and private cryptography – no central server ever sees your messages, and you hold the keys to your own conversations. As Nostr evolves, chat will become even more secure, but the fundamental principle remains: you control your data, always.
Ready to try it yourself? Jump into NostrChat and send your first encrypted DM! 🚀
Here's an working prototype of a separate webapp dedicated on sending messages (also includes GIF and sending images)
If you have more questions about Nostr privacy, check out our in‑app “Privacy & Security” section – no telemetry, no tracking, just honest explanations.