Another 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.
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:
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.
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).