nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-19 22:35:50 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

Remove "NIP-33" (#896)

Browse Source
This commit is contained in:
Asai Toshiya 2023-11-24 02:44:12 +09:00 committed by GitHub
parent 7822a8b126
commit 5ae5a6d055
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
09.md
View File

@ -8,7 +8,7 @@ Event Deletion
A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` tags, each referencing an event the author is requesting to be deleted.
Each tag entry must contain an "e" event id and/or NIP-33 `a` tags intended for deletion.
Each tag entry must contain an "e" event id and/or `a` tags intended for deletion.
The event's `content` field MAY contain a text note describing the reason for the deletion.

4
57.md
View File

@ -36,7 +36,7 @@ A `zap request` is an event of kind `9734` that is _not_ published to relays, bu
In addition, the event MAY include the following tags:
- `e` is an optional hex-encoded event id. Clients MUST include this if zapping an event rather than a person.
- `a` is an optional NIP-33 event coordinate that allows tipping parameterized replaceable events such as NIP-23 long-form notes.
- `a` is an optional event coordinate that allows tipping parameterized replaceable events such as NIP-23 long-form notes.
Example:
@ -110,7 +110,7 @@ When a client sends a `zap request` event to a server's lnurl-pay callback URL,
4. It MUST have 0 or 1 `e` tags
5. There should be a `relays` tag with the relays to send the `zap receipt` to.
6. If there is an `amount` tag, it MUST be equal to the `amount` query parameter.
7. If there is an `a` tag, it MUST be a valid NIP-33 event coordinate
7. If there is an `a` tag, it MUST be a valid event coordinate
The event MUST then be stored for use later, when the invoice is paid.

2
89.md
View File

@ -65,7 +65,7 @@ The third value of the tag SHOULD be the platform where this recommendation migh
* `content` is an optional `metadata`-like stringified JSON object, as described in NIP-01. This content is useful when the pubkey creating the `kind:31990` is not an application. If `content` is empty, the `kind:0` of the pubkey should be used to display application information (e.g. name, picture, web, LUD16, etc.)
* `k` tags' value is the event kind that is supported by this `kind:31990`.
Using a `k` tag(s) (instead of having the kind onf the NIP-33 `d` tag) provides:
Using a `k` tag(s) (instead of having the kind of the `d` tag) provides:
* Multiple `k` tags can exist in the same event if the application supports more than one event kind and their handler URLs are the same.
* The same pubkey can have multiple events with different apps that handle the same event kind.
* `bech32` in a URL MUST be replaced by clients with the NIP-19-encoded entity that should be loaded by the application.