NIP-17 - Private Direct Messages
Private Direct Messages draft optional relay This NIP defines an encrypted chat scheme which uses NIP-44 encryption and NIP-59 seals and gift wraps. Any event sent to an encrypted chat MUST NOT be signed, and MUST be encrypted as described in NIP-59 and illustrated below. Omitting signatures makes messages deniable in case they are accidentally or maliciously leaked, while still allowing the recipient to authenticate them. By convention, kind 14 direct messages, kind 15 file messages, and kind 7 reactions may be sent to an encrypted chat. Kind Definitions Chat Message Kind 14 is a chat message. p tags identify one or more receivers of the message. { "id": "", "pubkey": "", "created_at": "", "kind": 14, "tags": [ ["p", "", ""], ["p", "", ""], ["e", "", ""] // if this is a reply ["subject", ""], // rest of tags... ], "content": "", } .content MUST be plain text. Fields id and created_at are required. An e tag denotes the direct parent message this post is...
NIP-04 - Encrypted Direct Message
Warning unrecommended: deprecated in favor of NIP-17 Encrypted Direct Message final unrecommended optional relay A special event with kind 4, meaning "encrypted direct message". It is supposed to have the following attributes: content MUST be equal to the base64-encoded, aes-256-cbc encrypted string of anything a user wants to write, encrypted using a shared cipher generated by combining the recipient's public-key with the sender's private-key; this appended by the base64-encoded initialization vector as if it was a querystring parameter named "iv". The format is the following: "content": "?iv=". tags MUST contain an entry identifying the receiver of the message (such that relays may naturally forward this event to them), in the form ["p", ""]. tags MAY contain an entry identifying the previous message in a conversation or a message we are explicitly replying to (such that contextual, more organized conversations may happen), in the form ["e", ""]. Note: By default in the libsecp256k1...
NIP-A4 - Public Messages
Public Messages draft optional This NIP defines kind 24 as a simple plaintext message to one or more Nostr users. The .content contains the message. p tags identify one or more receivers. { "pubkey": "", "kind": 24, "tags": [ ["p", "", ""], ], "content": "", } Messages MUST be sent to the NIP-65 inbox relays of each receiver and the outbox relay of the sender. Kind 24 is designed to be shown and replied to from notification screens. The goal is to allow clients to support this feature without having to worry about chat history. There are no message chains. The concept of a "thread", a "thread root", or a "chatroom" does not exist in this system, as messages can start and continue without any syntactic connection to each other. e tags must not be used. This kind is not designed to be displayed on feeds, but anyone can see and reply to messages that may not be for them. Advanced Support NIP-40 expiration tags are recommended. Since there is no concept of a chatroom, it is un...
NIP-51 - Lists
Lists draft optional This NIP defines lists of things that users can create. Lists can contain references to anything, and these references can be public or private. Public items in a list are specified in the event tags array, while private items are specified in a JSON array that mimics the structure of the event tags array, but stringified and encrypted using the same scheme from NIP-44 (the shared key is computed using the author's public and private key) and stored in the .content. An earlier version of this specification used NIP-04 for encryptions. Those are now deprecated. For backward compatibility, Clients can automatically discover if the encryption is NIP-04 or NIP-44 by searching for "iv" in the ciphertext and decrypting accordingly. When new items are added to an existing list, clients SHOULD append them to the end of the list, so they are stored in chronological order. Types of lists Standard lists Standard lists use normal replaceable events, meaning users may only have...
NIP-11 - Relay Information Document
Relay Information Document draft optional relay Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay's websocket. When a relay receives an HTTP(s) request with an Accept header of application/nostr+json to a URI supporting WebSocket upgrades, they SHOULD return a document with the following structure. { "name": , "description": , "banner": , "icon": , "pubkey": , "self": , "contact": , "supported_nips": , "software": , "version": , "privacy_policy": , "terms_of_service": , } Any field may be omitted, and clients MUST ignore any additional fields they do not understand. Relays MUST accept CORS requests by sending Access-Control-Allow-Origin, Access-Control-Allow-Headers, and Access-Control-Allow-Methods headers. Field Descriptions Name A relay may select a name for use in client software. This is a str...
NIP-EE - E2EE Messaging using the Messaging Layer Security (MLS) Protocol
Warning unrecommended: superseded by the Marmot Protocol E2EE Messaging using the Messaging Layer Security (MLS) Protocol final unrecommended optional This NIP standardizes how to use the MLS Protocol with Nostr for efficient and E2EE (end-to-end encrypted) direct and group messaging. Context Originally, one-to-one direct messages (DMs) in Nostr happened via the scheme defined in NIP-04. This NIP is not recommended because, while it encrypts the content of the message (provides decent confidentiality), it leaks significant amounts of metadata about the parties involved in the conversation (completely lacks privacy). With the addition of NIP-44, we have an updated encryption scheme that improves confidentiality guarantees but stops short of defining a new scheme for doing direct messages using this encryption scheme. Hence, makes little to no difference to privacy. Most recently, NIP-17 combines NIP-44 encryption with NIP-59 gift-wrapping to hide the encrypted direct message inside ano...