protocol

Nostr NIPS 56

NIP-56 Reporting draft optional A report is a kind 1984 note that is used to report other notes for spam, illegal and explicit content. The content MAY contain additional information submitted by the entity reporting the content. Tags The report event MUST include a p tag referencing the pubkey of the user you are reporting. If reporting a note, an e tag MUST also be included referencing the note id.

Nostr NIPS 23

NIP-23 Long-form Content draft optional This NIP defines kind:30023 (a parameterized replaceable 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. Format The .content of these events should be a string text in Markdown syntax. To maximize compatibility and readability between different clients and devices, any client that is creating long form notes:

Nostr NIPS 65

NIP-65 Relay List Metadata draft optional Defines a replaceable event using kind:10002 to advertise preferred relays for discovering a user’s content and receiving fresh content from others. The event MUST include a list of r tags with relay URIs and a read or write marker. Relays marked as read / write are called READ / WRITE relays, respectively. If the marker is omitted, the relay is used for both purposes.

Nostr NIPS 21

NIP-21 nostr: URI scheme draft optional This NIP standardizes the usage of a common URI scheme for maximum interoperability and openness in the network. The scheme is nostr:. The identifiers that come after are expected to be the same as those defined in NIP-19 (except nsec). Examples nostr:npub1sn0wdenkukak0d9dfczzeacvhkrgz92ak56egt7vdgzn8pv2wfqqhrjdv9 nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gpp4mhxue69uhhytnc9e3k7mgpz4mhxue69uhkg6nzv9ejuumpv34kytnrdaksjlyr9p nostr:note1fntxtkcy9pjwucqwa9mddn7v03wwwsu9j330jj350nvhpky2tuaspk6nqc nostr:nevent1qqstna2yrezu5wghjvswqqculvvwxsrcvu7uc0f78gan4xqhvz49d9spr3mhxue69uhkummnw3ez6un9d3shjtn4de6x2argwghx6egpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5nxnepm Source: nostr-protocol/nips/21.md version: 37f6cbb 2023-11-15T21:42:51-03:00

Nostr NIPS 50

NIP-50 Search Capability draft optional Abstract 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 A new search field is introduced for REQ messages from clients: { ... "search": <string> } search field is a string describing a query in a human-readable form, i.

Nostr NIPS 33

NIP-33 Parameterized Replaceable Events final mandatory Moved to NIP-01 . Source: nostr-protocol/nips/33.md version: 37f6cbb 2023-11-15T21:42:51-03:00

Nostr NIPS 45

NIP-45 Event Counts draft optional Relays may support the verb COUNT, which provides a mechanism for obtaining event counts. Motivation 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 separate indexing server as an alternative, but both options erode the decentralization of the network by creating a second-layer protocol on top of Nostr.

Nostr NIPS 18

NIP-18 Reposts draft optional 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. The repost event MUST include an e tag with the id of the note that is being reposted. That tag MUST include a relay URL as its third entry to indicate where it can be fetched.

Nostr NIPS 42

NIP-42 Authentication of clients to relays draft optional This NIP defines a way for clients to authenticate to relays by signing an ephemeral event. Motivation A relay may want to require clients to authenticate to access restricted resources. For example, A relay may request payment or other forms of whitelisting to publish events – this can naïvely be achieved by limiting publication to events signed by the whitelisted key, but with this NIP they may choose to accept any events as long as they are published from an authenticated user; A relay may limit access to kind: 4 DMs to only the parties involved in the chat exchange, and for that it may require authentication before clients can query for that kind.

Nostr NIPS 19

NIP-19 bech32-encoded entities draft optional 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 closer to what must actually be used the core protocol.

Nostr NIPS 40

NIP-40 Expiration Timestamp draft optional 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. Spec tag: expiration values: - [UNIX timestamp in seconds]: required Example { "pubkey": "<pub-key>", "created_at": 1000000000, "kind": 1, "tags": [ ["expiration", "1600000000"] ], "content": "This message will expire at the specified timestamp and be deleted by relays.\n", "id": "<event-id>" } 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.

Nostr NIPS 36

NIP-36 Sensitive Content / Content Warning draft optional 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. l and L tags MAY be also be used as defined in NIP-32 with the content-warning or other namespace to support further qualification and querying. Spec tag: content-warning options: - [reason]: optional Example { "pubkey": "<pub-key>", "created_at": 1000000000, "kind": 1, "tags": [ ["t", "hastag"], ["L", "content-warning"], ["l", "reason", "content-warning"], ["L", "social.

Nostr NIPS 20

NIP-20 Command Results final mandatory Moved to NIP-01 . Source: nostr-protocol/nips/20.md version: 37f6cbb 2023-11-15T21:42:51-03:00

Nostr NIPS 28

NIP-28 Public Chat draft optional 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: 40 - channel create 41 - channel metadata 42 - channel message 43 - hide message 44 - mute user Client-centric moderation gives client developers discretion over what types of content they want included in their apps, while imposing no additional requirements on relays.

Nostr NIPS 27

NIP-27 Text Note References draft optional 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 codes, such as nostr:nprofile1qqsw3dy8cpu...6x2argwghx6egsqstvg. Including NIP-10 -style tags (["e", <hex-id>, <relay-url>, <marker>]) for each reference is optional, clients should do it whenever they want the profile being mentioned to be notified of the mention, or when they want the referenced event to recognize their mention as a reply.

Nostr NIPS 26

NIP-26 Delegated Event Signing draft optional 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 stored in cold storage.

Nostr NIPS 25

NIP-25 Reactions draft optional A reaction is a kind 7 event that is used to react to other events. The generic reaction, represented by the content set to a + string, SHOULD be interpreted as a “like” or “upvote”. A reaction with content set to - SHOULD be interpreted as a “dislike” or “downvote”. It SHOULD NOT be counted as a “like”, and MAY be displayed as a downvote or dislike on a post.

Nostr NIPS 15

NIP-15 Nostr Marketplace draft optional Based on https://github.com/lnbits/Diagon-Alley . Implemented in NostrMarket and Plebeian Market . Terms merchant - seller of products with NOSTR key-pair customer - buyer of products with NOSTR key-pair product - item for sale by the merchant stall - list of products controlled by merchant (a merchant can have multiple stalls) marketplace - clientside software for searching stalls and purchasing products Nostr Marketplace Clients Merchant admin Where the merchant creates, updates and deletes stalls and products, as well as where they manage sales, payments and communication with customers.

Nostr NIPS 16

NIP-16 Event Treatment final mandatory Moved to NIP-01 . Source: nostr-protocol/nips/16.md version: 37f6cbb 2023-11-15T21:42:51-03:00

Nostr NIPS 14

NIP-14 Subject tag in Text events draft optional This NIP defines the use of the “subject” tag in text (kind: 1) events. (implemented in more-speech) ["subject": <string>] 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 contents.

Nostr NIPS 07

NIP-07 window.nostr capability for web browsers draft optional 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: async window.nostr.getPublicKey(): string // returns a public key as hex async window.nostr.signEvent(event: { created_at: number, kind: number, tags: string[][], content: string }): Event // takes an event object, adds `id`, `pubkey` and `sig` and returns it Aside from these two basic above, the following functions can also be implemented optionally:

Nostr NIPS 13

NIP-13 Proof of Work draft optional 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. difficulty is defined to be the number of leading zero bits in the NIP-01 id.

Nostr NIPS 10

NIP-10 On “e” and “p” tags in Text Events (kind 1). draft optional Abstract This NIP describes how to use “e” and “p” tags in text events, especially those that are replies to other text events. It helps clients thread the replies into a tree rooted at the original event. Positional “e” tags (DEPRECATED) This scheme is in common use; but should be considered deprecated. ["e", <event-id>, <relay-url>] as per NIP-01.

Nostr NIPS 01

NIP-01 Basic protocol flow description draft mandatory 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 Each user has a keypair. Signatures, public key, and encodings are done according to the Schnorr signatures standard for the curve secp256k1 . The only object type that exists is the event, which has the following format on the wire:

Nostr NIPS 02

NIP-02 Follow List final optional 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 not provided), i.

Nostr NIPS 03

NIP-03 OpenTimestamps Attestations for Events draft optional This NIP defines an event with kind:1040 that can contain an OpenTimestamps proof for any other event: { "kind": 1040 "tags": [ ["e", <event-id>, <relay-url>], ["alt", "opentimestamps attestation"] ], "content": <base64-encoded OTS file data> } 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.

Nostr NIPS 04

Warning unrecommended: deprecated in favor of NIP-44 NIP-04 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”.

Nostr NIPS 05

NIP-05 Mapping Nostr keys to DNS-based internet identifiers final optional On events of kind 0 (metadata) one can specify the key "nip05" with an internet identifier (an email-like address) as the value. Although there is a link to a very liberal “internet identifier” specification above, NIP-05 assumes the <local-part> part will be restricted to the characters a-z0-9-_., case-insensitive. Upon seeing that, the client splits the identifier into <local-part> and <domain> and use these values to make a GET request to https://<domain>/.

Nostr NIPS 06

NIP-06 Basic key derivation from mnemonic seed phrase draft optional BIP39 is used to generate mnemonic seed words and derive a binary seed from them. BIP32 is used to derive the path m/44'/1237'/<account>'/0/0 (according to the Nostr entry on SLIP44 ). A basic client can simply use an account of 0 to derive a single key. For more advanced use-cases you can increment account, allowing generation of practically infinite keys from the 5-level path with hardened derivation.

Nostr NIPS 08

Warning unrecommended: deprecated in favor of NIP-27 NIP-08 Handling Mentions final unrecommended optional This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of text_notes. 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 with other ways to unambiguously differentiate between mentions and normal text.