laantungir/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2026-07-22 07:48:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' into custom-normal

Browse Source
This commit is contained in:
fiatjaf
2026-05-28 17:44:12 -03:00
committed by GitHub
parent c6c353b94e 90cafcdd49
commit 7c74f3808d
19 changed files with 484 additions and 190 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
17.md
View File

@@ -80,6 +80,7 @@ Kind `15` is used for sending encrypted file event messages:
- `ox` containing the SHA-256 hexencoded string of the file before encryption.
- `size` (optional) size of the encrypted file in bytes
- `dim` (optional) size in pixels in the form `<width>x<height>`
- `thumbhash`(optional) the [thumbhash](https://evanw.github.io/thumbhash/) to show while the client is loading the file
- `blurhash`(optional) the [blurhash](https://github.com/woltapp/blurhash) to show while the client is loading the file
- `thumb` (optional) URL of thumbnail with same aspect ratio (encrypted with the same key, nonce)
- `fallback` (optional) zero or more fallback file sources in case `url` fails (encrypted with the same key, nonce)
@@ -170,6 +171,10 @@ This NIP offers the following privacy and security features:
The main limitation of this approach is having to send a separate encrypted event to each receiver. Group chats with more than 100 participants should find a more suitable messaging scheme.
## Spam
Spam is a known problem in encrypted messaging. Since the inner events are unsigned and wrapped in gift wraps with random keys, relays cannot apply traditional anti-spam based on pubkey reputation. The recommended approach for spam mitigation is described in the [Spam Protection section of NIP-59](59.md#spam-protection).
## Examples
This example sends the message `Hola, que tal?` from `nsec1w8udu59ydjvedgs3yv5qccshcj8k05fh3l60k9x57asjrqdpa00qkmr89m` to `nsec12ywtkplvyq5t6twdqwwygavp5lm4fhuang89c943nf2z92eez43szvn4dt`.

4
23.md
View File

@@ -6,7 +6,9 @@ Long-form Content
`draft` `optional`
This NIP defines `kind:30023` (an _addressable event_) for long-form text content, generally referred to as "articles" or "blog posts". `kind:30024` has the same structure as `kind:30023` and is used to save long form drafts.
This NIP defines `kind:30023` (an _addressable event_) for long-form text content, generally referred to as "articles" or "blog posts".
Deprecated: `kind:30024` was used for long-form drafts (self-encrypted nip04, same format as `kind:30023`). The preferred way of doing long-form drafts is to use [NIP-37](37.md) instead.
"Social" clients that deal primarily with `kind:1` notes should not be expected to implement this NIP.

64
29.md
View File

@@ -20,11 +20,7 @@ Relays are supposed to generate the events that describe group metadata and grou
## 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`.
Group identifiers must be strings restricted to the characters `a-z0-9-_`, and SHOULD be random in order to avoid name collisions.
When encountering just the `<host>` without the `'<group-id>`, clients MAY infer `_` as the group id, which is a special top-level group dedicated to relay-local discussions.
A group may be identified by a `naddr1...` code to its `kind:39000` metadata event, with the public key set to the relay `self` public key, the `d` identifier set to the group id, the kind set to `39000` and a relay hint to the relay that is hosting the group.
## The `h` tag
@@ -48,6 +44,20 @@ The roles supported by the group as to having some special privilege assigned to
Users with any roles that have any privilege can be considered _admins_ in a broad sense and be returned in the `kind:39001` event for a group.
## Live audio/video (AV) spaces
Groups may indicate they support live audio and/or video chat by means of a [LiveKit](https://docs.livekit.io/transport/) server by having the tag `livekit` in the group announcement event. An empty `supported_kinds` tag should be used if the group doesn't support text messages, only live AV chat. This setup allows for both Discord-style independent AV rooms and text rooms and Telegram-style single-roomgroup with support for both text and AV.
Upon seeing a `livekit` tag in a group, clients that want to take part in the AV space should call the [token endpoint](https://docs.livekit.io/frontends/build/authentication/endpoint/) at the relay path `/.well-known/nip29/livekit/<group-id>` with a [NIP-98](98.md)-style `Authorization` header to get back the LiveKit JWT and the URL of the LiveKit server and proceed with the stardard LiveKit flow there.
The `Authorization` event should be of kind `27235` and contain a tag `["u", "https://relay.tld/.well-known/nip29/livekit/<group-id>"]`.
Relays should enforce access control at the LiveKit JWT creation time according to the group settings.
Relays MUST set the `sub` property on the issued JWT (called "identity" in the standard LiveKit libraries) such that the initial 64 characters correspond to the lowercase hex public key of the Nostr user. The same user can be issued multiple JWTs and join the same LiveKit room multiple times, so relays are expected to appending a random identifier to those 64 characters.
In order to inform clients about relay support for AV (so they can display that option for users when creating or editing groups) relays should serve a status code `204` at `https://relay.tld/.well-known/nip29/livekit`.
## Event definitions
These are the events expected to be found in NIP-29 groups.
@@ -112,15 +122,15 @@ Clients can send these events to a relay in order to accomplish a moderation act
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 | `put-user` | `p` with pubkey hex and optional roles |
| 9001 | `remove-user` | `p` with pubkey hex |
| 9002 | `edit-metadata` | fields to be modified, and optionally `unrestricted`, `open`, `visible` `public` |
| 9005 | `delete-event` | `e` with event id hex |
| 9007 | `create-group` | |
| 9008 | `delete-group` | |
| 9009 | `create-invite` | arbitrary `code` |
| kind | name | tags |
| --- | --- | --- |
| 9000 | `put-user` | `p` with pubkey hex and optional roles |
| 9001 | `remove-user` | `p` with pubkey hex |
| 9002 | `edit-metadata` | all the fields of *group-metadata* |
| 9005 | `delete-event` | `e` with event id hex |
| 9007 | `create-group` | |
| 9008 | `delete-group` | |
| 9009 | `create-invite` | arbitrary `code` |
It's expected that the group state (of who is an allowed member or not, who is an admin and with which permission or not, what are the group name and picture etc) can be fully reconstructed from the canonical sequence of these events.
@@ -144,7 +154,8 @@ If the group is forked and hosted in multiple relays, there will be multiple ver
["picture", "https://pizza.com/pizza.png"],
["about", "a group for people who love pizza"],
["private"],
["closed"]
["closed"],
["supported_kinds", "9", "11"]
]
// other fields...
}
@@ -155,6 +166,8 @@ If the group is forked and hosted in multiple relays, there will be multiple ver
- `restricted` indicates that only members can _write_ messages to the group. Omitting this tag indicates that anyone can send messages to the group.
- `hidden` indicates that relays should hide group metadata from non-members. Omitting this tag indicates that anyone can request group metadata events.
- `closed` indicates that join requests are ignored. Omitting this tag indicates that users can expect join requests to be honored.
- `livekit` indicates that a group supports LiveKit-powered media rooms (live audio/video).
- `supported_kinds` is a list of stringified kinds numbers the group supports. When not specified all kinds are assumed to be supported. It can contain no items, in which case no kinds are supported (this is the case for AV-only groups, for example).
- *group admins* (`kind:39001`) (optional)
@@ -217,6 +230,27 @@ The process through which the relay decides what roles to support and how to han
}
```
- *livekit participants* (`kind:39004`) (optional)
This is an event that MAY be published by the relay informing users and clients about who is live in an AV room.
This should be updated whenever a new user leaves or joins a group, clients are expected to be actively subscribed to it.
The event MUST contain zero or more `participant` tags with the participant's public key as lowercase hex.
```jsonc
{
"kind": 39004,
"content": "",
"tags": [
["d", "<group-id>"],
["participant", "<pubkey>"],
// other participants...
],
// other fields...
}
```
## Implementation quirks
### Checking your own membership in a group

2
30.md
View File

@@ -14,7 +14,7 @@ Custom emoji may be added to **kind 0**, **kind 1**, **kind 7** ([NIP-25](25.md)
Where:
- `<shortcode>` is a name given for the emoji, which MUST be comprised of only alphanumeric characters and underscores.
- `<shortcode>` is a name given for the emoji, which MUST be comprised of only alphanumeric characters, hyphens, and underscores.
- `<image-url>` is a URL to the corresponding image file of the emoji.
- `<emoji-set-address>` is an optional address pointer (`kind:pubkey:d-tag`) to the kind 30030 emoji set ([NIP-51](51.md)) the emoji belongs to.

35
34.md
View File

@@ -37,6 +37,27 @@ The `r` tag annotated with the `"euc"` marker should be the commit ID of the ear
Except `d`, all tags are optional.
### Nostr Clone URL format
A `nostr://` URL can be used to reference a repository announcement in a way that is compatible with `git clone` when a [git-remote-nostr](https://git-scm.com/docs/gitremote-helpers) helper is installed:
```
nostr://<naddr>
nostr://<npub|nip05>/<identifier>
nostr://<npub|nip05>/<relay-hint>/<identifier>
```
Both `<relay-hint>` and `<identifier>` MUST be percent-encoded per [RFC 3986 §2.1](https://datatracker.ietf.org/doc/html/rfc3986#section-2.1). `<relay-hint>` is a relay URL whose `wss://` scheme may be omitted for brevity. `<identifier>` is the `d` tag value of the kind `30617` event.
Examples:
```
nostr://npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr/relay.ngit.dev/ngit
nostr://npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr/my%20%F0%9F%9A%80%20repo
nostr://danconwaydev.com/ws%3A%2F%2Flocalhost%3A7334/my-local-only-repo
nostr://danconwaydev.com/relay.ngit.dev/ngit
```
## Repository state announcements
An optional source of truth for the state of branches and tags in a repository.
@@ -55,18 +76,6 @@ An optional source of truth for the state of branches and tags in a repository.
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 requests.
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 and Pull Requests (PRs)
Patches and PRs can be sent by anyone to any repository. Patches and PRs to a specific repository SHOULD be sent to the relays specified in that repository's announcement event's `"relays"` tag. Patch and PR events SHOULD include an `a` tag pointing to that repository's announcement address.
@@ -239,7 +248,7 @@ The event SHOULD include a list of `g` tags with grasp service websocket URLs in
"content": "",
"tags": [
["g", "<grasp-service-websocket-url>"], // zero or more grasp sever urls
]
],
}
```

13
37.md
View File

@@ -31,6 +31,19 @@ A blanked `.content` field signals that the draft has been deleted.
Clients SHOULD publish kind `31234` events to relays listed on kind `10013` below.
## Checkpoints
`kind:1234` defines checkpoints that belong to a parent `kind:31234` event. These can serve to provide a revision history of a parent event.
```js
{
"kind": 1234,
"tags": [
["a", "31234:<pubkey>:<identifier>"]
],
"content": nip44Encrypt(JSON.stringify(draft_event)),
}
```
## Relay List for Private Content
Kind `10013` indicates the user's preferred relays to store private events like Draft Wraps.

6
48.md
View File

@@ -1,8 +1,8 @@
NIP-48
======
Proxy Tags
----------
Bridged events
--------------
`draft` `optional`
@@ -57,4 +57,4 @@ ActivityPub object:
### See also
- [FEP-fffd: Proxy Objects](https://codeberg.org/fediverse/fep/src/branch/main/fep/fffd/fep-fffd.md)
- [Mostr bridge](https://mostr.pub/)
- [Mostr bridge](https://mostr.pub/)

8
51.md
View File

@@ -31,14 +31,21 @@ 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) |
| Profile badges | 10008 | [NIP-58](58.md) badges a user has accepted and chosen to display | `"a"` (kind:30009 badge definitions) and `"e"` (kind:8 badge awards), and `"a"` (kind:30008 badge set) |
| Simple groups | 10009 | [NIP-29](29.md) groups the user is in | `"group"` ([NIP-29](29.md) group id + relay URL + optional group name), `"r"` for each relay in use |
| Relay feeds | 10012 | user favorite browsable relays (and relay sets) | `"relay"` (relay URLs) and `"a"` (kind:30002 relay set) |
| Draft relays | 10013 | (nip44-encrypted) [NIP-37](37.md) draft relays | `"relay"` (relay URL) |
| Interests | 10015 | topics a user may be interested in and pointers | `"t"` (hashtags) and `"a"` (kind:30015 interest set) |
| Media follows | 10020 | multimedia (photos, short video) follow list | `"p"` (pubkeys -- with optional relay hint and petname) |
| 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)) |
| Blossom servers | 10063 | Servers where to upload and look for images and other blobs | `"server"` (see [NIP-B7](B7.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) |
| Git authors | 10017 | code (people who produce NIP-34 events) follow list | `"p"` (pubkeys -- with optional relay hint and petname) |
| Git repositories | 10018 | [NIP-34](34.md) followed repositories | `"a"` (kind:30617 repository announcement event) |
| Favorite podcasts | 10054 | podcasts a user wants to bookmark as favorites | `"p"` ([NIP-F4](F4.md) podcast pubkeys), `"url"` (RSS/XML podcast URLs) |
| Authored podcasts | 10064 | podcasts the user authors | `"p"` ([NIP-F4](F4.md) podcast pubkeys) |
### Sets
@@ -57,6 +64,7 @@ Aside from their main identifier, the `"d"` tag, sets can optionally have a `"ti
| Curation sets | 30005 | groups of videos picked by users as interesting and/or belonging to the same category | `"e"` (kind:21 videos) |
| Curation sets | 30006 | groups of pictures picked by users as interesting and/or belonging to the same category | `"e"` (kind:20 pictures) |
| Kind mute sets | 30007 | mute pubkeys by kinds<br>`"d"` tag MUST be the kind string | `"p"` (pubkeys) |
| Badge sets | 30008 | [NIP-58](58.md) categorized groups of badges | `"a"` (kind:30009 badge definitions) and `"e"` (kind:8 badge awards) |
| Interest sets | 30015 | interest topics represented by a bunch of "hashtags" | `"t"` (hashtags) |
| Emoji sets | 30030 | categorized emoji groups | `"emoji"` (see [NIP-30](30.md)) |
| Release artifact sets | 30063 | group of artifacts of a software release | `"e"` (kind:1063 [file metadata](94.md) events), `"a"` (software application event) |

20
58.md
View File

@@ -6,15 +6,18 @@ Badges
`draft` `optional`
Three special events are used to define, award and display badges in
Four special events are used to define, award, display and categorize badges in
user profiles:
1. A "Badge Definition" event is defined as an addressable event with kind `30009` having a `d` tag with a value that uniquely identifies the badge (e.g. `bravery`) published by the badge issuer. Badge definitions can be updated.
2. A "Badge Award" event is a kind `8` event with a single `a` tag referencing a "Badge Definition" event and one or more `p` tags, one for each pubkey the badge issuer wishes to award. Awarded badges are immutable and non-transferable.
3. A "Profile Badges" event is defined as an _addressable event_ with kind `30008` with a `d` tag with the value `profile_badges`.
Profile badges contain an ordered list of pairs of `a` and `e` tags referencing a `Badge Definition` and a `Badge Award` for each badge to be displayed.
3. A "Profile Badges" event is defined as a _replaceable event_ with kind `10008` as a [NIP-51](51.md) standard list.
Profile badges contain an ordered list of pairs of `a` and `e` tags referencing a `Badge Definition` and a `Badge Award` for each badge to be displayed. It may also contain `a` tags referencing "Badge Set" events.
4. A "Badge Set" event is defined as an _addressable event_ with kind `30008` as a [NIP-51](51.md) set.
Badge sets allow users to categorize accepted badges into labeled groups. They contain ordered pairs of `a` and `e` tags referencing a `Badge Definition` and a `Badge Award` for each badge in the set.
### Badge Definition event
@@ -43,10 +46,6 @@ The number of badges a pubkey can be awarded is unbounded. The Profile Badge
event allows individual users to accept or reject awarded badges, as well
as choose the display order of badges on their profiles.
The following tags MUST be present:
- A `d` tag with the unique identifier `profile_badges`
The following tags MAY be present:
- Zero or more ordered consecutive pairs of `a` and `e` tags referencing a kind `30009` Badge Definition and kind `8` Badge Award, respectively. Clients SHOULD
@@ -109,10 +108,9 @@ Clients SHOULD attempt to render the most appropriate badge thumbnail according
Honorable Bob The Brave:
```jsonc
{
"kind": 30008,
"kind": 10008,
"pubkey": "bob",
"tags": [
["d", "profile_badges"],
["a", "30009:alice:bravery"],
["e", "<bravery badge award event id>", "wss://nostr.academy"],
["a", "30009:alice:honor"],
@@ -121,3 +119,7 @@ Honorable Bob The Brave:
// other fields...
}
```
### Deprecated Profile Badges event
An earlier version of this NIP used a kind `30008` addressable event with a `d` tag value of `profile_badges` for the Profile Badges event. Clients should treat these events as equivalent to kind `10008` and migrate to the new format.

4
59.md
View File

@@ -77,6 +77,10 @@ needed to route the event to its intended recipient, including the recipient's `
Encryption is done following [NIP-44](44.md) on the JSON-encoded event. Place the encryption payload in the `.content`
of the wrapper event (either a `seal` or a `gift wrap`).
## Spam Protection
Gift wrap events are signed by random one-time keys, so relays cannot rely on pubkey-based anti-spam or anti-sybil measures (e.g. reputation, trust scores, rate limits by key). To mitigate this, a relay may enforce a [NIP-42](42.md) `auth-required` policy and authenticate clients before accepting gift wraps. Therefore clients SHOULD support authenticating to such relays using the user's real identity. Because NIP-42 authentication is ephemeral (it is not recorded in the event signature), it does not fully undermine the privacy or deniability properties of gift wrapping.
## Other Considerations
If a `rumor` is intended for more than one party, or if the author wants to retain an encrypted copy, a single

6
5A.md
View File

@@ -1,12 +1,12 @@
NIP-5A
======
Pubkey Static Websites
----------------------
Static Websites (nsites)
------------------------
`draft` `optional`
This nip describes a method by which static websites can be hosted under public keys using specialized host servers
This NIP describes a method by which static websites can be hosted from Blossom assets.
### Site Manifest Definition

4
66.md
View File

@@ -1,8 +1,8 @@
NIP-66
======
Relay Discovery and Liveness Monitoring
-------------------
Relay Liveness Monitoring
-------------------------
`draft` `optional` `relay`

3
68.md
View File

@@ -31,6 +31,7 @@ They may contain multiple images to be displayed as a single post.
"imeta",
"url https://nostr.build/i/my-image.jpg",
"m image/jpeg",
"thumbhash zOcFFIIKmXdCinaXaHcmcHUFSA==",
"blurhash eVF$^OI:${M{o#*0-nNFxakD-?xVM}WEWB%iNKxvR-oetmo#R-aen$",
"dim 3024x4032",
"alt A scenic photo overlooking the coast of Costa Rica",
@@ -42,7 +43,7 @@ They may contain multiple images to be displayed as a single post.
"imeta",
"url https://nostr.build/i/my-image2.jpg",
"m image/jpeg",
"blurhash eVF$^OI:${M{o#*0-nNFxakD-?xVM}WEWB%iNKxvR-oetmo#R-aen$",
"thumbhash zOcFFIIKmXgzmWaXWIcmcFQEGA",
"dim 3024x4032",
"alt Another scenic photo overlooking the coast of Costa Rica",
"x <sha256 hash as specified in NIP 94>",

2
70.md
View File

@@ -14,6 +14,8 @@ 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](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.
Reposts of protected events MUST NOT embed the reposted event. If a repost of a protected event embeds the event anyway, relays SHOULD summarily reject it.
## The tag
The tag is a simple tag with a single item: `["-"]`. It may be added to any event.

4
7D.md
View File

@@ -1,8 +1,8 @@
NIP-7D
======
Threads
-------
Forum Threads
-------------
`draft` `optional`

4
92.md
View File

@@ -1,8 +1,8 @@
NIP-92
======
Media Attachments
-----------------
Media Attachments Metadata
--------------------------
Media attachments (images, videos, and other files) may be added to events by including a URL in the event content, along with a matching `imeta` tag.

207
CC.md Normal file
View File

@@ -0,0 +1,207 @@
NIP-CC
======
Geocaching Events
-----------------
`draft` `optional`
This NIP defines event kinds for geocaching activities on Nostr, enabling users to create, discover, and log geocaches in a decentralized manner.
## Motivation
Geocaching is a global treasure hunting game where participants use GPS coordinates to hide and seek containers ("geocaches") at specific locations. This NIP brings geocaching to Nostr, allowing for censorship-resistant, decentralized geocache listings and logs without relying on centralized platforms.
## Event Kinds
This NIP defines two new event kinds:
- `kind:37515`: Geocache listing (addressable event)
- `kind:37516`: Geocache log entry
## Geocache Listing (kind:37515)
A geocache listing is an addressable event that describes a hidden geocache. The event is addressable to allow cache owners to update their listings (e.g., to provide maintenance updates or adjust coordinates).
### Content
The `.content` field contains the cache description as plain text.
### Tags
Required tags:
- `d` (required): Unique identifier for the geocache
- `name` (required): The name of the geocache
- `g` (required): Geohash of the cache location (minimum 6 characters precision)
- `location` (required): Human-readable location description (e.g., "Central Park, New York")
- `difficulty` (required): Integer from 1-5 indicating puzzle/finding difficulty (1=easiest, 5=hardest)
- `terrain` (required): Integer from 1-5 indicating physical difficulty (1=wheelchair accessible, 5=specialized equipment required)
- `size` (required): One of: `micro`, `small`, `regular`, `large`
- `cache-type` (required): One of: `traditional`, `multi`, `mystery`, `earth`, `virtual`, `letterbox`, `event`
Optional tags:
- `hint` (optional): An encrypted hint that can help seekers find the cache. Should be ROT13 encoded by convention
- `image` (optional, repeated): Image URLs related to the cache location or container
- `t` (optional, repeated): Hashtags/categories (e.g., "urban", "forest", "historical")
- `published_at` (optional): Unix timestamp when the cache was first hidden
- `status` (optional): Current cache status - `active` (default), `disabled`, or `archived`
- `relay` (optional but recommended, repeated): Preferred relays for log submissions in order of preference
### Example
```json
{
"kind": 37515,
"pubkey": "<cache owner's pubkey>",
"created_at": 1234567890,
"content": "A scenic cache along the river trail. Please be mindful of muggles during busy hours.",
"tags": [
["d", "riverside-mystery-2024"],
["name", "Riverside Mystery"],
["g", "dp3wfg"],
["location", "Riverside Park, Portland, OR"],
["difficulty", "2"],
["terrain", "3"],
["size", "small"],
["cache-type", "traditional"],
["hint", "Ybbx sbe gur byq bnx gerr"],
["image", "https://example.com/cache-area.jpg"],
["t", "scenic"],
["t", "river"],
["published_at", "1704067200"],
["status", "active"],
["relay", "wss://geocaching.example.com"],
["relay", "wss://oregon.nostr.com"]
]
}
```
## Geocache Log (kind:37516)
A geocache log represents a user's visit to a geocache. These are regular (non-addressable) events.
### Content
The `.content` field contains the log message as plain text.
### Tags
Required tags:
- `a` (required): Reference to the geocache being logged using NIP-01 `a` tag format: `["a", "37515:<cache-owner-pubkey>:<d-tag>", "<relay-url>"]`. The relay URL SHOULD be the preferred relay from the cache listing if available
- `log-type` (required): One of:
- `found`: Successfully found the cache
- `dnf`: Did Not Find despite searching
- `note`: General comment without searching
- `maintenance`: Maintenance performed by cache owner
- `disabled`: Cache temporarily disabled by owner
- `enabled`: Cache re-enabled by owner
- `archived`: Cache permanently retired
Optional tags:
- `image` (optional, repeated): Image URLs from the visit
- `g` (optional): Geohash of where the log was created (for privacy, should be less precise than cache location)
- `published_at` (optional): Unix timestamp of the actual visit (may differ from event creation time)
### Example
```json
{
"kind": 37516,
"pubkey": "<finder's pubkey>",
"created_at": 1234567890,
"content": "Beautiful location! Took me 20 minutes to find it. TFTC!",
"tags": [
["a", "37515:abc123...:riverside-mystery-2024", "wss://geocaching.example.com"],
["log-type", "found"],
["image", "https://example.com/selfie.jpg"],
["g", "dp3w"],
["published_at", "1704153600"]
]
}
```
## Relay Selection
### For Cache Listings
Cache owners SHOULD include one or more `relay` tags in their listing events to indicate preferred relays for log submissions. Relays are listed in order of preference, with the first relay being the primary choice.
### For Log Events
When creating log events (kind:37516), clients SHOULD:
1. Check the cache listing for `relay` tags and publish logs to those relays
2. Include the first (primary) relay URL in the `a` tag reference (third parameter)
3. Also publish to the user's regular write relays for their own activity tracking
### Geographic and Specialized Relays
Communities MAY establish geographic or geocaching-specific relays. Clients SHOULD:
- Allow users to configure geocaching-specific relays in settings
- Consider implementing relay selection based on geohash prefixes for geographic relevance
- Support community-maintained relay lists for geocaching activities
### Relay Discovery
When querying for geocaches and logs, clients SHOULD:
1. Use the relay hints from `a` tags when fetching referenced cache listings
2. Query both general-purpose and specialized geocaching relays
3. Consider geographic proximity when selecting relays to query
## Client Implementation Notes
### Querying Geocaches
Clients SHOULD use the following filters to query geocaches:
1. **All active geocaches**: `{"kinds": [37515], "#status": ["active"]}`
2. **Geocaches by location**: `{"kinds": [37515], "#g": ["dp3w"]}` (using geohash prefix)
3. **Geocaches by type**: `{"kinds": [37515], "#cache-type": ["mystery"]}`
4. **Geocaches by tag**: `{"kinds": [37515], "#t": ["scenic"]}`
5. **User's hidden caches**: `{"kinds": [37515], "authors": ["<pubkey>"]}`
### Querying Logs
1. **Logs for a specific cache**: `{"kinds": [37516], "#a": ["37515:<pubkey>:<d-tag>"]}`
2. **User's found caches**: `{"kinds": [37516], "authors": ["<pubkey>"], "#log-type": ["found"]}`
3. **Recent activity**: `{"kinds": [37516], "limit": 50}` with time-based sorting
### Privacy Considerations
- Log events MAY include less precise geohashes than the cache location to protect finder privacy
- Clients SHOULD warn users before publishing precise location data
- Images SHOULD have EXIF location data stripped before uploading
### Coordinate Handling
- Coordinates SHOULD be stored as geohashes for efficient geographic queries
- Clients MUST support at least 6-character geohash precision (±0.61km)
- For display, clients SHOULD convert between geohash and decimal degrees
### Statistics
Clients MAY calculate statistics by counting log events:
- **Find count**: Count of logs with `log-type: "found"` for a cache
- **DNF rate**: Ratio of "dnf" to total "found" + "dnf" logs
- **User stats**: Count of unique caches found by a user
## Appendix: Geocaching Terminology
- **TFTC**: Thanks For The Cache
- **Muggle**: Non-geocacher who might accidentally discover a cache
- **DNF**: Did Not Find
- **FTF**: First To Find
- **Cache**: Short for geocache
- **CO**: Cache Owner
- **Geohash**: A geographic encoding system that represents coordinates as a short alphanumeric string
## Security and Spam Considerations
- Clients SHOULD implement rate limiting for cache creation
- Cache owners SHOULD be able to delete/archive their own caches
- Clients MAY implement reputation systems based on found/hidden ratios
- Clients SHOULD verify that log coordinates are reasonably close to cache coordinates
## Future Considerations
This NIP intentionally keeps the initial implementation simple. Future NIPs may define:
- Trackable items that move between caches
- Event caches with specific date/time meetups
- Challenge caches with specific finding requirements
- Puzzle solutions stored as encrypted content
- Integration with Lightning for premium caches or tips

106
F4.md Normal file
View File

@@ -0,0 +1,106 @@
NIP-F4
======
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
## Concept
The idea is that each podcast is its own Nostr keypair. This is simple and allows podcasts to combine their _podcasting_ presence with a normal `kind:0`/`kind:1` microblogging presence.
It also allows podcasts to have shared ownership (via MuSig2 or just common agreements between friends) and to change that ownership over time (again, based on human trust over handling of key material).
## Event definitions
### Podcast Metadata
Podcast metadata is stored in `kind:10154` _replaceable_ events. This event contains the show-level information that podcast clients need to display the podcast.
Similar information may exist in the `kind:0` profile for the podcast, but podcast-specific clients should be able to read directly from `kind:10154` and ignore `kind:0` entirely.
```yaml
{
"id": "...",
"pubkey": "<podcast-pubkey>",
"kind": 10154,
"created_at": 1700682555,
"tags": [
["title", "<podcast-title>"],
["image", "<podcast-cover-image-URL>"],
["description", "<podcast-description>"],
["website", "<podcast-website-URL>"], // optional, multiple
["p", "<podcast-author-pubkey>", "<role>"] // optional, multiple
],
"content": "",
"sig": "..."
}
```
`<role>` is optional, can be `"host"`, `"cohost"` or `"editor"`.
### Authored Podcasts
The `p` tag in `kind:10154` shouldn't be blindly trusted as implying authorship, since any podcast can falsely claim anyone to be their author, so before it is displayed as information by clients it must be checked against an equivalent counter-claim by the podcast authors themselves.
This is the `kind:10164` event. Here podcast authors can list the public keys of the podcasts they author.
```yaml
{
"id": "...",
"pubkey": "<user-pubkey>",
"kind": 10064,
"created_at": 1700682555,
"tags": [
["p", "<podcast-pubkey-1>"],
["p", "<podcast-pubkey-2>"]
],
"content": "",
"sig": "..."
}
```
Clients can also use this to discover all podcasts authored by a given user.
### Podcast Episodes
Podcast episodes are `kind:54` events authored by the podcast public key directly.
```yaml
{
"id": "...",
"pubkey": "<podcast-pubkey>",
"kind": 54,
"created_at": 1700682555,
"tags": [
["title", "<episode title>"],
["image", "<optional episode image>"],
["description", "<a brief description>"],
["audio", "<audio-url>", "<optional_media_type>"], // can be specified multiple times
// ...other important fields to be specified here later after further discovery
],
"content": "<markdown content>",
"sig": "...",
}
```
### Favorite podcasts
See [NIP-51](51.md) for the description of a `kind:10054` event in which any user can list the podcasts they publicly advertise to listening to, as a soft recommendation.

177
README.md
View File

@@ -4,6 +4,8 @@ NIPs stand for **Nostr Implementation Possibilities**.
They exist to document what may be implemented by [Nostr](https://github.com/nostr-protocol/nostr)-compatible _relay_ and _client_ software.
NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP. Each app picks the subset relevant to its use case. Don't implement something just because it exists in this repo. Other standards and NIPs may exist outside this repository (e.g. as pull requests) and may already be deployed in the wild -- they should also be considered for implementation.
---
- [List](#list)
@@ -11,8 +13,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [Message Types](#message-types)
- [Client to Relay](#client-to-relay)
- [Relay to Client](#relay-to-client)
- [Common Tags](#common-tags)
- [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips)
- [Criteria for acceptance of NIPs](#criteria-for-acceptance-of-nips-in-this-repository)
- [Is this repository a centralizing factor?](#is-this-repository-a-centralizing-factor)
- [How this repository works](#how-this-repository-works)
- [License](#license)
@@ -23,18 +24,18 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-01: Basic protocol flow description](01.md)
- [NIP-02: Follow List](02.md)
- [NIP-03: OpenTimestamps Attestations for Events](03.md)
- [NIP-04: Encrypted Direct Message](04.md) --- **unrecommended**: deprecated in favor of [NIP-17](17.md)
~~- [NIP-03: OpenTimestamps Attestations for Events](03.md) --- **unrecommended**: vulnerable to one specific attack, needs update~~
~~- [NIP-04: Encrypted Direct Message](04.md) --- **unrecommended**: deprecated in favor of [NIP-17](17.md)~~
- [NIP-05: Mapping Nostr keys to DNS-based internet identifiers](05.md)
- [NIP-06: Basic key derivation from mnemonic seed phrase](06.md)
~~- [NIP-06: Basic key derivation from mnemonic seed phrase](06.md) --- **unrecommended**: prefer a single nsec~~
- [NIP-07: `window.nostr` capability for web browsers](07.md)
- [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md)
~~- [NIP-08: Handling Mentions](08.md) --- **unrecommended**: deprecated in favor of [NIP-27](27.md)~~
- [NIP-09: Event Deletion Request](09.md)
- [NIP-10: Text Notes and Threads](10.md)
- [NIP-11: Relay Information Document](11.md)
- [NIP-13: Proof of Work](13.md)
- [NIP-14: Subject tag in text events](14.md)
- [NIP-15: Nostr Marketplace (for resilient marketplaces)](15.md)
~~- [NIP-15: Nostr Marketplace (for resilient marketplaces)](15.md) --- **unrecommended**: too complicated, try [99](99.md) instead~~
- [NIP-17: Private Direct Messages](17.md)
- [NIP-18: Reposts](18.md)
- [NIP-19: bech32-encoded entities](19.md)
@@ -43,12 +44,12 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-23: Long-form Content](23.md)
- [NIP-24: Extra metadata fields and tags](24.md)
- [NIP-25: Reactions](25.md)
- [NIP-26: Delegated Event Signing](26.md) --- **unrecommended**: adds unnecessary burden for little gain
~~- [NIP-26: Delegated Event Signing](26.md) --- **unrecommended**: adds unnecessary burden for little gain~~
- [NIP-27: Text Note References](27.md)
- [NIP-28: Public Chat](28.md)
~~- [NIP-28: Public Chat](28.md) --- **unrecommended**: try [NIP-29](29.md) instead~~
- [NIP-29: Relay-based Groups](29.md)
- [NIP-30: Custom Emoji](30.md)
- [NIP-31: Dealing with Unknown Events](31.md)
~~- [NIP-31: Dealing with Unknown Events](31.md) --- **unrecommended**: unnecessarily bloated~~
- [NIP-32: Labeling](32.md)
- [NIP-34: `git` stuff](34.md)
- [NIP-35: Torrents](35.md)
@@ -63,7 +64,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-45: Counting results](45.md)
- [NIP-46: Nostr Remote Signing](46.md)
- [NIP-47: Nostr Wallet Connect](47.md)
- [NIP-48: Proxy Tags](48.md)
- [NIP-48: Bridged Events](48.md)
- [NIP-49: Private Key Encryption](49.md)
- [NIP-50: Search Capability](50.md)
- [NIP-51: Lists](51.md)
@@ -75,50 +76,53 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
- [NIP-57: Lightning Zaps](57.md)
- [NIP-58: Badges](58.md)
- [NIP-59: Gift Wrap](59.md)
- [NIP-5A: Pubkey Static Websites](5A.md)
- [NIP-5A: Static Websites (nsites)](5A.md)
- [NIP-60: Cashu Wallet](60.md)
- [NIP-61: Nutzaps](61.md)
- [NIP-62: Request to Vanish](62.md)
- [NIP-64: Chess (PGN)](64.md)
- [NIP-65: Relay List Metadata](65.md)
- [NIP-66: Relay Discovery and Liveness Monitoring](66.md)
- [NIP-66: Relay Liveness Monitoring](66.md)
- [NIP-68: Picture-first feeds](68.md)
- [NIP-69: Peer-to-peer Order events](69.md)
- [NIP-70: Protected Events](70.md)
- [NIP-71: Video Events](71.md)
- [NIP-72: Moderated Communities](72.md)
~~- [NIP-72: Moderated Communities](72.md) --- **unrecommended**: try [NIP-29](29.md) instead~~
- [NIP-73: External Content IDs](73.md)
- [NIP-75: Zap Goals](75.md)
- [NIP-77: Negentropy Syncing](77.md)
- [NIP-78: Application-specific data](78.md)
- [NIP-7D: Threads](7D.md)
- [NIP-7D: Forum Threads](7D.md)
- [NIP-84: Highlights](84.md)
- [NIP-85: Trusted Assertions](85.md)
- [NIP-86: Relay Management API](86.md)
- [NIP-87: Ecash Mint Discoverability](87.md)
- [NIP-88: Polls](88.md)
- [NIP-89: Recommended Application Handlers](89.md)
- [NIP-90: Data Vending Machines](90.md)
- [NIP-92: Media Attachments](92.md)
~~- [NIP-90: Data Vending Machines](90.md) --- **unrecommended**: this got totally out of control, prefer use-case-specific microstandards~~
- [NIP-92: Media Attachments Metadata](92.md)
- [NIP-94: File Metadata](94.md)
- [NIP-96: HTTP File Storage Integration](96.md) --- **unrecommended**: replaced by blossom APIs
~~- [NIP-96: HTTP File Storage Integration](96.md) --- **unrecommended**: replaced by Blossom~~
- [NIP-98: HTTP Auth](98.md)
- [NIP-99: Classified Listings](99.md)
- [NIP-A0: Voice Messages](A0.md)
- [NIP-A4: Public Messages](A4.md)
- [NIP-B0: Web Bookmarks](B0.md)
- [NIP-B7: Blossom](B7.md)
- [NIP-BE: Nostr BLE Communications Protocol](BE.md)
~~- [NIP-BE: Nostr BLE Communications Protocol](BE.md) --- **unrecommended**: only implemented once and unclear whether it works, requires review~~
- [NIP-C0: Code Snippets](C0.md)
- [NIP-CC: Geocaching](CC.md)
- [NIP-C7: Chats](C7.md)
- [NIP-EE: E2EE Messaging using MLS Protocol](EE.md) --- **unrecommended**: superseded by the [Marmot Protocol](https://github.com/marmot-protocol/marmot)
~~- [NIP-EE: E2EE Messaging using MLS Protocol](EE.md) --- **unrecommended**: superseded by the [Marmot Protocol](https://github.com/marmot-protocol/marmot)~~
## Event Kinds
This table is not exhaustive. For a machine-readable registry of all known event kinds prefer <https://github.com/nostr-protocol/registry-of-kinds> (or alternative registries following the same YAML schema).
| kind | description | NIP |
| ------------- | ------------------------------- | -------------------------------------- |
| `0` | User Metadata | [01](01.md) |
| `1` | Short Text Note | [10](10.md) |
| `2` | Recommend Relay | 01 (deprecated) |
| `3` | Follows | [02](02.md) |
| `4` | Encrypted Direct Messages | [04](04.md) |
| `5` | Event Deletion Request | [09](09.md) |
@@ -126,9 +130,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `7` | Reaction | [25](25.md) |
| `8` | Badge Award | [58](58.md) |
| `9` | Chat Message | [C7](C7.md) |
| `10` | Group Chat Threaded Reply | 29 (deprecated) |
| `11` | Thread | [7D](7D.md) |
| `12` | Group Thread Reply | 29 (deprecated) |
| `13` | Seal | [59](59.md) |
| `14` | Direct Message | [17](17.md) |
| `15` | File Message | [17](17.md) |
@@ -147,6 +149,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `42` | Channel Message | [28](28.md) |
| `43` | Channel Hide Message | [28](28.md) |
| `44` | Channel Mute User | [28](28.md) |
| `54` | Podcast Episode | [F4](F4.md) |
| `62` | Request to Vanish | [62](62.md) |
| `64` | Chess (PGN) | [64](64.md) |
| `78` | Application-specific Data | [78](78.md) |
@@ -157,6 +160,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `1018` | Poll Response | [88](88.md) |
| `1021` | Bid | [15](15.md) |
| `1022` | Bid confirmation | [15](15.md) |
| `1234` | Draft Checkpoint | [37](37.md) |
| `1040` | OpenTimestamps | [03](03.md) |
| `1059` | Gift Wrap | [59](59.md) |
| `1063` | File Metadata | [94](94.md) |
@@ -175,26 +179,21 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `1971` | Problem Tracker | [nostrocket][nostrocket] |
| `1984` | Reporting | [56](56.md) |
| `1985` | Label | [32](32.md) |
| `1986` | Relay reviews | |
| `1987` | AI Embeddings / Vector lists | [NKBIP-02] |
| `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) |
| `7374` | Reserved Cashu Wallet Tokens | [60](60.md) |
| `7375` | Cashu Wallet Tokens | [60](60.md) |
| `7376` | Cashu Wallet History | [60](60.md) |
| `7516` | Geocache log | [geocaching][geocaching] |
| `7517` | Geocache proof of find | [geocaching][geocaching] |
| `7516` | Geocache log | [CC](CC.md) |
| `7517` | Geocache proof of find | [CC](CC.md) |
| `8000` | Add User | [43](43.md) |
| `8001` | Remove User | [43](43.md) |
| `9000`-`9030` | Group Control Events | [29](29.md) |
| `9041` | Zap Goal | [75](75.md) |
| `9321` | Nutzap | [61](61.md) |
| `9467` | Tidal login | [Tidal-nostr] |
| `9734` | Zap Request | [57](57.md) |
| `9735` | Zap | [57](57.md) |
| `9802` | Highlights | [84](84.md) |
@@ -206,6 +205,7 @@ 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) |
| `10008` | Profile Badges | [51](51.md), [58](58.md) |
| `10009` | User groups | [51](51.md), [29](29.md) |
| `10011` | External Identities | [39](39.md) |
| `10012` | Favorite relays list | [51](51.md) |
@@ -215,37 +215,35 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `10020` | Media follows | [51](51.md) |
| `10030` | User emoji list | [51](51.md) |
| `10050` | Relay list to receive DMs | [51](51.md), [17](17.md) |
| `10051` | KeyPackage Relays List | [Marmot](marmot) |
| `10063` | User server list | [Blossom][blossom] |
| `10051` | KeyPackage Relays List | [Marmot][marmot] |
| `10054` | Favorite podcasts list | [51](51.md) |
| `10063` | User server list | [B7](B7.md) |
| `10064` | Authored podcasts list | [51](51.md) |
| `10096` | File storage server list | [96](96.md) (deprecated) |
| `10154` | Podcast Metadata | [F4](F4.md) |
| `10166` | Relay Monitor Announcement | [66](66.md) |
| `10312` | Room Presence | [53](53.md) |
| `10377` | Proxy Announcement | [Nostr Epoxy][nostr-epoxy] |
| `11111` | Transport Method Announcement | [Nostr Epoxy][nostr-epoxy] |
| `13194` | Wallet Info | [47](47.md) |
| `13534` | Membership Lists | [43](43.md) |
| `14388` | User Sound Effect Lists | [Corny Chat][cornychat-usersoundlist] |
| `15128` | Root nsite manifest | [5A](5A.md) |
| `17375` | Cashu Wallet Event | [60](60.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) |
| `24242` | Blobs stored on mediaservers | [Blossom][blossom] |
| `24242` | Blobs stored on mediaservers | [B7](B7.md) |
| `27235` | HTTP Auth | [98](98.md) |
| `28934` | Join Request | [43](43.md) |
| `28935` | Invite Request | [43](43.md) |
| `28936` | Leave Request | [43](43.md) |
| `30000` | Follow sets | [51](51.md) |
| `30001` | Generic lists | 51 (deprecated) |
| `30002` | Relay sets | [51](51.md) |
| `30003` | Bookmark sets | [51](51.md) |
| `30004` | Curation sets | [51](51.md) |
| `30005` | Video sets | [51](51.md) |
| `30006` | Picture sets | [51](51.md) |
| `30007` | Kind mute sets | [51](51.md) |
| `30008` | Profile Badges | [58](58.md) |
| `30008` | Badge sets | [51](51.md), [58](58.md) |
| `30009` | Badge Definition | [58](58.md) |
| `30015` | Interest sets | [51](51.md) |
| `30017` | Create or update a stall | [15](15.md) |
@@ -268,7 +266,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `30382` | User Trusted Assertion | [85](85.md) |
| `30383` | Event Trusted Assertion | [85](85.md) |
| `30384` | Addressable Trusted Assertion | [85](85.md) |
| `30388` | Slide Set | [Corny Chat][cornychat-slideset] |
| `30402` | Classified Listing | [99](99.md) |
| `30403` | Draft Classified Listing | [99](99.md) |
| `30617` | Repository announcements | [34](34.md) |
@@ -276,8 +273,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `30818` | Wiki article | [54](54.md) |
| `30819` | Redirects | [54](54.md) |
| `31234` | Draft Event | [37](37.md) |
| `31388` | Link Set | [Corny Chat][cornychat-linkset] |
| `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) |
@@ -285,40 +280,25 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `31989` | Handler recommendation | [89](89.md) |
| `31990` | Handler information | [89](89.md) |
| `32267` | Software Application | |
| `32388` | User Room Favorites | [Corny Chat][cornychat-roomfavorites] |
| `33388` | High Scores | [Corny Chat][cornychat-highscores] |
| `34235` | Addressable Video Event | [71](71.md) |
| `34236` | Addressable Short Video Event | [71](71.md) |
| `34388` | Sound Effects | [Corny Chat][cornychat-soundeffects] |
| `34550` | Community Definition | [72](72.md) |
| `34128` | Legacy nsite manifest | [5A](5A.md) (deprecated) |
| `35128` | Named nsite manifest | [5A](5A.md) |
| `38172` | Cashu Mint Announcement | [87](87.md) |
| `38173` | Fedimint Announcement | [87](87.md) |
| `37516` | Geocache listing | [geocaching](geocaching) |
| `37516` | Geocache listing | [CC](CC.md) |
| `38383` | Peer-to-peer Order events | [69](69.md) |
| `39000-9` | Group metadata events | [29](29.md) |
| `39089` | Starter packs | [51](51.md) |
| `39092` | Media starter packs | [51](51.md) |
| `39701` | Web bookmarks | [B0](B0.md) |
[NUD: Custom Feeds]: https://wikifreedia.xyz/cip-01/
[nostrocket]: https://github.com/nostrocket/NIPS/blob/main/Problems.md
[lnpub]: https://github.com/shocknet/Lightning.Pub/blob/master/proto/autogenerated/client.md
[cornychat-usersoundlist]: https://cornychat.com/datatypes#kind14388usersoundeffectslist
[cornychat-slideset]: https://cornychat.com/datatypes#kind30388slideset
[cornychat-linkset]: https://cornychat.com/datatypes#kind31388linkset
[cornychat-roomfavorites]: https://cornychat.com/datatypes#kind32388roomfavorites
[cornychat-highscores]: https://cornychat.com/datatypes#kind33388highscores
[cornychat-soundeffects]: https://cornychat.com/datatypes#kind34388soundeffectsets
[joinstr]: https://gitlab.com/1440000bytes/joinstr/-/blob/main/NIP.md
[NKBIP-01]: https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
[NKBIP-02]: https://wikistr.com/nkbip-02*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
[NKBIP-03]: https://wikistr.com/nkbip-03*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
[blossom]: https://github.com/hzrd149/blossom
[Tidal-nostr]: https://wikistr.com/tidal-nostr
[geocaching]: https://nostrhub.io/naddr1qvzqqqrcvypzppscgyy746fhmrt0nq955z6xmf80pkvrat0yq0hpknqtd00z8z68qqgkwet0vdskx6rfdenj6etkv4h8guc6gs5y5
[nostr-epoxy]: https://github.com/Origami74/nostr-epoxy-reverse-proxy
[marmot]: https://github.com/marmot-protocol/marmot
@@ -346,86 +326,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `AUTH` | used to send authentication challenges | [42](42.md) |
| `COUNT` | used to send requested event counts to clients | [45](45.md) |
## Common Tags
| name | value | other parameters | NIP |
| ----------------- | ------------------------------------ | ------------------------------- | -------------------------------------------------- |
| `a` | coordinates to an event | relay URL | [01](01.md) |
| `A` | root address | relay URL | [22](22.md) |
| `c` | commit id | | [34](34.md) |
| `d` | identifier | -- | [01](01.md) |
| `D` | day | -- | [52](52.md) |
| `e` | event id (hex) | relay URL, marker, pubkey (hex) | [01](01.md), [10](10.md) |
| `E` | root event id | relay URL | [22](22.md) |
| `f` | currency code | -- | [69](69.md) |
| `g` | geohash | -- | [52](52.md) |
| `h` | group id | -- | [29](29.md) |
| `i` | external identity | proof, url hint | [35](35.md), [39](39.md), [73](73.md) |
| `I` | root external identity | -- | [22](22.md) |
| `k` | kind | -- | [18](18.md), [25](25.md), [72](72.md), [73](73.md) |
| `K` | root scope | -- | [22](22.md) |
| `l` | label, label namespace, language name| -- | [32](32.md), [C0](C0.md) |
| `L` | label namespace | -- | [32](32.md) |
| `m` | MIME type | -- | [94](94.md) |
| `p` | pubkey (hex) | relay URL, petname | [01](01.md), [02](02.md), [22](22.md) |
| `P` | pubkey (hex) | -- | [22](22.md), [57](57.md) |
| `q` | event id (hex) | relay URL, pubkey (hex) | [18](18.md) |
| `r` | a reference (URL, etc) | -- | [24](24.md), [25](25.md) |
| `r` | relay url | marker | [65](65.md) |
| `s` | status | -- | [69](69.md) |
| `t` | hashtag | -- | [24](24.md), [34](34.md), [35](35.md) |
| `u` | url | -- | [61](61.md), [98](98.md) |
| `x` | hash | -- | [35](35.md), [56](56.md) |
| `y` | platform | -- | [69](69.md) |
| `z` | order number | -- | [69](69.md) |
| `-` | -- | -- | [70](70.md) |
| `alt` | summary | -- | [31](31.md) |
| `amount` | millisatoshis, stringified | -- | [57](57.md) |
| `bolt11` | `bolt11` invoice | -- | [57](57.md) |
| `branch-name` | branch name suggestion | -- | [34](34.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) |
| `dep` | Required dependency | -- | [C0](C0.md) |
| `description` | description | -- | [34](34.md), [57](57.md), [58](58.md), [C0](C0.md) |
| `emoji` | shortcode, image URL | -- | [30](30.md) |
| `encrypted` | -- | -- | [90](90.md) |
| `extension` | File extension | -- | [C0](C0.md) |
| `expiration` | unix timestamp (string) | -- | [40](40.md) |
| `file` | full path (string) | -- | [35](35.md) |
| `goal` | event id (hex) | relay URL | [75](75.md) |
| `merge-base` | commit id | | [34](34.md) |
| `HEAD` | `ref: refs/heads/<branch-name>` | | [34](34.md) |
| `image` | image URL | dimensions in pixels | [23](23.md), [52](52.md), [58](58.md) |
| `imeta` | inline metadata | -- | [92](92.md) |
| `license` | License of the shared content | -- | [C0](C0.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), [72](72.md), [C0](C0.md) |
| `nonce` | random | difficulty | [13](13.md) |
| `preimage` | hash of `bolt11` invoice | -- | [57](57.md) |
| `price` | price | currency, frequency | [99](99.md) |
| `proxy` | external ID | protocol | [48](48.md) |
| `published_at` | unix timestamp (string) | -- | [23](23.md), [B0](B0.md) |
| `relay` | relay url | -- | [42](42.md), [17](17.md) |
| `relays` | relay list | -- | [57](57.md) |
| `repo` | Reference to the origin repository | -- | [C0](C0.md) |
| `runtime` | Runtime or environment specification | -- | [C0](C0.md) |
| `server` | file storage server url | -- | [96](96.md) |
| `sound` | shortcode, sound url, image url | -- | [51](51.md) |
| `subject` | subject | -- | [14](14.md), [17](17.md), [34](34.md) |
| `summary` | summary | -- | [23](23.md), [52](52.md) |
| `thumb` | badge thumbnail | dimensions in pixels | [58](58.md) |
| `title` | title | -- | [23](23.md), [B0](B0.md) |
| `tracker` | torrent tracker URL | -- | [35](35.md) |
| `web` | webpage URL | -- | [34](34.md) |
| `zap` | pubkey (hex), relay URL | weight | [57](57.md) |
Please update these lists when proposing new NIPs.
## Criteria for acceptance of NIPs
## Criteria for acceptance in this repository
1. They should be fully implemented in at least two clients and one relay -- when applicable.
2. They should make sense.