Nostr Implementation Possibilities (NIPs)

NIP-90 defines a protocol for on-demand computation between Customers (who request jobs) and Service Providers (who fulfill them). It enables a marketplace where users announce desired outputs and willingness to pay, allowing service providers to compete to fulfill requirements.

Note: This NIP is marked as unrecommended and draft; users are encouraged to prefer use-case-specific microstandards.

NIPs (Nostr Implementation Possibilities) are documents that describe potential implementations for Nostr-compatible relay and client software.

Important Implementation Notes:

• NIPs are not a mandatory protocol checklist.
• Software developers should pick a subset of NIPs relevant to their specific use case.
• Do not implement a NIP solely because it exists in this repository.
• Be aware that standards and NIPs may exist outside this repository (e.g., in pull requests) and may already be in use.

NIP-59 defines a protocol for encapsulating Nostr events to obscure metadata, enable collaborative signing, and provide deniability. It uses three layers of protection:

1. Rumor: An unsigned event (any kind) containing the actual content. If leaked, it cannot be verified.
2. Seal (kind:13): An encrypted rumor placed in the content field of a kind:13 event. The seal is signed by the author, identifying them without revealing the content or recipient.
3. Gift Wrap (kind:1059 or kind:21059): An encrypted seal placed in the content field of a wrapper event. This layer can add routing metadata (like recipient p tags) without revealing the true author.

This protocol relies on NIP-44 for versioned encryption.

NIP-57 defines two new event types for recording lightning payments between users:

• 9734 (zap request): A payer's request to a recipient's lightning wallet for an invoice.
• 9735 (zap receipt): A confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid.

These events allow clients to display lightning payments on the network, which can be used for engagement or spam deterrence.

NIP-46 enables 2-way communication between a Nostr client and a remote signer (often called a 'bunker').

Key roles:

• user: The person using Nostr.
• client: The user-facing application that sends requests to the remote-signer.
• remote-signer: A daemon or server (bunker) that answers requests from the client.
• client-keypair/pubkey: Disposable keys generated by the client to encrypt communication with the remote-signer.
• remote-signer-keypair/pubkey: Keys used by the remote-signer to encrypt communication with the client.
• user-keypair/pubkey: The actual identity keys of the user, which the remote-signer typically controls and uses to sign events.

NIP-32 introduces a way to label events, people, relays, or topics using a new event kind (kind: 1985) or by adding tags to existing events. This supports use cases like moderation, collection management, and content classification.

New Tags

• L: Denotes a label namespace (e.g., ISO-639-1 or nip28.moderation).
• l: Denotes a label. If an L tag is present, the l tag MUST include a mark matching the L tag value. If no L tag is present, ugc (user generated content) is implied.

Label Targets

To label specific objects, a kind: 1985 event MUST include one or more of the following tags:

• e: Labels an event.
• p: Labels a person (pubkey).
• a: Labels an addressable/replaceable event.
• r: Labels a relay.
• t: Labels a topic.

As with NIP-01, a relay hint SHOULD be included when using e and p tags.

NIP-44 introduces a versioned data format for keypair-based encryption. This format is intended to be used within the context of a signed NIP-01 event. It is not a replacement for NIP-04, but rather a way to provide multiple algorithm choices for encryption through versioning.

Important Security Note: This NIP is designed for simplicity. It does not provide deniability, forward secrecy, post-compromise security, or post-quantum security. It also does not hide the created_at timestamp or the approximate message length. For high-risk communication, use specialized E2EE software instead of Nostr.

NIP-51 defines lists of items that users can create. Lists can contain both public and private references.

Public vs Private Items

• Public items: Specified directly in the event tags array.
• Private items: Specified in a JSON array that mimics the structure of the tags array. This array must be stringified and encrypted using NIP-44 (shared key computed using the author's public and private key) and stored in the .content field.

Encryption Compatibility

While NIP-44 is the current standard, some older lists use NIP-04. Clients can maintain backward compatibility by searching for "iv" in the ciphertext to determine the encryption scheme.

Ordering

When adding new items to an existing list, clients SHOULD append them to the end of the list to maintain chronological order.

NIP-5A defines a method for hosting static websites using Blossom assets via Nostr event manifests. You can host a root site for a pubkey or multiple named sites (subdomains) under that same pubkey.

Event Kinds

• Root site: Kind 15128. A single replaceable event per pubkey. Must NOT include a d tag.
• Named sites: Kind 35128. Sub-sites under a pubkey. MUST include a d tag for the site identifier.
• Manifest snapshots: Kind 5128. Regular events used to capture a specific version of a site for historical addressability.

NIP-28 defines event kinds for public chat channels, messages, and client-side moderation.

Warning: This NIP is marked as unrecommended. It is advised to use NIP-29 instead.

Reserved Event Kinds:

• 40: channel create
• 41: channel metadata
• 42: channel message
• 43: hide message
• 44: mute user

NIP-15 defines a protocol for a Nostr-based marketplace. It involves three main roles:

• merchant: Seller of products using a NOSTR key-pair.
• customer: Buyer of products using a NOSTR key-pair.
• marketplace: Clientside software used to search stalls and purchase products.

Note: This NIP is currently marked as draft, unrecommended, and optional. It is suggested to use NIP-99 instead.