What
The resolver serves a did:nostr document at:
/.well-known/did/nostr/<pubkey>.json (application/did+json)/api/did/<pubkey> (application/json)
Opened in a browser these render as raw, unstyled JSON. We should give humans a pretty "data browser" view of that document, following how we already do losos / databrowser for displaying data.
Approach (open)
Not prescribing the mechanism — whatever fits the losos/databrowser convention. Could be a databrowser-style viewer page, a dedicated browse route/hash view, or content negotiation on the canonical URL (one option, not a requirement).
Data island: the HTML view embeds the document directly, e.g.
<script type="application/did+json" id="did-document">{ ...the DID doc... }</script>so the machine representation travels inside the same page — losos/databrowser (and any consumer) can read it straight out of the island, no separate fetch or content negotiation needed. That's what makes this easy: one HTML resource is both the pretty view and the data.
The raw application/did+json representation must stay available and byte-identical for resolvers/machines (whether that's the embedded island, the plain .json, or both) — presentation must not change what a did:nostr resolver fetches.
Rendering
The detail panel in public/index.html already has most of the pieces — reuse them:
- Syntax-highlighted JSON via the existing
highlight() helper (keys in accent, strings in green).
- Make the structured bits interactive:
controller and each follows entry deep-link to that DID's view, service relay endpoints as chips, the verificationMethod Multikey called out.
- Profile header (name/picture/nip05) + the
did:nostr: identifier, in the current light palette.
- A visible "raw ↗" link to the plain JSON.
Acceptance
- A human opening the document gets a styled data-browser view.
- The DID doc is present verbatim as a data island in that page, and a resolver/
curl still gets the raw JSON unchanged from today.
- DID-document conformance (
cid/v1 + Multikey) is unaffected.
What
The resolver serves a did:nostr document at:
/.well-known/did/nostr/<pubkey>.json(application/did+json)/api/did/<pubkey>(application/json)Opened in a browser these render as raw, unstyled JSON. We should give humans a pretty "data browser" view of that document, following how we already do losos / databrowser for displaying data.
Approach (open)
Not prescribing the mechanism — whatever fits the losos/databrowser convention. Could be a databrowser-style viewer page, a dedicated browse route/hash view, or content negotiation on the canonical URL (one option, not a requirement).
Data island: the HTML view embeds the document directly, e.g.
so the machine representation travels inside the same page — losos/databrowser (and any consumer) can read it straight out of the island, no separate fetch or content negotiation needed. That's what makes this easy: one HTML resource is both the pretty view and the data.
The raw
application/did+jsonrepresentation must stay available and byte-identical for resolvers/machines (whether that's the embedded island, the plain.json, or both) — presentation must not change what a did:nostr resolver fetches.Rendering
The detail panel in
public/index.htmlalready has most of the pieces — reuse them:highlight()helper (keys in accent, strings in green).controllerand eachfollowsentry deep-link to that DID's view,servicerelay endpoints as chips, theverificationMethodMultikey called out.did:nostr:identifier, in the current light palette.Acceptance
curlstill gets the raw JSON unchanged from today.cid/v1+Multikey) is unaffected.