NIP-10 On “e” and “p” tags in Text Events (kind 1) draft optional
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
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 .
The only object type that exists is the event, which has the following format on the wire:
NIP-02 Follow List final optional
A special event with kind 3, meaning “follow 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.
NIP-03 OpenTimestamps Attestations for Events draft optional
This NIP defines an event with kind:1040 that can contain an OpenTimestamps proof for any other event:
{ "kind": 1040 "tags": [ ["e", <event-id>, <relay-url>], ["alt", "opentimestamps attestation"] ], "content": <base64-encoded OTS file data> } The OpenTimestamps proof MUST prove the referenced e event id as its digest. The content MUST be the full content of an .ots file containing at least one Bitcoin attestation.
Warning unrecommended: deprecated in favor of NIP-17 NIP-04 Encrypted Direct Message final unrecommended optional
A special event with kind 4, meaning “encrypted direct message”. It is supposed to have the following attributes:
content MUST be equal to the base64-encoded, aes-256-cbc encrypted string of anything a user wants to write, encrypted using a shared cipher generated by combining the recipient’s public-key with the sender’s private-key; this appended by the base64-encoded initialization vector as if it was a querystring parameter named “iv”.
NIP-05 Mapping Nostr keys to DNS-based internet identifiers final optional
On events of kind 0 (user metadata) one can specify the key "nip05" with an internet identifier (an email-like address) as the value. Although there is a link to a very liberal “internet identifier” specification above, NIP-05 assumes the <local-part> part will be restricted to the characters a-z0-9-_., case-insensitive.
Upon seeing that, the client splits the identifier into <local-part> and <domain> and use these values to make a GET request to https://<domain>/.
NIP-06 Basic key derivation from mnemonic seed phrase draft optional
BIP39 is used to generate mnemonic seed words and derive a binary seed from them.
BIP32 is used to derive the path m/44'/1237'/<account>'/0/0 (according to the Nostr entry on SLIP44 ).
A basic client can simply use an account of 0 to derive a single key. For more advanced use-cases you can increment account, allowing generation of practically infinite keys from the 5-level path with hardened derivation.
Warning unrecommended: deprecated in favor of NIP-27 NIP-08 Handling Mentions final unrecommended optional
This document standardizes the treatment given by clients of inline mentions of other events and pubkeys inside the content of text_notes.
Clients that want to allow tagged mentions they MUST show an autocomplete component or something analogous to that whenever the user starts typing a special key (for example, “@”) or presses some button to include a mention etc – or these clients can come up with other ways to unambiguously differentiate between mentions and normal text.
NIP-09 Event Deletion Request draft optional
A special event with kind 5, meaning “deletion request” is defined as having a list of one or more e or a tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a k tag for the kind of each event being requested for deletion.
The event’s content field MAY contain a text note describing the reason for the deletion request.
NIP-11 Relay Information Document draft optional
Relays may provide server metadata to clients to inform them of capabilities, administrative contacts, and various server attributes. This is made available as a JSON document over HTTP, on the same URI as the relay’s websocket.
When a relay receives an HTTP(s) request with an Accept header of application/nostr+json to a URI supporting WebSocket upgrades, they SHOULD return a document with the following structure.
NIP-12 Generic Tag Queries final mandatory
Moved to NIP-01 .
Source: nostr-protocol/nips/12.md version: 37f6cbb 2023-11-15T21:42:51-03:00
NIPs NIPs stand for Nostr Implementation Possibilities.
They exist to document what may be implemented by Nostr -compatible relay and client software.
List Event Kinds Message Types Client to Relay Relay to Client Standardized Tags Criteria for acceptance of NIPs Is this repository a centralizing factor? How this repository works Breaking Changes License List NIP-01: Basic protocol flow description NIP-02: Follow List NIP-03: OpenTimestamps Attestations for Events NIP-04: Encrypted Direct Message — unrecommended: deprecated in favor of NIP-17 NIP-05: Mapping Nostr keys to DNS-based internet identifiers NIP-06: Basic key derivation from mnemonic seed phrase NIP-07: window.