protocol

NIP-24 Extra metadata fields and tags draft optional author:fiatjaf This NIP defines extra optional fields added to events. kind 0 These are extra fields not specified in NIP-01 that may be present in the stringified JSON of metadata events: display_name: a bigger name with richer characters than name. Implementations should fallback to name when this is not available. website: a web URL related in any way to the event author. banner: an URL to a wide (~1024x768) picture to be optionally displayed in the background of a profile screen.

NIP-75 Zap Goals draft optional author:verbiricha This NIP defines an event for creating fundraising goals. Users can contribute funds towards the goal by zapping the goal event. Nostr Event A kind:9041 event is used. The .content contains a human-readable description of the goal. The following tags are defined as REQUIRED. amount - target amount in milisats. relays - a list of relays the zaps to this goal will be sent to and tallied from.

NIP-38 User Statuses draft optional author:jb55 Abstract 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. Live Statuses A special event with kind:30315 “User Status” is defined as an optionally expiring parameterized replaceable event, where the d tag represents the status type: For example: { "kind": 30315, "content": "Sign up for nostrasia!

NIP-72 Moderated Communities (Reddit Style) draft optional author:vitorpamplona author:arthurfranca The goal of this NIP is to create moderator-approved public communities around a topic. 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 issue an approval event kind:4550 that links the community with the new post.

NIP-48 Proxy Tags draft optional author:alexgleason Nostr events bridged from other protocols such as ActivityPub can link back to the source object by including a "proxy" tag, in the form: ["proxy", <id>, <protocol>] Where: <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". Clients may use this information to reconcile duplicated content bridged from other protocols, or to display a link to the source object.

NIP-99 Classified Listings draft optional author:erskingardner This NIP defines kind:30402: a parameterized replaceable 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 category of classifieds includes a very broad range of physical goods, services, work opportunities, rentals, free giveaways, personals, etc. and is distinct from the more strictly structured marketplaces defined in NIP-15 that often sell many units of specific products through very specific channels.

NIP-53 Live Activities draft optional author:vitorpamplona author:v0l Abstract Service providers want to offer live activities to the Nostr network in such a way that participants can easily logged and queried by clients. This NIP describes a general framework to advertise the involvement of pubkeys in such live activities. Live Event A special event with kind:30311 “Live Event” is defined as a parameterized replaceable event of public p tags. Each p tag SHOULD have a displayable marker name for the current role (e.

NIP-52 Calendar Events draft optional author:tyiu This specification defines calendar events representing an occurrence at a specific moment or between moments. These calendar events are parameterized replaceable and deletable per NIP-09 . 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. Calendar Events There are two types of calendar events represented by different kinds: date-based and time-based calendar events.

NIP-89 Recommended Application Handlers draft optional author:pablof7z This NIP describes kind:31989 and kind:31990: a way to discover applications that can handle unknown event-kinds. Rationale 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. Parties involved There are three actors to this workflow:

NIP-32 Labeling draft optional author:staab author:gruruya author:s3x-jay A label is a kind 1985 event that is used to label other entities. This supports a number of use cases, from distributed moderation and content recommendations to reviews and ratings. Label Target The label event MUST include one or more tags representing the object or objects being labeled: e, p, a, r, or t tags. This allows for labeling of events, people, relays, or topics respectively.

NIP-31 Dealing with unknown event kinds draft optional author:pablof7z author:fiatjaf 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 author:alexgleason Custom emoji may be added to kind 0 and kind 1 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 author:kieran author:melvincarvalho 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 author:kiwiidb author:bumi author:semisol author:vitorpamplona 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 pay Lightning invoices. user: The person using the client, and want’s to connect their wallet app to their client.

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 author:gzuuus 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-94 File Metadata draft optional author:frbitten author:kieran author:lovvtide author:fiatjaf author:staab 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.

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 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 “Badge Definition” 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 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 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) 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.

NIP-65 Relay List Metadata draft optional author:mikedilger author:vitorpamplona 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. If the marker is omitted, the relay is used for both purposes. The .content is not used. { "kind": 10002, "tags": [ ["r", "wss://alicerelay.

NIP-21 nostr: URI scheme draft optional author:fiatjaf 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: 7f75d0d 2023-05-01T14:15:06-04: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 final mandatory author:Semisol author:Kukks author:Cameri author:Giszmo Moved to NIP-01 . Source: nostr-protocol/nips/33.md version: 72bb8a1 2023-08-13T13:47:45-03:00

NIP-45 Event Counts draft optional author:staab 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 author:jb55 author:fiatjaf author:arthurfranca 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.

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.