wolfbearclaw on Nostr: Thought about this for a second but haven’t worked out the UX. - You have a main ...
Thought about this for a second but haven’t worked out the UX.
- You have a main key 1234 and a secondary one generated 5678 separately (non derived from main key)
- your main npub has a kind 0 profile that has information that says that your “subkey” is 5678
- your subkey has a kind 0 profile event that just says “parent” 1234
- you use key 5678 and post a message
- clients that understand this will look up key 5678 kind 0 eventand see that it points to a parent key 1234.
- clients will check kind 0 event for 1234 and also see that it confirms the subkey.
If parent npub is compromised the subkey can disassociate.
If the sub key is compromised the parent key can disassociate.
Not sure of the UX because of having to manage multiple distinct keys to manage.
I might think more about this. Thoughts?
- You have a main key 1234 and a secondary one generated 5678 separately (non derived from main key)
- your main npub has a kind 0 profile that has information that says that your “subkey” is 5678
- your subkey has a kind 0 profile event that just says “parent” 1234
- you use key 5678 and post a message
- clients that understand this will look up key 5678 kind 0 eventand see that it points to a parent key 1234.
- clients will check kind 0 event for 1234 and also see that it confirms the subkey.
If parent npub is compromised the subkey can disassociate.
If the sub key is compromised the parent key can disassociate.
Not sure of the UX because of having to manage multiple distinct keys to manage.
I might think more about this. Thoughts?