nostr

NIP-32 Labeling draft optional 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. New Tags: L denotes a label namespace l denotes a label Label Namespace Tag An L tag can be any string, but publishers SHOULD ensure they are unambiguous by using a well-defined namespace (such as an ISO standard) or reverse domain name notation.

NIP-31 Dealing with unknown event kinds draft optional 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.

NIP-30 Custom Emoji draft optional Custom emoji may be added to kind 0, kind 1, kind 7 (NIP-25 ) and kind 30315 (NIP-38 ) events by including one or more "emoji" tags, in the form: ["emoji", <shortcode>, <image-url>] Where: <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. For each emoji tag, clients should parse emoji shortcodes (aka “emojify”) like :shortcode: in the event to display custom emoji.

NIP-98 HTTP Auth draft optional 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. Nostr event A kind 27235 (In reference to RFC 7235 ) event is used. The content SHOULD be empty. The following tags MUST be included. u - absolute URL method - HTTP Request Method Example event:

NIP-47 Nostr Wallet Connect draft optional Rationale 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. Terms 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 wallet to their client.

NIP-39 External Identities in Profiles draft optional Abstract Nostr protocol users may have other online identities such as usernames, profile pages, keypairs etc. they control and they may want to include this data in their profile metadata so clients can parse, validate and display this information. i tag on a metadata event A new optional i tag is introduced for kind 0 metadata event defined in NIP-01 : { "id": <id>, "pubkey": <pubkey>, "tags": [ ["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"], ["i", "twitter:semisol_public", "1619358434134196225"], ["i", "mastodon:bitcoinhackers.

NIP-51 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 .

NIP-94 File Metadata draft optional 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. Event format This NIP specifies the use of the 1063 event type, having in content a description of the file content, and a list of tags described below:

NIP-78 Arbitrary custom app data draft optional The goal of this NIP is to enable remoteStorage -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, for example: a user would open an app and somehow input their preferred relay for storage, which would then enable these apps to store application-specific data there.

NIP-58 Badges draft optional Three special events are used to define, award and display badges in user profiles: 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. A “Badge Award” event is a kind 8 event with a single a tag referencing a “Badge Definition” event and one or more p tags, one for each pubkey the badge issuer wishes to award.

NIP-46 Nostr Remote Signing Changes remote-signer-key is introduced, passed in bunker url, clients must differentiate between remote-signer-pubkey and user-pubkey, must call get_public_key after connect, nip05 login is removed, create_account moved to another NIP. Rationale 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.

NIP-57 Lightning Zaps draft optional 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 clients to display lightning payments from entities on the network.

NIP-56 Reporting optional 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. Tags The report event MUST include a p tag referencing the pubkey of the user you are reporting.

NIP-23 Long-form Content draft optional 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. 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:

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.

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: 0c1dfa9 2024-07-28T15:36:31-04:00

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: { // other fields on filter object... "search": <string> } search field is a string describing a query in a human-readable form, i.

NIP-33 Parameterized Replaceable Events final mandatory Renamed to “Addressable events” and moved to NIP-01 . Source: nostr-protocol/nips/33.md version: ca3c52e 2024-08-20T12:56:05-03:00

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.

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.

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.

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.

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.

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.

NIP-35 Torrents draft optional This NIP defined a new kind 2003 which is a Torrent. kind 2003 is a simple torrent index where there is enough information to search for content and construct the magnet link. No torrent files exist on nostr. Tags x: V1 BitTorrent Info Hash, as seen in the magnet link 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 In order to make torrents searchable by general category, you SHOULD include a few tags like movie, tv, HD, UHD etc.

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

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.

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.

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.

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.