NIPs stand for Nostr Implementation Possibilities . They exist to document what may be implemented by Nostr -compatible relay and client software.
kind description NIP 0Metadata 1 1Short Text Note 1 2Recommend Relay 1 3Contacts 2 4Encrypted Direct Messages 4 5Event Deletion 9 6Reposts 18 7Reaction 25 8Badge Award 58 40Channel Creation 28 41Channel Metadata 28 42Channel Message 28 43Channel Hide Message 28 44Channel Mute User 28 1063File Metadata 94 1984Reporting 56 9734Zap Request 57 9735Zap 57 10000Mute List 51 10001Pin List 51 10002Relay List Metadata 65 13194Wallet Info 47 22242Client Authentication 42 23194Wallet Request 47 23195Wallet Response 47 24133Nostr Connect 46 30000Categorized People List 51 30001Categorized Bookmark List 51 30008Profile Badges 58 30009Badge Definition 58 30017Create or update a stall 15 30018Create or update a product 15 30023Long-form Content 23 30078Application-specific Data 78
range description NIP 1000--9999Regular Events 16 10000--19999Replaceable Events 16 20000--29999Ephemeral Events 16 30000--39999Parameterized Replaceable Events 33
type description NIP AUTHused to send authentication events 42 CLOSEused to stop previous subscriptions 1 COUNTused to request event counts 45 EVENTused to publish events 1 REQused to request events and subscribe to new updates 1
type description NIP AUTHused to send authentication challenges 42 COUNTused to send requested event counts to clients 45 EOSEused to notify clients all stored events have been sent 1 EVENTused to send events requested to clients 1 NOTICEused to send human-readable messages to clients 1 OKused 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 acoordinates to an event relay URL 33 , 23 didentifier -- 33 eevent id (hex) relay URL, marker 1 , 10 ggeohash -- 12 iidentity proof 39 ppubkey (hex) relay URL 1 ra reference (URL, etc) -- 12 thashtag -- 12 amountmillisats -- 57 bolt11bolt11 invoice-- 57 challengechallenge string -- 42 content-warningreason -- 36 delegationpubkey, conditions, delegation token -- 26 descriptionbadge description -- 58 descriptioninvoice description -- 57 expirationunix timestamp (string) -- 40 imageimage URL dimensions in pixels 23 , 58 lnurlbech32 encoded lnurl-- 57 namebadge name -- 58 noncerandom -- 13 preimagehash of bolt11 invoice -- 57 published_atunix timestamp (string) -- 23 relayrelay url -- 42 relaysrelay list -- 57 subjectsubject -- 14 summaryarticle summary -- 23 thumbbadge thumbnail dimensions in pixels 58 titlearticle title -- 23 zapprofile 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.