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
`3`	Contacts	2
`4`	Encrypted Direct Messages	4
`5`	Event Deletion	9
`6`	Repost	18
`7`	Reaction	25
`8`	Badge Award	58
`16`	Generic Repost	18
`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
`1311`	Live Chat Message	53
`1984`	Reporting	56
`1985`	Label	32
`4550`	Community Post Approval	72
`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
`27235`	HTTP Auth	98
`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
`30024`	Draft Long-form Content	23
`30078`	Application-specific Data	78
`30311`	Live Event	53
`30402`	Classified Listing	99
`30403`	Draft Classified Listing	99
`31922`	Date-Based Calendar Event	52
`31923`	Time-Based Calendar Event	52
`31924`	Calendar	52
`31925`	Calendar Event RSVP	52
`31989`	Handler recommendation	89
`31990`	Handler information	89
`34550`	Community Definition	72

Message types

Client to Relay

type	description	NIP
`EVENT`	used to publish events	01
`REQ`	used to request events and subscribe to new updates	01
`CLOSE`	used to stop previous subscriptions	01
`AUTH`	used to send authentication events	42
`COUNT`	used to request event counts	45
`FILE`	used to publish events with binary content (file)	97
`RETRIEVE`	used to retrieve a binary content (file)	97

Relay to Client

type	description	NIP
`EOSE`	used to notify clients all stored events have been sent	01
`EVENT`	used to send events requested to clients	01
`NOTICE`	used to send human-readable messages to clients	01
`OK`	used to notify clients if an EVENT was successful	01
`AUTH`	used to send authentication challenges	42
`COUNT`	used to send requested event counts to clients	45

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

Standardized Tags

name	value	other parameters	NIP
`e`	event id (hex)	relay URL, marker	01, 10
`p`	pubkey (hex)	relay URL, petname	01, 02
`a`	coordinates to an event	relay URL	01
`d`	identifier	--	01
`alt`	Alt tag	--	31
`g`	geohash	--	52
`i`	identity	proof	39
`k`	kind number (string)	--	18, 72
`l`	label, label namespace	annotations	32
`m`	content type of a file (mime)	--	94, 97
`L`	label namespace	--	32
`x`	SHA256 hash of a file	--	94, 97
`r`	a reference (URL, etc)	--
`t`	hashtag	--
`amount`	millisatoshis, stringified	--	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
`location`	location string	--	52, 99
`name`	badge name	--	58
`nonce`	random	--	13
`preimage`	hash of `bolt11` invoice	--	57
`price`	price	currency, frequency	99
`proxy`	external ID	protocol	48
`published_at`	unix timestamp (string)	--	23
`relay`	relay url	--	42
`relays`	relay list	--	57
`subject`	subject	--	14
`summary`	article summary	--	23
`size`	size of a file in bytes	--	94, 97
`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.

Mailing Lists

The nostr ecosystem is getting large with many different organizations, relays and clients. Following the nips repo on github is becoming more difficult and noisy. To coordinate on protocol development outside of github, there are mailing lists where you can work on NIPs before submitting them here:

w3c nostr community group - public-nostr@w3.org - requires signup
nostr-protocol google group - nostr-protocol@googlegroups.com - no signup required

License

All NIPs are public domain.

13 KiB Raw Blame History