The Nostr Protocol is a protocol that defines the format and flow of communication between clients and relays. It includes a structure for events, which are the only object type in the protocol, and a set of messages that clients can send to relays over a WebSocket connection. Events have a specific format and are signed using Schnorr signatures with the secp256k1 curve. Clients can send three types of messages to relays: EVENT, REQ, and CLOSE. The EVENT message is used to publish events, the REQ message is used to request events and create subscriptions, and the CLOSE message is used to stop subscriptions. The REQ message includes a subscription_id and a set of filters that determine which events are sent in the subscription. Relays are expected to store the filters and send all future matching events to the same WebSocket until it is closed or replaced by a new subscription.

The Nostr Protocol defines a special event with kind 3, called the "contact list", which is a list of "p" tags representing profiles that a user is following. Each tag entry includes the public key of the profile, a relay URL where events from that key can be found, and a local name or "petname" for the profile. Contact lists can be used for a variety of purposes, including backing up a list of followed profiles, discovering and displaying lists of followed profiles, sharing relay information to increase censorship resistance, and constructing local "petname" tables for easier identification of profiles. When a new contact list is published, it overwrites any previous contact lists and should be stored by relays and clients.

The Nostr Protocol allows for the inclusion of OpenTimestamps (OTS) attestations in events. An OTS attestation is a timestamp that serves as evidence that a document existed at a specific point in time. To include an OTS attestation in an event, it can be added to the event body under the ots key as base64-encoded OTS file data. The event's ID should be used as the raw hash to be included in the OpenTimestamps merkle tree. OTS attestations can be provided by either clients or relays, and can be used to show that an event is at least as old as the OTS date.

The Nostr Protocol defines a special event with kind 4, called an "encrypted direct message", which is a message that is encrypted and intended for a specific recipient. The content attribute of the event should contain the base64-encoded, AES-256-CBC encrypted message, appended by the base64-encoded initialization vector as a querystring parameter. The tags attribute should contain an entry identifying the recipient of the message using the recipient's public key. The tags attribute may also contain an entry identifying the previous message in a conversation or a message that the encrypted message is explicitly replying to, using the event ID of the previous message. The message is encrypted using a shared cipher generated by combining the recipient's public key with the sender's private key.

The purpose of NIP-05 is to allow users to map their public keys to internet identifiers (email-like addresses) and vice versa. This allows clients to find a user's public key by searching for their internet identifier and display that identifier instead of the public key. The process involves making a GET request to a specific URL with the user's name as a query string. The response should include a JSON object with the names and public keys of users and optional relay URLs where the user can be found. Clients should primarily reference public keys rather than internet identifiers. This is an optional feature and is not mandatory for all clients to implement.

NIP-06 outlines the process for generating a public key from a mnemonic seed phrase using the BIP39 and BIP32 standards. The BIP39 standard is used to generate a mnemonic seed phrase, which is then used to generate a binary seed. The BIP32 standard is then used to derive a specific path, m/44'/1237'/0'/0/0, from the binary seed. This process is the default method for generating a public key in a single-key client. However, other types of clients may use different derivation paths for different purposes.

NIP-07 is a proposal for an interface that can be used by web browsers and web-based applications to interact with Nostr-based systems. The interface includes methods for getting a user's public key, signing an event, and (optionally) getting a list of relay URLs and performing NIP-04 encrypted direct messaging. The interface is intended to be used by browser extensions such as nos2x and Alby, or by the Blockcore wallet.

NIP-08 specifies a method for clients to handle mentions of other events and pubkeys in the content of text_note events. When a client identifies a mention, it should add the pubkey or event ID to the tags array with the tag "p" and replace the textual reference in the content with the notation "#[index]", where index is the 0-based index of the related tag in the tags array. When receiving a text_note event with these mentions, the client can do a search-and-replace using the actual contents from the tags array and perform any desired context augmentation.

NIP-09 describes an event kind for event deletion, which includes a list of event IDs for events to be deleted. The content field of the event may contain a text note explaining the reason for the deletion. Relays should delete or stop publishing any events with the same pubkey as the deletion request, and clients should hide or indicate a deletion status for the referenced events. Relays should continue to publish deletion events indefinitely and clients should broadcast deletion events to other relays that don't have them. Clients may choose to fully hide events referenced by valid deletion events or show the event with an indication that the author has "disowned" the event. A client must validate that the pubkey of each event referenced in the deletion request is identical to the pubkey of the deletion request before hiding or deleting the event. Relays may validate this as well, but are not required to do so. There is no "undelete" functionality.

This NIP describes the proper use of "e" and "p" tags in text events, which helps clients display replies in a tree structure and track the pubkeys involved in a reply thread. The "e" tag may be positional or marked with "reply" or "root" to denote the event or root of a reply chain, and the "p" tag lists the pubkeys involved in a reply thread, including the pubkey of the event being replied to.

The NIP-11 defines the format for a Relay Information Document, which is a JSON document provided by relays to clients to inform them of their capabilities, administrative contacts, and various server attributes. The document includes a name, a description, a public key for administrative contact, an alternate contact, a list of supported NIPs, information about the software used by the relay, and a version identifier. This document is provided to clients over HTTP when they make a request with the Accept header set to application/nostr+json to a URI that supports WebSocket upgrades.

The NIP-12 (Network Improvement Proposal) suggests the addition of a feature to allow relays (server nodes in the Nostr network) to support subscriptions to arbitrary tags in events. This feature would allow clients to search for events based on specific tags, such as location or topic. The NIP specifies that only single-letter tags can be used in queries to avoid bloating the relay indexes and to allow for easier detection of any potential abuse of the feature. The NIP provides suggestions for possible uses of this feature, including a decentralized commenting system, location-specific posts, and hashtags. However, the NIP does not standardize the use of any specific tag for any particular purpose.

NIP-13 (Network Improvement Proposal) proposes the use of Proof of Work (PoW) in Nostr notes as a means of deterring spam. PoW is a computation-based proof that can be universally validated by relays and clients, and it is added to notes to provide evidence of computational work. To generate PoW for a Nostr note, a nonce tag is added to the note, and the number of leading zero bits in the note's ID is used to determine the difficulty of the PoW. Clients can use the difficulty of a note's PoW to determine whether to accept or reject it, with higher difficulty indicating a higher level of computational work. Reference code for calculating the difficulty of a note's PoW is provided in the NIP. The NIP also suggests using prefix searches to filter notes by their PoW difficulty when querying relays.

The NIP-14 proposes the use of a "subject" tag in text events, which can be used in threaded lists of messages in browsers instead of using the first few words of the message. It is similar to how email clients display lists of incoming emails by subject. When replying to a message, the subject tag should be replicated, and clients may add text to denote that it is a reply. The subject should generally be shorter than 80 characters in length.

The NIP-15 proposes a method for relays to notify clients when all stored events have been sent. The relay will send the client a "EOSE" message after it has sent all the events it has persisted, indicating that all events coming after this message are newly published. Clients should use the "supported_nips" field to determine if a relay supports this feature, which is intended to reduce uncertainty and potentially simplify client code by knowing when all events have been sent.

The NIP-16 proposes the creation of three categories of events: regular events, replaceable events, and ephemeral events. Regular events have a kind between 1000 and 10000, and upon being received by a relay, they are sent to all clients with a matching filter and are stored. Replaceable events have a kind between 10000 and 20000, and upon being received by a relay, if they have a newer timestamp and are signed by the same key as the currently known latest replaceable event with the same kind, the old event is discarded and replaced with the newer event. Ephemeral events have a kind between 20000 and 30000, and upon being received by a relay, they are sent to all clients with a matching filter but are not stored. Clients should use the "supported_nips" field to determine if a relay supports these event categories, and should not send ephemeral events to relays that do not support this NIP as they may be persisted. Replaceable events may be sent to relays that do not support this NIP, and clients querying should be prepared to receive multiple events and use the latest one. These event categories may be used in various applications such as states, typing indicators, and messaging.

The NIP-18 proposes the use of "reposts," which are kind 6 notes that signal to followers that another event is worth reading. The content of a repost event is empty, and it must include an "e" tag with the ID of the note being reposted, as well as a "p" tag with the pubkey of the event being reposted. The "e" tag should also include a relay URL as its third entry to indicate where it can be fetched.

The NIP-19 proposes the use of bech32-formatted strings to display keys, IDs, and other information in clients. These formats are not intended to be used in the core protocol, but rather for displaying to users, copy-pasting, sharing, rendering QR codes, and inputting data. It is recommended that IDs and keys be stored in hex or binary format for use in the core protocol. The NIP defines three bech32 prefixes for bare keys and IDs: "npub" for public keys, "nsec" for private keys, and "note" for note IDs. The NIP also defines two bech32 prefixes with TLV (type-length-value) contents for shareable identifiers with extra metadata: "nprofile" for nostr profiles and "nevent" for nostr events. Standardized TLV types are defined for these prefixes, including "special" for the key or ID of the profile or event, and "relay" for a relay where the entity is more likely to be found. These bech32 encodings are not intended to be used inside the standard NIP-01 event formats or filters, but are meant for human-friendly display and input. Clients should accept keys in both hex and npub format for now and convert them internally.

The NIP-20 proposes the introduction of "command results," which provide more information about whether an event was accepted or rejected by a relay when it is submitted. A command result is a JSON object with the structure ["OK", event_id, true/false, message], where "OK" indicates that the event was either successfully saved to the database or rejected, event_id is the ID of the event, true/false indicates whether the event was a duplicate and has already been saved, and message provides additional information about the success or failure of the command. Possible values for message include "duplicate," "blocked," "invalid," "pow," "rate-limited," and "error." Clients should handle these messages differently based on the prefix, such as showing error popups for "invalid" or "blocked," querying relay metadata for updated difficulty requirements for "pow," or trying again with a longer timeout for "rate-limited." Ephemeral events are not acknowledged with "OK" responses unless there is a failure. If the event or "EVENT" command is malformed and cannot be parsed, a NOTICE message should be used instead of a command result. This NIP only applies to non-malformed "EVENT" commands.

NIP-22 proposes a standard for relays to set limits on the timestamps of events they are willing to store. The limits would be specified as unix timestamps in seconds and would apply to all events, including regular and replaceable events. If a relay supports this NIP, it would send a command result to the client indicating whether an event was accepted or rejected due to its created_at timestamp falling outside the permitted range. Clients can use the supported_nips field to determine whether a relay uses event created_at time limits and can handle command results accordingly. The motivation for this NIP is to improve the user experience by decreasing the number of events that appear out of order or from impossible dates in the past or future.

A reaction is a type of note used to express a positive or negative sentiment towards another note. The content of a reaction event can be a "+" or "-", which indicates a "like" or "dislike" respectively, or an emoji. The reaction event should include the "e" and "p" tags from the note being reacted to, allowing users to be notified of reactions to their posts and enabling clients to retrieve all reactions for a specific post or thread. The "e" tag should include the ID of the note being reacted to, and the "p" tag should include the pubkey of the event being reacted to.

This NIP (Network Improvement Proposal) describes a way for events to be signed by keypairs other than the ones that are normally used. This can be used to allow a user to generate new keypairs for each client they use, and authorize those keypairs to generate events on behalf of their root pubkey (a keypair that is stored in a secure location). The proposal introduces a new "delegation" tag that can be included in events to indicate that the event has been signed by a delegate keypair on behalf of another keypair. The proposal also describes the process for creating and using a "delegation token", which is a signature that grants authorization for the delegate keypair to sign events on behalf of the delegator.

This NIP (Network Improvement Proposal) defines new event kinds for public chat channels, messages in those channels, and basic moderation of those channels. The proposal reserves five event kinds for immediate use and five event kinds for future use. These event kinds include: creating a chat channel, setting metadata for a chat channel, sending a message in a chat channel, hiding a message in a chat channel, and muting a user in a chat channel. The proposal outlines how each of these event kinds should be used, including the data that should be included in the event and how clients and relays should handle the events.

This NIP (Network Improvement Proposal) adds a new range of event kinds that allow for the replacement of events that have the same "d" tag and kind. This is an extension of NIP-16, which only allowed for the replacement of events with the same kind. The proposal defines a "parameterized replaceable event" as an event with a kind of 30000 or greater, but less than 40000. The proposal outlines how these events should be handled by clients and relays, including the use of the "supported_nips" field to determine support for this NIP and the use of tag filters to handle multiple events.

This NIP (Network Improvement Proposal) introduces the "content-warning" tag, which allows users to specify that the content of an event requires approval by readers before it is shown. The proposal describes how the tag should be used, including the optional inclusion of a "reason" for the content warning. This tag can be used by clients to hide the content of the event until the user has approved it.

This NIP (Network Improvement Proposal) introduces the "expiration" tag, which allows users to specify a unix timestamp at which an event should be considered expired and deleted by relays. The proposal outlines how the tag should be used, including the format of the timestamp and how it should be interpreted. The proposal also describes the behavior that clients and relays should follow when working with expired events, including the use of the "supported_nips" field to determine support for this NIP and the requirement for relays to drop expired events that are published to them. The proposal suggests potential use cases for the expiration tag, including temporary announcements and limited-time offers. The proposal notes that expired events may still be accessible to third parties through the relays, and warns against using the expiration tag as a security feature.