nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 08:25:53 -05: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. 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. 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: 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. - `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: 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 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. 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. 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. 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.) * `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`. * `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. * 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. * 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. * `bech32` in a URL MUST be replaced by clients with the NIP-19-encoded entity that should be loaded by the application.