Lib.rs

› Development tools
#nostr #gnostr #git #version-control

app nips

git+nostr workflow utility

by gnostr-org, Michael Dilger, DanConwayDev, Max Inden, fiatjaf_. Owned by @RandyMcMillan.

2 releases

0.0.36 May 16, 2024
0.0.35 May 16, 2024

#15 in #gnostr

39 downloads per month

Apache-2.0

120KB

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 01
1 Short Text Note 01
2 Recommend Relay 01 (deprecated)
3 Follows 02
4 Encrypted Direct Messages 04
5 Event Deletion 09
6 Repost 18
7 Reaction 25
8 Badge Award 58
9 Group Chat Message 29
10 Group Chat Threaded Reply 29
11 Group Thread 29
12 Group Thread Reply 29
13 Seal 59
14 Direct Message 17
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
1021 Bid 15
1022 Bid confirmation 15
1040 OpenTimestamps 03
1059 Gift Wrap 59
1063 File Metadata 94
1311 Live Chat Message 53
1617 Patches 34
1621 Issues 34
1622 Replies 34
1630-1633 Status 34
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
9000-9030 Group Control Events 29
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
10009 User groups 51, 29
10015 Interests list 51
10030 User emoji list 51
10050 Relay list to receive DMs 17
10096 File storage server list 96
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
30019 Marketplace UI/UX 15
30020 Product sold as an auction 15
30023 Long-form Content 23
30024 Draft Long-form Content 23
30030 Emoji sets 51
30063 Release artifact sets 51
30078 Application-specific Data 78
30311 Live Event 53
30315 User Statuses 38
30402 Classified Listing 99
30403 Draft Classified Listing 99
30617 Repository announcements 34
30818 Wiki article 54
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
39000-9 Group metadata events 29

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
q event id (hex) relay URL 18
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
clone git clone URL -- 34
content-warning reason -- 36
delegation pubkey, conditions, delegation token -- 26
description description -- 34, 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
imeta inline metadata -- 92
lnurl bech32 encoded lnurl -- 57
location location string -- 52, 99
name name -- 34, 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, 17
relays relay list -- 57
server file storage server url -- 96
subject subject -- 14, 17
summary article summary -- 23
thumb badge thumbnail dimensions in pixels 58
title article title -- 23
web webpage URL -- 34
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.

Breaking Changes

Breaking Changes

License

All NIPs are public domain.

Contributors

No runtime deps