nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-14 15:59:07 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'nostr-protocol:master' into patch-2

Browse Source
This commit is contained in:
Sepehr Safari 2024-08-11 14:41:32 +03:30 committed by GitHub
commit 010fc579a9
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
23 changed files with 299 additions and 169 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
01.md
View File

@ -143,7 +143,7 @@ All conditions of a filter that are specified must match for an event for it to
A `REQ` message may contain multiple filters. In this case, events that match any of the filters are to be returned, i.e., multiple filters are to be interpreted as `||` conditions.
The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data.
The `limit` property of a filter is only valid for the initial query and MUST be ignored afterwards. When `limit: n` is present it is assumed that the events returned in the initial query will be the last `n` events ordered by the `created_at`. Newer events should appear first, and in the case of ties the event with the lowest id (first in lexical order) should be first. It is safe to return less events than `limit` specifies, but it is expected that relays do not return (much) more events than requested so clients don't get unnecessarily overwhelmed by data.
### From relay to client: sending events and notices

4
07.md
View File

@ -24,6 +24,10 @@ async window.nostr.nip44.encrypt(pubkey, plaintext): string // returns ciphertex
async window.nostr.nip44.decrypt(pubkey, ciphertext): string // takes ciphertext as specified in nip-44
```
### Recommendation to Extension Authors
To make sure that the `window.nostr` is available to nostr clients on page load, the authors who create Chromium and Firefox extensions should load their scripts by specifying `"run_at": "document_end"` in the extension's manifest.
### Implementation
See https://github.com/aljazceru/awesome-nostr#nip-07-browser-extensions.

8
09.md
View File

@ -6,9 +6,7 @@ Event Deletion
`draft` `optional`
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 `a` tags intended for deletion.
A special event with kind `5`, meaning "deletion" is defined as having a list of one or more `e` or `a` tags, each referencing an event the author is requesting to be deleted. Deletion requests SHOULD include a `k` tag for the kind of each event being deleted.
The event's `content` field MAY contain a text note describing the reason for the deletion.
@ -21,7 +19,9 @@ For example:
"tags": [
["e", "dcd59..464a2"],
["e", "968c5..ad7a4"],
["a", "<kind>:<pubkey>:<d-identifier>"]
["a", "<kind>:<pubkey>:<d-identifier>"],
["k", "1"],
["k", "30023"]
],
"content": "these posts were published by accident",
...other fields

14
15.md
View File

@ -6,7 +6,7 @@ Nostr Marketplace
`draft` `optional`
Based on https://github.com/lnbits/Diagon-Alley.
Based on [Diagon-Alley](https://github.com/lnbits/Diagon-Alley).
Implemented in [NostrMarket](https://github.com/lnbits/nostrmarket) and [Plebeian Market](https://github.com/PlebeianTech/plebeian-market).
@ -139,7 +139,7 @@ Fields that are not self-explanatory:
## Checkout events
All checkout events are sent as JSON strings using ([NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md)).
All checkout events are sent as JSON strings using [NIP-04](04.md).
The `merchant` and the `customer` can exchange JSON messages that represent different actions. Each `JSON` message `MUST` have a `type` field indicating the what the JSON represents. Possible types:
@ -150,7 +150,7 @@ The `merchant` and the `customer` can exchange JSON messages that represent diff
| 2 | Merchant | Order Status Update |
### Step 1: `customer` order (event)
The below JSON goes in content of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md).
The below JSON goes in content of [NIP-04](04.md).
```json
{
@ -182,7 +182,7 @@ _Open_: is `contact.nostr` required?
Sent back from the merchant for payment. Any payment option is valid that the merchant can check.
The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md).
The below JSON goes in `content` of [NIP-04](04.md).
`payment_options`/`type` include:
@ -217,7 +217,7 @@ The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/n
Once payment has been received and processed.
The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md).
The below JSON goes in `content` of [NIP-04](04.md).
```json
{
@ -231,7 +231,7 @@ The below JSON goes in `content` of [NIP-04](https://github.com/nostr-protocol/n
## Customize Marketplace
Create a customized user experience using the `naddr` from [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md#shareable-identifiers-with-extra-metadata). The use of `naddr` enables easy sharing of marketplace events while incorporating a rich set of metadata. This metadata can include relays, merchant profiles, and more. Subsequently, it allows merchants to be grouped into a market, empowering the market creator to configure the marketplace's user interface and user experience, and share that marketplace. This customization can encompass elements such as market name, description, logo, banner, themes, and even color schemes, offering a tailored and unique marketplace experience.
Create a customized user experience using the `naddr` from [NIP-19](19.md#shareable-identifiers-with-extra-metadata). The use of `naddr` enables easy sharing of marketplace events while incorporating a rich set of metadata. This metadata can include relays, merchant profiles, and more. Subsequently, it allows merchants to be grouped into a market, empowering the market creator to configure the marketplace's user interface and user experience, and share that marketplace. This customization can encompass elements such as market name, description, logo, banner, themes, and even color schemes, offering a tailored and unique marketplace experience.
### Event `30019`: Create or update marketplace UI/UX
@ -331,7 +331,7 @@ Another thing that can happen is - if bids happen very close to the end date of
## Customer support events
Customer support is handled over whatever communication method was specified. If communicating via nostr, NIP-04 is used https://github.com/nostr-protocol/nips/blob/master/04.md.
Customer support is handled over whatever communication method was specified. If communicating via nostr, [NIP-04](04.md) is used.
## Additional

3
19.md
View File

@ -34,8 +34,8 @@ These are the possible bech32 prefixes with `TLV`:
- `nprofile`: a nostr profile
- `nevent`: a nostr event
- `nrelay`: a nostr relay
- `naddr`: a nostr _replaceable event_ coordinate
- `nrelay`: a nostr relay (deprecated)
These possible standardized `TLV` types are indicated here:
@ -43,7 +43,6 @@ These possible standardized `TLV` types are indicated here:
- depends on the bech32 prefix:
- for `nprofile` it will be the 32 bytes of the profile public key
- for `nevent` it will be the 32 bytes of the event id
- for `nrelay`, this is the relay URL
- for `naddr`, it is the identifier (the `"d"` tag) of the event being referenced. For non-parameterized replaceable events, use an empty string.
- `1`: `relay`
- for `nprofile`, `nevent` and `naddr`, _optionally_, a relay in which the entity (profile or event) is more likely to be found, encoded as ascii

2
21.md
View File

@ -10,7 +10,7 @@ This NIP standardizes the usage of a common URI scheme for maximum interoperabil
The scheme is `nostr:`.
The identifiers that come after are expected to be the same as those defined in [NIP-19](https://github.com/nostr-protocol/nips/blob/master/19.md) (except `nsec`).
The identifiers that come after are expected to be the same as those defined in [NIP-19](19.md) (except `nsec`).
## Examples

1
24.md
View File

@ -40,4 +40,5 @@ tags
These tags may be present in multiple event kinds. Whenever a different meaning is not specified by some more specific NIP, they have the following meanings:
- `r`: a web URL the event is referring to in some way
- `i`: an external id the event is referring to in some way - see [NIP-73](73.md)
- `title`: name of [NIP-51](51.md) sets, [NIP-52](52.md) calendar event, [NIP-53](53.md) live event or [NIP-99](99.md) listing

20
25.md
View File

@ -52,6 +52,26 @@ func make_like_event(pubkey: String, privkey: String, liked: NostrEvent) -> Nost
}
```
Reactions to a website
---------------------
If the target of the reaction is a website, the reaction MUST be a `kind 17` event and MUST include an `r` tag with the website's URL.
```json
{
"kind": 17,
"content": "⭐",
"tags": [
["r", "https://example.com/"]
],
...other fields
}
```
URLs SHOULD be [normalized](https://datatracker.ietf.org/doc/html/rfc3986#section-6), so that reactions to the same website are not omitted from queries.
A fragment MAY be attached to the URL, to react to a section of the page.
It should be noted that a URL with a fragment is not considered to be the same URL as the original.
Custom Emoji Reaction
---------------------

19
32.md
View File

@ -6,10 +6,9 @@ Labeling
`draft` `optional`
A label is a `kind 1985` event that is used to label other entities. This supports a number of use cases,
including distributed moderation, collection management, license assignment, and content classification.
This NIP defines two new indexable tags to label events and a new event kind (`kind:1985`) to attach those labels to existing events. This supports several use cases, including distributed moderation, collection management, license assignment, and content classification.
This NIP introduces two new tags:
New Tags:
- `L` denotes a label namespace
- `l` denotes a label
@ -129,6 +128,20 @@ is labeling their note as being related to Milan, Italy using ISO 3166-2.
}
```
Author is labeling their note language as English using ISO-639-1.
```json
{
"kind": 1,
"tags": [
["L", "ISO-639-1"],
["l", "en", "ISO-639-1"]
],
"content": "English text",
...
}
```
Other Notes
-----------

32
34.md
View File

@ -35,6 +35,36 @@ The `r` tag annotated with the `"euc"` marker should be the commit ID of the ear
Except `d`, all tags are optional.
## Repository state announcements
An optional source of truth for the state of branches and tags in a repository.
```jsonc
{
"kind": 30618,
"content": "",
"tags": [
["d", "<repo-id>"], // matches the identifier in the coresponding repository announcement
["refs/<heads|tags>/<branch-or-tag-name>","<commit-id>"]
["HEAD", "ref: refs/heads/<branch-name>"]
]
}
```
The `refs` tag may appear multiple times, or none.
If no `refs` tags are present, the author is no longer tracking repository state using this event. This approach enables the author to restart tracking state at a later time unlike [NIP-09](09.md) deletion.
The `refs` tag can be optionally extended to enable clients to identify how many commits ahead a ref is:
```jsonc
{
"tags": [
["refs/<heads|tags>/<branch-or-tag-name>", "<commit-id>", "<shorthand-parent-commit-id>", "<shorthand-grandparent>", ...],
]
}
```
## 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.
@ -53,7 +83,7 @@ The first patch revision in a patch revision SHOULD include a NIP-10 `e` `reply`
["p", "<repository-owner>"],
["p", "<other-user>"], // optionally send the patch to another user to bring it to their attention
["t", "root"], // ommited for additional patches in a series
["t", "root"], // omitted for additional patches in a series
// for the first patch in a revision
["t", "root-revision"],

4
39.md
View File

@ -12,9 +12,11 @@ Nostr protocol users may have other online identities such as usernames, profile
## `i` tag on a metadata event
A new optional `i` tag is introduced for `kind 0` metadata event contents in addition to name, about, picture fields as included in [NIP-01](https://github.com/nostr-protocol/nips/blob/master/01.md):
A new optional `i` tag is introduced for `kind 0` metadata event defined in [NIP-01](01.md):
```json
{
"id": <id>,
"pubkey": <pubkey>,
"tags": [
["i", "github:semisol", "9721ce4ee4fceb91c9711ca2a6c9a5ab"],
["i", "twitter:semisol_public", "1619358434134196225"],

8
45.md
View File

@ -16,14 +16,14 @@ Some queries a client may want to execute against connected relays are prohibiti
This NIP defines the verb `COUNT`, which accepts a subscription id and filters as specified in [NIP 01](01.md) for the verb `REQ`. Multiple filters are OR'd together and aggregated into a single count result.
```json
```
["COUNT", <subscription_id>, <filters JSON>...]
```
Counts are returned using a `COUNT` response in the form `{"count": <integer>}`. Relays may use probabilistic counts to reduce compute requirements.
In case a relay uses probabilistic counts, it MAY indicate it in the response with `approximate` key i.e. `{"count": <integer>, "approximate": <true|false>}`.
```json
```
["COUNT", <subscription_id>, {"count": <integer>}]
```
@ -33,14 +33,14 @@ Whenever the relay decides to refuse to fulfill the `COUNT` request, it MUST ret
### Followers count
```json
```
["COUNT", <subscription_id>, {"kinds": [3], "#p": [<pubkey>]}]
["COUNT", <subscription_id>, {"count": 238}]
```
### Count posts and reactions
```json
```
["COUNT", <subscription_id>, {"kinds": [1, 7], "authors": [<pubkey>]}]
["COUNT", <subscription_id>, {"count": 5}]
```

8
46.md
View File

@ -28,7 +28,7 @@ The remote signer would provide a connection token in the form:
bunker://<remote-user-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
```
This token is pasted into the client by the user and the client then uses the details to connect to the remote signer via the specified relay(s).
This token is pasted into the client by the user and the client then uses the details to connect to the remote signer via the specified relay(s). Optional secret can be used for single successfully established connection only, remote signer SHOULD ignore new attempts to establish connection with old optional secret.
### Direct connection initiated by the client
@ -101,7 +101,7 @@ nostrconnect://<local-keypair-pubkey>?relay=<wss://relay-to-connect-on>&metadata
}
```
The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md) encrypted and has the following structure:
The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted and has the following structure:
```json
{
@ -148,7 +148,7 @@ The `connect` method may be provided with `optional_requested_permissions` for u
}
```
The `content` field is a JSON-RPC-like message that is [NIP-04](https://github.com/nostr-protocol/nips/blob/master/04.md) encrypted and has the following structure:
The `content` field is a JSON-RPC-like message that is [NIP-04](04.md) encrypted and has the following structure:
```json
{
@ -224,4 +224,4 @@ Coming soon...
## References
- [NIP-04 - Encryption](https://github.com/nostr-protocol/nips/blob/master/04.md)
- [NIP-04 - Encryption](04.md)

2
47.md
View File

@ -38,7 +38,7 @@ a plaintext string with the supported commands, space-separated, eg. `pay_invoic
Both the request and response events SHOULD contain one `p` tag, containing the public key of the **wallet service** if this is a request, and the public key of the **user** if this is a response. The response event SHOULD contain an `e` tag with the id of the request event it is responding to.
Optionally, a request can have an `expiration` tag that has a unix timestamp in seconds. If the request is received after this timestamp, it should be ignored.
The content of requests and responses is encrypted with [NIP04](https://github.com/nostr-protocol/nips/blob/master/04.md), and is a JSON-RPCish object with a semi-fixed structure:
The content of requests and responses is encrypted with [NIP04](04.md), and is a JSON-RPCish object with a semi-fixed structure:
Request:
```jsonc

1
51.md
View File

@ -32,6 +32,7 @@ For example, _mute list_ can contain the public keys of spammers and bad actors
| 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) |
| DM relays | 10050 | Where to receive [NIP-17](17.md) direct messages | `"relay"` (see [NIP-17](17.md)) |
| Good wiki authors | 10101 | [NIP-54](54.md) user recommended wiki authors | `"p"` (pubkeys) |
| Good wiki relays | 10102 | [NIP-54](54.md) relays deemed to only host useful articles | `"relay"` (relay URLs) |

9
52.md
View File

@ -90,9 +90,12 @@ The list of tags are as follows:
* `end` (optional) exclusive end Unix timestamp in seconds. If omitted, the calendar event ends instantaneously.
* `start_tzid` (optional) time zone of the start timestamp, as defined by the IANA Time Zone Database. e.g., `America/Costa_Rica`
* `end_tzid` (optional) time zone of the end timestamp, as defined by the IANA Time Zone Database. e.g., `America/Costa_Rica`. If omitted and `start_tzid` is provided, the time zone of the end timestamp is the same as the start timestamp.
* `summary` (optional) brief description of the calendar event
* `image` (optional) url of an image to use for the event
* `location` (optional, repeated) location of the calendar event. e.g. address, GPS coordinates, meeting room name, link to video call
* `g` (optional) [geohash](https://en.wikipedia.org/wiki/Geohash) to associate calendar event with a searchable physical location
* `p` (optional, repeated) 32-bytes hex pubkey of a participant, optional recommended relay URL, and participant's role in the meeting
* `l` (optional, repeated) label to categorize calendar event. e.g. `audiospace` to denote a scheduled event from a live audio space implementation such as cornychat.com
* `t` (optional, repeated) hashtag to categorize calendar event
* `r` (optional, repeated) references / links to web pages, documents, video calls, recorded videos, etc.
@ -110,6 +113,8 @@ The following tags are deprecated:
["d", "<UUID>"],
["title", "<title of calendar event>"],
["summary", "<brief description of the calendar event>"],
["image", "<string with image URI>"],
// Timestamps
["start", "<Unix timestamp in seconds>"],
@ -126,6 +131,10 @@ The following tags are deprecated:
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>", "<role>"],
// Labels (example using com.cornychat namespace denoting the event as an audiospace)
["L", "com.cornychat"],
["l", "audiospace", "com.cornychat"],
// Hashtags
["t", "<tag>"],
["t", "<tag>"],

2
70.md
View File

@ -12,7 +12,7 @@ A protected event is an event that can only be published to relays by its author
The default behavior of a relay MUST be to reject any event that contains `["-"]`.
Relays that want to accept such events MUST first require that the client perform the [NIP-42](https://github.com/nostr-protocol/nips/blob/master/42.md) `AUTH` flow and then check if the authenticated client has the same pubkey as the event being published and only accept the event in that case.
Relays that want to accept such events MUST first require that the client perform the [NIP-42](42.md) `AUTH` flow and then check if the authenticated client has the same pubkey as the event being published and only accept the event in that case.
## The tag

45
72.md
View File

@ -6,11 +6,11 @@ Moderated Communities (Reddit Style)
`draft` `optional`
The goal of this NIP is to create moderator-approved public communities around a topic. It defines the replaceable event `kind:34550` to define the community and the current list of moderators/administrators. Users that want to post into the community, simply tag any Nostr event with the community's `a` tag. Moderators issue an approval event `kind:4550` that links the community with the new post.
The goal of this NIP is to enable public communities. It defines the replaceable event `kind:34550` to define the community and the current list of moderators/administrators. Users that want to post into the community, simply tag any Nostr event with the community's `a` tag. Moderators may issue an approval event `kind:4550`.
# Community Definition
`kind:34550` SHOULD include any field that helps define the community and the set of moderators. `relay` tags MAY be used to describe the preferred relay to download requests and approvals.
`Kind:34550` SHOULD include any field that helps define the community and the set of moderators. `relay` tags MAY be used to describe the preferred relay to download requests and approvals. A community definition event's `d` tag MAY double as its name, but if a `name` tag is provided, it SHOULD be displayed instead of the `d` tag.
```jsonc
{
@ -18,6 +18,7 @@ The goal of this NIP is to create moderator-approved public communities around a
"kind": 34550,
"tags": [
["d", "<community-d-identifier>"],
["name", "<Community name>"],
["description", "<Community description>"],
["image", "<Community image url>", "<Width>x<Height>"],
@ -38,9 +39,9 @@ The goal of this NIP is to create moderator-approved public communities around a
}
```
# New Post Request
# Posting to a community
Any Nostr event can be submitted to a community by anyone for approval. Clients MUST add the community's `a` tag to the new post event in order to be presented for the moderator's approval.
Any Nostr event can be posted to a community. Clients MUST add one or more community `a` tags, each with a recommended relay.
```jsonc
{
@ -53,11 +54,15 @@ Any Nostr event can be submitted to a community by anyone for approval. Clients
}
```
Community management clients MAY filter all mentions to a given `kind:34550` event and request moderators to approve each submission. Moderators MAY delete his/her approval of a post at any time using event deletions (See [NIP-09](09.md)).
# Moderation
# Post Approval by moderators
Anyone may issue an approval event to express their opinion that a post is appropriate for a community. Clients MAY choose which approval events to honor, but SHOULD at least use ones published by the group's defined moderators.
The post-approval event MUST include `a` tags of the communities the moderator is posting into (one or more), the `e` tag of the post and `p` tag of the author of the post (for approval notifications). The event SHOULD also include the stringified `post request` event inside the `.content` ([NIP-18-style](18.md)) and a `k` tag with the original post's event kind to allow filtering of approved posts by kind.
An approval event MUST include one or more community `a` tags, an `e` or `a` tag pointing to the post, and the `p` tag of the author of the post (for approval notifications). `a` tag prefixes can be used to disambiguate between community and replaceable event pointers (community `a` tags always begin with `34550`).
The event SHOULD also include the JSON-stringified `post request` event inside the `.content`, and a `k` tag with the original post's event kind to allow filtering of approved posts by kind.
Moderators MAY delete their approval of a post at any time using NIP 09 event deletions.
```jsonc
{
@ -76,26 +81,16 @@ The post-approval event MUST include `a` tags of the communities the moderator i
It's recommended that multiple moderators approve posts to avoid deleting them from the community when a moderator is removed from the owner's list. In case the full list of moderators must be rotated, the new moderator set must sign new approvals for posts in the past or the community will restart. The owner can also periodically copy and re-sign of each moderator's approval events to make sure posts don't disappear with moderators.
Post Approvals of replaceable events can be created in three ways: (i) by tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the replaceable event; (ii) by tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and (iii) by tagging the replaceable event with both its `e` and `a` tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI. Since relays are instructed to delete old versions of a replaceable event, the `.content` of an `e`-approval MUST have the specific version of the event or Clients might not be able to find that version of the content anywhere.
Approvals of replaceable events can be created in three ways:
Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be included in all `34550:*` `a` tags.
1. By tagging the replaceable event as an `e` tag if moderators want to approve each individual change to the replaceable event
2. By tagging the replaceable event as an `a` tag if the moderator authorizes the replaceable event author to make changes without additional approvals and
3. By tagging the replaceable event with both its `e` and `a` tag which empowers clients to display the original and updated versions of the event, with appropriate remarks in the UI.
# Displaying
Since relays are instructed to delete old versions of a replaceable event, the `content` of an approval using an `e` tag MUST have the specific version of the event or clients might not be able to find that version of the content anywhere.
Community clients SHOULD display posts that have been approved by at least 1 moderator or by the community owner.
Clients SHOULD evaluate any non-`34550:*` `a` tag as posts to be approved for all `34550:*` `a` tags.
The following filter displays the approved posts.
# Cross-posting
```json
[
"REQ",
"_",
{
"authors": ["<owner-pubkey>", "<moderator1-pubkey>", "<moderator2-pubkey>", "<moderator3-pubkey>", ...],
"kinds": [4550],
"#a": ["34550:<Community event author pubkey>:<d-identifier of the community>"],
}
]
```
Clients MAY hide approvals by blocked moderators at the user's request.
Clients MAY support cross-posting between communities by posting a NIP 18 `kind 6` or `kind 16` repost to one or more communities using `a` tags as described above. The `content` of the repost MUST be the original event, not the approval event.

48
73.md Normal file
View File

@ -0,0 +1,48 @@
NIP-73
======
External Content IDs
-------------------------
`draft` `optional`
There are certain established global content identifiers that would be useful to reference in nostr events so that clients can query all events assosiated with these ids.
- Book [ISBNs](https://en.wikipedia.org/wiki/ISBN)
- Podcast [GUIDs](https://podcastnamespace.org/tag/guid)
- Movie [ISANs](https://en.wikipedia.org/wiki/International_Standard_Audiovisual_Number)
Since the `i` tag is already used for similar references in kind-0 metadata events it makes sense to use it for these content ids as well.
## Supported IDs
### Books:
- Book ISBN: `["i", "isbn:9780765382030"]` - https://isbnsearch.org/isbn/9780765382030
Book ISBNs MUST be referenced _**without hyphens**_ as many book search APIs return the ISBNs without hyphens. Removing hypens from ISBNs is trivial, whereas adding the hyphens back in is non-trivial requiring a library.
### Podcasts:
- Podcast RSS Feed GUID: `["i", "podcast:guid:c90e609a-df1e-596a-bd5e-57bcc8aad6cc"]` - https://podcastindex.org/podcast/c90e609a-df1e-596a-bd5e-57bcc8aad6cc
- Podcast RSS Item GUID: `["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f"]`
- Podcast RSS Publisher GUID: `["i", "podcast:publisher:guid:18bcbf10-6701-4ffb-b255-bc057390d738"]`
### Movies:
- Movie ISAN: `["i", "isan:0000-0000-401A-0000-7"]` - https://web.isan.org/public/en/isan/0000-0000-401A-0000-7
Movie ISANs SHOULD be referenced _**without the version part**_ as the versions / edits of movies are not relevant. More info on ISAN parts here - https://support.isan.org/hc/en-us/articles/360002783131-Records-relations-and-hierarchies-in-the-ISAN-Registry
---
### Optional URL Hints
Each `i` tag MAY have a url hint as the second argument to redirect people to a website if the client isn't opinionated about how to interpret the id:
`["i", "podcast:item:guid:d98d189b-dc7b-45b1-8720-d4b98690f31f", https://fountain.fm/episode/z1y9TMQRuqXl2awyrQxg]`
`["i", "isan:0000-0000-401A-0000-7", https://www.imdb.com/title/tt0120737]`

2
96.md
View File

@ -301,7 +301,7 @@ Example Response:
// ...other metadata
]
"content": "haha funny meme", // caption
"created_at": 1715691130 // upload timestmap
"created_at": 1715691130 // upload timestamp
},
...
]

8
99.md
View File

@ -8,9 +8,9 @@ Classified Listings
This NIP defines `kind:30402`: a parameterized replaceable event to describe classified listings that list any arbitrary product, service, or other thing for sale or offer and includes enough structured metadata to make them useful.
The category of classifieds includes a very broad range of physical goods, services, work opportunities, rentals, free giveaways, personals, etc. and is distinct from the more strictly structured marketplaces defined in [NIP-15](https://github.com/nostr-protocol/nips/blob/master/15.md) that often sell many units of specific products through very specific channels.
The category of classifieds includes a very broad range of physical goods, services, work opportunities, rentals, free giveaways, personals, etc. and is distinct from the more strictly structured marketplaces defined in [NIP-15](15.md) that often sell many units of specific products through very specific channels.
The structure of these events is very similar to [NIP-23](https://github.com/nostr-protocol/nips/blob/master/23.md) long-form content events.
The structure of these events is very similar to [NIP-23](23.md) long-form content events.
### Draft / Inactive Listings
@ -26,8 +26,8 @@ The `.pubkey` field of these events are treated as the party creating the listin
### Metadata
- For "tags"/"hashtags" (i.e. categories or keywords of relevance for the listing) the `"t"` event tag should be used, as per [NIP-12](https://github.com/nostr-protocol/nips/blob/master/12.md).
- For images, whether included in the markdown content or not, clients SHOULD use `image` tags as described in [NIP-58](https://github.com/nostr-protocol/nips/blob/master/58.md). This allows clients to display images in carousel format more easily.
- For "tags"/"hashtags" (i.e. categories or keywords of relevance for the listing) the `"t"` event tag should be used, as per [NIP-12](12.md).
- For images, whether included in the markdown content or not, clients SHOULD use `image` tags as described in [NIP-58](58.md). This allows clients to display images in carousel format more easily.
The following tags, used for structured metadata, are standardized and SHOULD be included. Other tags may be added as necessary.

4
BREAKING.md
View File

@ -5,6 +5,10 @@ reverse chronological order.
| Date | Commit | NIP | Change |
| ----------- | --------- | -------- | ------ |
| 2024-07-31 | [3ea2f1a4](https://github.com/nostr-protocol/nips/commit/3ea2f1a4) | [NIP-45](45.md) | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) was reverted |
| 2024-07-30 | [444ad28d](https://github.com/nostr-protocol/nips/commit/444ad28d) | [NIP-45](45.md) | NIP-45 was deprecated |
| 2024-07-26 | [ecee40df](https://github.com/nostr-protocol/nips/commit/ecee40df) | [NIP-19](19.md) | `nrelay` was deprecated |
| 2024-07-23 | [0227a2cd](https://github.com/nostr-protocol/nips/commit/0227a2cd) | [NIP-01](01.md) | events should be sorted by id after created_at |
| 2024-06-06 | [58e94b20](https://github.com/nostr-protocol/nips/commit/58e94b20) | [NIP-25](25.md) | [8073c848](https://github.com/nostr-protocol/nips/commit/8073c848) was reverted |
| 2024-06-06 | [a6dfc7b5](https://github.com/nostr-protocol/nips/commit/a6dfc7b5) | [NIP-55](55.md) | NIP number was changed |
| 2024-05-25 | [5d1d1c17](https://github.com/nostr-protocol/nips/commit/5d1d1c17) | [NIP-71](71.md) | 'aes-256-gcm' tag was removed |

222
README.md
View File

@ -77,6 +77,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-70: Protected Events](70.md)
- [NIP-71: Video Events](71.md)
- [NIP-72: Moderated Communities](72.md)
- [NIP-73: External Content IDs](73.md)
- [NIP-75: Zap Goals](75.md)
- [NIP-78: Application-specific data](78.md)
- [NIP-84: Highlights](84.md)
@ -89,112 +90,115 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-99: Classified Listings](99.md)
## Event Kinds
| kind | description | NIP |
| ------------- | -------------------------- | ------------------------ |
| `0` | User Metadata | [01](01.md) |
| `1` | Short Text Note | [01](01.md) |
| `2` | Recommend Relay | 01 (deprecated) |
| `3` | Follows | [02](02.md) |
| `4` | Encrypted Direct Messages | [04](04.md) |
| `5` | Event Deletion | [09](09.md) |
| `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) |
| `14` | Direct Message | [17](17.md) |
| `16` | Generic Repost | [18](18.md) |
| `40` | Channel Creation | [28](28.md) |
| `41` | Channel Metadata | [28](28.md) |
| `42` | Channel Message | [28](28.md) |
| `43` | Channel Hide Message | [28](28.md) |
| `44` | Channel Mute User | [28](28.md) |
| `818` | Merge Requests | [54](54.md) |
| `1021` | Bid | [15](15.md) |
| `1022` | Bid confirmation | [15](15.md) |
| `1040` | OpenTimestamps | [03](03.md) |
| `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) |
| `1630`-`1633` | Status | [34](34.md) |
| `1971` | Problem Tracker | [nostrocket][nostrocket] |
| `1984` | Reporting | [56](56.md) |
| `1985` | Label | [32](32.md) |
| `2003` | Torrent | [35](35.md) |
| `2004` | Torrent Comment | [35](35.md) |
| `2022` | Coinjoin Pool | [joinstr][joinstr] |
| `4550` | Community Post Approval | [72](72.md) |
| `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) |
| `9802` | Highlights | [84](84.md) |
| `10000` | Mute list | [51](51.md) |
| `10001` | Pin list | [51](51.md) |
| `10002` | Relay List Metadata | [65](65.md) |
| `10003` | Bookmark list | [51](51.md) |
| `10004` | Communities list | [51](51.md) |
| `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) |
| `10050` | Relay list to receive DMs | [17](17.md) |
| `10096` | File storage server list | [96](96.md) |
| `13194` | Wallet Info | [47](47.md) |
| `21000` | Lightning Pub RPC | [Lightning.Pub][lnpub] |
| `22242` | Client Authentication | [42](42.md) |
| `23194` | Wallet Request | [47](47.md) |
| `23195` | Wallet Response | [47](47.md) |
| `24133` | Nostr Connect | [46](46.md) |
| `27235` | HTTP Auth | [98](98.md) |
| `30000` | Follow sets | [51](51.md) |
| `30001` | Generic lists | [51](51.md) |
| `30002` | Relay sets | [51](51.md) |
| `30003` | Bookmark sets | [51](51.md) |
| `30004` | Curation sets | [51](51.md) |
| `30005` | Video sets | [51](51.md) |
| `30008` | Profile Badges | [58](58.md) |
| `30009` | Badge Definition | [58](58.md) |
| `30015` | Interest sets | [51](51.md) |
| `30017` | Create or update a stall | [15](15.md) |
| `30018` | Create or update a product | [15](15.md) |
| `30019` | Marketplace UI/UX | [15](15.md) |
| `30020` | Product sold as an auction | [15](15.md) |
| `30023` | Long-form Content | [23](23.md) |
| `30024` | Draft Long-form Content | [23](23.md) |
| `30030` | Emoji sets | [51](51.md) |
| `30063` | Release artifact sets | [51](51.md) |
| `30078` | Application-specific Data | [78](78.md) |
| `30311` | Live Event | [53](53.md) |
| `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) |
| `30818` | Wiki article | [54](54.md) |
| `30819` | Redirects | [54](54.md) |
| `31890` | Feed | [NUD: Custom Feeds](https://wikifreedia.xyz/cip-01/97c70a44366a6535c1) |
| `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) |
| `34235` | Video Event | [71](71.md) |
| `34236` | Short-form Portrait Video Event | [71](71.md) |
| `34237` | Video View Event | [71](71.md) |
| `34550` | Community Definition | [72](72.md) |
| `39000-9` | Group metadata events | [29](29.md) |
| kind | description | NIP |
| ------------- | ------------------------------- | -------------------------------------- |
| `0` | User Metadata | [01](01.md) |
| `1` | Short Text Note | [01](01.md) |
| `2` | Recommend Relay | 01 (deprecated) |
| `3` | Follows | [02](02.md) |
| `4` | Encrypted Direct Messages | [04](04.md) |
| `5` | Event Deletion | [09](09.md) |
| `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) |
| `14` | Direct Message | [17](17.md) |
| `16` | Generic Repost | [18](18.md) |
| `17` | Reaction to a website | [25](25.md) |
| `40` | Channel Creation | [28](28.md) |
| `41` | Channel Metadata | [28](28.md) |
| `42` | Channel Message | [28](28.md) |
| `43` | Channel Hide Message | [28](28.md) |
| `44` | Channel Mute User | [28](28.md) |
| `818` | Merge Requests | [54](54.md) |
| `1021` | Bid | [15](15.md) |
| `1022` | Bid confirmation | [15](15.md) |
| `1040` | OpenTimestamps | [03](03.md) |
| `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) |
| `1630`-`1633` | Status | [34](34.md) |
| `1971` | Problem Tracker | [nostrocket][nostrocket] |
| `1984` | Reporting | [56](56.md) |
| `1985` | Label | [32](32.md) |
| `2003` | Torrent | [35](35.md) |
| `2004` | Torrent Comment | [35](35.md) |
| `2022` | Coinjoin Pool | [joinstr][joinstr] |
| `4550` | Community Post Approval | [72](72.md) |
| `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) |
| `9802` | Highlights | [84](84.md) |
| `10000` | Mute list | [51](51.md) |
| `10001` | Pin list | [51](51.md) |
| `10002` | Relay List Metadata | [65](65.md) |
| `10003` | Bookmark list | [51](51.md) |
| `10004` | Communities list | [51](51.md) |
| `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) |
| `10050` | Relay list to receive DMs | [51](51.md), [17](17.md) |
| `10096` | File storage server list | [96](96.md) |
| `13194` | Wallet Info | [47](47.md) |
| `21000` | Lightning Pub RPC | [Lightning.Pub][lnpub] |
| `22242` | Client Authentication | [42](42.md) |
| `23194` | Wallet Request | [47](47.md) |
| `23195` | Wallet Response | [47](47.md) |
| `24133` | Nostr Connect | [46](46.md) |
| `27235` | HTTP Auth | [98](98.md) |
| `30000` | Follow sets | [51](51.md) |
| `30001` | Generic lists | [51](51.md) |
| `30002` | Relay sets | [51](51.md) |
| `30003` | Bookmark sets | [51](51.md) |
| `30004` | Curation sets | [51](51.md) |
| `30005` | Video sets | [51](51.md) |
| `30008` | Profile Badges | [58](58.md) |
| `30009` | Badge Definition | [58](58.md) |
| `30015` | Interest sets | [51](51.md) |
| `30017` | Create or update a stall | [15](15.md) |
| `30018` | Create or update a product | [15](15.md) |
| `30019` | Marketplace UI/UX | [15](15.md) |
| `30020` | Product sold as an auction | [15](15.md) |
| `30023` | Long-form Content | [23](23.md) |
| `30024` | Draft Long-form Content | [23](23.md) |
| `30030` | Emoji sets | [51](51.md) |
| `30063` | Release artifact sets | [51](51.md) |
| `30078` | Application-specific Data | [78](78.md) |
| `30311` | Live Event | [53](53.md) |
| `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) |
| `30618` | Repository state announcements | [34](34.md) |
| `30818` | Wiki article | [54](54.md) |
| `30819` | Redirects | [54](54.md) |
| `31890` | Feed | [NUD: Custom Feeds][NUD: Custom Feeds] |
| `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) |
| `34235` | Video Event | [71](71.md) |
| `34236` | Short-form Portrait Video Event | [71](71.md) |
| `34237` | Video View Event | [71](71.md) |
| `34550` | Community Definition | [72](72.md) |
| `39000-9` | Group metadata events | [29](29.md) |
[NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/97c70a44366a6535c1
[nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
@ -236,13 +240,13 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `-` | -- | -- | [70](70.md) |
| `g` | geohash | -- | [52](52.md) |
| `h` | group id | -- | [29](29.md) |
| `i` | identity | proof | [39](39.md) |
| `i` | external identity | proof, url hint | [39](39.md), [73](73.md) |
| `k` | kind number (string) | -- | [18](18.md), [25](25.md), [72](72.md) |
| `l` | label, label namespace | -- | [32](32.md) |
| `L` | label namespace | -- | [32](32.md) |
| `m` | MIME type | -- | [94](94.md) |
| `q` | event id (hex) | relay URL | [18](18.md) |
| `r` | a reference (URL, etc) | petname | [24](24.md) |
| `r` | a reference (URL, etc) | -- | [24](24.md), [25](25.md) |
| `r` | relay url | marker | [65](65.md) |
| `t` | hashtag | -- | |
| `alt` | summary | -- | [31](31.md) |
@ -262,7 +266,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `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` | name | -- | [34](34.md), [58](58.md), [72](72.md) |
| `nonce` | random | difficulty | [13](13.md) |
| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
| `price` | price | currency, frequency | [99](99.md) |