Decentralized identity for an open internet. A W3C DID method built on Nostr that delivers self-sovereign identity with global reach, open standards, and royalty-free licensing.
Every major social platform follows the same arc. It starts open, attracts developers and users through permissionless innovation, then gradually closes down as corporate incentives take over.
The platform launches with a generous API. Third-party clients, bots, and integrations flourish. Users,not the company,invent the features that define the platform.
The company goes public. Fiduciary duties to shareholders replace the original mission. An advertising model is adopted to generate revenue.
The API is restricted to protect ad revenue. Third-party clients are killed. The ecosystem that built the platform gets locked out.
Users discover they never owned their identity, their audience, or their social graph. The platform is the gatekeeper. Leaving means starting over.
This isn't a failure of any individual company. It is the structural consequence of building identity and communication on top of corporate infrastructure instead of open protocols. The incentives of public ownership,advertisers, investors, stock price,inevitably create a single point of failure.
The internet's most durable infrastructure is built on open protocols. Email (SMTP), the web (HTTP), and DNS have survived decades of corporate upheaval because no single company controls them.
You don't need anyone's permission to send an email or publish a website. The same principle applies to identity. When your identity lives on a platform, that platform becomes a gatekeeper,of your name, your audience, your ability to speak. When your identity is rooted in cryptography and open standards, no one can take it away.
The future of the internet depends on protocols where you don't need a company's permission to build a business or an interface. Identity should work like email: portable, interoperable, and owned by the user.
Nostr is a simple, open protocol for decentralized communication. It uses secp256k1 keypairs for identity and distributes messages through relays. There is no company behind it, no CEO, no venture funding. It is tamper-proof because it lacks a single point of failure.
The identity layer of Nostr is a public key. Powerful, but on its own it speaks a language that only Nostr understands. The rest of the standards ecosystem,W3C, IETF, credential verifiers, enterprise systems,can't interoperate with a raw hex key.
did:nostr is a W3C DID method that bridges Nostr's cryptographic identity with the global standards ecosystem. Developed under the W3C Nostr Community Group, it wraps a Nostr public key in a W3C Decentralized Identifier:
did:nostr:3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d
This is not a new identity system layered on top of Nostr. It is the Nostr key, expressed in a format that the rest of the world can verify, resolve, and trust,through open standards with global reach.
| Capability | Standard | What It Enables |
|---|---|---|
| Identity format | W3C DID Core | Interoperability with any DID-aware system worldwide |
| Credential issuance | W3C Verifiable Credentials | Digitally signed claims, diplomas, licenses, attestations |
| Key representation | W3C Multikey | Standardized public key encoding across ecosystems |
| Cryptography | BIP-340 Schnorr | Bitcoin-compatible signatures, proven at scale |
| Governance | W3C Community Group | Open participation, IPR policy, royalty-free licensing |
The W3C Community Group process provides something Nostr's NIP process alone cannot: a formal Intellectual Property Rights (IPR) policy. Contributors agree to royalty-free licensing terms, ensuring that did:nostr can be implemented by anyone without patent encumbrance. This is the difference between an experiment and infrastructure.
The promise of self-sovereign identity is that users own their keys for money and their data and social graph for speech,moving freely between apps without losing their identity or content. did:nostr makes this concrete.
A Nostr keypair gives you a did:nostr identifier that works across every application that supports W3C DIDs,not just Nostr clients. Portable across social media, credential systems, financial applications, and anything built on open standards.
The did:nostr resolution process pulls your profile (kind 0), your follows (kind 3), and your relay preferences (kind 10002) from the Nostr network and presents them as a standard DID document. Switch clients, switch platforms,your relationships follow.
History has shown how easily a platform CEO becomes a gatekeeper of speech. With did:nostr, there is no CEO to make that call. Your identity is derived from mathematics, not from a terms-of-service agreement.
A minimal did:nostr document contains everything needed for cryptographic verification:
{
"@context": [
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/multikey/v1"
],
"id": "did:nostr:3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d",
"verificationMethod": [{
"id": "did:nostr:3bf0c63f...#key-0",
"type": "Multikey",
"controller": "did:nostr:3bf0c63f...",
"publicKeyMultibase": "fe701023bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d"
}],
"authentication": ["did:nostr:3bf0c63f...#key-0"],
"assertionMethod": ["did:nostr:3bf0c63f...#key-0"]
}
This document can be generated from the public key alone, with zero network access. No relay, no server, no DNS. The public key is the identifier. Resolution can be enhanced through Nostr relays or HTTP, but neither is required for basic verification.
Not all DID methods are created equal. The most widely adopted method in enterprise, did:web, resolves to a JSON file hosted on a web server behind DNS. Proposals to improve it (cryptographic event logs, DNS TXT record hashes) are welcome steps, but the base architecture still depends on DNS. Domains can be seized, servers taken down, hosting can lapse. The improvements add auditability to a centralized foundation; they don't change the foundation.
| Property | did:web | did:nostr |
|---|---|---|
| Decentralized | No,depends on DNS | Yes,derived from cryptographic key |
| Self-sovereign | No,requires domain ownership | Yes,only requires a keypair |
| Censorship-resistant | No,domains can be seized | Yes,no single point of failure |
| Persistent | No,domains expire | Yes,keys are permanent |
| Requires infrastructure | Yes,web hosting, TLS, DNS | No,works offline |
| Registration needed | Yes,domain registrar | No,generate a key |
| Cost | Domain + hosting fees | Free |
Typing did: instead of https:// doesn't make your system decentralized any more than wooden headphones summon cargo planes. did:web is HTTP with a different prefix. did:nostr is actually decentralized: the identifier is the key, the key is self-certifying, and no infrastructure dependency can be seized or shut down.
Nostr is growing fast, but it remains a relatively small protocol community. did:nostr gives Nostr identity global reach by connecting it to the W3C ecosystem,the same standards body behind HTML, CSS, and the web itself.
Issue W3C Verifiable Credentials,diplomas, professional certifications, membership attestations,recognized by any VC-compatible verifier worldwide.
Link to did:web, did:key, or AT Protocol identities via alsoKnownAs. Bridge between ecosystems without losing your root identity.
Use the same keypair for Nostr social, Bitcoin payments, and web authentication. One identity across every context.
Provide cryptographic identity for autonomous systems operating across platforms. Agents get the same self-sovereign properties as humans.
// A did:nostr identity bridging ecosystems
{
"id": "did:nostr:3bf0c63fcb93463407af97a5e5ee64fa...",
"alsoKnownAs": [
"did:web:alice.example.com",
"did:key:z6Mkf...",
"at://alice.bsky.social"
]
}
The simplicity of did:nostr's resolution also matters for browser integration. Methods that require witness networks, P2P infrastructure, or blockchain queries impose significant maintenance cost on browser vendors. did:nostr's offline-first resolution means a browser can produce a valid DID document from the identifier alone, with no external dependencies. Low complexity, low maintenance, low barrier to integration.
Bitcoin is a peer-to-peer system that removes financial gatekeepers. did:nostr shares Bitcoin's cryptographic DNA.
This is not a coincidence. It means the same keypair can sign a Nostr event, resolve as a W3C DID, and authorize a Bitcoin transaction. Identity, communication, and money unified under one set of keys. This is what sovereignty looks like in practice.
// The same 32-byte key across three domains
// 1. Nostr identity
npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6
// 2. W3C DID
did:nostr:3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d
// 3. Bitcoin (Taproot)
bc1p80cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkws5tk7cm
Nostr's NIP process is beautifully minimal: propose an idea, get rough consensus, ship it. But this informality means there is no formal IPR commitment from contributors. Anyone could theoretically claim patent rights over a NIP they contributed to.
did:nostr doesn't change Nostr itself. Nostr remains an experiment, and that freedom is valuable. But for the identity layer that connects Nostr to the rest of the world, having proper licensing and governance removes a barrier to enterprise adoption, government recognition, and institutional trust.
Even well-meaning companies with boards and VC funding eventually face pressure to centralize or moderate under government or market demands. The structure of a corporation,with fiduciary duties, investors, and a CEO who can be pressured,inevitably creates the single points of failure that decentralization was meant to eliminate.
Open protocol → company forms around it → VC funding → board of directors → fiduciary duties → government pressure → centralized moderation → gatekeeper. Even "Public Benefit Corporations" are not immune. The structure is the vulnerability.
did:nostr avoids this trap structurally:
| Property | What It Means |
|---|---|
| No company | Maintained by a W3C Community Group, not a corporation |
| No VC funding | No investors to satisfy, no revenue model to protect |
| No CEO | No individual can make unilateral decisions about who gets an identity |
| No permission required | Anyone can implement the spec, run a resolver, or build a product |
| Cryptographic guarantee | Identity is derived from math, not from a database entry someone controls |
This is what permissionless innovation means: the ability to build without asking. No API key to request. No terms of service to accept. No partnership to negotiate. The specification is open. The cryptography is standard. Build.
did:nostr prioritizes simplicity and deployability. That means it deliberately omits features that other fully-decentralized DID methods consider essential. It is worth being explicit about what did:nostr does not have and why.
Methods like did:webvh and did:cel construct the DID document from a formal, witnessed event log that provides a tamper-evident history of every change. did:nostr has no such log. However, Nostr's signed events (kind 0 profiles, kind 3 contact lists, kind 10002 relay lists) are themselves a lightweight event history: each is signed, timestamped, and distributed across multiple relays. This is not a formal CEL with oblivious witnesses and heartbeats, but it is not nothing either. The trade-off is auditability vs. simplicity.
If you lose your private key, you lose your did:nostr identity. There is no key pre-rotation, no recovery key, no mechanism to migrate to a new keypair. This is the most significant limitation for general-public adoption. Potential Nostr-native approaches (social recovery through trusted contacts, NIP-46 delegation, multisig schemes) are active areas of experimentation but none are standardized. For now, key management is the user's responsibility.
Formal CEL-based methods use cryptographic heartbeats to prove a log is still active and has not been silently forked. did:nostr has no equivalent mechanism. If two relays serve conflicting kind 0 events for the same pubkey, the resolver takes the most recent by timestamp. This is simple but offers weaker guarantees than a witnessed log.
These omissions are intentional. Every feature added is complexity that must be implemented, maintained, and understood. did:nostr's bet is that a DID method people actually use today is more valuable than a feature-complete method that takes years to standardize. The two approaches are complementary: did:nostr works now, while heavier fully-decentralized methods mature through the W3C DID Methods Working Group.
The internet's identity layer is broken. It's fragmented across corporate silos, each with its own login, its own terms of service, its own power to revoke access. Every platform that promises openness eventually closes down as market pressures mount.
did:nostr offers a different path:
Own your identity. Your key, your DID, your credentials. No platform can take them away.
Build on an open standard. No API keys to request, no terms to violate, no rug pulls.
Issue and verify credentials using a W3C standard with proper licensing, not a proprietary API.
Connect to the global standards world without compromising on decentralization.