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.
One of the biggest problems of the original version of NIP-26 is that if a client doesn't follow it, it ends not showing pertinent events, or showing them unlinked from the original author.
This version 2 follow a different approach: it keeps the original (root) key in the usual `pubkey` field and ask to check the event's signature against a new `sub_pubkey` field, if it exists; so it proposes to _extend_ the signature check with a secondary pattern that is signaled by the presence of the `sub_pubkey` field.
The rest of the nip remains the same.
This update has some interesting benefits:
* It is backward compatible with the standard signature;
* The code used by clients to retrieve and show events stay untouched;
* The code used by relays to answer the requests stay untouched;
* The needed update to the code that verify the signature is minimal, just a conditional check (plus the check of the embedded Schnorr signature);
The support at relays level have to be complete, otherwise events would be discarded as formally invalid.
Probably a good approach could be to set a deadline for the relays, and a later one for the clients.
Clients that doesn't immediately support this spec after the migration could just show the note as 'unverified' without disrupting the full experience;
#### Introducing the 'sub_pubkey' field
This v2.0 of the NIP introduces the `sub_pubkey` is the secondary key used to actually sig the event:
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 the vast majority of use-cases, it is advisable that:
1. 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.
2. 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.
Delegation string to grant note publishing authorization to the delegatee (477318cf) from now, for the next 30 days, given the current timestamp is `1674834236`.
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`, `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.