draft NIP-54 podcasts NIP.

2025-12-09 16:48:50 +00:00 · 2024-02-28 12:23:48 -03:00
8 changed files with 90 additions and 324 deletions
--- a/29.md
+++ b/29.md
@@ -1,197 +0,0 @@
 NIP-29
 ======
 Relay-based Groups
 ------------------
 `draft` `optional`
 This NIP defines a standard for groups that are only writable by a closed set of users. They can be public for reading by external users or not.
 Groups are identified by a random string of any length that serves as an _id_.
 There is no way to create a group, what happens is just that relays (most likely when asked by users) will create rules around some specific ids so these ids can serve as an actual group, henceforth messages sent to that group will be subject to these rules.
 Normally a group will originally belong to one specific relay, but the community may choose to move the group to other relays or even fork the group so it exists in different forms -- still using the same _id_ -- across different relays.
 ## Relay-generated events
 Relays are supposed to generate the events that describe group metadata and group admins. These are parameterized replaceable events signed by the relay keypair directly, with the group _id_ as the `d` tag.
 ## Group identifier
 A group may be identified by a string in the format `<host>'<group-id>`. For example, a group with _id_ `abcdef` hosted at the relay `wss://groups.nostr.com` would be identified by the string `groups.nostr.com'abcdef`.
 ## The `h` tag
 Events sent by users to groups (chat messages, text notes, moderation events etc) must have an `h` tag with the value set to the group _id_.
 ## Timeline references
 In order to not be used out of context, events sent to these groups may contain references to previous events seen from the same relay in the `previous` tag. The choice of which previous events to pick belongs to the clients. The references are to be made using the first 8 characters (4 bytes) of any event in the last 50 events seen by the user in the relay, excluding events by themselves. There can be any number of references (including zero), but it's recommended that clients include at least 3 and that relays enforce this.
 This is a hack to prevent messages from being broadcasted to external relays that have forks of one group out of context. Relays are expected to reject any events that contain timeline references to events not found in their own database. Clients should also check these to keep relays honest about them.
 ## Late publication
 Relays should prevent late publication (messages published now with a timestamp from days or even hours ago) unless they are open to receive a group forked or moved from another relay.
 ## Event definitions
 - *text root note* (`kind:11`)
 This is the basic unit of a "microblog" root text note sent to a group.
 ```js
  "kind": 11,
  "content": "hello my friends lovers of pizza",
  "tags": [
    ["h", "<group-id>"],
    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", ...]
  ]
  ...
 ```
 - *threaded text reply* (`kind:12`)
 This is the basic unit of a "microblog" reply note sent to a group. It's the same as `kind:11`, except for the fact that it must be used whenever it's in reply to some other note (either in reply to a `kind:11` or a `kind:12`). `kind:12` events SHOULD use NIP-10 markers, leaving an empty relay url:
 * `["e", "<kind-11-root-id>", "", "root"]`
 * `["e", "<kind-12-event-id>", "", "reply"]`
 - *chat message* (`kind:9`)
 This is the basic unit of a _chat message_ sent to a group.
 ```js
  "kind": 9,
  "content": "hello my friends lovers of pizza",
  "tags": [
    ["h", "<group-id>"],
    ["previous", "<event-id-first-chars>", "<event-id-first-chars>", ...]
  ]
  ...
 ```
 - *chat message threaded reply* (`kind:10`)
 Similar to `kind:12`, this is the basic unit of a chat message sent to a group. This is intended for in-chat threads that may be hidden by default. Not all in-chat replies MUST use `kind:10`, only when the intention is to create a hidden thread that isn't part of the normal flow of the chat (although clients are free to display those by default too).
 `kind:10` SHOULD use NIP-10 markers, just like `kind:12`.
 - *join request* (`kind:9021`)
 Any user can send one of these events to the relay in order to be automatically or manually added to the group. If the group is `open` the relay will automatically issue a `kind:9000` in response adding this user. Otherwise group admins may choose to query for these requests and act upon them.
 ```js
 {
  "kind": 9021,
  "content": "optional reason",
  "tags": [
    ["h", "<group-id>"]
  ]
 }
 ```
 - *moderation events* (`kinds:9000-9020`) (optional)
 Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action. The relay may discard the event after taking action or keep it as a moderation log.
 ```js
 {
  "kind": 90xx,
  "content": "optional reason",
  "tags": [
    ["h", "<group-id>"],
    ["previous", ...]
  ]
 }
 ```
 Each moderation action uses a different kind and requires different arguments, which are given as tags. These are defined in the following table:
 | kind | name                | tags                                      |
 | ---  | ---                 | ---                                       |
 | 9000 | `add-user`          | `p` (pubkey hex)                          |
 | 9001 | `remove-user`       | `p` (pubkey hex)                          |
 | 9002 | `edit-metadata`     | `name`, `about`, `picture` (string)       |
 | 9003 | `add-permission`    | `p` (pubkey), `permission` (name)         |
 | 9004 | `remove-permission` | `p` (pubkey), `permission` (name)         |
 | 9005 | `delete-event`      | `e` (id hex)                              |
 | 9006 | `edit-group-status` | `public` or `private`, `open` or `closed` |
 - *group metadata* (`kind:39000`) (optional)
 This event defines the metadata for the group -- basically how clients should display it. It must be generated and signed by the relay in which is found. Relays shouldn't accept these events if they're signed by anyone else.
 If the group is forked and hosted in multiple relays, there will be multiple versions of this event in each different relay and so on.
 ```js
 {
  "kind": 39000,
  "content": "",
  "tags": [
    ["d", "<group-id>"],
    ["name", "Pizza Lovers"],
    ["picture", "https://pizza.com/pizza.png"],
    ["about", "a group for people who love pizza"],
    ["public"], // or ["private"]
    ["open"] // or ["closed"]
  ]
  ...
 }
 ```
 `name`, `picture` and `about` are basic metadata for the group for display purposes. `public` signals the group can be _read_ by anyone, while `private` signals that only AUTHed users can read. `open` signals that anyone can request to join and the request will be automatically granted, while `closed` signals that members must be pre-approved or that requests to join will be manually handled.
 - *group admins* (`kind:39001`) (optional)
 Similar to the group metadata, this event is supposed to be generated by relays that host the group.
 Each admin gets a label that is only used for display purposes, and a list of permissions it has are listed afterwards. These permissions can inform client building UI, but ultimately are evaluated by the relay in order to become effective.
 The list of capabilities, as defined by this NIP, for now, is the following:
 - `add-user`
 - `edit-metadata`
 - `delete-event`
 - `remove-user`
 - `add-permission`
 - `remove-permission`
 - `edit-group-status`
 ```js
 {
  "kind": 39001,
  "content": "list of admins for the pizza lovers group",
  "tags": [
    ["d", "<group-id>"],
    ["p", "<pubkey1-as-hex>", "ceo", "add-user", "edit-metadata", "delete-event", "remove-user"],
    ["p", "<pubkey2-as-hex>", "secretary", "add-user", "delete-event"]
  ]
  ...
 }
 ```
 - *group members* (`kind:39002`) (optional)
 Similar to *group admins*, this event is supposed to be generated by relays that host the group.
 It's a NIP-51-like list of pubkeys that are members of the group. Relays might choose to not to publish this information or to restrict what pubkeys can fetch it.
 ```json
 {
  "kind": 39002,
  "content": "list of members for the pizza lovers group",
  "tags": [
    ["d", "<group-id>"],
    ["p", "<admin1>"],
    ["p", "<member-pubkey1>"],
    ["p", "<member-pubkey2>"],
  ]
 }
 ```
 ## Storing the list of groups a user belongs to
 A definition for kind `10009` was included in [NIP-51](51.md) that allows clients to store the list of groups a user wants to remember being in.
--- a/34.md
+++ b/34.md
@@ -1,102 +0,0 @@
 NIP-34
 ======
 `git` stuff
 -----------
 `draft` `optional`
 This NIP defines all the ways code collaboration using and adjacent to [`git`](https://git-scm.com/) can be done using Nostr.
 ## Repository announcements
 Git repositories are hosted in Git-enabled servers, but their existence can be announced using Nostr events, as well as their willingness to receive patches, bug reports and comments in general.
 ```jsonc
 {
  "kind": 30617,
  "content": "",
  "tags": [
    ["d", "<repo-id>"],
    ["name", "<human-readable project name>"],
    ["description", "brief human-readable project description>"],
    ["web", "<url for browsing>", ...], // a webpage url, if the git server being used provides such a thing
    ["clone", "<url for git-cloning>", ...], // a url to be given to `git clone` so anyone can clone it
    ["relays", "<relay-url>", ...] // relays that this repository will monitor for patches and issues
  ]
 }
 ```
 The tags `web`, `clone`, `relays` can have multiple values.
 Except `d`, all tags are optional.
 ## Patches
 Patches can be sent by anyone to any repository. Patches to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch events SHOULD include an `a` tag pointing to that repository's announcement address.
 ```jsonc
 {
  "kind": 1617,
  "content": "<patch>", // contents of <git format-patch>
  "tags": [
    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
    ["p", "<repository-owner>"],
    ["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
    // for the first patch in a thread or series
    ["t", "root"],
    // optional tags for when it is desirable that the merged patch has a stable commit id
    // these fields are necessary for ensuring that the commit resulting from applying a patch
    // has the same id as it had in the proposer's machine -- all these tags can be omitted
    // if the maintainer doesn't care about these things
    ["commit", "<current-commit-id>"],
    ["parent-commit", "<parent-commit-id>"],
    ["commit-pgp-sig", "-----BEGIN PGP SIGNATURE-----..."], // empty string for unsigned commit
    ["committer", "<name>", "<email>", "<timestamp>", "<timezone offset in minutes>"],
  ]
 }
 ```
 ## Issues
 Issues are Markdown text that is just human-readable conversational threads related to the repository: bug reports, feature requests, questions or comments of any kind. Like patches, these SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag.
 ```jsonc
 {
  "kind": 1621,
  "content": "<markdown text>",
  "tags": [
    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>"],
    ["p", "<repository-owner>"]
  ]
 }
 ```
 ## Replies
 Replies are also Markdown text. The difference is that they MUST be issued as replies to either a `kind:1621` _issue_ or a `kind:1617` _patch_ event. The threading of replies and patches should follow NIP-10 rules.
 ```jsonc
 {
  "kind": 1622,
  "content": "<markdown text>",
  "tags": [
    ["a", "30617:<base-repo-owner-pubkey>:<base-repo-id>", "<relay-url>"],
    ["e", "<issue-or-patch-id-hex>", "", "root"],
    // other "e" and "p" tags should be applied here when necessary, following the threading rules of NIP-10
    ["p", "<patch-author-pubkey-hex>", "", "mention"],
    ["e", "<previous-reply-id-hex>", "", "reply"],
    // ...
  ]
 }
 ```
 ## Possible things to be added later
 - "status" kind (for letting people know a patch was merged or an issue was fixed or won't be fixed)
 - "branch merge" kind (specifying a URL from where to fetch the branch to be merged)
 - "cover letter" kind (to which multiple patches can refer and serve as a unifying layer to them)
 - inline file comments kind (we probably need one for patches and a different one for merged files)
--- a/50.md
+++ b/50.md
@@ -47,7 +47,3 @@ Relays SHOULD exclude spam from search results by default if they support some f
 Relay MAY support these extensions:
 - `include:spam` - turn off spam filtering, if it was enabled by default
 - `domain:<domain>` - include only events from users whose valid nip05 domain matches the domain
 - `language:<two letter ISO 639-1 language code>` - include only events of a specified language
 - `sentiment:<negative/neutral/positive>` - include only events of a specific sentiment
 - `nsfw:<true/false>` - include or exclude nsfw events (default: true)
--- a/51.md
+++ b/51.md
@@ -29,8 +29,6 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
 | Public chats   | 10005 | [NIP-28](28.md) chat channels the user is in                | `"e"` (kind:40 channel definitions)                                               |
 | Blocked relays | 10006 | relays clients should never connect to                      | `"relay"` (relay URLs)                                                            |
 | Search relays  | 10007 | relays clients should use when performing search queries    | `"relay"` (relay URLs)                                                            |
 | Wiki relays    | 10008 | relays clients should use to read/write wiki entries        | `"relay"` (relay URLs)                                                            |
 | Simple groups  | 10009 | [NIP-29](29.md) groups the user is in                       | `"group"` ([NIP-29](29.md) group ids + mandatory relay URL)                       |
 | Interests      | 10015 | topics a user may be interested in and pointers             | `"t"` (hashtags) and `"a"` (kind:30015 interest set)                              |
 | Emojis         | 10030 | user preferred emojis and pointers to emoji sets            | `"emoji"` (see [NIP-30](30.md)) and `"a"` (kind:30030 emoji set)                  |
--- a/54.md
+++ b/54.md
@@ -0,0 +1,80 @@
 NIP-54
 ======
 Podcasts
 --------
 `draft` `optional`
 This NIP defines how podcast episodes can be fetched from relays. It's intended to fit easily into existing podcast players.
 ## Rationale
 RSS feeds are great, but they have some problems that are solved by moving feeds from RSS URLs to multiple Nostr events, one for each episode:
 - they depend on a URL and that is hard for most people, so podcasters tend to use service providers that can
   - charge money -- which isn't a bad thing per se but it turns out that with a Nostr-native podcast feed protocol it would be much simpler to host feeds and infinitely cheaper to host the media, so the ecosystem could be more decentralized
   - seal them into their walled gardens (like Spotify has been doing), slowly turning a previously open ecosystem into a centralized system captured by big corporations
   - censor podcasters and prevent them from migrating (on Nostr this wouldn't be a problem even if a relay banned someone as moving to other relays would be trivial as long as the podcaster held their key and podcast clients could easily discover the new relay URLs)
 - they can only be loaded in full, with no pagination or filtering of any kind, which means that
   - the sync process in normal RSS clients is slow and cumbersome (which also nudges people into using centralized solutions)
     - this has also led to the creation of broken schemes like [Podping](https://podping.org/), which wouldn't be necessary in a Nostr-native podcast feed
   - It's impossible to reference a single episode directly (since it only exists as a member in the full RSS list of episodes), this means there is no way to share a podcast episode with friends or on social media, so people tend to share links to centralized platforms or to YouTube videos of the same podcast content, which is an antipattern
 - they cannot be interacted with in any way: listeners cannot "like" or comment or signal that they have listened to the episode, which is also another factor in the push towards centralized closed platforms: better analytics and insights and possibilities of engagement with the public
 ## Event definitions
 ### Podcast Profile
 Podcasts have their own key and their own [NIP-01](01.md) `kind:0` profile, but with a tag `["type", "podcast"]` that can be used to signal that they have podcast episodes published.
 ### Podcast Episodes
 Podcast episodes are `kind:54` with some tags:
 ```jsonc
 {
  "id": "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d",
  "pubkey": "79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798",
  "kind": 54,
  "created_at": 1700682555,
  "tags": [
    ["title", "<episode title>"],
    ["image", "<optional episode image>"],
    ["description", "<a brief description>"],
    ["audio", "https://.../", "<optional_media_type>"], // can be specified multiple times
    ["t", "<optional tag>"], // can be specified multiple times
    ["alt", "<optional NIP-31 short description for displaying in incompatible clients>"]
  ],
  "content": "<markdown content (or what is supported in RSS feeds content nowadays?)>",
  "sig": "...",
 }
 ```
 ### Podcast Comments
 These are normal text comments like `kind:1`, but specific for podcast episodes.
 ```jsonc
 {
  "id": "606f6c703f04c70806a5c2830e3853bd83c44985b1f282a070ba894add3724b0",
  "pubkey": "b2c5d5bf69d14d35c25fa47d5c67896b13394136734065a371c5bf2c62f905d2",
  "kind": 55,
  "created_at": 1700682556,
  "tags": [
    ["e", "55807e7d5cd90d0303d7dce7397f996fdbaed8697903f326c7cf8ad999b9de3d"],
  ],
  "content": "<plain text content>",
  "sig": "...",
 }
 ```
 (It's unclear if it's best to use this or a generic kind for commenting on stuff that isn't `kind:1`.)
 ### Reactions (likes), zaps and reposts
 These work normally according to their own NIPs.
 ### To be added:
 - "read" events, signaling that a user has listened to a given podcast, perhaps just use https://github.com/nostr-protocol/nips/pull/933
--- a/96.md
+++ b/96.md
@@ -82,7 +82,14 @@ it must use the "api_url" field instead.
 ### List of Supporting File Storage Servers
-See https://github.com/aljazceru/awesome-nostr#nip-96-file-storage-servers.
+| Name          | Domain                    |
 | ------------- | ------------------------- |
 | nostrcheck.me | https://nostrcheck.me     |
 | nostrage      | https://nostrage.com      |
 | sove          | https://sove.rent         |
 | nostr.build   | https://nostr.build       |
 | sovbit        | https://files.sovbit.host |
 | void.cat      | https://void.cat          |
 ## Upload
--- a/BREAKING.md
+++ b/BREAKING.md
@@ -5,7 +5,6 @@ reverse chronological order.
 | Date        | Commit    | NIP      | Change |
 | ----------- | --------- | -------- | ------ |
 | 2024-02-25  | [4a171cb0](https://github.com/nostr-protocol/nips/commit/4a171cb0) | [NIP-18](18.md) | quote repost should use `q` tag |
 | 2024-02-16  | [cbec02ab](https://github.com/nostr-protocol/nips/commit/cbec02ab) | [NIP-49](49.md) | Password first normalized to NFKC |
 | 2024-02-15  | [afbb8dd0](https://github.com/nostr-protocol/nips/commit/afbb8dd0) | [NIP-39](39.md) | PGP identity was removed |
 | 2024-02-07  | [d3dad114](https://github.com/nostr-protocol/nips/commit/d3dad114) | [NIP-46](46.md) | Connection token format was changed |
--- a/README.md
+++ b/README.md
@@ -45,11 +45,9 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 - [NIP-26: Delegated Event Signing](26.md)
 - [NIP-27: Text Note References](27.md)
 - [NIP-28: Public Chat](28.md)
 - [NIP-29: Relay-based Groups](29.md)
 - [NIP-30: Custom Emoji](30.md)
 - [NIP-31: Dealing with Unknown Events](31.md)
 - [NIP-32: Labeling](32.md)
 - [NIP-34: `git` stuff](34.md)
 - [NIP-36: Sensitive Content](36.md)
 - [NIP-38: User Statuses](38.md)
 - [NIP-39: External Identities in Profiles](39.md)
@@ -94,10 +92,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `6`           | Repost                     | [18](18.md)              |
 | `7`           | Reaction                   | [25](25.md)              |
 | `8`           | Badge Award                | [58](58.md)              |
 | `9`           | Group Chat Message         | [29](29.md)              |
 | `10`          | Group Chat Threaded Reply  | [29](29.md)              |
 | `11`          | Group Thread               | [29](29.md)              |
 | `12`          | Group Thread Reply         | [29](29.md)              |
 | `13`          | Seal                       | [59](59.md)              |
 | `16`          | Generic Repost             | [18](18.md)              |
 | `40`          | Channel Creation           | [28](28.md)              |
@@ -111,9 +105,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `1059`        | Gift Wrap                  | [59](59.md)              |
 | `1063`        | File Metadata              | [94](94.md)              |
 | `1311`        | Live Chat Message          | [53](53.md)              |
 | `1617`        | Patches                    | [34](34.md)              |
 | `1621`        | Issues                     | [34](34.md)              |
 | `1622`        | Replies                    | [34](34.md)              |
 | `1971`        | Problem Tracker            | [nostrocket][nostrocket] |
 | `1984`        | Reporting                  | [56](56.md)              |
 | `1985`        | Label                      | [32](32.md)              |
@@ -121,7 +112,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `5000`-`5999` | Job Request                | [90](90.md)              |
 | `6000`-`6999` | Job Result                 | [90](90.md)              |
 | `7000`        | Job Feedback               | [90](90.md)              |
 | `9000`-`9030` | Group Control Events       | [29](29.md)              |
 | `9041`        | Zap Goal                   | [75](75.md)              |
 | `9734`        | Zap Request                | [57](57.md)              |
 | `9735`        | Zap                        | [57](57.md)              |
@@ -134,7 +124,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `10005`       | Public chats list          | [51](51.md)              |
 | `10006`       | Blocked relays list        | [51](51.md)              |
 | `10007`       | Search relays list         | [51](51.md)              |
 | `10009`       | User groups                | [51](51.md), [29](29.md) |
 | `10015`       | Interests list             | [51](51.md)              |
 | `10030`       | User emoji list            | [51](51.md)              |
 | `10096`       | File storage server list   | [96](96.md)              |
@@ -166,14 +155,12 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
 | `30315`       | User Statuses              | [38](38.md)              |
 | `30402`       | Classified Listing         | [99](99.md)              |
 | `30403`       | Draft Classified Listing   | [99](99.md)              |
 | `30617`       | Repository announcements   | [34](34.md)              |
 | `31922`       | Date-Based Calendar Event  | [52](52.md)              |
 | `31923`       | Time-Based Calendar Event  | [52](52.md)              |
 | `31924`       | Calendar                   | [52](52.md)              |
 | `31925`       | Calendar Event RSVP        | [52](52.md)              |
 | `31989`       | Handler recommendation     | [89](89.md)              |
 | `31990`       | Handler information        | [89](89.md)              |
 | `39000-9`     | Group metadata events      | [29](29.md)              |
 | `34550`       | Community Definition       | [72](72.md)              |
 [nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
@@ -228,10 +215,9 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `bolt11`          | `bolt11` invoice                     | --                   | [57](57.md)                           |
 | `challenge`       | challenge string                     | --                   | [42](42.md)                           |
 | `client`          | name, address                        | relay URL            | [89](89.md)                           |
 | `clone`           | git clone URL                        | --                   | [34](34.md)                           |
 | `content-warning` | reason                               | --                   | [36](36.md)                           |
 | `delegation`      | pubkey, conditions, delegation token | --                   | [26](26.md)                           |
-| `description`     | description                          | --                   | [34](34.md), [57](57.md), [58](58.md) |
+| `description`     | invoice/badge description            | --                   | [57](57.md), [58](58.md)              |
 | `emoji`           | shortcode, image URL                 | --                   | [30](30.md)                           |
 | `encrypted`       | --                                   | --                   | [90](90.md)                           |
 | `expiration`      | unix timestamp (string)              | --                   | [40](40.md)                           |
@@ -240,7 +226,7 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `imeta`           | inline metadata                      | --                   | [92](92.md)                           |
 | `lnurl`           | `bech32` encoded `lnurl`             | --                   | [57](57.md)                           |
 | `location`        | location string                      | --                   | [52](52.md), [99](99.md)              |
-| `name`            | name                                 | --                   | [34](34.md), [58](58.md)              |
+| `name`            | badge name                           | --                   | [58](58.md)                           |
 | `nonce`           | random                               | --                   | [13](13.md)                           |
 | `preimage`        | hash of `bolt11` invoice             | --                   | [57](57.md)                           |
 | `price`           | price                                | currency, frequency  | [99](99.md)                           |
@@ -253,7 +239,6 @@ Please update these lists when proposing NIPs introducing new event kinds.
 | `summary`         | article summary                      | --                   | [23](23.md)                           |
 | `thumb`           | badge thumbnail                      | dimensions in pixels | [58](58.md)                           |
 | `title`           | article title                        | --                   | [23](23.md)                           |
 | `web`             | webpage URL                          | --                   | [34](34.md)                           |
 | `zap`             | pubkey (hex), relay URL              | weight               | [57](57.md)                           |
 ## Criteria for acceptance of NIPs