Nostr Implementation Possibilities

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

#1

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

#2

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

#3

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

#4

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

#5

[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)).

#6

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:

#7

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

#8

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.

#9

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

#10

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

#11

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

#12

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:

#13

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

#14

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).

#15

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

#16

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

#17

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`.

#18

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

#19

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

#20

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

#21

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).

#22

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.

#23

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:

#24

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

#25

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

#26

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

#27

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:

#28

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_.

#29

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

#30

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

#31

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

#32

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

#33

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

#34

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

#35

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.

#36

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`.

#37

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:

#38

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

#39

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.

#40

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,

#42

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.

#43

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.

#44

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

#45

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.

#46

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

#47

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"`.

#48

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

#49

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

#50

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

#51