doc-hex / nips

Nostr Implementation Possibilities

NIPs

NIPs stand for Nostr Implementation Possibilities. They exist to document what MUST, what SHOULD and what MAY be implemented by Nostr-compatible relay and client software.

• NIP-01: Basic protocol flow description
• NIP-02: Contact List and Petnames
• NIP-03: OpenTimestamps Attestations for Events
• NIP-04: Encrypted Direct Message
• NIP-05: Mapping Nostr keys to DNS-based internet identifiers
• NIP-06: Basic key derivation from mnemonic seed phrase
• NIP-07: window.nostr capability for web browsers
• NIP-08: Handling Mentions
• NIP-09: Event Deletion
• NIP-10: Conventions for clients' use of e and p tags in text events.
• NIP-11: Relay Information Document
• NIP-12: Generic Tag Queries
• NIP-13: Proof of Work
• NIP-14: Subject tag in text events.
• NIP-15: End of Stored Events Notice
• NIP-16: Event Treatment
• NIP-18: Reposts
• NIP-19: bech32-encoded entities
• NIP-20: Command Results
• NIP-22: Event created_at Limits
• NIP-25: Reactions
• NIP-26: Delegated Event Signing
• NIP-28: Public Chat
• NIP-33: Parameterized Replaceable Events
• NIP-36: Sensitive Content
• NIP-40: Expiration Timestamp

Event Kinds

kind	description	NIP
0	Metadata	1, 5
1	Text	1
2	Recommend Relay	1
3	Contacts	2
4	Encrypted Direct Messages	4
5	Event Deletion	9
6	Repost	18
7	Reaction	25
40	Channel Creation	28
41	Channel Metadata	28
42	Channel Message	28
43	Channel Hide Message	28
44	Channel Mute User	28
45-49	Public Chat Reserved	28
10000-19999	Replaceable Events Reserved	16
20000-29999	Ephemeral Events Reserved	16

Message types

Client to Relay

type	description	NIP
EVENT	used to publish events	1
REQ	used to request events and subscribe to new updates	1
CLOSE	used to stop previous subscriptions	1

Relay to Client

type	description	NIP
EVENT	used to send events requested to clients	1
NOTICE	used to send human-readable messages to clients	1
EOSE	used to notify clients all stored events have been sent	15
OK	used to notify clients if an EVENT was successuful	20

Please update these lists when proposing NIPs introducing new event kinds.

When experimenting with kinds, keep in mind the classification introduced by NIP-16.

Criteria for acceptance of NIPs

1. They should be implemented in at least two clients and one relay -- when applicable.
2. They should make sense.
3. They should be optional and backwards-compatible: care must be taken such that clients and relays that choose to not implement them do not stop working when interacting with the ones that choose to.
4. There should be no more than one way of doing the same thing.
5. Other rules will be made up when necessary.

License

All NIPs are public domain.