Specifications about #nip

Kinds 40 to 44, public chat channels with moderation left to the client.

Kind 7, the reaction, whose content is a plus, a minus or an emoji, pointing at the event it answers.

Kind 1111, the comment: a reply scoped to a root event or to an external identifier, with uppercase tags for the root and lowercase ones for the parent.

Private direct messages, built from NIP-44 encryption and NIP-59 gift wraps, where the set of participants is what defines a room.

The JSON document a relay serves over HTTP to describe itself: its name, its contacts, the NIPs it supports, its limits and its policies.

Kind 5, the deletion request, where an author asks relays to drop events they signed earlier.

How a key claims an email-like address, by serving a nostr.json document under the domain that maps a name to that pubkey.

Kind 3, the follow list: one p tag per followed key, each carrying an optional relay hint and petname.

The core protocol: the event object, how its id and signature are computed, what makes a kind regular, replaceable or addressable, and the messages clients and relays exchange.

Kind 37516 and its companions, geocache listings and the logs of the people who found them.

A third element on EOSE, telling a client whether the relay really sent every stored event matching the filter.

How a client on Android asks a signer application on the same device to sign, so it never handles the private key.

The imeta tag, which describes a media URL found in the content: its dimensions, its mime type, its hash and its fallbacks.

How an ecash mint announces itself and its capabilities, and how users recommend the mints they trust.

Gift wraps: a rumor sealed to its recipient, then wrapped again under a throwaway key, so relays see only the wrapper.

ncryptsec, a private key encrypted under a password, with scrypt deciding how expensive guessing it is.

How two devices speak Nostr over Bluetooth Low Energy, emulating the websocket protocol within its limits.

The alt tag, a plain text summary so a client that does not know a kind can still show something for it.

The delegation tag, which let one key authorise another to sign events on its behalf.

Deriving a key from a BIP39 mnemonic along the m/44'/1237' path.