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

Avoid derivation tree proof for now

Browse Source
This commit is contained in:
gzuuus 2024-02-15 13:00:57 +00:00
parent 63b2318429
commit f3cdbd050c
1 changed files with 3 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
41.md
View File

@ -13,7 +13,7 @@ This NIP introduces a reliable and verifiable solution for users to manage their
* **Secured identities**
* These identities are composed of a **master keypair** and an **active subkey**.
* The master key pair is used to derive, secure and back up subkeys, and acts as a trusted source of truth for announcements related to subkeys.
* To derive a subkey it is recommended, but not mandatory, to use bip-32 as described in [NIP-06](https://github.com/nostr-protocol/nips/blob/master/06.md) with the derivation path `m/44'/1237'/<account>'/0/0`. This gives us HD addresses and a `xpub` that can be used as proof in a future catastrophe case. Other derivation paths can be used if the user knows what its doing. No derivation scheme needs to be used, users can just generate random keypairs and use them, this gives users less control over subkeys and no proof of derivation.
* To derive a subkey it is recommended, but not mandatory, to use bip-32 as described in [NIP-06](https://github.com/nostr-protocol/nips/blob/master/06.md) with the derivation path `m/44'/1237'/<account>'/`. This gives us HD addresses. Other derivation paths can be used if the user knows what its doing. No derivation scheme needs to be used, users can just generate random keypairs and use them, this gives users less control over subkeys.
* The active subkey should be considered the current account in use for a master keypair, and there should only be one current subkey in use per master keypair.
* Both the master keypair and active subkey should maintain a list of relays in common.
* Users should follow the master keypair to stay up to date with announcements related to the active subkey or revocation certificates. However, it is not mandatory as the described conventions ensure backward compatibility. Subkeys can provide all necessary information to stay uptadate.
@ -41,7 +41,6 @@ This NIP introduces a reliable and verifiable solution for users to manage their
* When a *Simple Identity* publishes this event, a 60-day period begins during which a user may publish a competing migration event pointing to an earlier `kind:1776` event. After this period, clients SHOULD automatically update the user's follower list to the new pubkey.
* When the master key pair of a *secured identity* publishes a revocation certificate, clients can check to validate the following proofs.
* Checkpoint Proof: The client checks if a provided preimage and a secure checkpoint hash match.
* Derivation tree proof(optional): The client checks if the historical identities used in past `kind:1776` events belong to a given `xpub`.
* Social proof(optional): the event contains a list of people that the master keypair attaches to the revocation certificate as `p` tags. These pubkeys are designated as trusted identities that can judge/signal if the new proposed identity is trustworthy or not.
* If no social proof is required, clients can simply check the proofs provided, and if they are valid, they SHOULD automatically update the user's follower list to the new pubkey.
* If social proof is required, a 30-day period begins during which designated users can signal whether the new identity announced in the revocation certificate is trustworthy by reacting to the revocation certificate event with a `kind:7` reaction event.
@ -111,7 +110,7 @@ The implementation can be done directly on regular clients or microapps to handl
{
"pubkey": "master-pubkey-A",
"kind": 1776,
"id" : "master-keypair-rotation-event-id"
"id" : "master-keypair-rotation-event-id",
"content": "",
"tags": [
[ "p", "subkey-B" ],
@ -240,13 +239,11 @@ Public revocation certificate event example:
// Checkpoint event id
[ "e", "<master-pubkey-A-checkpoint-event-id>" ],
// Declaring new master public key and id of checkpoint id
[ "i", "master-pubkey-B", "<master-pubkey-B cpid>" ],
[ "i", "nostr:master-pubkey-B", "<master-pubkey-B cpid>" ],
// (optional) List of designated people to provide social proof
["p", "witness1-pubkey"],
["p", "witness2-pubkey"],
["p", "witness3-pubkey"],
// (optional) Xpub for proof of derivation tree
["xpub", "xpub..."]
// OTS
["proof", "<kind:1040-event-id>"]
// Relays where to look for checkpoints
@ -260,7 +257,6 @@ Public revocation certificate event example:
* `e` tag MUST point to the `kind:1775` checkpoint event that `.content` should match .
* `i` tag MUST list the pubkey and `event-id` of the new master keypair's checkpoint.
* `p` tags SHOULD list designated people who should be trusted to judge how trustworthy the new purposed identity is.
* `xpub` tag SHOULD reveal the extended public address to provide more proofs for the revocation certificate's trustworthiness.
* `relays` tag SHOULD list relays where both `kind:1775` and `kind:1040` events can be found.
At the moment the revocation certificate becomes public, clients can validate the proofs provided and, if social proof is required, a 30-day period will start during which the designated people can judge how trustworthy the new proposed identity is.