NIP-25 Reactions draft optional
A reaction is a kind 7 event that is used to react to other events.
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 Comment draft optional
A comment is a threading note always scoped to a root event or an I-tag.
It uses kind:1111 with plaintext .content (no HTML, Markdown, or other formatting).
Comments MUST point to the root scope using uppercase tag names (e.g. K, E, A or I) and MUST point to the parent item with lowercase ones (e.g. k, e, a or i).
{ kind: 1111, content: '<comment>', tags: [ // root scope: event addresses, event ids, or I-tags.
NIP-15 Nostr Marketplace draft optional
Based on Diagon-Alley .
Implemented in NostrMarket and Plebeian Market .
Terms merchant - seller of products with NOSTR key-pair customer - buyer of products with NOSTR key-pair product - item for sale by the merchant stall - list of products controlled by merchant (a merchant can have multiple stalls) marketplace - clientside software for searching stalls and purchasing products Nostr Marketplace Clients Merchant admin Where the merchant creates, updates and deletes stalls and products, as well as where they manage sales, payments and communication with customers.
NIP-16 Event Treatment final mandatory
Moved to NIP-01 .
Source: nostr-protocol/nips/16.md version: 37f6cbb 2023-11-15T21:42:51-03:00
NIP-14 Subject tag in Text events draft optional
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
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: { created_at: number, kind: number, tags: string[][], content: string }): 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
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.
difficulty is defined to be the number of leading zero bits in the NIP-01 id.
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.
Marked “e” tags (PREFERRED) ["e", <event-id>, <relay-url>, <marker>, <pubkey>]
Where:
<event-id> is the id of the event being referenced. <relay-url> is the URL of a recommended relay associated with the reference.
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
A single java file to query Certificate Transparency log records and verification.
Introduction Certificate Transparency (CT) depends on independent, reliable logs because it is a distributed ecosystem. Built using Merkle trees, logs are publicly verifiable, append-only, and tamper-proof.
Logs are publicly available and monitored.
How CT works Certificates are deposited in public, transparent logs Certificate logs are append-only ledgers of certificates. Because they’re distributed and independent, anyone can query them to see what certificates have been included and when.
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.