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
- Event Kind Ranges
Message Types
- Client to Relay
- Relay to Client
Standardized Tags
Criteria for acceptance of NIPs
License

List

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
`1063`	File Metadata	94
`1984`	Reporting	56
`9734`	Zap Request	57
`9735`	Zap	57
`10000`	Mute List	51
`10001`	Pin List	51
`10002`	Relay List Metadata	65
`13194`	Wallet Info	47
`22242`	Client Authentication	42
`23194`	Wallet Request	47
`23195`	Wallet Response	47
`24133`	Nostr Connect	46
`30000`	Categorized People List	51
`30001`	Categorized Bookmark List	51
`30008`	Profile Badges	58
`30009`	Badge Definition	58
`30017`	Create or update a stall	15
`30018`	Create or update a product	15
`30023`	Long-form Content	23
`30078`	Application-specific Data	78
`31989`	Handler recommendation	89
`31990`	Handler information	89

Event Kind Ranges

range	description	NIP
`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
`content-warning`	reason	--	36
`delegation`	pubkey, conditions, delegation token	--	26
`description`	badge description	--	58
`description`	invoice description	--	57
`emoji`	shortcode	image URL	30
`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

They should be implemented in at least two clients and one relay -- when applicable.
They should make sense.
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.
There should be no more than one way of doing the same thing.
Other rules will be made up when necessary.

License

All NIPs are public domain.

10 KiB Raw Blame History