Key Rotation & DID Nostr - Where do we stand?

Hi all,

As we continue developing the **DID Nostr specification**, the topic of key
rotation has naturally come up. Since `did:nostr` embeds the public key
directly in the identifier (e.g., `did:nostr:<pubkey>`), a true key
rotation would, by definition, require changing the DID itself.

However, we can potentially support **key migration** using existing DID
Core properties like `alsoKnownAs`. This method allows an old DID document
to point to the new one, signaling the migration:

{
  "id": "did:nostr:oldpubkey...",
  "alsoKnownAs": ["did:nostr:newpubkey..."]
}

This approach raises several technical questions we need to address in the
specification:

## Key Migration Questions

1.  **NIP-41 Status:** There was a proposal (NIP-41) for key migration
within Nostr. Does anyone know the current status of this NIP? Is there
active work being done, or has it stalled?

2.  **Deactivation Signaling:** What is the best and most reliable way to
signal that an old key/DID is deactivated or has been migrated? We have a
few options:
      * A dedicated **Nostr event kind**.
      * A defined convention within the `kind:0` profile metadata.
      * Relying on **Resolver inference** based solely on the presence of
`alsoKnownAs`.

Would love to hear thoughts on key rotation implementation experience, or
on NIP41.

Related discussion on GitHub: https://github.com/nostrcg/did-nostr/issues/73


Thanks,
Melvin