NIPs stand for Nostr Implementation Possibilities .
They exist to document what may be implemented by Nostr -compatible relay and client software.
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
range
description
NIP
1000
--9999
Regular Events
16
10000
--19999
Replaceable Events
16
20000
--29999
Ephemeral Events
16
30000
--39999
Parameterized Replaceable Events
33
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
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 .
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.
All NIPs are public domain.