nostr

NIP-39 External Identities in Profiles draft optional author:pseudozach author:Semisol 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 contents in addition to name, about, picture fields as included in NIP-01 :

NIP-51 Lists draft optional author:fiatjaf author:arcbtc author:monlovesmango author:eskema depends:33 A “list” event is defined as having a list of public and/or private tags. Public tags will be listed in the event tags. Private tags will be encrypted in the event content. Encryption for private tags will use NIP-04 - Encrypted Direct Message encryption, using the list author’s private and public key for the shared secret. A distinct event kind should be used for each list type created.

NIP-78 Arbitrary custom app data draft optional author:sandwich author:fiatjaf 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 that 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 author:cameri Three special events are used to define, award and display badges in user profiles: A “Badge Definition” event is defined as a parameterized replaceable 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 “Define Badge” event and one or more p tags, one for each pubkey the badge issuer wishes to award.

NIP-46 Nostr Connect draft optional author:tiero author:giowe author:vforvalerio87 Rationale Private keys should be exposed to as few systems - apps, operating systems, devices - as possible as each system adds to the attack surface. Entering private keys can also be annoying and requires exposing them to even more systems such as the operating system’s clipboard that might be monitored by malicious apps. Terms App: Nostr app on any platform that requires to act on behalf of a nostr account.

NIP-57 Lightning Zaps draft optional author:jb55 author:kieran This NIP defines a new note type called a lightning zap of kind 9735. These represent paid lightning invoice receipts sent by a lightning node called the zapper. We also define another note type of kind 9734 which are zap request notes, which will be described in this document. Having lightning receipts on nostr allows clients to display lightning payments from entities on the network.

NIP-56 Reporting draft optional author:jb55 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.

NIP-23 Long-form Content draft optional author:fiatjaf This NIP defines kind:30023 (a parameterized replaceable event according to NIP-33 ) for long-form text content, generally referred to as “articles” or “blog posts”. “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. Metadata For the date of the last update the .created_at field should be used, for “tags”/“hashtags” (i.

NIP-65 Relay List Metadata draft optional author:mikedilger A special replaceable event meaning “Relay List Metadata” is defined as an event with kind 10002 having a list of r tags, one for each relay the author uses to either read or write to. The primary purpose of this relay list is to advertise to others, not for configuring one’s client. The content is not used and SHOULD be an empty string.

NIP-21 nostr: URL scheme draft optional author:fiatjaf This NIP standardizes the usage of a common URL 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: 45649d7 2023-01-24T10:23:00-03:00

NIP-50 Search Capability draft optional author:brugeman author:mikedilger author:fiatjaf 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.

NIP-33 Parameterized Replaceable Events draft optional author:Semisol author:Kukks author:Cameri author:Giszmo This NIP adds a new event range that allows for replacement of events that have the same d tag and kind unlike NIP-16 which only replaced by kind. Implementation The value of a tag is defined as the first parameter of a tag after the tag name. A parameterized replaceable event is defined as an event with a kind 30000 <= n < 40000.

NIP-42 Authentication of clients to relays draft optional author:Semisol author:fiatjaf 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 author:jb55 author:fiatjaf author:Semisol 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 author:0xtlt 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.

NIP-36 Sensitive Content / Content Warning draft optional author:fernandolguevara 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. Spec tag: content-warning options: - [reason]: optional Example { "pubkey": "<pub-key>", "created_at": 1000000000, "kind": 1, "tags": [ ["t", "hastag"], ["content-warning", "reason"] /* reason is optional */ ], "content": "sensitive content with #hastag\n", "id": "<event-id>" } Source: nostr-protocol/nips/36.

NIP-20 Command Results draft optional author:jb55 When submitting events to relays, clients currently have no way to know if an event was successfully committed to the database. This NIP introduces the concept of command results which are like NOTICE’s except provide more information about if an event was accepted or rejected. A command result is a JSON object with the following structure that is returned when an event is successfully saved to the database or rejected:

NIP-28 Public Chat draft optional author:ChristopherDavid author:fiatjaf author:jb55 author:Cameri 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 author:arthurfranca author:hodlbod author:fiatjaf 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.

NIP: 26 Delegated Event Signing draft optional author:markharding author:minds 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 author:jb55 A reaction is a kind 7 note that is used to react to other notes. 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.

NIP-22 Event created_at Limits draft optional author:jeffthibault author:Giszmo Relays may define both upper and lower limits within which they will consider an event’s created_at to be acceptable. Both the upper and lower limits MUST be unix timestamps in seconds as defined in NIP-01 . If a relay supports this NIP, the relay SHOULD send the client a NIP-20 command result saying the event was not stored for the created_at timestamp not being within the permitted limits.

NIP-15 End of Stored Events Notice final optional author:Semisol Relays may support notifying clients when all stored events have been sent. If a relay supports this NIP, the relay SHOULD send the client a EOSE message in the format ["EOSE", <subscription_id>] after it has sent all the events it has persisted and it indicates all the events that come after this message are newly published. Client Behavior Clients SHOULD use the supported_nips field to learn if a relay supports end of stored events notices.

NIP-16 Event Treatment draft optional author:Semisol Relays may decide to allow replaceable and/or ephemeral events. Regular Events A regular event is defined as an event with a kind 1000 <= n < 10000. Upon a regular event being received, the relay SHOULD send it to all clients with a matching filter, and SHOULD store it. New events of the same kind do not affect previous events in any way. Replaceable Events A replaceable event is defined as an event with a kind 10000 <= n < 20000.

NIP-14 Subject tag in Text events. draft optional author:unclebobmartin 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.

NIP-07 window.nostr capability for web browsers draft optional author:fiatjaf 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: Event): 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:

NIP-13 Proof of Work draft optional author:jb55 author:cameri 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.

NIP-10 On “e” and “p” tags in Text Events (kind 1). draft optional author:unclebobmartin 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.

NIP-01 Basic protocol flow description draft mandatory author:fiatjaf author:distbit author:scsibug author:kukks author:jb55 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 .

NIP-02 Contact List and Petnames final optional author:fiatjaf author:arcbtc A special event with kind 3, meaning “contact 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.