NIPs

NIPs stand for Nostr Implementation Possibilities. They exist to document 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 – unrecommended: deprecated in favor of NIP-27
• 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-16: Event Treatment
• NIP-18: Reposts
• NIP-19: bech32-encoded entities
• NIP-20: Command Results
• NIP-21: nostr: URL scheme
• NIP-22: Event created_at Limits
• NIP-23: Long-form Content
• NIP-25: Reactions
• NIP-26: Delegated Event Signing
• NIP-27: Text Note References
• NIP-28: Public Chat
• NIP-33: Parameterized Replaceable Events
• NIP-36: Sensitive Content
• NIP-39: External Identities in Profiles
• NIP-40: Expiration Timestamp
• NIP-42: Authentication of clients to relays
• NIP-45: Counting results
• NIP-46: Nostr Connect
• NIP-50: Keywords filter
• NIP-51: Lists
• NIP-56: Reporting
• NIP-57: Lightning Zaps
• NIP-58: Badges
• NIP-65: Relay List Metadata
• NIP-78: Application-specific data

Event Kinds

kind	description	NIP
0	Metadata	1
1	Short Text Note	1
2	Recommend Relay	1
3	Contacts	2
4	Encrypted Direct Messages	4
5	Event Deletion	9
6	Reposts	18
7	Reaction	25
8	Badge Award	58
40	Channel Creation	28
41	Channel Metadata	28
42	Channel Message	28
43	Channel Hide Message	28
44	Channel Mute User	28
1984	Reporting	56
9734	Zap Request	57
9735	Zap	57
10000	Mute List	51
10001	Pin List	51
10002	Relay List Metadata	65
22242	Client Authentication	42
24133	Nostr Connect	46
30000	Categorized People List	51
30001	Categorized Bookmark List	51
30008	Profile Badges	58
30009	Badge Definition	58
30023	Long-form Content	23
30078	Application-specific Data	78
1000-9999	Regular Events	16
10000-19999	Replaceable Events	16
20000-29999	Ephemeral Events	16
30000-39999	Parameterized Replaceable Events	33

Message types

Client to Relay

type	description	NIP
AUTH	used to send authentication events	42
CLOSE	used to stop previous subscriptions	1
COUNT	used to request event counts	45
EVENT	used to publish events	1
REQ	used to request events and subscribe to new updates	1

Relay to Client

type	description	NIP
AUTH	used to send authentication challenges	42
COUNT	used to send requested event counts to clients	45
EOSE	used to notify clients all stored events have been sent	1
EVENT	used to send events requested to clients	1
NOTICE	used to send human-readable messages to clients	1
OK	used to notify clients if an EVENT was successful	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 and NIP-33.

Standardized Tags

name	value	other parameters	NIP
a	coordinates to an event	relay URL	33, 23
d	identifier	--	33
e	event id (hex)	relay URL, marker	1, 10
g	geohash	--	12
i	identity	proof	39
p	pubkey (hex)	relay URL	1
r	a reference (URL, etc)	--	12
t	hashtag	--	12
amount	millisats	--	57
bolt11	bolt11 invoice	--	57
challenge	challenge string	--	42
delegation	pubkey, conditions, delegation token	--	26
description	badge description	--	58
description	invoice description	--	57
expiration	unix timestamp (string)	--	40
image	image URL	dimensions in pixels	23, 58
lnurl	bech32 encoded lnurl	--	57
name	badge name	--	58
nonce	random	--	13
preimage	hash of bolt11 invoice	--	57
published_at	unix timestamp (string)	--	23
relay	relay url	--	42
relays	relay list	--	57
subject	subject	--	14
summary	article summary	--	23
thumb	badge thumbnail	dimensions in pixels	58
title	article title	--	23
zap	profile name	type of value	57

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.