NIP-17 - Private Direct Messages
Private Direct Messages draft optional This NIP defines an encrypted direct messaging scheme using NIP-44 encryption and NIP-59 seals and gift wraps. Direct Message Kind 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 replying to. q tags MAY be used when citing events in the .content with NIP-21. ["q", " or ", "", ""] Kind 14s MUST never be signed. If it is signed, the message might leak to relays and become fully public. File Message Kind { "id": "", "pubkey": "", "created_at": "", "kind": 15, "tags": [ ["p", "", ""], ["p", "", ""], ["e", "", "", "reply"], // if this is a reply ["subject",...
NIP-04 - Encrypted Direct Message
Warning unrecommended: deprecated in favor of NIP-17 Encrypted Direct Message final unrecommended optional 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 ECDH ...
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 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": , "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 string, and SHOULD be ...
NIP-EE - E2EE Messaging using the Messaging Layer Security (MLS) Protocol
E2EE Messaging using the Messaging Layer Security (MLS) Protocol draft 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 another set of events to ensure that it's impossible to see who is talking ...