Re: Ideal set of features and DID Methods?

Hi Adrian,

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

I wonder if separating the DID document "in to two" end-to-end. A public
document and a private document

Meaning two registries, two identifiers, two histories, etc.

Would be a helpful approach

Everything that is being done to ensure the availabililty and durability of
the verification part.

What if we do it in a decoupled way for the controller part, but keep the
content encrypted outside memory.

I actually made this video with premature understanding of how the DIDs and
VCs work end-to-end.

But if you apply the "Private Data Space you can move between applications
/ hosts" idea here you get strong durability for the private keys.

When viewing these materials it is important to not focus on where the keys
come from or what the recovery flow is in my implementation but rather the
general principle

- https://youtu.be/GIFVetIC8X0

Here are text and other assets for those that do not want to watch video:
-https://github.com/z-base/ <https://github.com/z-base/z-base>

Regards,
Jori


pe 20.2.2026 klo 19.29 Adrian Gropper (agropper@healthurl.com) kirjoitti:

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