{"id":"92c72ca093a0779f6b825d8fe5537739febd7fbee875608dacb65c98192a30cf","pubkey":"2b39b4ffe62933df970e19366c22c1e092f953f83fcfed754e0f04d5a3b459f9","created_at":1780225830,"kind":30817,"tags":[["d","nip-26"],["title","NIP-26: Delegated Event Signing"],["summary","The delegation tag, which let one key authorise another to sign events on its behalf."],["s","unrecommended"],["t","nostr"],["t","nip"],["alt","A specification: NIP-26: Delegated Event Signing"],["client","openspecs-import"],["published_at","1659602018"],["proxy","https://github.com/nostr-protocol/nips/blob/656cecc7c0a815b6a2b218d3b5d6f078b3f4dbab/26.md","web"],["x","6a5de661716de15145c8c638a3bb0b8541f5929f13a1fa456392a12d124e1959"]],"content":"> __Warning__  `unrecommended`: adds unnecessary burden for little gain\n\nNIP-26\n=======\n\nDelegated Event Signing\n-----------------------\n\n`draft` `unrecommended` `optional` `relay`\n\nThis NIP defines how events can be delegated so that they can be signed by other keypairs.\n\nAnother application of this proposal is to abstract away the use of the 'root' keypairs when interacting with clients. For example, a user could generate new keypairs for each client they wish to use and authorize those keypairs to generate events on behalf of their root pubkey, where the root keypair is stored in cold storage. \n\n#### Introducing the 'delegation' tag\n\nThis NIP introduces a new tag: `delegation` which is formatted as follows:\n\n```json\n[\n  \"delegation\",\n  <pubkey of the delegator>,\n  <conditions query string>,\n  <delegation token: 64-byte Schnorr signature of the sha256 hash of the delegation string>\n]\n```\n\n##### Delegation Token\n\nThe **delegation token** should be a 64-byte Schnorr signature of the sha256 hash of the following string:\n\n```\nnostr:delegation:<pubkey of publisher (delegatee)>:<conditions query string>\n```\n\n##### Conditions Query String\n\nThe following fields and operators are supported in the above query string:\n\n*Fields*:\n1. `kind`\n   -  *Operators*:\n      -  `=${KIND_NUMBER}` - delegatee may only sign events of this kind\n2. `created_at`\n   -  *Operators*:\n      -  `<${TIMESTAMP}` - delegatee may only sign events created ***before*** the specified timestamp\n      -  `>${TIMESTAMP}` - delegatee may only sign events created ***after*** the specified timestamp\n\nIn 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 `&`.\n\nFor example, the following condition strings are valid:\n\n- `kind=1&created_at<1675721813`\n- `kind=0&kind=1&created_at>1675721813`\n- `kind=1&created_at>1674777689&created_at<1675721813`\n\nFor the vast majority of use-cases, it is advisable that:\n1. 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.\n2. Query strings should include a `created_at` ***before*** condition that is not empty and is not some extremely distant time in the future. If delegations are not limited in time scope, they expose similar security risks to simply using the root key for authentication.\n\n#### Example\n\n```\n# Delegator:\nprivkey: ee35e8bb71131c02c1d7e73231daa48e9953d329a4b701f7133c8f46dd21139c\npubkey:  8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd\n\n# Delegatee:\nprivkey: 777e4f60b4aa87937e13acc84f7abcc3c93cc035cb4c1e9f7a9086dd78fffce1\npubkey:  477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396\n```\n\nDelegation string to grant note publishing authorization to the delegatee (477318cf) from now, for the next 30 days, given the current timestamp is `1674834236`.\n```json\nnostr:delegation:477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396:kind=1&created_at>1674834236&created_at<1677426236\n```\n\nThe delegator (8e0d3d3e) then signs a SHA256 hash of the above delegation string, the result of which is the delegation token:\n```\n6f44d7fe4f1c09f3954640fb58bd12bae8bb8ff4120853c4693106c82e920e2b898f1f9ba9bd65449a987c39c0423426ab7b53910c0c6abfb41b30bc16e5f524\n```\n\nThe 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.\n```json\n{\n  \"id\": \"e93c6095c3db1c31d15ac771f8fc5fb672f6e52cd25505099f62cd055523224f\",\n  \"pubkey\": \"477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396\",\n  \"created_at\": 1677426298,\n  \"kind\": 1,\n  \"tags\": [\n    [\n      \"delegation\",\n      \"8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd\",\n      \"kind=1&created_at>1674834236&created_at<1677426236\",\n      \"6f44d7fe4f1c09f3954640fb58bd12bae8bb8ff4120853c4693106c82e920e2b898f1f9ba9bd65449a987c39c0423426ab7b53910c0c6abfb41b30bc16e5f524\"\n    ]\n  ],\n  \"content\": \"Hello, world!\",\n  \"sig\": \"633db60e2e7082c13a47a6b19d663d45b2a2ebdeaf0b4c35ef83be2738030c54fc7fd56d139652937cdca875ee61b51904a1d0d0588a6acd6168d7be2909d693\"\n}\n```\n\nThe 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.\n\nClients should display the delegated note as if it was published directly by the delegator (8e0d3d3e).\n\n\n#### Relay & Client Support\n\nRelays should answer requests such as `[\"REQ\", \"\", {\"authors\": [\"A\"]}]` by querying both the `pubkey` and delegation tags `[1]` value.\n\nRelays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf).\n","sig":"29c535d912132559214e6d98bffe99e0a776cc090a704648152b6b4b2c8a0a8cce8f09c84a0a109a908a4a042b7d89e1f43889b5bed723caa1176fda73c39e98"}