Introduction
Nostr (Notes and Other Stuff Transmitted by Relays) and Decentralized Identifiers share a core principle: identity comes from public key cryptography, not from platform accounts. Both systems let users control their identity without a central authority. The two systems overlap significantly. If you know how they can work together, you can build more capable decentralized applications.
The Nostr Identity Model
In Nostr, your identity is a secp256k1 key pair, and Bitcoin uses the same curve. Your public key is your identity, and your private key proves that you control it. The familiar npub and nsec strings are the bech32 encodings of NIP-19. NIP-19 says that these formats "are not meant to be used anywhere in the core protocol" and limits them to display, copy-paste, and QR codes. Inside the core protocol, keys are 32-byte lowercase hex. NIP-01 specifies that each event (post, message, reaction) carries a Schnorr signature on the secp256k1 curve, made with your private key.
This model is similar to the DID model:
- The identifier comes from a public key.
- Authentication is proof that you control the private key for that public key.
- There is no registration authority and no process to create an account.
The difference is the lifecycle. A Nostr pubkey is the identity, so it is permanent. No NIP in the NIP index defines a standard mechanism for key rotation or recovery (as of September 2026).
Metadata is not the gap. NIP-01 defines a standard kind 0 user metadata event, and NIP-24 adds more profile fields. But the profile is one JSON object in the event content, not a resolvable document with an auditable update history. Kind 0 is also a replaceable event, so relays keep only the latest version and "MAY" discard older versions. DID methods that define update operations address that gap.
Where the Models Align
Shared cryptographic foundation
Nostr and Bitcoin-anchored DIDs both use secp256k1. ION is a DID network that implements the Sidetree protocol on Bitcoin. The default parameters of Sidetree specify secp256k1 keys and ES256K signatures (ECDSA on that curve) for DID operations. Implementers can choose other values, and Sidetree-based methods can support other key types for the verification methods in a DID document.
In theory, one key pair can be both a Nostr identity and the basis for a DID. The practical benefit depends on signature support, not only on the curve. Nostr events carry BIP-340 Schnorr signatures. A hardware wallet or a secure enclave can hold a Nostr key. It can take part in DID operations only if it also supports the signature scheme of the DID method.
Self-sovereignty
Nostr needs no permission to create an identity. You generate a key pair, and the identity exists. There is no email verification, no phone number, and no approval from an identity provider. DID Core lists decentralization as a design goal, with no requirement for centralized authorities to register identifiers. Many DID methods follow this goal. For example, did:btcr2 supports offline creation without any on-chain or online interaction.
Censorship resistance
Nostr gets censorship resistance from relay redundancy. A user can publish the same signed event to multiple relays, so no single relay can block it. The protection is weaker than it looks. The Nostr README states that relays can "have any rule or internal policy they want". NIP-01 also standardizes rejection prefixes such as blocked and restricted. Thus the protection is only as strong as the redundancy that a user actually keeps.
DIDs anchored to Bitcoin depend instead on the cost to rewrite the proof-of-work history. Together, the two systems cover identity and communication.
Where DIDs Extend Nostr
Key rotation
If an attacker gets your Nostr private key, you lose your identity. You cannot update your npub, because the npub is your key. The closest standardized attempt at indirection is NIP-26 (Delegated Event Signing). NIP-26 lets a separate key pair sign on behalf of a delegator, but it does not replace the identity key. The NIP index now marks NIP-26 as unrecommended.
In contrast, many DID methods support key rotation. You can update the keys in your DID document and keep the same identifier. Rotation is a property of each method, not a guarantee of the DID data model. Some methods do not define rotation, for example the did:nostr draft (see below). If you link a Nostr identity to a DID method that defines rotation, users get a recovery path that the pubkey alone does not give. This path works only for clients that follow the DID instead of the raw pubkey.
Verifiable Credentials
Nostr has NIP-05. NIP-05 maps a human-readable, email-like address (for example, user@domain.com) to a public key. For this purpose, the domain serves a /.well-known/nostr.json file over HTTPS. The NIP states that it "is not intended to verify a user, but only to identify them". NIP-05 also depends on DNS and HTTP, which are centralized infrastructure. With DIDs, the same identifier can anchor Verifiable Credentials.
A credential can carry claims that an issuer makes and stands behind (real name, organization membership, certifications). These claims do not depend on domain control.
Structured metadata
DID documents support standardized service endpoints, multiple key types, and machine-readable metadata. These features extend what a Nostr identity can express beyond the current profile event (kind 0) format.
Cross-protocol identity
A DID can connect Nostr and other systems. In principle, the DID that identifies you on Nostr can also authenticate you to a web service through its authentication keys. It can also issue verifiable credentials through its assertionMethod keys. You do not need a separate account for each of these tasks.
Integration Patterns
DID-linked Nostr profiles
A Nostr profile event can include a DID in its metadata. The did:nostr draft already states that users can put an alsoKnownAs field in their kind 0 profile event. The signature of the event then covers that claim of linked identities. Clients that understand DIDs can resolve the linked DID document for more verification and key discovery.
Nostr as a DID communication channel
The DID ecosystem includes DIDComm Messaging v2, a specification of the Decentralized Identity Foundation (DIF), not of the W3C. DIDComm gives encrypted, authenticated messages between DIDs. One of its goals is to be transport-agnostic, so Nostr relays can be one transport for DIDComm messages.
The harder part is the key material, not the transport. DIDComm encryption uses key agreement curves (X25519 and the NIST P-curves). A Nostr secp256k1 identity key does not supply these curves. Thus a DID document must carry separate keys for key agreement.
Credential-gated relays
Relays can require verifiable credential presentations for write access. Today, some relays require payment or an invitation. NIP-11 defines the payment_required and restricted_writes flags, and NIP-43 defines invite codes. A relay can instead require proof of a specific credential, such as a membership or an identity verification.
What the relay learns depends on the proof mechanism, not on the use of credentials as such. An ordinary presentation gives the relay all the data that the credential contains. The VC Data Model notes that signature values and their metadata can become correlation handles if they stay the same across sessions. For unlinkability, the issuer must use a scheme that makes new signature values for each presentation. One example is the Data Integrity BBS Cryptosuites, a W3C Candidate Recommendation Draft as of September 2026.
NIP-based DID method
A did:nostr method already exists. It is a Draft Community Group Report of the W3C Nostr Community Group, not a W3C standard. Its version is 0.1.1 as of September 2026. The method derives a DID directly from a Nostr secp256k1 public key (did:nostr:<hex-pubkey>). It can optionally enrich the resolved DID document from Nostr events. Examples are kind 0 profile metadata, kind 3 contact lists, and kind 10002 relay lists.
In its current form, the draft treats the identifier as permanent, but the document itself can change. The document is a projection of signed Nostr events. If the controller publishes a newer kind 0 profile, kind 3 contact list, or kind 10002 relay-list event, the next resolution returns a different document. The draft states that "This version of the method defines no native mechanism for key rotation or deactivation". It calls rotation and deactivation "an open item" for "a future revision". Thus recovery from a lost or compromised key must come from a separate layer on top of the method.
The next post examines the draft in detail.
Conclusion
Nostr and DIDs complement each other. Nostr is one communication layer that a DID ecosystem can build on. DID methods supply the identity lifecycle management that Nostr does not define. The shared cryptographic foundation removes a whole class of integration problems. It does not solve rotation, recovery, or the separate key agreement material that encrypted DIDComm messages need.
As both ecosystems mature, the two will probably converge further. The result can be identity, communication, and credentials that are self-sovereign, interoperable, and based on keys that you control.