Re: did:nostr v0.1.0 and BIP-340 Data Integrity

st 1. 7. 2026 v 17:34 odesílatel Brian Richter <brian@aviary.tech> napsal:

> Hi Melvin,
>
> Congrats on reaching this stage. I’ve only had a quick read through so
> far. Will give it a real read as soon as I can and give some of the
> implementations a play with.
>
> 2 questions I have on my quick read:
>
> 1. How is one intended to know the <domain> to query. Apologies if this is
> laid out already I did a search for “domain” and it only came up with the 2
> results which didn’t explain. Maybe this is a NOSTR concept that I’m
> missing?
>
> 2. How exactly does updating work? As someone not familiar with NOSTR it’s
> not clear to me if all posted events are guaranteed to reach resolvers.
>

Hi Brian,

Good questions, and implementation feedback would be very welcome.

Nostr is a pub/sub protocol over websockets: users sign events, publish
them to interchangeable relays, and clients can read them back from any
relay with a copy. NIP-01 is the short technical overview:

https://github.com/nostr-protocol/nips/blob/master/01.md

For a higher-level explanation, Jack Dorsey and Rabble give a useful
overview here:

https://www.youtube.com/watch?v=NS5JI-ksaXs

For did:nostr, the baseline resolver does not need a domain: it can
generate the minimal DID document offline from the pubkey in the
identifier. Relay queries and .well-known HTTP lookup are optional
enrichment layers.

Updates come from newer signed Nostr events, but relay propagation is
eventually consistent, so the core DID document must not depend on relay
data arriving.

I agree the spec should make this clearer.

Best,
Melvin


>
> Thanks,
> Brian
>
>
>
> On Wed, Jul 1, 2026 at 5:40 AM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> st 1. 7. 2026 v 14:24 odesílatel Will Abramson <will@legreq.com> napsal:
>>
>>> This is great to hear, thanks Melvin.
>>>
>>> Would you be interested to present did:nostr on a CCG call sometime?
>>>
>>> On a quick scan, I found it interesting that you used the Controlled
>>> Identifier context - https://www.w3.org/ns/cid/v1  - rather than the
>>> DID context. I think this may make it a Controlled Identifier, not a
>>> Decentralized Identifier as stated.
>>>
>>> At least it seems in conflict with this normative MUST from the DID spec:
>>>
>>> > In addition to using the JSON representation
>>> <https://www.w3.org/TR/did-1.1/#dfn-representations> production
>>> <https://www.w3.org/TR/did-1.1/#dfn-production> rules, production *MUST* include
>>> the @context entry. The serialized value of @context *MUST* be the JSON
>>> String <https://www.rfc-editor.org/rfc/rfc8259#section-7>
>>> https://www.w3.org/ns/did/v1.1, or a JSON Array
>>> <https://www.rfc-editor.org/rfc/rfc8259#section-5> where the first item
>>> is the JSON String <https://www.rfc-editor.org/rfc/rfc8259#section-7>
>>> https://www.w3.org/ns/did/v1.1 and the subsequent items are serialized
>>> according to the JSON production
>>> <https://www.w3.org/TR/did-1.1/#dfn-production> rules.
>>>
>>> Was this intentional?
>>>
>>
>> Thanks Will, this is a great catch! So we want to support both DID and
>> CID since they are RECs. And we also want to to support the upcoming LWS
>> REC.
>>
>> We started out with the did context, then moved to the cid context, as I
>> thought that is what we were supposed to do. This copy slipped through the
>> refactor.
>>
>> So now I am wondering what is the best practice? Should we use the did
>> context or the did context, or do we need 2 specs?
>>
>>
>>>
>>> Great to see the work progressing,
>>> Thanks,
>>> Will
>>>
>>>
>>> On Wed, Jul 1, 2026 at 1:09 PM Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> A brief heads-up that the W3C Nostr Community Group has published
>>>> did:nostr v0.1.0 as a Community Group Draft Report:
>>>>
>>>> https://nostrcg.github.io/did-nostr/
>>>>
>>>> did:nostr defines a DID method for Nostr identities, based on secp256k1
>>>> / BIP-340. The method now has 30+ implementations, so this seemed worth
>>>> surfacing here given the overlap with CCG work.
>>>>
>>>> A few items that may be of interest:
>>>>
>>>> 1. did:nostr is registered in the DID Method Registry.
>>>>
>>>> 2. It includes a conformance test-vector suite covering key
>>>> transformation, parity decoding, error taxonomy, and document generation.
>>>>
>>>> 3. A DIF did-resolver driver is available, so it can be used through
>>>> the Universal Resolver.
>>>>
>>>> 4. Verification methods use Multikey with secp256k1 keys, which
>>>> connects directly with CCG work on Data Integrity and cryptosuites.
>>>>
>>>> If useful in making the case for that work, did:nostr provides a live
>>>> DID method and implementation ecosystem that wants to issue and verify VCs
>>>> with Nostr keys via Data Integrity.
>>>>
>>>> Status-wise, this is still an early Draft Report. The main open design
>>>> item on the path to a Final Report is key rotation / deactivation. Review
>>>> and critique are very welcome, especially around Multikey/parity handling,
>>>> the resolution model, and how this should fit with CCG Data Integrity work.
>>>>
>>>> See also:
>>>>
>>>> https://did-nostr.com/
>>>>
>>>> Thanks,
>>>> Melvin
>>>>
>>>