mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-13 19:06:24 +00:00
Nostr Implementation Possibilities
5355edb9cb
I think that adding a mention marker would eliminate ambiguity for clients supporting both the deprecated and preferred conventions. I also think that this would allow for extensibility in adding new types of event mentions (for example if we want to add context for a note). |
||
|---|---|---|
| 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 | ||
| 18.md | ||
| 19.md | ||
| 20.md | ||
| 22.md | ||
| 25.md | ||
| 26.md | ||
| 28.md | ||
| 33.md | ||
| 36.md | ||
| 40.md | ||
| README.md | ||
NIPs
NIPs stand for Nostr Implementation Possibilities. They exist to document what MUST, what SHOULD and 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.nostrcapability for web browsers - NIP-08: Handling Mentions
- NIP-09: Event Deletion
- NIP-10: Conventions for clients' use of
eandptags 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-18: Reposts
- NIP-19: bech32-encoded entities
- NIP-20: Command Results
- NIP-22: Event created_at Limits
- 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
Event Kinds
| kind | description | NIP |
|---|---|---|
| 0 | Metadata | 1, 5 |
| 1 | Text | 1 |
| 2 | Recommend Relay | 1 |
| 3 | Contacts | 2 |
| 4 | Encrypted Direct Messages | 4 |
| 5 | Event Deletion | 9 |
| 6 | Repost | 18 |
| 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 |
| 10000-19999 | Replaceable Events Reserved | 16 |
| 20000-29999 | Ephemeral Events Reserved | 16 |
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 |
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 |
Please update these lists when proposing NIPs introducing new event kinds.
When experimenting with kinds, keep in mind the classification introduced by NIP-16.
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.