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
andp
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-22: Event
created_at
Limits - 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-89: Recommended Application Handlers
- NIP-90: Data Vending Machines
- NIP-94: File Metadata
- NIP-98: HTTP Auth
- NIP-99: Classified Listings
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 |
1040 |
OpenTimestamps | 03 |
1984 |
Reporting | 56 |
1985 |
Label | 32 |
4550 |
Community Post Approval | 72 |
7000 |
Job Feedback | 90 |
9041 |
Zap Goal | 75 |
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 |
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 |
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 |
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.
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 |
summary | -- | 31 |
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 | -- | |
amount |
millisatoshis, stringified | -- | 57 |
bolt11 |
bolt11 invoice |
-- | 57 |
challenge |
challenge string | -- | 42 |
content-warning |
reason | -- | 36 |
delegation |
pubkey, conditions, delegation token | -- | 26 |
description |
invoice/badge description | -- | 57, 58 |
emoji |
shortcode, image URL | -- | 30 |
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 |
- 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.
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
All NIPs are public domain.