nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-11-09 22:09:06 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

NIP-26: Draft v2 with sub_pubkey field

Browse Source
This commit is contained in:
dtonon 2024-07-12 15:57:21 +02:00
parent cf563d71f4
commit 913f5f2296
1 changed files with 35 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
26.md
View File

@ -1,14 +1,44 @@
NIP-26 NIP-26
======= =======
Delegated Event Signing Delegated Event Signing, v2.0
----- -----
`draft` `optional` `draft` `mandatory`
This NIP defines how events can be delegated so that they can be signed by other keypairs. This NIP defines how events can be delegated so that they can be signed by other keypairs.
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. 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:
```
{
"id": "e93c6095c3db1c31d15ac771f8fc5fb672f6e52cd25505099f62cd055523224f",
"pubkey": "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
"sub_pubkey": "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
"created_at": 1677426298,
"kind": 1,
...
}
```
#### Introducing the 'delegation' tag #### Introducing the 'delegation' tag
@ -82,7 +112,8 @@ The delegatee (477318cf) can now construct an event on behalf of the delegator (
```json ```json
{ {
"id": "e93c6095c3db1c31d15ac771f8fc5fb672f6e52cd25505099f62cd055523224f", "id": "e93c6095c3db1c31d15ac771f8fc5fb672f6e52cd25505099f62cd055523224f",
"pubkey": "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396", "pubkey": "8e0d3d3eb2881ec137a11debe736a9086715a8c8beeeda615780064d68bc25dd",
"sub_pubkey": "477318cfb5427b9cfc66a9fa376150c1ddbc62115ae27cef72417eb959691396",
"created_at": 1677426298, "created_at": 1677426298,
"kind": 1, "kind": 1,
"tags": [ "tags": [
@ -105,6 +136,4 @@ Clients should display the delegated note as if it was published directly by the
#### Relay & Client Support #### Relay & Client Support
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). Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf).