Re: Ideal set of features and DID Methods?

The did:nostr paper points out the unsolved problem of key recovery. I
suspect it's our biggest barrier to decentralized identity at scale.

Adrian

On Fri, Feb 20, 2026 at 12:03 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> pá 20. 2. 2026 v 15:39 odesílatel Manu Sporny <msporny@digitalbazaar.com>
> napsal:
>
>> On Fri, Feb 20, 2026 at 5:02 AM Melvin Carvalho
>> <melvincarvalho@gmail.com> wrote:
>> > For more detail, here’s a longer piece on how did:nostr fits within
>> this broader landscape, for those less familiar with it:
>> >
>> > https://melvin.me/public/articles/did-nostr.html
>>
>> FWIW, I found that web page really compelling Melvin. I suggest that
>> those interested in decentralized DID Methods read it because if we
>> were to just delete "nostr" from the entire page, I think it outlines
>> a number of the ideal set of features we're looking for in a fully
>> decentralized DID Method.
>>
>> I find myself internally conflicted about "How many DID Methods are
>> enough?". On the one hand, "at least three -- generate from public
>> key, Web/DNS-based, and fully decentralized"... and on the other hand,
>> there are MANY different types of vehicles in the world, and even more
>> brands that specialize in aspects of each type of vehicle. Perhaps
>> there should be as many different types of DID Methods in time? Well,
>> maybe not as many because there is only so much to differentiate DID
>> Methods from each other... but certainly more than three, or possibly
>> ten. Is twenty five too many? Fifty?
>>
>> More specifically, Melvin, I'm wondering if the "alsoKnownAs"
>> equivalence could work in reverse. Where we add something to did:key,
>> such as: did:key:...?aka=nostr, which would auto-generate the
>> nostr-equivalent key. IOW, it would hint that you could do a nostr
>> lookup that might work via a did:key?
>>
>
> Thanks Manu, really appreciate the kind words about the article.
>
> On "how many methods" - I think at least three (key-based, DNS-based,
> fully decentralized) is the floor, but realistically a page of actively
> maintained methods with real deployments is healthy.
>
> On did:key?aka=nostr - it's an interesting direction and cross-method
> hints could be valuable. But I'd be wary of leaning too heavily on query
> parameters in identifiers - that way lies the session ID mess of the early
> web, where URIs became fragile, uncacheable, and implementation-specific.
> More practically, did:nostr needs its own method because the method needs
> to evolve with its ecosystem. The Nostr community is actively building
> toward key rotation, on-chain commitments, hardware wallet integration, and
> signing device support. A query parameter on did:key doesn't give us room
> to evolve resolution semantics as these capabilities mature.
>
> There's also existing infrastructure. NIP-98 (HTTP auth using signed Nostr
> events) has 100+ implementing projects [1]. The W3C Nostr CG is formalizing
> this as HTTP Authentication Using Schnorr Signatures [2] and did:nostr
> integration with Solid is under active discussion [3]. The ecosystem isn't
> theoretical.
>
> That said, the reverse hint idea is neat as a general mechanism - a
> did:key document could advertise "this key is also resolvable via Nostr
> relays" without collapsing the two methods into one.
>
> Cheers
> Melvin
>
> [1] https://nip98.com/
> [2] https://nostrcg.github.io/http-schnorr-auth/
> [3] https://github.com/w3c-cg/solid/issues/62
>
>
>>
>> -- manu
>>
>> --
>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>> Founder/CEO - Digital Bazaar, Inc.
>> https://www.digitalbazaar.com/
>>
>