Mirror/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-14 19:36:22 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
94330ffb10
nips/README.md
Jonathan Staab 30696049cc Deprecate NIP 04
2023-08-11 13:14:52 -07:00

13 KiB
Raw Blame History

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

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 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

Event Kind Ranges

range description NIP
1000--9999 Regular Events 16
10000--19999 Replaceable Events 16
20000--29999 Ephemeral Events 16
30000--39999 Parameterized Replaceable Events 33

Message types

Client to Relay

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

Relay to Client

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.

Standardized Tags

name value other parameters NIP
a coordinates to an event relay URL 33, 23
alt Alt tag -- 31
d identifier -- 33
e event id (hex) relay URL, marker 1, 10
g geohash -- 12, 52
i identity proof 39
k kind number (string) -- 18, 72
l label, label namespace annotations 32
L label namespace -- 32
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
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 profile name type of value 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.

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:

License

All NIPs are public domain.