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
• Message Types
  • Client to Relay
  • Relay to Client
• Standardized Tags
• Criteria for acceptance of NIPs
• Is this repository a centralizing factor?
• How this repository works
• License

---

List

• NIP-01: Basic protocol flow description
• NIP-02: Follow List
• 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-13: Proof of Work
• NIP-14: Subject tag in text events
• NIP-15: Nostr Marketplace (for resilient marketplaces)
• NIP-18: Reposts
• NIP-19: bech32-encoded entities
• NIP-21: nostr: URI scheme
• NIP-23: Long-form Content
• NIP-24: Extra metadata fields and tags
• NIP-25: Reactions
• NIP-26: Delegated Event Signing
• NIP-27: Text Note References
• NIP-28: Public Chat
• NIP-30: Custom Emoji
• NIP-31: Dealing with Unknown Events
• NIP-32: Labeling
• NIP-36: Sensitive Content
• NIP-38: User Statuses
• 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-47: Wallet Connect
• NIP-48: Proxy Tags
• NIP-50: Search Capability
• NIP-51: Lists
• NIP-52: Calendar Events
• NIP-53: Live Activities
• NIP-56: Reporting
• NIP-57: Lightning Zaps
• NIP-58: Badges
• NIP-65: Relay List Metadata
• NIP-72: Moderated Communities
• NIP-75: Zap Goals
• NIP-78: Application-specific data
• NIP-84: Highlights
• NIP-89: Recommended Application Handlers
• NIP-90: Data Vending Machines
• NIP-94: File Metadata
• NIP-98: HTTP Auth
• NIP-99: Classified Listings

Event Kinds

kind	description	NIP
0	Metadata	1
1	Short Text Note	1
2	Recommend Relay
3	Follows	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
1040	OpenTimestamps	03
1063	File Metadata	94
1311	Live Chat Message	53
1971	Problem Tracker	nostrocket
1984	Reporting	56
1985	Label	32
4550	Community Post Approval	72
5000-5999	Job Request	90
6000-6999	Job Result	90
7000	Job Feedback	90
9041	Zap Goal	75
9734	Zap Request	57
9735	Zap	57
9802	Highlights	84
10000	Mute list	51
10001	Pin list	51
10002	Relay List Metadata	65
10003	Bookmark list	51
10004	Communities list	51
10005	Public chats list	51
10006	Blocked relays list	51
10007	Search relays list	51
10015	Interests list	51
10030	User emoji list	51
13194	Wallet Info	47
21000	Lightning Pub RPC	Lightning.Pub
22242	Client Authentication	42
23194	Wallet Request	47
23195	Wallet Response	47
24133	Nostr Connect	46
27235	HTTP Auth	98
30000	Follow sets	51
30001	Generic lists	51
30002	Relay sets	51
30003	Bookmark sets	51
30004	Curation sets	51
30008	Profile Badges	58
30009	Badge Definition	58
30015	Interest sets	51
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
30030	Emoji sets	51
30078	Application-specific Data	78
30311	Live Event	53
30315	User Statuses	38
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

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
CLOSED	used to notify clients that a REQ was ended and why	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
g	geohash	--	52
i	identity	proof	39
k	kind number (string)	--	18, 25, 72
l	label, label namespace	annotations	32
L	label namespace	--	32
m	MIME type	--	94
r	a reference (URL, etc)	petname
r	relay url	marker	65
t	hashtag	--
alt	summary	--	31
amount	millisatoshis, stringified	--	57
bolt11	bolt11 invoice	--	57
challenge	challenge string	--	42
client	name, address	relay URL	89
content-warning	reason	--	36
delegation	pubkey, conditions, delegation token	--	26
description	invoice/badge description	--	57, 58
emoji	shortcode, image URL	--	30
encrypted	--	--	90
expiration	unix timestamp (string)	--	40
goal	event id (hex)	relay URL	75
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
thumb	badge thumbnail	dimensions in pixels	58
title	article title	--	23
zap	pubkey (hex), relay URL	weight	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.

Is this repository a centralizing factor?

To promote interoperability, we standards that everybody can follow, and we need them to define a single way of doing each thing without ever hurting backwards-compatibility, and for that purpose there is no way around getting everybody to agree on the same thing and keep a centralized index of these standards. However the fact that such index exists doesn't hurt the decentralization of Nostr. At any point the central index can be challenged if it is failing to fulfill the needs of the protocol and it can migrate to other places and be maintained by other people.

It can even fork into multiple and then some clients would go one way, others would go another way, and some clients would adhere to both competing standards. This would hurt the simplicity, openness and interoperability of Nostr a little, but everything would still work in the short term.

There is a list of notable Nostr software developers who have commit access to this repository, but that exists mostly for practical reasons, as by the nature of the thing we're dealing with the repository owner can revoke membership and rewrite history as they want -- and if these actions are unjustified or perceived as bad or evil the community must react.

How this repository works

Standards may emerge in two ways: the first way is that someone starts doing something, then others copy it; the second way is that someone has an idea of a new standard that could benefit multiple clients and the protocol in general without breaking backwards-compatibility and the principle of having a single way of doing things, then they write that idea and submit it to this repository, other interested parties read it and give their feedback, then once most people reasonably agree we codify that in a NIP which client and relay developers that are interested in the feature can proceed to implement.

These two ways of standardizing things are supported by this repository. Although the second is preferred, an effort will be made to codify standards emerged outside this repository into NIPs that can be later referenced and easily understood and implemented by others -- but obviously as in any human system discretion may be applied when standards are considered harmful.

License

All NIPs are public domain.

Contributors