[NIP-26] Fix for multiple kinds in delegation conditions (#208)

This commit is contained in:
kdmukai 2023-02-06 09:21:58 -06:00 committed by GitHub
parent 025beb332c
commit 6a11f4d4cd
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

26
26.md
View File

@ -38,20 +38,34 @@ The following fields and operators are supported in the above query string:
*Fields*:
1. `kind`
- *Operators*:
- `=${KIND_NUMBER}` - delegatee may only sign events of this kind
- `=${KIND_NUMBERS}` - delegatee may only sign events of listed kind(s) (comma-separated)
2. `created_at`
- *Operators*:
- `<${TIMESTAMP}` - delegatee may only sign events created ***before*** the specified timestamp
- `>${TIMESTAMP}` - delegatee may only sign events created ***after*** the specified timestamp
- `<${TIMESTAMP}` - delegatee may only sign events whose `created_at` is ***before*** the specified timestamp
- `>${TIMESTAMP}` - delegatee may only sign events whose `created_at` is ***after*** the specified timestamp
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 `&`.
Multiple conditions can be used in a single query string, including on the same field. Conditions must be combined with `&`.
Multiple conditions should be treated as `AND` requirements; all conditions must be true for the delegated event to be valid.
Multiple comma-separated `kind` values should be interpreted as:
```
# kind=0,1,3000
... AND (kind == 0 OR kind == 1 OR kind == 3000) AND ...
```
For example, the following condition strings are valid:
- `kind=1`
- `created_at<1675721813`
- `kind=1&created_at<1675721813`
- `kind=0&kind=1&created_at>1675721813`
- `kind=0,1,3000&created_at>1675721813`
- `kind=1&created_at>1674777689&created_at<1675721813`
However, specifying multiple _separate_ `kind` conditions is impossible to satisfy:
- `kind=1&kind=5`
There is no way for an event to satisfy the `AND` requirement of being both `kind`s simultaneously.
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.
#### Example