mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-13 19:06:24 +00:00
Nostr Implementation Possibilities
01.md | ||
02.md | ||
03.md | ||
04.md | ||
05.md | ||
06.md | ||
07.md | ||
08.md | ||
09.md | ||
10.md | ||
11.md | ||
12.md | ||
13.md | ||
14.md | ||
15.md | ||
16.md | ||
19.md | ||
20.md | ||
21.md | ||
22.md | ||
23.md | ||
25.md | ||
26.md | ||
28.md | ||
33.md | ||
36.md | ||
39.md | ||
40.md | ||
42.md | ||
46.md | ||
50.md | ||
51.md | ||
56.md | ||
57.md | ||
58.md | ||
65.md | ||
78.md | ||
README.md |
NIPs
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
- NIP-09: Event Deletion
- NIP-10: Conventions for clients' use of
e
andp
tags in text events - NIP-11: Relay Information Document
- NIP-12: Generic Tag Queries
- NIP-13: Proof of Work
- NIP-14: Subject tag in text events.
- NIP-15: End of Stored Events Notice
- NIP-16: Event Treatment
- NIP-19: bech32-encoded entities
- NIP-20: Command Results
- NIP-21:
nostr:
URL scheme - NIP-22: Event
created_at
Limits - NIP-23: Long-form Content
- NIP-25: Reactions
- NIP-26: Delegated Event Signing
- NIP-28: Public Chat
- NIP-33: Parameterized Replaceable Events
- NIP-36: Sensitive Content
- NIP-39: External Identities in Profiles
- NIP-40: Expiration Timestamp
- NIP-42: Authentication of clients to relays
- NIP-46: Nostr Connect
- NIP-50: Keywords filter
- NIP-51: Lists
- NIP-56: Reporting
- NIP-57: Lightning Zaps
- NIP-58: Badges
- NIP-65: Relay List Metadata
- NIP-78: Application-specific data
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 |
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 |
1984 | Reporting | 56 |
9734 | Zap Request | 57 |
9735 | Zap | 57 |
10000 | Mute List | 51 |
10001 | Pin List | 51 |
10002 | Relay List Metadata | 65 |
22242 | Client Authentication | 42 |
24133 | Nostr Connect | 46 |
30000 | Categorized People List | 51 |
30001 | Categorized Bookmark List | 51 |
30008 | Profile Badges | 58 |
30009 | Badge Definition | 58 |
30023 | Long-form Content | 23 |
30078 | Application-specific Data | 78 |
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 |
---|---|---|
EVENT | used to publish events | 1 |
REQ | used to request events and subscribe to new updates | 1 |
CLOSE | used to stop previous subscriptions | 1 |
AUTH | used to send authentication events | 42 |
Relay to Client
type | description | NIP |
---|---|---|
EVENT | used to send events requested to clients | 1 |
NOTICE | used to send human-readable messages to clients | 1 |
EOSE | used to notify clients all stored events have been sent | 15 |
OK | used to notify clients if an EVENT was successful | 20 |
AUTH | used to send authentication challenges | 42 |
Please update these lists when proposing NIPs introducing new event kinds.
When experimenting with kinds, keep in mind the classification introduced by NIP-16.
Standardized Tags
name | value | other parameters | NIP |
---|---|---|---|
e | event id (hex) | relay URL, marker | 1, 10 |
p | pubkey (hex) | relay URL | 1 |
a | coordinates to an event | relay URL | 33, 23 |
r | a reference (URL, etc) | 12 | |
t | hashtag | 12 | |
g | geohash | 12 | |
nonce | random | 13 | |
subject | subject | 14 | |
d | identifier | 33 | |
expiration | unix timestamp (string) | 40 |
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.
License
All NIPs are public domain.