Messages, Groups and Encryption: Where Private Conversation Meets Public Relays
A deep guide to encrypted direct messages, private DMs, public chats, groups, lists, gift wrap, versioned encryption and MLS-style messaging.
Why this part of the NIP map matters
Messaging is where Nostr's promise gets intimate. A public note can tolerate rough edges. A private message cannot. A group room, chat, encrypted payload or public community has to answer questions people feel immediately: who can read this, who can reply, where is it stored, what metadata remains, what happens when a relay disappears and can another client open the same conversation?
The old direct-message model taught the ecosystem an important lesson: encryption is not a sticker you place on a feature after the fact. Metadata, relay choice, recipient lists, wrapping, timestamp behavior, key handling and client recovery all shape whether a private conversation is actually private enough for its purpose.
The aim is not to crown one messaging standard. It is to help you read a conversation product honestly: what is public, what is encrypted, what is only obscured, what travels and what depends on one client.
The most useful privacy sentence is plain: encryption protects content, not every fact around the content. Nostr can improve control, but it cannot make a careless interface safe.
The mental model
Older direct messages remain part of history and compatibility, but modern private-message work points toward better encryption and wrapping.
Public chats and groups are social products with protocol plumbing. The standard can describe events and roles; the client still decides how visible and safe the room feels.
Lists are more than bookmarks. They can become mute lists, follow sets, relay collections, communities or application state. That makes list privacy and visibility important.
Versioned encryption is necessary because cryptography ages. A standard needs room to move without breaking every existing encrypted object.
The best messaging products explain the boundary before you write the message, not after something goes wrong.
Read this topic with one hand on the protocol and one hand on the product. The protocol tells you the shared format. The product tells you what a person actually sees, approves, loses, recovers or can take elsewhere. Both are necessary. One without the other creates either abstract standards talk or a pretty interface with no durable proof underneath.
Use the source links as proof, not as decoration. A useful NIP explanation gives you the mental model first, then sends you to the official markdown when exact fields, status notes, examples or implementation details matter.
Private conversation starts with a public transport problem
Nostr messaging has a strange tension: the network is built around relays that can see public events, while human conversation often needs privacy, context and consent. Encryption protects payloads, but it does not automatically hide metadata. A relay may still see that an event exists, when it appeared, who published it, which relays received it and sometimes which envelope shape it uses. That is why messaging standards have to explain both content secrecy and traffic shape.
Older encrypted direct-message patterns taught the ecosystem a hard lesson. If encryption is easy to ship but weak in practice, the social feature may spread faster than the warning. NIP-44 pushes modern encrypted payloads in a better direction, while gift wrapping and private direct-message designs try to reduce obvious metadata leaks. The important habit is to ask what the product hides, what it still exposes and whether the interface tells you the difference before you send.
Public chat and group standards solve a different problem. Not every conversation is private. Some rooms want public history, shared moderation, membership rules, reply structure, topics, live presence or event-specific context. A music show, conference backchannel, developer support room and local venue chat do not need the same privacy model. They need legible expectations. Who can read? Who can write? Who moderates? Which relay stores the room? Can the room migrate?
Lists and mute filters are part of messaging too because conversation is not only sending. It is also deciding what reaches you. A client that cannot mute, filter, label or separate rooms pushes all social pressure into one feed. Nostr's strength is not that every message becomes equally visible. Its strength is that conversation rules can be expressed, signed and moved across tools when standards are clear enough.
Encryption is useful only when the surrounding story is honest
A product can say encrypted and still leave you exposed through backups, screenshots, notifications, relay metadata, device compromise, signer prompts, link previews or poor key handling. That does not make encryption worthless. It makes the surrounding story important. A good Nostr messaging page should say plainly which layer is protected and which layer is still visible.
Versioned encryption matters because cryptography ages. A standard can improve the payload format, key derivation, nonce handling or associated data, but existing clients and old messages do not magically migrate with one headline. When you evaluate a messaging product, ask which encryption version it uses, whether it supports compatibility with older content and how it tells you when a conversation has mixed capabilities.
Multi-device use is another trap. People expect messages on phones, laptops and web clients. Key custody, signer design and relay sync all affect whether that is safe. If a product solves multi-device convenience by quietly uploading secrets or centralizing the message store, it may feel better while weakening the Nostr promise. The better product makes the tradeoff visible.
Group privacy is harder than one-to-one privacy. Every member adds a device, a trust boundary and a future departure problem. MLS-style approaches and group management standards point toward more serious rooms, but the product still has to explain membership changes, history access, invite control and what happens when someone leaves. Private groups that cannot explain those basics are not private in the way people assume.
Conversation products need consent language
A good messaging interface does not make you reverse-engineer the room. Before you write, it should be clear whether the message is public, encrypted, gift-wrapped, group-bound, relay-bound, recoverable, deletable or only hidden by client convention. The words private, secure and encrypted are too broad unless the product says which layer they describe.
Consent also includes audience shape. A direct message, a public chat, a private group and a moderated room are different social promises. If a product blurs them, people will send the right words to the wrong room. Nostr's flexibility is useful only when the client makes those rooms legible without asking you to memorize event kinds.
Message history is another consent question. Can a new device recover old messages? Can a new group member see previous history? Can a relay operator infer membership? Can a client export a conversation? Can a person leave without leaving readable history behind? These are product questions, but the answer often depends on the NIPs underneath.
The healthiest messaging tools are honest about limits. They do not pretend that encryption removes screenshots, compromised devices, social forwarding, metadata or bad key storage. They explain the protocol boundary, then help you behave safely inside it.
How to compare two Nostr messaging apps
Do not begin with the design. Begin with the room model. Does the app focus on one-to-one direct messages, public chats, private groups, communities, live rooms or forum-like threads? Each surface needs different rules. If two apps both say messaging but one is built around encrypted envelopes and the other around public room events, you are not comparing the same thing.
Next, compare key handling. Does the app sign directly, use a browser signer, use a mobile signer, support remote signing or hide the key inside its own account system? A messaging app that handles private conversation but weakens key custody may solve one problem by creating another.
Then compare relay dependence. Can you choose relays? Can a room move? Are group events stored on a specific relay? Does the product explain what happens if that relay blocks, forgets or disappears? Messaging feels personal, but its reliability often depends on infrastructure nobody notices until a room goes silent.
Finally, compare proof. Can another client recover the message, room, thread, mute list or membership state? Can you export meaningful context? Are deletions, reports, labels and moderation decisions visible? Interoperability is not only whether a message appears. It is whether the surrounding social context can survive outside the first app.
Messaging is where metadata teaches humility
The hardest privacy lesson is that content is only one layer. If the message body is encrypted but timing, relay choice, reply patterns, group membership or sender behavior are obvious, a determined observer may still learn too much. This is not a reason to reject encrypted messaging. It is a reason to describe it honestly.
Gift wrapping, sealed envelopes and private-message delivery patterns are attempts to make that metadata less revealing. They do not make every trace disappear. They make the obvious trace smaller and the product responsibility larger. A client has to avoid undoing the privacy gain through notifications, previews, backups or sloppy signing prompts.
Public groups have the opposite challenge. They may want visibility, but still need boundaries. Who can join, who can post, which relay stores history, whether moderation is signed, whether deleted or edited context is legible, and whether another client can render the room all decide whether a group feels like an open protocol room or a private app feature.
The best messaging article should therefore give you a vocabulary: payload, envelope, relay, membership, recovery, device, signer, metadata and moderation. Once you have those words, you can evaluate a product without being dazzled by a lock icon.
The message should tell you what kind of room you are in
The most practical test for a Nostr messaging product is whether you understand the room before you type. A one-to-one encrypted message, a public room, a private group, a relay-bound community and a forum thread should not look identical. The interface should show the audience, the storage expectation and the privacy boundary without forcing you to open a protocol explainer.
If a product cannot do that, the standard work underneath loses power. NIPs can define event kinds and encryption formats, but human trust happens in the moment before you send. That is where the page, the client and the signer all have to be honest.
This is why messaging belongs beside privacy, not far away from it. A conversation feature is also a metadata feature, a signing feature and a relay feature.
If you remember only one thing, remember this: a private-looking chat can still leak context when the surrounding transport, signer and storage choices are careless. The NIP stack helps you ask where that context goes.
The NIP pages in this topic
Private Direct Messages
NIP-17 belongs to the modern private-message stack. It is about delivery, wrapping and metadata reduction as much as encryption.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 14, kind 15, kind 7, kind 13, kind 1059, kind 10050 because these are the terms that usually surface as product behavior. Nearby standards: NIP-44, NIP-59, NIP-42, NIP-21.
Encrypted Payloads (Versioned
NIP-44 gives encrypted payloads a modern versioned format. It protects content, not every piece of metadata around it.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind, created_at, base64 is invalid, hkdf_expand(OKM, info, L), secp256k1_ec_pubkey_tweak_mul, valid.get_conversation_key because these are the terms that usually surface as product behavior. Nearby standards: NIP-01, NIP-04.
Encrypted Direct Message
A special event with kind 4, meaning "encrypted direct message". It is supposed to have the following attributes: The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 4, relay, content, "content": "<encrypted_text>?iv=<initialization_vector>", tags, ["p", "<pubkey, as a hex string>"] because these are the terms that usually surface as product behavior. Nearby standards: NIP-17.
Public Chat
This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation. The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 40, kind 41, kind 42, kind 43, kind 44, 43 - hide message because these are the terms that usually surface as product behavior. Nearby standards: NIP-29, NIP-10.
Relay-based Groups
This NIP defines a standard for groups that are only writable by a closed set of users. They can be public for reading by external users or not.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 39000, kind 39003, kind 9000, kind 39001, kind 9021, kind 9009 because these are the terms that usually surface as product behavior. Nearby standards: NIP-98, NIP-11, NIP-51.
Lists
This NIP defines lists of things that users can create. Lists can contain references to anything, and these references can be public or private.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 1, kind 30023, kind 34550, kind 40, kind 30009, kind 8 because these are the terms that usually surface as product behavior. Nearby standards: NIP-44, NIP-04, NIP-02, NIP-65, NIP-72.
Public Messages
This NIP defines kind 24 as a simple plaintext message to one or more Nostr users.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 24, .content, expiration, nevent1, kind, kind:24 because these are the terms that usually surface as product behavior. Nearby standards: NIP-65, NIP-40, NIP-18, NIP-21, NIP-25.
Chats
A reply to a kind 9 is an additional kind 9 which quotes the parent using a q tag.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 9, kind 9 because these are the terms that usually surface as product behavior.
E2EE Messaging using MLS Protocol
E2EE Messaging using the Messaging Layer Security (MLS) Protocol ---------------------------------------------------------------- The official README carries a caution here, so use it as history or compatibility context before you build something new.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. Watch kind 445, kind 10051, kind 444, kind 9, kind 7, kind: 445 because these are the terms that usually surface as product behavior. Nearby standards: NIP-04, NIP-44, NIP-17, NIP-59, NIP-70.
Deep reading: where the details become product behavior
NIP-17: Private Direct Messages
NIP-17 belongs to the modern private-message stack. It is about delivery, wrapping and metadata reduction as much as encryption.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind 14, kind 15, kind 7, kind 13, kind 1059, kind 10050, kind 5, relay. It also touches NIP-44, NIP-59, NIP-42, NIP-21, so do not read it as an island.
The source structure points you toward Chat Rooms, Encrypting, Publishing, Relays. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-44: Encrypted Payloads (Versioned
NIP-44 gives encrypted payloads a modern versioned format. It protects content, not every piece of metadata around it.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind, created_at, base64 is invalid, hkdf_expand(OKM, info, L), secp256k1_ec_pubkey_tweak_mul, valid.get_conversation_key, valid.get_message_keys, valid.calc_padded_len. It also touches NIP-01, NIP-04, so do not read it as an island.
The source structure points you toward Versions, Limitations, Version 2, Encryption. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-04: Encrypted Direct Message
A special event with kind 4, meaning "encrypted direct message". It is supposed to have the following attributes:
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind 4, relay, content, "content": "<encrypted_text>?iv=<initialization_vector>", tags, ["p", "<pubkey, as a hex string>"], ["e", "<event_id>"], AUTH. It also touches NIP-17, so do not read it as an island.
The source structure points you toward Security Warning, Client Implementation Warning. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-28: Public Chat
This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind 40, kind 41, kind 42, kind 43, kind 44, 43 - hide message, content, name. It also touches NIP-29, NIP-10, so do not read it as an island.
The source structure points you toward Kind 40: Create channel, Kind 41: Set channel metadata, Kind 42: Create channel message, Kind 43: Hide message. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-29: Relay-based Groups
This NIP defines a standard for groups that are only writable by a closed set of users. They can be public for reading by external users or not.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind 39000, kind 39003, kind 9000, kind 39001, kind 9021, kind 9009, kind 9022, kind 9001. It also touches NIP-98, NIP-11, NIP-51, so do not read it as an island.
The source structure points you toward Relay-generated events, Group identifier, The h tag, Timeline references. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-51: Lists
This NIP defines lists of things that users can create. Lists can contain references to anything, and these references can be public or private.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind 1, kind 30023, kind 34550, kind 40, kind 30009, kind 8, kind 30008, kind 30002. It also touches NIP-44, NIP-04, NIP-02, NIP-65, NIP-72, NIP-28, so do not read it as an island.
The source structure points you toward Types of lists, Standard lists, Sets, Deprecated standard lists. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-A4: Public Messages
This NIP defines kind 24 as a simple plaintext message to one or more Nostr users.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind 24, .content, expiration, nevent1, kind, kind:24, imeta. It also touches NIP-65, NIP-40, NIP-18, NIP-21, NIP-25, NIP-57, so do not read it as an island.
The source structure points you toward Advanced Support, Warnings. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-C7: Chats
A reply to a kind 9 is an additional kind 9 which quotes the parent using a q tag.
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind 9, kind 9.
The source structure points you toward the event fields, examples and edge cases. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
NIP-EE: E2EE Messaging using MLS Protocol
E2EE Messaging using the Messaging Layer Security (MLS) Protocol ----------------------------------------------------------------
Ask what is public, what is encrypted, which metadata remains, which relays see the envelope and whether another client can recover the conversation. In the official file, slow down around kind 445, kind 10051, kind 444, kind 9, kind 7, kind: 445, required_capabilities, identity. It also touches NIP-04, NIP-44, NIP-17, NIP-59, NIP-70, so do not read it as an island.
The source structure points you toward Context, Why is this important?, Goals of this NIP, Why MLS?. That is where the useful detail lives: not in the fact that the NIP exists, but in the exact behavior it asks independent software to share. When you test a product claim, open the official file, try another client or relay, and ask whether the visible feature still means the same thing outside the app that introduced it.
What to check before you trust a product claim
Start with the most concrete promise. Does the feature claim portable identity, encrypted messaging, relay discovery, zaps, wallet permissions, long-form publishing, moderation, search or application data? Name the promise before you open the source. Otherwise every NIP starts to look like background reading.
Open the official markdown next. Look for required fields, event kinds, tags, relay messages, status warnings and examples. Do not stop at the title. Many Nostr mistakes happen because a product advertises a NIP number while ignoring the boring edge case that actually protects the user.
Then test another implementation. If the event, payment, list, message, article, badge or relay behavior only works inside one product, the feature may still be useful, but it is not yet a strong portability claim. The second implementation is where the standard stops being a slogan.
Finally, check the risk class. Keys, private messages, money, storage, moderation and identity need more caution than a playful app format. A product can be young and promising, but the page should not ask you to trust it like a mature standard when the source trail is thin.
How this area usually fails
The first failure is overclaiming. A client says it supports a NIP, but it supports only the easiest happy path. That may be enough for a demo and not enough for real use.
The second failure is hidden custody. The app feels convenient because it quietly holds the key, routes the wallet, chooses relays or stores media in a way that makes leaving hard. Nostr is most interesting when those boundaries are visible.
The third failure is stale source material. A guide, blog post or old archive page may describe a version of the ecosystem that changed. The official repository and active implementations matter because Nostr standards are living documents.
The fourth failure is social flattening. Reports, badges, zaps, follows, labels and community events are not neutral numbers. They are signed social signals. You need to know who produced them, who displays them and what the product does with them.
The fifth failure is pretending the protocol solves product judgment. A NIP can define a format. It cannot force a client to explain it well, moderate fairly, store files forever or make a wallet prompt humane. Good pages keep that distinction clear.
Where to go next
The common thread is that a NIP is not a magic wand. It gives independent software a shared object, permission, message, tag, filter or social signal. The product still has to explain what it does with that shared shape.
If you are new to the topic, read the cards first and open only the NIP that matches your immediate question. If you are building, read the official markdown and test against more than one implementation. If you are evaluating a product, ask which parts travel with your key and which parts stay inside the product.
That is the difference between a useful NIP atlas and a numbered archive. The archive tells you that a document exists. The Wissenslexikon tells you why the document changes the way Nostr feels in your hands.
When a NIP touches keys, money, private messages, moderation or storage, slow down. Those are not decorative protocol topics. They decide who can sign, who can pay, who can read, who can hide, who can recover and who can leave.
The best Nostr product writing stays close to those consequences. It does not bury you in acronym soup, and it does not pretend every standard is equally mature. It tells you what you can do next, what you should verify, and where trust enters the room.
Direct sources
Use these sources to verify the text, not as decoration. The official repository is the canonical source; mirrors, guides and project pages help you see how the standard is explained or implemented elsewhere.