Re: Ideal set of features and DID Methods?

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/
>