NIP-44: Encrypted Payloads (Versioned)
Nostr needed a better encryption primitive than old direct messages
NIP-44 is one of the standards that changes the texture of the whole network. It does not define a new chat kind. It defines a versioned encryption payload that other NIPs can use when they need encrypted content inside signed Nostr events.
That distinction is important. NIP-04 direct messages existed early, but the ecosystem gradually learned that private messaging needed a cleaner, audited and more flexible cryptographic format. NIP-44 answers that narrow problem. It gives implementers a shared envelope: derive a conversation key from the two keys, create per-message keys from a nonce, pad the plaintext, encrypt with ChaCha20, authenticate with HMAC-SHA256 and encode the result.
The result is not Signal. The official source is unusually honest about that. NIP-44 does not provide forward secrecy, post-compromise security, deniability, metadata hiding, post-quantum protection or attachment handling. It is a practical encrypted payload format for a public relay network, not a complete high-risk messenger.
Version 2, padding and a careful cryptographic boundary
The current defined algorithm is version 0x02. It uses secp256k1 ECDH to derive a shared x coordinate, HKDF with the salt nip44-v2 to derive a conversation key, then a random 32-byte nonce to derive message keys. The plaintext is padded with a custom scheme before encryption, then encrypted and authenticated.
NIP-44's padding scheme is part of the privacy story. It does not hide all length information, but it reduces the precision of message-size leaks, especially for small messages. The source defines minimum and maximum plaintext sizes, base64 length checks and test vectors so implementations can detect subtle incompatibilities.
The most important product sentence is negative: NIP-44 must not be used as a drop-in replacement for old NIP-04 payloads. Other standards have to define the event kinds, message semantics and threat model. NIP-44 supplies the encryption format.
From video-event mistake to audited encryption standard
The file history has an odd beginning. A December 2023 NIP-44 file initially appeared for video events and was quickly moved out. The NIP-44 number then became the encryption standard through Paul Miller's revision 3 work in PR #746. Jon Staab followed with clarifications around separation of concerns, encryption steps and the warning against treating it as a NIP-04 replacement.
The audit is the key milestone. Paul Miller's nip44 repository states that v2 was audited by Cure53 in December 2023, while also warning that not every implementation is covered by that audit. That nuance belongs in the page because people often hear audit and assume every port is safe. The repository says the TypeScript/JavaScript, Go and Rust repositories were the implementations in audit scope.
Later 2024 commits clarified ECDH hashing, base64 wording and small unit details. Those are not cosmetic. In encryption standards, a phrase about whether an x coordinate is hashed, how length is validated or how an unknown version is reported can decide whether two clients interoperate safely.
Good NIP-44 support is measured by test vectors, not vibes
NIP-44 is a place where product teams needs to be boring. The right question is not whether a client can encrypt and decrypt its own messages. The right question is whether it passes the published test vectors, rejects malformed payloads safely, handles unknown versions correctly and gives the user an honest privacy boundary.
The paulmillr/nip44 repository is central because it collects spec text, multi-language implementations, test vectors and the Cure53 audit reference. Rust-nostr also advertises NIP-44 support, and NIP-46 now uses NIP-44 rather than NIP-04 for remote signer communication. NIP-59 gift wraps rely on NIP-44 for the encrypted private-message construction.
A serious Nostr client needs to avoid vague copy such as secure chat. It needs to say what is protected: the event content is encrypted to another key. It needs to also say what is still public or inferable: relay choice, event timing, signatures, relationship patterns and stored ciphertext.
The main danger is overpromising privacy
NIP-44 makes encrypted Nostr payloads much better. It does not make relays blind to metadata, prevent screenshotting, erase old ciphertext or protect old messages after key compromise. A private-message product that hides those limits is giving users the wrong mental model.
There is also implementation risk. Cryptography does not forgive approximate ports. A library that passes happy-path examples but skips length checks, MAC verification, nonce quality or constant-time comparisons can turn an audited design into unsafe software.
Read NIP-44 in the wild
NIP-44 is the modern encrypted payload envelope. It gives Nostr clients a versioned way to encrypt content that does not repeat the old NIP-04 weaknesses.
Encryption is not the whole privacy story. Metadata, relays, timing, recipient sets and key handling still matter. This NIP gives you a better box; it does not make the delivery path invisible.
What changes when you actually use it
For you, NIP-44: Encrypted Payloads (Versioned) is felt inside the room: who can read, who can reply, what remains visible and what the interface makes private by implication. Messaging standards are risky because familiar chat design can smuggle in promises the protocol never made. Read NIP-01, NIP-04 as the surrounding map before trusting the room label.
What changes for builders and operators
For builders, NIP-44: Encrypted Payloads (Versioned) is expectation control. Test the same conversation across relays, devices and clients. Make audience, persistence, encryption and moderation visible. A chat-shaped interface can feel private even when the event is public, and that mismatch is a product bug.
What the official file makes concrete
The official file is organized around Versions, Limitations, Version 2, Encryption, Decryption, Details, Implementation pseudocode, Audit. Inspect kind, created_at, nonce, info=nonce, chacha_nonce, ciphertext, base64 is invalid, hkdf_expand(OKM, info, L) because these are the pieces most likely to surface as product behavior. Read it beside NIP-01, NIP-04 before treating it as isolated.
NIP-44: Encrypted Payloads (Versioned) needs honest audience language. Public, private, group, encrypted, temporary and moderated are different promises.
Where it breaks
The failure mode in NIP-44: Encrypted Payloads (Versioned) is false intimacy. The room feels like a messenger, but storage, audience, reply context or metadata tell a more public story. This is where copywriting, UI labels and protocol behavior need to match exactly.
Where this appears outside the markdown
In the ecosystem, NIP-44: Encrypted Payloads (Versioned) touches the most emotionally familiar interface: a conversation. That makes it easy for products to borrow the comfort of chat, groups or DMs while the actual protocol object has different privacy and delivery properties. The page has to slow that moment down before the interface creates a false expectation.
The nearby-standard trap
The nearby-standard trap in NIP-44: Encrypted Payloads (Versioned) is using one room word for several protocols. Chat, public chat, private DM, group, forum thread, comment and encrypted envelope are different. Read NIP-01, NIP-04 and keep the interface honest about which promise is actually present.
Language that keeps the feature honest
Good product copy for NIP-44: Encrypted Payloads (Versioned) names the room. It says public, encrypted, relay-scoped, group-controlled, archived, temporary or moderation-aware when those things are true. It avoids borrowing private-message comfort for data that travels more openly.
What this page does not promise
NIP-44: Encrypted Payloads (Versioned) does not turn every conversation into a private room. A chat-like screen can hide public relays, visible metadata, partial delivery, missing devices or moderation rules that only live on one server. The safe reading is concrete: who can read, where does the event live, what does encryption cover, and what happens when one client leaves?
Read it as a field test
Start NIP-44: Encrypted Payloads (Versioned) with the audience. A message-like interface earns trust only when public, private, encrypted, group-scoped and relay-scoped behavior are not blurred. Read NIP-01, NIP-04 before drawing product conclusions, because most messaging mistakes come from using the wrong room model for the event in front of you.
Where the standard earns trust
The source links give you places to test the interpretation in public: paulmillr/nip44, Cure53 audit PDF, Encrypted Chat master thread, NIP-46 Remote Signing. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-44 source is the anchor for exact wording, and NIP-44 commit history shows how that wording moved over time. The strongest secondary clues here are paulmillr/nip44, Cure53 audit PDF, Encrypted Chat master thread. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-44: Encrypted Payloads (Versioned): first the human promise, then kind, created_at, nonce, info=nonce, chacha_nonce, ciphertext, then the implementation record, then the real-world failure case. That order keeps NIP-44 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- Who can read the event, and does the screen say that before you type?
- What metadata remains visible even when content is encrypted or wrapped?
- Can another client recover the thread, room or message history without pretending delivery is guaranteed?
What to verify before you rely on it
- Find
kind,created_at,nonce,info=nonce,chacha_noncein the official file and check where the UI exposes the same concept. - Read NIP-01, NIP-04 as context before treating NIP-44 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-44: Encrypted Payloads (Versioned) in that order: Official NIP-44 source for the current wording; NIP-44 commit history for the change record; paulmillr/nip44, Cure53 audit PDF, Encrypted Chat master thread for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
