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", "", "", "reply"] // if this is a reply ["subject", ""], // rest of tags... ], "content": "", } .content MUST be plain text. Fields id and created_at are required. Tags that mention, quote and assemble threading structures MUST follow NIP-10. Kind 14s MUST never be signed. If it is signed, the message might leak to relays and become fully public. Chat Rooms The set of pubkey + p tags defines a chat room. If a new p tag is added or a current one is removed, a new room is created with clean message history. Clients SHOULD render messages of the same room in a continuous thread. An optional subject tag defines ...
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-04 (the shared key is computed using the author's public and private key) and stored in the .content. 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 a single list of each kind. They have special meaning and clients may rely on them to augment a user's profile or browsing experience. For example, mute list can contain the public keys of spammers and bad actors users don't want to see in their feeds or receive a...
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": } 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 less than 30 characters to avoid client trunca...