From 843c33b3ccb6efe28d612b770f926c10798a893b Mon Sep 17 00:00:00 2001
From: Vinny Fiano <ynniv@ynniv.com>
Date: Thu, 29 Aug 2024 22:07:45 -0400
Subject: [PATCH] Rename attributes by purpose instead of structure. Use a
 single letter tag . Clarify migration path. Add a note about defensive
 coding.

---
 102.md    | 37 +++++++++++++++++++++++++------------
 README.md |  1 +
 2 files changed, 26 insertions(+), 12 deletions(-)

diff --git a/102.md b/102.md
index 633da2a..060fdc3 100644
--- a/102.md
+++ b/102.md
@@ -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
 
diff --git a/README.md b/README.md
index 9f456fa..61a63ea 100644
--- a/README.md
+++ b/README.md
@@ -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)                           |