A valid concern that I see just being hand waved away usually. "Don't be so concerned, just start a new one. Losing your identity is NBD 🤷‍♂️" Not having any way to recover or transfer identity is a major downside of Nostr.

Sometimes the fact that nostr doesn't support edits sucks 😅

Yeah, I really hope that it's possible to solve this. I really envision a feature where I can trust my WOT everywhere (filter online reviews, can i buy from this guy p2p, general recommendations, health tips, p2p research, loans etc.) It could unlock so much. But all this won't work if you can loose it all with one single compromised app. In this case a social network for us nerds is all we can get.

This is why I only use apps that let me use a signing app, no nsec pasting. At least the attack surface is lessened that way.

Yeah definitely the way to go for now 👍 But I really hope we can do better.

I've worked a support for Internet and SAAS companies. Without any way to recover accounts it limits Nostr's use for a majority of people I think. Key management is not obvious, and most people just don't understand or care enough.

If we can get at least a decent tech stack for all the people that value their personal sovereignty would be a good start. Let's hope it can be done on nostr. If not we'll come up with something else ✌️

I'll let someone smarter than me get into the weeds on this. As I understand it, there was a lot of thought and even a spec created for key rotation, but it ends up creating more problems than it solves. See NIP-26 and the discussion around it: NIP-26

GitHub

nips/26.md at master · nostr-protocol/nips

Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.

Some issues discussing key rotation:

GitHub

Stateless key rotation using a series of hidden commitments · Issue #103 · nostr-protocol/nips

So the idea here is that Nostr apps could generate a series of keys for each user, all based on an initial seed. And they would show the seed and t...

GitHub

Key rotation verified through root key attestation · Issue #116 · nostr-protocol/nips

The purpose here is to provide users with a mechanism to use revocable "hot" keys in less secure application-level contexts while keeping the root ...

GitHub

Trusted public-key-bundle attestations for key rotation and group definition · Issue #123 · nostr-protocol/nips

Purpose The purpose of this NIP is to provide users with a mechanism to define a group of related keys that speak on behalf of the user (e.g. multi...

GitHub

NIP-26: Delegation coordination flow, new events (general discussion) · Issue #247 · nostr-protocol/nips

Specifying delegation coordination between two apps is not in the scope of NIP-26, but some hints could be included; and some extra specification w...

GitHub

Add key revocation method to NIP-26 · Issue #654 · nostr-protocol/nips

Motivation When using NIP46 for remote signing, people are expected to delegate keys with longer expiration dates using NIP-26 for convenience. If ...

GitHub

some thoughts on identity · Issue #726 · nostr-protocol/nips

nostr is great! ...but, there is one fundamental problem I see. The identity. The major thing I currently dislike about clients, is the fact of exp...

GitHub

Deprecates NIP-26 by vitorpamplona · Pull Request #1051 · nostr-protocol/nips

GitHub

Linked Keys for Multi-Device Nostr · Issue #1810 · nostr-protocol/nips

Right now, using Nostr across multiple devices is a challenge. Either you: Share your master key (risky, especially on a phone). Use separate keys ...

GitHub

NIP-A0: Keychains by mikedilger · Pull Request #1837 · nostr-protocol/nips

I think this is the simplest yet effective way to move towards master keys and device keys. I have yet to compare this to other key management prop...

GitHub

NIP-26 should not be discouraged - Ephemeral Keys are a key to improve key management UX · Issue #1959 · nostr-protocol/nips

Can we discuss why this NIP is unrecommended? I think that we ought to have a standardized mechanism to generate ephemeral keys; it allows us to cr...

It's a lot to read, but it shows that our intrepid devs have not just ignored the issue. It is one that has been discussed multiple times at length without a good solution so far. Bottom line: Don't stick your nsec into clients directly. Use a signer app to limit the potential for your private key to be compromised.

Thank for the links will check them out.

Yes View quoted note →

One solution (not the only solution) will be web of trust. If my WoT tells me that Alice’s nsec got compromised on such and such a date, and her new nsec is whatever, then my apps will curate content accordingly. My WoT will do a good job because she’ll tell as many of her close associates as it takes to get the word out, and my WoT will have established previously who are her close associates. This is very doable.

The problem is in such an attack you can't also trust the other keys anymore that claim that this is new key. Plus the fact that the new key would start at zero. People actively have to connect again etc.

The problem is important, the difficulty is that because we directly link to pubkeys rather than some proxy identifier (like DIDs do), there's no way to unilaterally migrate links to your key. In other words, people follow your key, and there needs to be some kind of support for either migrating references to keys, or translating an old key to a new one. The former approach would be marginally easier to accomplish, since it would only require a single client to implement migration. However, users would all have to periodically visit that client in order to perform migrations. Building this into a "core" client like a signer might allow users to run migrations in the background, but even then, only replaceable events could be migrated; kind 1 references would be permanently broken. The latter approach is more complete, but would require EVERY client to implement complex logic for discovering and validating migrations, potentially creating dependencies on timestamping servers for sequencing events reliably. Right now, even if there were a standard that worked, it would be unlikely to get adoption. What we need is a migrate-keys-sdk that client developers can add to support both migration and key proxying. Someone needs to really own this because it requires an incredible amount of effort.

Why would you not be able to trust the other keys, particularly if they are keys that you know / follow / interact with?

Exactly. If we presume Alice’s nsec is the only one compromised, and if she discovers the problem quickly and if she tells her close associates of the problem, and if a handful of them get the word out quickly using their uncompromised nsecs, then we have a relatively effective solution that can be implemented rapidly. Over time the new nsec would rebuild the old connections, but there’s no need for that to happen overnight.

Because if a big client gets compromised there will be many compromised nsecs.

Key rotation, a debate that comes up every now and then.

The WoT solution I described will be useful (once we have a healthy WoT system in nostr) in the typical scenario where an individual nsec gets compromised. If everyone’s nsec gets compromised at once, yeah, that would be a catastrophic failure. Which is why I don’t describe WoT as the one and only solution to this problem. Scenarios like yours are why we don’t hand over our nsecs directly to apps. We use various tools and strategies to minimize our exposure.