NIPs — Merged

This NIP defines the basic protocol that should be implemented by everybody. New NIPs may add new optional (or mandatory) fields and messages and features to the structures and flows described here. ## Events and signatures

A special event with kind `3`, meaning "follow list" is defined as having a list of `p` tags, one for each of the followed/known profiles one is following. Each tag entry should contain the key for the profile, a relay URL where events from that key can be found (can be set to an empty string if not needed), and a local name (or "petname") for that profile (can also be set to an empty string or no

This NIP defines an event with `kind:1040` that can contain an [OpenTimestamps](https://opentimestamps.org/) proof for any other event: - The OpenTimestamps proof MUST prove the referenced `e` event id as its digest. - The `content` MUST be the full content of an `.ots` file containing at least one Bitcoin attestation. This file SHOULD contain a **single** Bitcoin attestation (as not more than one

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 vecto

On events of kind `0` (`user metadata`) one can specify the key `"nip05"` with an [internet identifier](https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1) (an email-like address) as the value. Although there is a link to a very liberal "internet identifier" specification above, the `<local-part>` part MUST only use characters `a-z0-9-_.`. Upon seeing that, the client splits the identifie

[BIP39](https://bips.xyz/39) is used to generate mnemonic seed words and derive a binary seed from them. [BIP32](https://bips.xyz/32) is used to derive the path `m/44'/1237'/<account>'/0/0` (according to the Nostr entry on [SLIP44](https://github.com/satoshilabs/slips/blob/master/slip-0044.md)).

The `window.nostr` object may be made available by web browsers or extensions and websites or web-apps may make use of it after checking its availability. That object must define the following methods:

This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of `text_note`s. Clients that want to allow tagged mentions they MUST show an autocomplete component or something analogous to that whenever the user starts typing a special key (for example, "@") or presses some button to include a mention etc -- or these clients can come up

A special event with kind `5`, meaning "deletion request" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a `k` tag for the kind of each event being requested for deletion. The event's `content` field MAY contain a text note describing the reason for the deletion request.

This NIP defines `kind:1` as a simple plaintext note. The `.content` property contains some human-readable text.

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

Moved to [NIP-01](01.md).

This NIP defines a way to generate and interpret Proof of Work for nostr notes. Proof of Work (PoW) is a way to add a proof of computational work to a note. This is a bearer proof that all relays and clients can universally validate with a small amount of code. This proof can be used as a means of spam deterrence. To generate PoW for a `NIP-01` note, a `nonce` tag is used:

This NIP defines the use of the "subject" tag in text (kind: 1) events. (implemented in more-speech) Browsers often display threaded lists of messages. The contents of the subject tag can be used in such lists, instead of the more ad hoc approach of using the first few words of the message. This is very similar to the way email browsers display lists of incoming emails by subject rather than by

Based on [Diagon-Alley](https://github.com/lnbits/Diagon-Alley). Implemented in [NostrMarket](https://github.com/lnbits/nostrmarket) and [Plebeian Market](https://github.com/PlebeianTech/plebeian-market).

Moved to [NIP-01](01.md).

This NIP defines an encrypted chat scheme which uses [NIP-44](44.md) encryption and [NIP-59](59.md) seals and gift wraps. Any event sent to an encrypted chat MUST NOT be signed, and MUST be encrypted as described in [NIP-59](./59.md) and illustrated below. Omitting signatures makes messages deniable in case they are accidentally or maliciously leaked, while still allowing the recipient to authenti

A repost is a `kind 6` event that is used to signal to followers that a `kind 1` text note is worth reading. The `content` of a repost event is _the stringified JSON of the reposted note_. It MAY also be empty, but that is not recommended. Reposts of [NIP-70](70.md)-protected events SHOULD always have an empty `content`.

This NIP standardizes bech32-formatted strings that can be used to display keys, ids and other information in clients. These formats are not meant to be used anywhere in the core protocol, they are only meant for displaying to users, copy-pasting, sharing, rendering QR codes and inputting data. It is recommended that ids and keys are stored in either hex or binary format, since these formats are c

Moved to [NIP-01](01.md).

This NIP standardizes the usage of a common URI scheme for maximum interoperability and openness in the network. The scheme is `nostr:`.

A comment is a threading note always scoped to a root event or an [`I`-tag](73.md). It uses `kind:1111` with plaintext `.content` (no HTML, Markdown, or other formatting).

This NIP defines `kind:30023` (an _addressable event_) for long-form text content, generally referred to as "articles" or "blog posts". `kind:30024` has the same structure as `kind:30023` and is used to save long form drafts. "Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP.

This NIP keeps track of extra optional fields that can added to events which are not defined anywhere else but have become _de facto_ standards and other minor implementation possibilities that do not deserve their own NIP and do not have a place in other NIPs. These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events:

A reaction is a `kind 7` event that is used to indicate user reactions to other events. A reaction's `content` field MUST include user-generated-content indicating the value of the reaction (conventionally `+`, `-`, or an emoji). A reaction with `content` set to `+` or an empty string MUST be interpreted as a "like" or "upvote". A reaction with `content` set to `-` MUST be interpreted as a "dislik

This NIP defines how events can be delegated so that they can be signed by other keypairs. Another application of this proposal is to abstract away the use of the 'root' keypairs when interacting with clients. For example, a user could generate new keypairs for each client they wish to use and authorize those keypairs to generate events on behalf of their root pubkey, where the root keypair is sto

This document standardizes the treatment given by clients of inline references of other events and profiles inside the `.content` of any event that has readable text in its `.content` (such as kinds 1 and 30023). When creating an event, clients should include mentions to other profiles and to other events in the middle of the `.content` using [NIP-21](21.md) codes, such as `nostr:nprofile1qqsw3dy8

This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation. It reserves five event kinds (40-44) for immediate use:

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. Groups are identified by a random string of any length that serves as an _id_.

Custom emoji may be added to **kind 0**, **kind 1**, **kind 7** ([NIP-25](25.md)) and **kind 30315** ([NIP-38](38.md)) events by including one or more `"emoji"` tags, in the form: - `<shortcode>` is a name given for the emoji, which MUST be comprised of only alphanumeric characters and underscores. - `<image-url>` is a URL to the corresponding image file of the emoji. - `<emoji-set-address>` is an

When creating a new custom event kind that is part of a custom protocol and isn't meant to be read as text (like `kind:1`), clients should use an `alt` tag to write a short human-readable plaintext summary of what that event is about. The intent is that social clients, used to display only `kind:1` notes, can still show something in case a custom event pops up in their timelines. The content of th

This NIP defines two new indexable tags to label events and a new event kind (`kind:1985`) to attach those labels to existing events. This supports several use cases, including distributed moderation, collection management, license assignment, and content classification. - `L` denotes a label namespace - `l` denotes a label

Renamed to "Addressable events" and moved to [NIP-01](01.md).

This NIP defines all the ways code collaboration using and adjacent to [`git`](https://git-scm.com/) can be done using Nostr. ## Repository announcements

This NIP defined a new `kind 2003` which is a Torrent. ## Tags - `x`: V1 BitTorrent Info Hash, as seen in the [magnet link](https://www.bittorrent.org/beps/bep_0053.html) `magnet:?xt=urn:btih:HASH` - `file`: A file entry inside the torrent, including the full path ie. `info/example.txt` - `tracker`: (Optional) A tracker to use for this torrent

The `content-warning` tag enables users to specify if the event's content needs to be approved by readers to be shown. Clients can hide the content until the user acts on it.

This NIP defines kind `31234` as an encrypted storage for unsigned draft events of any other kind. The draft is JSON-stringified, [NIP44-encrypted](44.md) to the signer's public key and placed inside the `.content`.

This NIP enables a way for users to share live statuses such as what music they are listening to, as well as what they are currently doing: work, play, out of office, etc. A special event with `kind:30315` "User Status" is defined as an *optionally expiring* _addressable event_, where the `d` tag represents the status type:

Users can declare their control over one or more online identities such as usernames, profile pages, keypairs in kind `10011` using `i` tags. An `i` tag MUST have two parameters, which are defined as the following: 1. `platform:identity`: This is the platform name (for example `github`) and the identity on that platform (for example `semisol`) joined together with `:`. 2. `proof`: String or object

The `expiration` tag enables users to specify a unix timestamp at which the message SHOULD be considered expired (by relays and clients) and SHOULD be deleted by relays. Note: The timestamp should be in the same format as the created_at timestamp and should be interpreted as the time at which the message should be deleted by relays.

This NIP defines a way for clients to authenticate to relays by signing an ephemeral event. A relay may want to require clients to authenticate to access restricted resources. For example,

This NIP defines a way for relays to advertise membership lists, and for clients to request admission to relays on behalf of users. Relays MAY publish a `kind 13534` event which indicates pubkeys that have access to a given relay. This event MUST be signed by the pubkey specified in the `self` field of the relay's [NIP 11](./11.md) document.

The NIP introduces a new data format for keypair-based encryption. This NIP is versioned to allow multiple algorithm choices to exist simultaneously. This format may be used for many things, but MUST be used in the context of a signed event as described in NIP-01. *Note*: this format DOES NOT define any `kind`s related to a new direct messaging standard, only the encryption required to define one.

Relays may support the verb `COUNT`, which provides a mechanism for obtaining event counts. Some queries a client may want to execute against connected relays are prohibitively expensive, for example, in order to retrieve follower counts for a given pubkey, a client must query all kind-3 events referring to a given pubkey only to count them. The result may be cached, either by a client or by a sep

Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface. This NIP describes a method for 2-way communication between a remote signer and a Nostr client. The remote signer could be, for example, a hardware device dedicated to signing Nostr events, while the client is a normal Nostr client.

This NIP describes a way for clients to access a remote lightning wallet through a standardized protocol. Custodians may implement this, or the user may run a bridge that bridges their wallet/node and the Nostr Wallet Connect protocol. * **client**: Nostr app on any platform that wants to interact with a lightning wallet. * **user**: The person using the **client**, and wants to connect their wall

Nostr events bridged from other protocols such as ActivityPub can link back to the source object by including a `"proxy"` tag, in the form: - `<id>` is the ID of the source object. The ID format varies depending on the protocol. The ID must be universally unique, regardless of the protocol. - `<protocol>` is the name of the protocol, e.g. `"activitypub"`.

This NIP defines a method by which clients can encrypt (and decrypt) a user's private key with a password. Symmetric Encryption Key derivation

Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids. Specifics of the search algorithms will differ between event kinds, this NIP only describes a general extensible framework for performing such queries. ## `search` filter field

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](44.md) (the sh

This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are _addressable_ and deletable per [NIP-09](09.md). Unlike the term `calendar event` specific to this NIP, the term `event` is used broadly in all the NIPs to describe any Nostr event. The distinction is being made here to discern between the two terms.

This NIP introduces event kinds to advertise live spaces and the participation of pubkeys in them. A special event with `kind:30311` "Live Streaming Event" is defined as an _addressable event_ whose tags advertise the content and participants of a live stream.

This NIP defines `kind:30818` (an _addressable event_) for descriptions (or encyclopedia entries) of particular subjects, and it's expected that multiple people will write articles about the exact same subjects, with either small variations or completely independent content. Articles are identified by lowercase, normalized `d` tags.

This NIP describes a method for 2-way communication between an Android signer and any Nostr client on Android. The Android signer is an Android Application and the client can be a web client or an Android application. ## Usage for Android applications

A report is a `kind 1984` event that signals to users and relays that some referenced content is objectionable. The definition of objectionable is obviously subjective and all agents on the network (users, apps, relays, etc.) may consume and take action on them as they see fit. The `content` MAY contain additional information submitted by the entity reporting the content.

This NIP defines two new event types for recording lightning payments between users. `9734` is a `zap request`, representing a payer's request to a recipient's lightning wallet for an invoice. `9735` is a `zap receipt`, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a `zap request` has been paid. Having lightning receipts on nostr allows cl

Three special events are used to define, award and display badges in user profiles: 1. A "Badge Definition" event is defined as an addressable event with kind `30009` having a `d` tag with a value that uniquely identifies the badge (e.g. `bravery`) published by the badge issuer. Badge definitions can be updated.

This NIP defines a protocol for encapsulating any nostr event. This makes it possible to obscure most metadata for a given event, perform collaborative signing, and more. This NIP *does not* define any messaging protocol. Applications of this NIP should be defined separately.

This NIP defines the operations of a cashu-based wallet. A cashu wallet is a wallet which information is stored in relays to make it accessible across applications.

A Nutzap is a P2PK Cashu token in which the payment itself is the receipt. ## High-level flow Alice wants to nutzap 1 sat to Bob because of an event `event-id-1` she liked.

This NIP offers a Nostr-native way to request a complete reset of a key's fingerprint on the web. This procedure is legally binding in some jurisdictions, and thus, supporters of this NIP should truly delete events from their database. ## Request to Vanish from Relay

This NIP defines `kind:64` notes representing chess games in [PGN][pgn_specification] format, which can be read by humans and is also supported by most chess software. The `.content` of these notes is a string representing a [PGN-database][pgn_formal_syntax].

Defines a replaceable event using `kind:10002` to advertise relays where the user generally **writes** to and relays where the user generally **reads** mentions. The event MUST include a list of `r` tags with relay URLs as value and an optional `read` or `write` marker. If the marker is omitted, the relay is both **read** and **write**.

This NIP defines events for relay discovery and the announcement of relay monitors. ## Relay Discovery Events

This NIP defines event kind `20` for picture-first clients. Images must be self-contained. They are hosted externally and referenced using `imeta` tags. The idea is for this type of event to cater to Nostr clients resembling platforms like Instagram, Flickr, Snapchat, or 9GAG, where the picture itself takes center stage in the user experience.

Peer-to-peer (P2P) platforms have seen an upturn in recent years, while having more and more options is positive, in the specific case of p2p, having several options contributes to the liquidity split, meaning sometimes there's not enough assets available for trading. If we combine all these individual solutions into one big pool of orders, it will make them much more competitive compared to centr

When the `"-"` tag is present, that means the event is "protected". A protected event is an event that can only be published to relays by its author. This is achieved by relays ensuring that the author is [authenticated](42.md) before publishing their own events or by just rejecting events with `["-"]` outright.

This specification defines _video_ events representing a dedicated post of externally hosted content. Unlike a `kind:1` event with a video attached, video events are meant to contain all additional metadata concerning the subject media and to be surfaced in video-specific clients rather than general micro-blogging clients. The thought is for events of this kind to be referenced in a Netflix, YouTu

The goal of this NIP is to enable public communities. It defines the replaceable event `kind:34550` to define the community and the current list of moderators/administrators. Users that want to post into the community, simply tag any Nostr event with the community's `a` tag. Moderators may issue an approval event `kind:4550`. ## Community Definition

There are certain established global content identifiers such as [Book ISBNs](https://en.wikipedia.org/wiki/ISBN), [Podcast GUIDs](https://podcastnamespace.org/tag/guid), and [Movie ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number) that are useful to reference in nostr events so that clients can query all the events associated with these ids. | Type

This NIP defines an event for creating fundraising goals. Users can contribute funds towards the goal by zapping the goal event. A `kind:9041` event is used.

This document describes a protocol extension for syncing events. It works for both client-relay and relay-relay scenarios. If both sides of the sync have events in common, then this protocol will use less bandwidth than transferring the full set of events (or even just their IDs). It is a Nostr-friendly wrapper around the [Negentropy](https://github.com/hoytech/negentropy) protocol, which uses a t

The goal of this NIP is to enable [remoteStorage](https://remotestorage.io/)-like capabilities for custom applications that do not care about interoperability. Even though interoperability is great, some apps do not want or do not need interoperability, and it wouldn't make sense for them. Yet Nostr can still serve as a generalized data storage for these apps in a "bring your own database" way, fo

This NIP defines `kind:9802`, a "highlight" event, to signal content a user finds valuable. ## Format The `.content` of these events is the highlighted portion of the text.

Certain Webs of Trust calculations require access to a large volume of events and/or computing power, making it virtually impossible to perform them directly on clients. This NIP allows users to offload such calculations to declared trusted service providers, and for these providers to publish signed "Trusted Assertion" events for the user client's consumption. Trusted Assertions are always addres

Relays may provide an API for performing management tasks. This is made available as a JSON-RPC-like request-response protocol over HTTP, on the same URI as the relay's websocket. When a relay receives an HTTP(s) request with a `Content-Type` header of `application/nostr+json+rpc` to a URI supporting WebSocket upgrades, it should parse the request as a JSON document with the following fields:

This NIP describes `kind:38173`, `kind:38172` and `kind:38000`: a way to discover ecash mints, their capabilities, and people who recommend them. Nostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics. This NIP provides a simple way for users to discover ecash mints recommended by other users and to interact with them.

This NIP defines the event scheme that describe Polls on nostr. The poll event is defined as a `kind:1068` event.

This NIP describes `kind:31989` and `kind:31990`: a way to discover applications that can handle unknown event-kinds. Nostr's discoverability and transparent event interaction is one of its most interesting/novel mechanics. This NIP provides a simple way for clients to discover applications that handle events of a specific kind to ensure smooth cross-client and cross-kind interactions.

This NIP defines the interaction between customers and Service Providers for performing on-demand computation. ## Kinds This NIP reserves the range `5000-7000` for data vending machine use.

Media attachments (images, videos, and other files) may be added to events by including a URL in the event content, along with a matching `imeta` tag. The `imeta` tag is variadic, and each entry is a space-delimited key/value pair. Each `imeta` tag MUST have a `url`, and at least one other field. `imeta` MAY include any field specified by [NIP 94](./94.md). There SHOULD be only one `imeta` tag per

The purpose of this NIP is to allow an organization and classification of shared files. So that relays can filter and organize in any way that is of interest. With that, multiple types of filesharing clients can be created. NIP-94 support is not expected to be implemented by "social" clients that deal with `kind:1` notes or by longform clients that deal with `kind:30023` articles. This NIP specifi

This NIP defines a REST API for HTTP file storage servers intended to be used in conjunction with the nostr network. The API will enable nostr users to upload files and later reference them by url on nostr notes. The spec DOES NOT use regular nostr events through websockets for storing, requesting nor retrieving data because, for simplicity, the server will not have to learn anything about nostr r

This NIP defines an ephemeral event used to authorize requests to HTTP servers using nostr events. This is useful for HTTP services which are built for Nostr and deal with Nostr user accounts.

This NIP defines `kind:30402`: an addressable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful. The specification supports a broad range of use cases physical goods, services, work opportunities, rentals, free giveaways, personals, etc. To promote interoperability between cli