Summary

jss already implements most of a did:nostr resolution server. This RFC proposes a resolver/indexer mode so jss can resolve any pubkey's did:nostr document from indexed relay data, not just the pod owner's, and in doing so absorb the aging nostr-labs/nostr-beacon (which maintains a divergent, buggy DID-doc generator: see nostr-labs/nostr-beacon#3).

What jss already has

• /.well-known/did/nostr/:pubkey.json (src/idp/well-known-did-nostr.js), currently owner-scoped.
• buildDidDocument(pubkey, webId), the conformant DID-doc generator (once Use CID v1.0 @context in served did:nostr docs so Multikey is defined #569//private/privkey.jsonld uses external cid/v1 @context, inconsistent with profile.js (inline) and not conneg-expandable #570 land: cid/v1 context, Multikey + publicKeyMultibase, DIDNostr).
• A MongoDB document store: --mongo enables the /db/ route, backed by src/db/store.js.
• nostr-tools / NIP-98 key handling.

The one new component: a relay-indexer

Subscribe and upsert, keyed by pubkey, into a collection in the existing Mongo store:

• kind 0 (profile) -> profile
• kind 3 (contacts) -> follows
• kind 10002 (relay list) -> service (Relay) entries

The well-known resolver then builds the doc for an arbitrary pubkey from the offline-derivable base plus whatever the index holds (the spec's enhanced resolution), via buildDidDocument.

Why this shape

The bug class in nostr-beacon#3 (wrong context, missing key material) exists because nostr-beacon has its own DID-doc generator that drifted from jss's. One shared, conformant builder removes that class permanently. Everything except the indexer already exists in jss.

Open questions

1. Indexing trigger: on-demand (fetch relays on first request for a pubkey, cache in Mongo) vs a background firehose. On-demand is simpler and likely sufficient.
2. In-process vs sidecar: indexer as a jss module/route, or a separate service writing the same Mongo and importing buildDidDocument as a library.
3. Owner precedence: if the requested pubkey is the pod owner, serve the owner doc (with WebID backlink); otherwise the indexed/derived doc.
4. Fallback: if not indexed, return the minimal offline-derived (key-only) doc, not 404.
5. Dependency: the conformant @context/IRIs (Use CID v1.0 @context in served did:nostr docs so Multikey is defined #569, /private/privkey.jsonld uses external cid/v1 @context, inconsistent with profile.js (inline) and not conneg-expandable #570) should land first.

Companion RFC on the indexer side: filed alongside this on nostr-labs/nostr-beacon.