From e55c86d207e11a29ccceaa0d28554a8eca9440cf Mon Sep 17 00:00:00 2001 From: kdmukai Date: Sat, 7 Jan 2023 17:12:48 -0600 Subject: NIP-26: Change example condition to expire at a future date (#157) also Regenerate example PKs and improve organization/presentation. --- 26.md | 46 ++++++++++++++++++++++++++++++++-------------- 1 file changed, 32 insertions(+), 14 deletions(-) (limited to '26.md') diff --git a/26.md b/26.md index 4557875..fc4d6f8 100644 --- a/26.md +++ b/26.md @@ -25,41 +25,59 @@ This NIP introduces a new tag: `delegation` which is formatted as follows: ##### Delegation Token -The **delegation token** should be a 64-bytes schnorr signature of the sha256 hash of the following string: +The **delegation token** should be a 64-byte Schnorr signature of the sha256 hash of the following string: ``` nostr:delegation:: ``` -For example, the token `c33c88ba78ec3c760e49db591ac5f7b129e3887c8af7729795e85a0588007e5ac89b46549232d8f918eefd73e726cb450135314bfda419c030d0b6affe401ec1` is signed by `86f0689bd48dcd19c67a19d994f938ee34f251d8c39976290955ff585f2db42e` and consists of: -```json -nostr:delegation:62903b1ff41559daf9ee98ef1ae67cc52f301bb5ce26d14baba3052f649c3f49:kind=1&created_at>1640995200 +#### Example + ``` +# Delegator: +privkey: ee35e8bb71131c02c1d7e73231daa48e9953d329a4b701f7133c8f46dd21139c +pubkey: 8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd -#### Example +# Delegatee: +privkey: 777e4f60b4aa87937e13acc84f7abcc3c93cc035cb4c1e9f7a9086dd78fffce1 +pubkey: 477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396 +``` + +Delegation string to grant note publishing authorization to the delegatee (477318cf) for the next 30 days. +```json +nostr:delegation:477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396:kind=1&created_at<1675721885 +``` -Below is an example of an event published by `62903b1ff41559daf9ee98ef1ae67cc52f301bb5ce26d14baba3052f649c3f49`, on behalf of `86f0689bd48dcd19c67a19d994f938ee34f251d8c39976290955ff585f2db42e`. +The delegator (8e0d3d3e) then signs the above delegation string, the result of which is the delegation token: +``` +cbc49c65fe04a3181d72fb5a9f1c627e329d5f45d300a2dfed1c3e788b7834dad48a6d27d8e244af39c77381334ede97d4fd15abe80f35fda695fd9bd732aa1e +``` +The delegatee (477318cf) can now construct an event on behalf of the delegator (8e0d3d3e). The delegatee then signs the event with its own private key and publishes. ```json { - "id": "a080fd288b60ac2225ff2e2d815291bd730911e583e177302cc949a15dc2b2dc", - "pubkey": "62903b1ff41559daf9ee98ef1ae67cc52f301bb5ce26d14baba3052f649c3f49", - "created_at": 1660896109, + "id": "ac4c71e69c39b1bd605de812543ebfaf81d5af365354f061d48981fb61e00b8a", + "pubkey": "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396", + "created_at": 1673129661, "kind": 1, "tags": [ [ "delegation", - "86f0689bd48dcd19c67a19d994f938ee34f251d8c39976290955ff585f2db42e", - "kind=1&created_at>1640995200", - "c33c88ba78ec3c760e49db591ac5f7b129e3887c8af7729795e85a0588007e5ac89b46549232d8f918eefd73e726cb450135314bfda419c030d0b6affe401ec1" + "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd", + "kind=1&created_at<1675721813", + "cbc49c65fe04a3181d72fb5a9f1c627e329d5f45d300a2dfed1c3e788b7834dad48a6d27d8e244af39c77381334ede97d4fd15abe80f35fda695fd9bd732aa1e" ] ], - "content": "Hello world", - "sig": "cd4a3cd20dc61dcbc98324de561a07fd23b3d9702115920c0814b5fb822cc5b7c5bcdaf3fa326d24ed50c5b9c8214d66c75bae34e3a84c25e4d122afccb66eb6" + "content": "Hello, world!", + "sig": "55ed9a78d6449b8c189b6dbc34bc4bcd34dcc79e6da6c9078268fe3d7c0cbe62b1b907ffb76ba591e83895b1329bf2e6e16f3b0cd5827272e420d419c6f0f0b5" } ``` +The event should be considered a valid delegation if the conditions are satisfied (`kind=1` and `created_at<1675721813` in this example) and, upon validation of the delegation token, are found to be unchanged from the conditions in the original delegation string. + +Clients should display the delegated note as if it was published directly by the delegator (8e0d3d3e). + #### Relay & Client Querying Support -- cgit v1.2.3 From 95fa5a4a5f15b54a0e98edccf480ca5b03896f99 Mon Sep 17 00:00:00 2001 From: Zack Wynne Date: Fri, 27 Jan 2023 03:11:27 -0800 Subject: NIP-26: adding section documenting valid fields and operators for conditions string (#194) --- 26.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to '26.md') diff --git a/26.md b/26.md index fc4d6f8..3eb1856 100644 --- a/26.md +++ b/26.md @@ -31,6 +31,26 @@ The **delegation token** should be a 64-byte Schnorr signature of the sha256 has nostr:delegation:: ``` +##### Conditions Query String + +The following fields and operators are supported in the above query string: + +*Fields*: +1. `kind` + - *Operators*: + - `=${KIND_NUMBER}` - delegator may only sign events of this kind +2. `created_at` + - *Operators*: + - `<${TIMESTAMP}` - delegator may only sign events created ***before*** the specified timestamp + - `>${TIMESTAMP}` - delegator may only sign events created ***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 `&`. + +For example, the following condition strings are valid: + +- `kind=1&created_at<1675721813` +- `kind=0&kind=1&created_at>1675721813` +- `kind=1&created_at>1674777689&created_at<1675721813` #### Example -- cgit v1.2.3 From 3b1cd96798a9c6b6607b01814b31266dc41934f0 Mon Sep 17 00:00:00 2001 From: Zack Wynne Date: Fri, 27 Jan 2023 11:47:54 -0700 Subject: NIP-26: fixing typo in conditions query string section --- 26.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to '26.md') diff --git a/26.md b/26.md index 3eb1856..1299b72 100644 --- a/26.md +++ b/26.md @@ -38,11 +38,11 @@ The following fields and operators are supported in the above query string: *Fields*: 1. `kind` - *Operators*: - - `=${KIND_NUMBER}` - delegator may only sign events of this kind + - `=${KIND_NUMBER}` - delegatee may only sign events of this kind 2. `created_at` - *Operators*: - - `<${TIMESTAMP}` - delegator may only sign events created ***before*** the specified timestamp - - `>${TIMESTAMP}` - delegator may only sign events created ***after*** the specified timestamp + - `<${TIMESTAMP}` - delegatee may only sign events created ***before*** the specified timestamp + - `>${TIMESTAMP}` - delegatee may only sign events created ***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 `&`. -- cgit v1.2.3 From 38074f664301b0bcb65f0b77da533ffba8df46e4 Mon Sep 17 00:00:00 2001 From: Ben Hayward Date: Wed, 1 Feb 2023 12:05:25 +0000 Subject: NIP-26: Advice on using after operators in conditions query string (#199) Co-authored-by: Ben Hayward --- 26.md | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-) (limited to '26.md') diff --git a/26.md b/26.md index 1299b72..955a043 100644 --- a/26.md +++ b/26.md @@ -19,7 +19,7 @@ This NIP introduces a new tag: `delegation` which is formatted as follows: "delegation", , , - <64-bytes schnorr signature of the sha256 hash of the delegation token> + <64-byte Schnorr signature of the sha256 hash of the delegation token> ] ``` @@ -52,6 +52,8 @@ For example, the following condition strings are valid: - `kind=0&kind=1&created_at>1675721813` - `kind=1&created_at>1674777689&created_at<1675721813` +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 ``` @@ -64,41 +66,41 @@ privkey: 777e4f60b4aa87937e13acc84f7abcc3c93cc035cb4c1e9f7a9086dd78fffce1 pubkey: 477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396 ``` -Delegation string to grant note publishing authorization to the delegatee (477318cf) for the next 30 days. +Delegation string to grant note publishing authorization to the delegatee (477318cf) from now, for the next 30 days, given the current timestamp is `1674834236`. ```json -nostr:delegation:477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396:kind=1&created_at<1675721885 +nostr:delegation:477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396:kind=1&created_at>1674834236&created_at<1677426236 ``` -The delegator (8e0d3d3e) then signs the above delegation string, the result of which is the delegation token: +The delegator (8e0d3d3e) then signs a SHA256 hash of the above delegation string, the result of which is the delegation token: ``` -cbc49c65fe04a3181d72fb5a9f1c627e329d5f45d300a2dfed1c3e788b7834dad48a6d27d8e244af39c77381334ede97d4fd15abe80f35fda695fd9bd732aa1e +6f44d7fe4f1c09f3954640fb58bd12bae8bb8ff4120853c4693106c82e920e2b898f1f9ba9bd65449a987c39c0423426ab7b53910c0c6abfb41b30bc16e5f524 ``` The delegatee (477318cf) can now construct an event on behalf of the delegator (8e0d3d3e). The delegatee then signs the event with its own private key and publishes. ```json { - "id": "ac4c71e69c39b1bd605de812543ebfaf81d5af365354f061d48981fb61e00b8a", + "id": "e93c6095c3db1c31d15ac771f8fc5fb672f6e52cd25505099f62cd055523224f", "pubkey": "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396", - "created_at": 1673129661, + "created_at": 1677426298, "kind": 1, "tags": [ [ "delegation", "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd", - "kind=1&created_at<1675721813", - "cbc49c65fe04a3181d72fb5a9f1c627e329d5f45d300a2dfed1c3e788b7834dad48a6d27d8e244af39c77381334ede97d4fd15abe80f35fda695fd9bd732aa1e" + "kind=1&created_at>1674834236&created_at<1677426236", + "6f44d7fe4f1c09f3954640fb58bd12bae8bb8ff4120853c4693106c82e920e2b898f1f9ba9bd65449a987c39c0423426ab7b53910c0c6abfb41b30bc16e5f524" ] ], "content": "Hello, world!", - "sig": "55ed9a78d6449b8c189b6dbc34bc4bcd34dcc79e6da6c9078268fe3d7c0cbe62b1b907ffb76ba591e83895b1329bf2e6e16f3b0cd5827272e420d419c6f0f0b5" + "sig": "633db60e2e7082c13a47a6b19d663d45b2a2ebdeaf0b4c35ef83be2738030c54fc7fd56d139652937cdca875ee61b51904a1d0d0588a6acd6168d7be2909d693" } ``` -The event should be considered a valid delegation if the conditions are satisfied (`kind=1` and `created_at<1675721813` in this example) and, upon validation of the delegation token, are found to be unchanged from the conditions in the original delegation string. +The event should be considered a valid delegation if the conditions are satisfied (`kind=1`, `created_at>1674834236` and `created_at<1677426236` in this example) and, upon validation of the delegation token, are found to be unchanged from the conditions in the original delegation string. Clients should display the delegated note as if it was published directly by the delegator (8e0d3d3e). #### Relay & Client Querying Support -Relays should answer requests such as `["REQ", "", {"authors": ["A"]}]` by querying both the `pubkey` and delegation tags `[1]` value. +Relays should answer requests such as `["REQ", "", {"authors": ["A"]}]` by querying both the `pubkey` and delegation tags `[1]` value. \ No newline at end of file -- cgit v1.2.3 From 6a11f4d4cd0159c517414ffa6cfc646f8c7c9da3 Mon Sep 17 00:00:00 2001 From: kdmukai Date: Mon, 6 Feb 2023 09:21:58 -0600 Subject: [NIP-26] Fix for multiple `kind`s in delegation conditions (#208) --- 26.md | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) (limited to '26.md') diff --git a/26.md b/26.md index 955a043..0f8f64a 100644 --- a/26.md +++ b/26.md @@ -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 `&`. -For example, the following condition strings are valid: +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 -- cgit v1.2.3 From 3f39a241b170a4e11d5c162c03f03da4fedb0756 Mon Sep 17 00:00:00 2001 From: fiatjaf Date: Wed, 8 Feb 2023 08:36:07 -0300 Subject: Revert "[NIP-26] Fix for multiple `kind`s in delegation conditions (#208)" This reverts commit 6a11f4d4cd0159c517414ffa6cfc646f8c7c9da3. --- 26.md | 26 ++++++-------------------- 1 file changed, 6 insertions(+), 20 deletions(-) (limited to '26.md') diff --git a/26.md b/26.md index 0f8f64a..955a043 100644 --- a/26.md +++ b/26.md @@ -38,34 +38,20 @@ The following fields and operators are supported in the above query string: *Fields*: 1. `kind` - *Operators*: - - `=${KIND_NUMBERS}` - delegatee may only sign events of listed kind(s) (comma-separated) + - `=${KIND_NUMBER}` - delegatee may only sign events of this kind 2. `created_at` - *Operators*: - - `<${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 + - `<${TIMESTAMP}` - delegatee may only sign events created ***before*** the specified timestamp + - `>${TIMESTAMP}` - delegatee may only sign events created ***after*** the specified timestamp -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 ... -``` +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 `&`. For example, the following condition strings are valid: -- `kind=1` -- `created_at<1675721813` + - `kind=1&created_at<1675721813` -- `kind=0,1,3000&created_at>1675721813` +- `kind=0&kind=1&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 -- cgit v1.2.3 From 23b863ad65694f041bbe921168d96cd274b998d3 Mon Sep 17 00:00:00 2001 From: Adam B <13562139+catenocrypt@users.noreply.github.com> Date: Mon, 13 Feb 2023 12:34:12 +0100 Subject: Minor change to make delegation token/string naming consistent --- 26.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to '26.md') diff --git a/26.md b/26.md index 955a043..11468c0 100644 --- a/26.md +++ b/26.md @@ -19,7 +19,7 @@ This NIP introduces a new tag: `delegation` which is formatted as follows: "delegation", , , - <64-byte Schnorr signature of the sha256 hash of the delegation token> + ] ``` -- cgit v1.2.3 From ab93992948d1f3b8c05ef268ddc85d9f667424fa Mon Sep 17 00:00:00 2001 From: codytseng Date: Thu, 13 Apr 2023 20:31:35 +0800 Subject: NIP-26 allow the delegator to delete the events published by the delegatee --- 26.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to '26.md') diff --git a/26.md b/26.md index 11468c0..b8fa902 100644 --- a/26.md +++ b/26.md @@ -101,6 +101,8 @@ The event should be considered a valid delegation if the conditions are satisfie Clients should display the delegated note as if it was published directly by the delegator (8e0d3d3e). -#### Relay & Client Querying Support +#### Relay & Client Support -Relays should answer requests such as `["REQ", "", {"authors": ["A"]}]` by querying both the `pubkey` and delegation tags `[1]` value. \ No newline at end of file +Relays should answer requests such as `["REQ", "", {"authors": ["A"]}]` by querying both the `pubkey` and delegation tags `[1]` value. + +Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf). \ No newline at end of file -- cgit v1.2.3