protocol

Nostr NIPS 34

NIP-34 git stuff draft optional This NIP defines all the ways code collaboration using and adjacent to git can be done using Nostr. Repository announcements Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events, as well as their willingness to receive patches, bug reports and comments in general. { "kind": 30617, "content": "", "tags": [ ["d", "<repo-id>"], ["name", "<human-readable project name>"], ["description", "brief human-readable project description>"], ["web", "<url for browsing>", .

Nostr NIPS 92

NIP-92 Media Attachments Media attachments (images, videos, and other files) may be added to events by including a URL in the event content, along with a matching imeta tag. imeta (“inline metadata”) tags add information about media URLs in the event’s content. Each imeta tag SHOULD match a URL in the event content. Clients may replace imeta URLs with rich previews. The imeta tag is variadic, and each entry is a space-delimited key/value pair.

Nostr NIPS 49

NIP-49 Private Key Encryption draft optional This NIP defines a method by which clients can encrypt (and decrypt) a user’s private key with a password. Symmetric Encryption Key derivation PASSWORD = Read from the user. The password should be unicode normalized to NFKC format to ensure that the password can be entered identically on other computers/clients. LOG_N = Let the user or implementer choose one byte representing a power of 2 (e.

Nostr NIPS 96

NIP-96 HTTP File Storage Integration draft optional Introduction This NIP defines a REST API for HTTP file storage servers intended to be used in conjunction with the nostr network. The API will enable nostr users to upload files and later reference them by url on nostr notes. The spec DOES NOT use regular nostr events through websockets for storing, requesting nor retrieving data because, for simplicity, the server will not have to learn anything about nostr relays.

Nostr NIPS 44

NIP-44 Encrypted Payloads (Versioned) optional 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 kinds related to a new direct messaging standard, only the encryption required to define one.

Nostr NIPS 29

NIP-29 Relay-based Groups draft optional 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. There is no way to create a group, what happens is just that relays (most likely when asked by users) will create rules around some specific ids so these ids can serve as an actual group, henceforth messages sent to that group will be subject to these rules.

Nostr NIPS 84

NIP-84 Highlights draft optional This NIP defines kind:9802, a “highlight” event, to signal content a user finds valuable. Format The .content of these events is the highlighted portion of the text. .content might be empty for highlights of non-text based media (e.g. NIP-94 audio/video). References Events SHOULD tag the source of the highlight, whether nostr-native or not. a or e tags should be used for nostr events and r tags for URLs.

Nostr NIPS 24

NIP-24 Extra metadata fields and tags draft optional 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: an alternative, bigger name with richer characters than name. name should always be set regardless of the presence of display_name in the metadata. website: a web URL related in any way to the event author.

Nostr NIPS 75

NIP-75 Zap Goals draft optional 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.

Nostr NIPS 38

NIP-38 User Statuses draft optional 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!

Nostr NIPS 59

NIP-59 Gift Wrap optional This NIP defines a protocol for encapsulating any nostr event. This makes it possible to obscure most metadata for a given event, perform collaborative signing, and more. This NIP does not define any messaging protocol. Applications of this NIP should be defined separately. This NIP relies on NIP-44 ’s versioned encryption algorithms. Overview This protocol uses three main concepts to protect the transmission of a target event: rumors, seals, and gift wraps.

Nostr NIPS 72

NIP-72 Moderated Communities (Reddit Style) draft optional 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. Community Definition kind:34550 SHOULD include any field that helps define the community and the set of moderators.

Nostr NIPS 48

NIP-48 Proxy Tags draft optional 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.

Nostr NIPS 90

NIP-90 Data Vending Machine draft optional This NIP defines the interaction between customers and Service Providers for performing on-demand computation. Money in, data out. Kinds This NIP reserves the range 5000-7000 for data vending machine use. Kind Description 5000-5999 Job request kinds 6000-6999 Job result 7000 Job feedback Job results always use a kind number that is 1000 higher than the job request kind. (e.g. request: kind:5001 gets a result: kind:6001).

Nostr NIPS 99

NIP-99 Classified Listings draft optional 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.

Nostr NIPS 53

NIP-53 Live Activities draft optional Service providers want to offer live activities to the Nostr network in such a way that participants can easily log and query by clients. This NIP describes a general framework to advertise the involvement of pubkeys in such live activities. Concepts 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.

Nostr NIPS 52

NIP-52 Calendar Events draft optional 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.

Nostr NIPS 89

NIP-89 Recommended Application Handlers draft optional 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:

Nostr NIPS 32

NIP-32 Labeling draft optional A label is a kind 1985 event that is used to label other entities. This supports a number of use cases, including distributed moderation, collection management, license assignment, and content classification. This NIP introduces two 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.

Nostr NIPS 31

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.

Nostr NIPS 30

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.

Nostr NIPS 98

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:

Nostr NIPS 47

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 pay Lightning invoices. user: The person using the client, and want’s to connect their wallet app to their client.

Nostr NIPS 39

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 contents in addition to name, about, picture fields as included in NIP-01 :

Nostr NIPS 51

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 .

Nostr NIPS 94

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:

Nostr NIPS 78

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.

Nostr NIPS 58

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

Nostr NIPS 46

NIP-46 - Nostr Remote Signing 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. The remote signer could be, for example, a hardware device dedicated to signing Nostr events, while the client is a normal Nostr client.

Nostr NIPS 57

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.