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

Rename attributes by purpose instead of structure. Use a single letter tag . Clarify migration path. Add a note about defensive coding.

Browse Source
This commit is contained in:
Vinny Fiano 2024-08-29 22:07:45 -04:00
parent d31a149053
commit 843c33b3cc
2 changed files with 26 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
102.md
View File

@ -27,12 +27,9 @@ The parent key can publish a `Kind 10102` event for subkey management. This even
Content:
```json
{
"keys": {
"<hex-subkey0-pubkey>": { "active_at": "<epoch-timestamp>" },
"<hex-subkey1-pubkey>": { "active_at": "<epoch-timestamp>", "revoked_at": "<epoch-timestamp>" },
"<hex-subkey2-pubkey>": { "active_at": "<epoch-timestamp>" }
},
"default_policy": "allow"
"inbox_keys": ["<hex-subkey0-pubkey>", "hex-subkey2-pubkey"],
"revoked_keys": ["<hex-subkey1-pubkey>"],
"other_keys": ["<non-derived-subkey>"]
}
```
@ -45,8 +42,8 @@ When signing events using a subkey, the account pubkey and subkey derivation pat
"pubkey": "<hex-subkey1-pubkey>",
"kind": 1,
"tags": [
["account", "<hex-account0-pubkey>", "<subkey1-derivation-path>"],
],
["I", "<hex-account0-pubkey>", "<subkey1-derivation-path>"],
]
}
```
@ -55,18 +52,34 @@ For clients that don't implement NIP-102, we can have the account key publish a
Content:
```json
{
"account": "<hex-account0-pubkey>",
"account_key": "<hex-account0-pubkey>",
"derivation_path": "<subkey1-derivation-path>"
}
```
## Migration
Most current keys do not use BIP-39 derivation and will need to publish a `Kind 10102` event pointing to a new pubkey:
```json
{
"other_keys": ["<non-derived-subkey>"]
}
```
The new key must publish the opposite `Kind 10102` event claiming the parent:
```json
{
"account_key": ["<parent-pubkey>"]
}
```
## Behavior
All searches for the account pubkey should return those signed by any account subkey. If an event is replaceable, it is up to the client or relay as to whether both messages are maintained, or if only the latest across all subkeys is maintained. In any situation where data will be lost, a reasonable effort should be made to locate the most recent revocation list before proceeding.
## Migration
Most current keys do not use BIP-39 derivation and will need to perform a manual key rotation to a new pubkey using a method not defined here.
Do not attempt to resolve `other_keys`, as this could grow exponentially. Always work up from the subkey, as each key can only have a single `account_key`. Limit any search to a reasonable constant maximum depth, maybe 8. If the maximum depth is reached, use the original key instead of the most recently found.
## Reference Code

1
README.md
View File

@ -244,6 +244,7 @@ They exist to document what may be implemented by [Nostr](https://github.com/nos
| `g` | geohash | -- | [52](52.md) |
| `h` | group id | -- | [29](29.md) |
| `i` | external identity | proof, url hint | [39](39.md), [73](73.md) |
| `I` | parent of subkey | pubkey (hex) | [102](102.md) |
| `k` | kind number (string) | -- | [18](18.md), [25](25.md), [72](72.md) |
| `l` | label, label namespace | -- | [32](32.md) |
| `L` | label namespace | -- | [32](32.md) |