mirror of
https://github.com/nostr-protocol/nips.git
synced 2026-01-25 11:38:57 +00:00
Compare commits
1 Commits
f461065c29
...
nip50-quer
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
e943ab847a |
20
29.md
20
29.md
@@ -120,21 +120,21 @@ 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` | fields from `kind:39000` to be modified |
|
||||
| 9005 | `delete-event` | `e` with event id hex |
|
||||
| 9007 | `create-group` | |
|
||||
| 9008 | `delete-group` | |
|
||||
| 9009 | `create-invite` | |
|
||||
|
||||
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.
|
||||
|
||||
### Group metadata events
|
||||
|
||||
These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only (as stated by the [NIP-11](11.md) `"self"` pubkey) and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).
|
||||
These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).
|
||||
|
||||
- *group metadata* (`kind:39000`) (optional)
|
||||
|
||||
|
||||
4
46.md
4
46.md
@@ -41,7 +41,7 @@ There are two ways to initiate a connection:
|
||||
|
||||
_remote-signer_ provides connection token in the form:
|
||||
|
||||
```
|
||||
`relay`
|
||||
bunker://<remote-signer-pubkey>?relay=<wss://relay-to-connect-on>&relay=<wss://another-relay-to-connect-on>&secret=<optional-secret-value>
|
||||
```
|
||||
|
||||
@@ -204,7 +204,7 @@ _client_ should display (in a popup or new tab) the URL from the `error` field a
|
||||
|
||||
### Announcing _remote-signer_ metadata
|
||||
|
||||
_remote-signer_ MAY publish its metadata by using [NIP-05](05.md) and [NIP-89](89.md). With NIP-05, a request to `<remote-signer>/.well-known/nostr.json?name=_` MAY return this:
|
||||
_remote-signer_ MAY publish it's metadata by using [NIP-05](05.md) and [NIP-89](89.md). With NIP-05, a request to `<remote-signer>/.well-known/nostr.json?name=_` MAY return this:
|
||||
```jsonc
|
||||
{
|
||||
"names":{
|
||||
|
||||
43
50.md
43
50.md
@@ -26,11 +26,50 @@ Relays SHOULD interpret the query to the best of their ability and return events
|
||||
Relays SHOULD perform matching against `content` event field, and MAY perform
|
||||
matching against other fields if that makes sense in the context of a specific kind.
|
||||
|
||||
Results SHOULD be returned in descending order by quality of search result (as defined by the implementation),
|
||||
not by the usual `.created_at`. The `limit` filter SHOULD be applied after sorting by matching score.
|
||||
A query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore
|
||||
extensions they don't support.
|
||||
|
||||
### Query Expression Extensions
|
||||
|
||||
Relays MAY support query expressions with boolean operators and filter attributes. When supported, this MUST be advertised in NIP-11:
|
||||
|
||||
```json
|
||||
{
|
||||
"supported_nips": [50],
|
||||
"nip50_search": {
|
||||
"boolean_operators": true,
|
||||
"filter_attributes": ["limit", "since", "until"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
When `boolean_operators` is `true`, relays SHOULD support:
|
||||
|
||||
- Terms split by whitespace (implicit AND)
|
||||
- Double quotes for phrase matching: `"hello world"`
|
||||
- Boolean operators: `AND`, `OR` (uppercase, case-sensitive)
|
||||
- Parentheses for grouping: `(cat AND dog) OR bird`
|
||||
- Operator precedence: `AND` binds tighter than `OR`
|
||||
|
||||
Examples:
|
||||
- `hello world` → both terms required (implicit AND)
|
||||
- `hello OR world` → either term matches
|
||||
- `cat AND (dog OR bird)` → "cat" plus either "dog" or "bird"
|
||||
|
||||
When `filter_attributes` is present, relays SHOULD support filter attributes in the query string:
|
||||
|
||||
- `limit:<number>` - limit number of results (e.g., `limit:50`)
|
||||
- `since:<unix timestamp>` - filter events after timestamp (e.g., `since:1609459200`)
|
||||
- `until:<unix timestamp>` - filter events before timestamp (e.g., `until:1640995200`)
|
||||
|
||||
Examples:
|
||||
- `nostr limit:50` → search "nostr" and return up to 50 results
|
||||
- `bitcoin since:1609459200` → search "bitcoin" for events after the specified time
|
||||
- `cats OR dogs limit:100 since:1640995200` → combined query with filters
|
||||
|
||||
Results SHOULD be returned in descending order by quality of search result (as defined by the implementation),
|
||||
not by the usual `.created_at`. The `limit` filter SHOULD be applied after sorting by matching score.
|
||||
|
||||
Clients may specify several search filters, i.e. `["REQ", "", { "search": "orange" }, { "kinds": [1, 2], "search": "purple" }]`. Clients may
|
||||
include `kinds`, `ids` and other filter field to restrict the search results to particular event kinds.
|
||||
|
||||
|
||||
4
55.md
4
55.md
@@ -210,10 +210,10 @@ launcher.launch(intent)
|
||||
context.startActivity(intent)
|
||||
```
|
||||
- result:
|
||||
- If the user approved intent it will return the **result** and **id** fields
|
||||
- If the user approved intent it will return the **signature** and **id** fields
|
||||
|
||||
```kotlin
|
||||
val encryptedText = intent.data?.getStringExtra("result")
|
||||
val encryptedText = intent.data?.getStringExtra("signature")
|
||||
// the id you sent
|
||||
val id = intent.data?.getStringExtra("id")
|
||||
```
|
||||
|
||||
2
66.md
2
66.md
@@ -67,7 +67,7 @@ Tags include:
|
||||
- `frequency` - The frequency in seconds at which the monitor publishes events.
|
||||
- `timeout` (optional) - The timeout values for various checks conducted by a monitor. Index `1` is the monitor's timeout in milliseconds. Index `2` describes what test the timeout is used for. If no index `2` is provided, it is inferred that the timeout provided applies to all tests.
|
||||
- `c` - a lowercase string describing the checks conducted by a monitor. Examples include `open`, `read`, `write`, `auth`, `nip11`, `dns`, and `geo`.
|
||||
- `g` - [NIP-52](https://github.com/nostr-protocol/nips/blob/master/52.md) geohash tag
|
||||
- `g` - [NIP-52](https://github.com/nostr-protocol/nips/blob/master/11.md) geohash tag
|
||||
|
||||
Monitors SHOULD also publish a `kind 0` profile and a `kind 10002` relay selections event.
|
||||
|
||||
|
||||
75
71.md
75
71.md
@@ -20,27 +20,13 @@ Nothing except cavaliership and common sense prevents a _short_ video from being
|
||||
|
||||
The format uses a _regular event_ kind `21` for _normal_ videos and `22` for _short_ videos.
|
||||
|
||||
## Addressable Video Events
|
||||
|
||||
For content that may need updates after publication (such as correcting metadata, descriptions, or handling URL migrations), addressable versions are available:
|
||||
|
||||
- Kind `34235` for _addressable normal videos_
|
||||
- Kind `34236` for _addressable short videos_
|
||||
|
||||
These addressable events follow the same format as their regular counterparts but include a `d` tag as a unique identifier and can be updated while maintaining the same addressable reference. This is particularly useful for:
|
||||
|
||||
- Metadata corrections (descriptions, titles, tags) without republishing
|
||||
- Preservation of imported content IDs from legacy platforms
|
||||
- URL migration when hosting changes
|
||||
- Platform migration tracking
|
||||
|
||||
The `.content` of these events is a summary or description on the video content.
|
||||
|
||||
The primary source of video information is the `imeta` tags which is defined in [NIP-92](92.md)
|
||||
|
||||
Each `imeta` tag can be used to specify a variant of the video by the `dim` & `m` properties.
|
||||
|
||||
This NIP defines the following additional `imeta` properties aside from those listed in [NIP-92](92.md) & [NIP-94](94.md):
|
||||
This NIP defines the following additional `imeta` properties aside form those listen in [NIP-92](92.md) & [NIP-94](94.md):
|
||||
|
||||
* `duration` (recommended) the duration of the video/audio in seconds (floating point number)
|
||||
* `bitrate` (recommended) the average bitrate of the video/audio in bits/sec
|
||||
@@ -95,9 +81,6 @@ The `image` tag contains a preview image (at the same resolution). Multiple `ima
|
||||
|
||||
Additionally `service nip96` may be included to allow clients to search the authors NIP-96 server list to find the file using the hash.
|
||||
|
||||
### Required tags for addressable events:
|
||||
* `d` - Unique identifier for this video (user-chosen string, required for kinds 34235, 34236)
|
||||
|
||||
### Other tags:
|
||||
* `title` (required) title of the video
|
||||
* `published_at`, for the timestamp in unix seconds (stringified) of the first time the video was published
|
||||
@@ -109,9 +92,6 @@ Additionally `service nip96` may be included to allow clients to search the auth
|
||||
* `p` (optional, repeated) 32-bytes hex pubkey of a participant in the video, optional recommended relay URL
|
||||
* `r` (optional, repeated) references / links to web pages
|
||||
|
||||
### Optional tags for imported content:
|
||||
* `origin` - Track original platform and ID: `["origin", "<platform>", "<external-id>", "<original-url>", "<optional-metadata>"]`
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"id": "<32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>",
|
||||
@@ -155,56 +135,3 @@ Additionally `service nip96` may be included to allow clients to search the auth
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Addressable Event Example
|
||||
|
||||
```jsonc
|
||||
{
|
||||
"id": <32-bytes lowercase hex-encoded SHA-256 of the the serialized event data>,
|
||||
"pubkey": <32-bytes lowercase hex-encoded public key of the event creator>,
|
||||
"created_at": <Unix timestamp in seconds>,
|
||||
"kind": 34235 | 34236,
|
||||
"content": "<summary / description of video>",
|
||||
"tags": [
|
||||
["d", "<unique-identifier>"],
|
||||
["title", "<title of video>"],
|
||||
["published_at", "<unix timestamp>"],
|
||||
["alt", "<description for accessibility>"],
|
||||
|
||||
// video data
|
||||
["imeta",
|
||||
"url https://example.com/media.mp4",
|
||||
"m video/mp4",
|
||||
"dim 480x480",
|
||||
"blurhash eVF$^OI:${M{%LRjWBoLoLaeR*",
|
||||
"image https://example.com/thumb.jpg",
|
||||
"x 3093509d1e0bc604ff60cb9286f4cd7c781553bc8991937befaacfdc28ec5cdc"
|
||||
],
|
||||
|
||||
["duration", <duration in seconds>],
|
||||
["content-warning", "<reason>"],
|
||||
|
||||
// origin tracking for imported content
|
||||
["origin", "<platform>", "<external-id>", "<original-url>", "<optional-metadata>"],
|
||||
|
||||
// participants
|
||||
["p", "<32-bytes hex of a pubkey>", "<optional recommended relay URL>"],
|
||||
|
||||
// hashtags
|
||||
["t", "<tag>"],
|
||||
["t", "<tag>"],
|
||||
|
||||
// reference links
|
||||
["r", "<url>"]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Referencing Addressable Events
|
||||
|
||||
To reference an addressable video:
|
||||
|
||||
```
|
||||
["a", "34235:<pubkey>:<d-tag-value>", "<relay-url>"] // for normal videos
|
||||
["a", "34236:<pubkey>:<d-tag-value>", "<relay-url>"] // for short videos
|
||||
```
|
||||
|
||||
2
72.md
2
72.md
@@ -41,7 +41,7 @@ The goal of this NIP is to enable public communities. It defines the replaceable
|
||||
|
||||
## Posting to a community
|
||||
|
||||
[NIP-22](22.md) kind 1111 events SHOULD be used for text notes posted to a community, with the `A` tag always scoped to the community definition.
|
||||
[NIP-22](NIP-22) kind 1111 events SHOULD be used for text notes posted to a community, with the `A` tag always scoped to the community definition.
|
||||
|
||||
### Top-level posts
|
||||
|
||||
|
||||
2
88.md
2
88.md
@@ -48,7 +48,7 @@ Example Event
|
||||
|
||||
The response event is a `kind:1018` event. It contains an e tag with the poll event it is referencing, followed by one or more response tags.
|
||||
|
||||
- **response** : The tag contains "response" as its first positional argument followed by the option Id selected.
|
||||
- **response** : The tag contains "response" as it's first positional argument followed by the option Id selected.
|
||||
|
||||
The responses are meant to be published to the relays specified in the poll event.
|
||||
|
||||
|
||||
2
90.md
2
90.md
@@ -58,7 +58,7 @@ All tags are optional.
|
||||
* `<input-type>`: The way this argument should be interpreted. MUST be one of:
|
||||
* `url`: A URL to be fetched of the data that should be processed.
|
||||
* `event`: A Nostr event ID.
|
||||
* `job`: The output of a previous job with the specified event ID. The determination of which output to build upon is up to the service provider to decide (e.g. waiting for a signaling from the customer, waiting for a payment, etc.)
|
||||
* `job`: The output of a previous job with the specified event ID. The dermination of which output to build upon is up to the service provider to decide (e.g. waiting for a signaling from the customer, waiting for a payment, etc.)
|
||||
* `text`: `<data>` is the value of the input, no resolution is needed
|
||||
* `<relay>`: If `event` or `job` input-type, the relay where the event/job was published, otherwise optional or empty string
|
||||
* `<marker>`: An optional field indicating how this input should be used within the context of the job
|
||||
|
||||
2
C0.md
2
C0.md
@@ -25,7 +25,7 @@ The `.content` field contains the actual code snippet text.
|
||||
- `runtime` - Runtime or environment specification (e.g., "node v18.15.0", "python 3.11")
|
||||
- `license` - License under which the code (along with any related data contained within the event, when available, such as the description) is shared. This MUST be a standard [SPDX](https://spdx.org/licenses/) short identifier (e.g., "MIT", "GPL-3.0-or-later", "Apache-2.0") when available. An additional parameter containing a reference to the actual text of the license MAY be provided. This tag can be repeated, to indicate multi-licensing, allowing recipients to use the code under any license of choosing among the referenced ones
|
||||
- `dep` - Dependency required for the code to run (can be repeated)
|
||||
- `repo` - Reference to a repository where this code originates. This MUST be either a standard URL or, alternatively, the address of a [NIP-34](34.md) Git repository announcement event in the form `"30617:<32-bytes hex a pubkey>:<d tag value>"`. If a repository announcement is referenced, a recommended relay URL where to find the event should be provided as an additional parameter
|
||||
- `repo` - Reference to a repository where this code originates. This MUST be a either standard URL or, alternatively, the address of a [NIP-34](34.md) Git repository announcement event in the form `"30617:<32-bytes hex a pubkey>:<d tag value>"`. If a repository announcement is referenced, a recommended relay URL where to find the event should be provided as an additional parameter
|
||||
|
||||
## Format
|
||||
|
||||
|
||||
@@ -279,8 +279,6 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
|
||||
| `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) |
|
||||
| `38172` | Cashu Mint Announcement | [87](87.md) |
|
||||
|
||||
Reference in New Issue
Block a user