diff options
| -rw-r--r-- | 05.md | 2 | ||||
| -rw-r--r-- | 26.md | 26 | ||||
| -rw-r--r-- | README.md | 1 |
3 files changed, 22 insertions, 7 deletions
| @@ -50,7 +50,7 @@ or with the **optional** `"relays"` attribute: | |||
| 50 | 50 | ||
| 51 | If the pubkey matches the one given in `"names"` (as in the example above) that means the association is right and the `"nip05"` identifier is valid and can be displayed. | 51 | If the pubkey matches the one given in `"names"` (as in the example above) that means the association is right and the `"nip05"` identifier is valid and can be displayed. |
| 52 | 52 | ||
| 53 | The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays a that user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available. | 53 | The optional `"relays"` attribute may contain an object with public keys as properties and arrays of relay URLs as values. When present, that can be used to help clients learn in which relays that user may be found. Web servers which serve `/.well-known/nostr.json` files dynamically based on the query string SHOULD also serve the relays data for any name they serve in the same reply when that is available. |
| 54 | 54 | ||
| 55 | ## Finding users from their NIP-05 identifier | 55 | ## Finding users from their NIP-05 identifier |
| 56 | 56 | ||
| @@ -38,20 +38,34 @@ The following fields and operators are supported in the above query string: | |||
| 38 | *Fields*: | 38 | *Fields*: |
| 39 | 1. `kind` | 39 | 1. `kind` |
| 40 | - *Operators*: | 40 | - *Operators*: |
| 41 | - `=${KIND_NUMBER}` - delegatee may only sign events of this kind | 41 | - `=${KIND_NUMBERS}` - delegatee may only sign events of listed kind(s) (comma-separated) |
| 42 | 2. `created_at` | 42 | 2. `created_at` |
| 43 | - *Operators*: | 43 | - *Operators*: |
| 44 | - `<${TIMESTAMP}` - delegatee may only sign events created ***before*** the specified timestamp | 44 | - `<${TIMESTAMP}` - delegatee may only sign events whose `created_at` is ***before*** the specified timestamp |
| 45 | - `>${TIMESTAMP}` - delegatee may only sign events created ***after*** the specified timestamp | 45 | - `>${TIMESTAMP}` - delegatee may only sign events whose `created_at` is ***after*** the specified timestamp |
| 46 | 46 | ||
| 47 | In order to create a single condition, you must use a supported field and operator. Multiple conditions can be used in a single query string, including on the same field. Conditions must be combined with `&`. | 47 | Multiple conditions can be used in a single query string, including on the same field. Conditions must be combined with `&`. |
| 48 | 48 | ||
| 49 | For example, the following condition strings are valid: | 49 | Multiple conditions should be treated as `AND` requirements; all conditions must be true for the delegated event to be valid. |
| 50 | |||
| 51 | Multiple comma-separated `kind` values should be interpreted as: | ||
| 52 | ``` | ||
| 53 | # kind=0,1,3000 | ||
| 54 | ... AND (kind == 0 OR kind == 1 OR kind == 3000) AND ... | ||
| 55 | ``` | ||
| 50 | 56 | ||
| 57 | For example, the following condition strings are valid: | ||
| 58 | - `kind=1` | ||
| 59 | - `created_at<1675721813` | ||
| 51 | - `kind=1&created_at<1675721813` | 60 | - `kind=1&created_at<1675721813` |
| 52 | - `kind=0&kind=1&created_at>1675721813` | 61 | - `kind=0,1,3000&created_at>1675721813` |
| 53 | - `kind=1&created_at>1674777689&created_at<1675721813` | 62 | - `kind=1&created_at>1674777689&created_at<1675721813` |
| 54 | 63 | ||
| 64 | However, specifying multiple _separate_ `kind` conditions is impossible to satisfy: | ||
| 65 | - `kind=1&kind=5` | ||
| 66 | |||
| 67 | There is no way for an event to satisfy the `AND` requirement of being both `kind`s simultaneously. | ||
| 68 | |||
| 55 | For the vast majority of use-cases, it is advisable that query strings should include a `created_at` ***after*** condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator's behalf. | 69 | For the vast majority of use-cases, it is advisable that query strings should include a `created_at` ***after*** condition reflecting the current time, to prevent the delegatee from publishing historic notes on the delegator's behalf. |
| 56 | 70 | ||
| 57 | #### Example | 71 | #### Example |
| @@ -50,6 +50,7 @@ NIPs stand for **Nostr Implementation Possibilities**. They exist to document wh | |||
| 50 | | 45-49 | Public Chat Reserved | [28](28.md) | | 50 | | 45-49 | Public Chat Reserved | [28](28.md) | |
| 51 | | 10002 | Relay List Metadata | [65](65.md) | | 51 | | 10002 | Relay List Metadata | [65](65.md) | |
| 52 | | 22242 | Client Authentication | [42](42.md) | | 52 | | 22242 | Client Authentication | [42](42.md) | |
| 53 | | 1000-9999 | Regular Events Reserved | [16](16.md) | | ||
| 53 | | 10000-19999 | Replaceable Events Reserved | [16](16.md) | | 54 | | 10000-19999 | Replaceable Events Reserved | [16](16.md) | |
| 54 | | 20000-29999 | Ephemeral Events Reserved | [16](16.md) | | 55 | | 20000-29999 | Ephemeral Events Reserved | [16](16.md) | |
| 55 | | 30000-39999 | Param. Repl. Events Reserved| [33](33.md) | | 56 | | 30000-39999 | Param. Repl. Events Reserved| [33](33.md) | |