Re: First Draft of did:nostr method

po 31. 3. 2025 v 11:32 odesílatel John O'Hare <J.OHare5@salford.ac.uk>
napsal:

> Hi Melvin,
> Fantastic to see the did:nostr  FPWD published – this aligns with
> something I've been exploring for using Nostr as an identity layer for
> people, AI agents, and persistent objects within linked metaverse/immersive
> environments.
> Considering the spec currently defines a DID document primarily derived
> statically from the public key (without update/revoke operations), I'm
> particularly interested in how this model might represent moredynamic
> entities like AI agents (whose capabilities or associated service endpoints
> might evolve) or global objects (which might change state or context). Does
> this lean towards did:nostr acting as the stable, cryptographic root
> identifier, with dynamic aspects perhaps best reflected through associated,
> queryable Nostr events (like Kind 0 or potentially new kinds) rather than
> within the resolved DID document itself? I might redo my layers documents
> and see if i can get it to make sense to me in the next week or two in this
> context.
>
Thanks for the feedback—great questions!

did:nostr is based on Nostr, which itself follows a simple but powerful
principle: adding hyperlinks to things makes those things better.

The web was born when hyperlinks were added to hypertext—hence HTML and
HTTP. Before that, hypertext and even early browsers existed, but they
didn’t operate at scale. The web introduced a syntax for documents to
contain hyperlinks, which made them vastly more powerful and scalable.

Linked Data applies the same principle to data. JSON-LD is just JSON with
hyperlinks at its core. Over time, more features were added, but the
foundational idea remains: adding a standard syntax for (typed) hyperlinks
makes data more expressive and scalable.

== How did:nostr fits in ==

What did:nostr does is turn a Nostr pubkey into a hyperlink (i.e., a URI),
and embed it into an extensible JSON document that understands URIs. In
this format, "id" is the standard key for the subject identifier.

Just as HTML lets you write anything and enhance it with links, JSON-LD
lets you structure anything and enhance it with typed hyperlinks. This
gives the data model extensibility, interoperability, and scale.

So, did:nostr inherits:

   -

   The ability to use typed hyperlinks
   -

   The ability to extend JSON arbitrarily

== AI Agents and Extensibility ==

AI agents in Nostr are already identified by a pubkey, with a field like bot:
true. That fits naturally into a DID Document.

We just need to decide whether to structure it like:

{
  "profile": {
    "bot": true
  }
}

or:

{
  "bot": true
}

Each approach has trade-offs. The flat structure is simpler, but
namespacing under "profile" keeps a cleaner separation and avoids field
conflicts. The namespaced version might also be easier for clients to
integrate without breaking existing workflows. Something we can discuss
further in an issue.

Similarly, for agent workflows, we can extend the did:nostr document in
multiple ways—more fields, nested objects, or linked resources. That could
include

 -Agent services in external documents
- User storage references
- Other use cases as they arise

In general, the DID community tends to keep DID documents minimal and use
hyperlinks to point to optional extensions. did:nostr is flexible enough to
support either model.

Perhaps we should also write a Primer for folks new to the system, or
collect use cases.
Hope that helps!


> Congratulations again on reaching this stage! Looking forward to digging
> into the details.
> Best regards,
> *DR JOHN O'HARE*
>
> Chief Hallucination Officer | Spatial AI Lead
>
> *DREAMLAB <https://thedreamlab.uk/>*
>
> *MediaCity Immersive Technologies Innovation Hub*
> HOST, Blue, MediaCity UK, Salford
> Contact me:  LinkedIn <https://www.linkedin.com/in/jjohare/> | Email
> <j.ohare5@salford.ac.uk>
>
> Narrative Goldmine Research Pages <https://narrativegoldmine.com/#/graph>
>
>