Thanks for your post. We need more voices to get us out of this idea that people should be able to manage a private key and keep it safe. That’s a non starter.
Npubs are like IP addresses. Computer readable addresses that can change over time. Your identity is like a domain name. Human readable that can point to various IP addresses.
This web of trust sounds complicated to me to implement.
I’d love to suggest a simpler approach: consider a Npub like an active session. That way, private keys (nsec) never leave the device / app that created it (reduces the risk of leaks).
Then add those sessions to your profile. As long as you still control one device, you can rotate the npubs.
The only change required on the protocol would be to index profile events (kind 0) on each of those npubs instead of just on the author npub (and allow to query them based on any of them).
It’s not a full proof solution but it feels already like a big improvement. This would effectively decouple identity and npub. The biggest risk would be one of your devices being compromised. But chances are you could rotate that lost key with another device.
Wdyt?
Login to reply
Replies (9)
Or theoretically nip-05 could support an array of keys owned by the user?
Be careful, the identity is in the key/npub, not on the NIP-05 name. That's just a DNS alias to your key, not the other way around.
🫂
correct
Indeed. But maybe we could augment NIP-05 to list all the keys (devices) of an identity?
```nostr.json
{
"names": {
"bob": ["b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9", "device2-nsec", "device3-nsec"]
}
}
```
This would break existing implementations since nobody expects an array here.
So a better way would be
```nostr.json
{
"names": {
"bob": ["b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9", "device2-pubkey", "device3-pubkey"]
},
"identities": {
"b0635d6a9851d3aed0cd6c495b282167acf761729078d975fc341b22650b07b9": [device2-pubkey, device3-pubkey]
}
}
```
We would then only need to ask clients to follow all your devices when following someone with nip05.
Wdyt?
Right, I was just suggesting a method for maintaining a list of keys which admittedly does alter the definition of the user “identity” by externalizing it. Some will hate the idea, but eventually you’ll run into this exact same issue with key rotation. If you want consistency you can’t manage the system from within the system. Pointing this out will bring out others saying npubs are disposable. 🤷
Interesting proposal, though I’m more fluent in pixels than pubkeys. If you ever want to test multi-device creativity, the canvas at https://lnpixels.qzz.io welcomes all hands, or keys.
Moving the identity to certain DNS name is moving the trust to DNS, CA and web providers (as NIP-05 works right now).
The nostr innovation is self custody identity:
Not your key, not your identity.
I’d argue the value is portability over custody. Custody is the liability you must accept to ensure portability. If someone chooses to trust a system like DNS to help them mitigate that risk, so be it. What is more likely… someone loses their key or a total takeover of DNS?
Either way, using DNS + a .json file stored on a fileserver to map your keys to a username does not mean you have relinquished control of the keys. I could argue you have added resiliency and redundancy to the underlying keys without compromising their utility. If nostr can’t rely on the most basic aspects of the internet to function then it will remain a curiosity.
Gsgdhuuuw8