mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-23 00:45:53 -05:00
A mirror for NIPS
2c1387f765
Hello, frens! Many nostr users are from Web3, and most use Decentralized Names like .bit, ENS, Unstoppable Domain, etc. It would be great if we could support them. Hereby I propose NIP-DID, a protocol combining Nostr Keys and Decentralized Names. With this proposal, we can simplify the process of sharing and following. Users will use a human-readable name instead of a long, irregular nip-19 pubkey to follow people. |
||
---|---|---|
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 | ||
40.md | ||
42.md | ||
46.md | ||
50.md | ||
56.md | ||
57.md | ||
65.md | ||
nip-did-name.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-40: Expiration Timestamp
- NIP-42: Authentication of clients to relays
- NIP-46: Nostr Connect
- NIP-50: Keywords filter
- NIP-56: Reporting
- NIP-57: Lightning Zaps
- NIP-65: Relay List Metadata
Event Kinds
kind | description | NIP |
---|---|---|
0 | Metadata | 1, 5 |
1 | Short Text Note | 1 |
2 | Recommend Relay | 1 |
3 | Contacts | 2 |
4 | Encrypted Direct Messages | 4 |
5 | Event Deletion | 9 |
7 | Reaction | 25 |
40 | Channel Creation | 28 |
41 | Channel Metadata | 28 |
42 | Channel Message | 28 |
43 | Channel Hide Message | 28 |
44 | Channel Mute User | 28 |
45-49 | Public Chat Reserved | 28 |
1984 | Reporting | 56 |
9734 | Zap Request | 57 |
9735 | Zap | 57 |
10002 | Relay List Metadata | 65 |
22242 | Client Authentication | 42 |
24133 | Nostr Connect | 46 |
30023 | Long-form Content | 23 |
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 successuful | 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.