Bug

On startup, the DID:nostr well-known indexer logs repeated warnings for accounts whose WebID uses a root path:

well-known-did-nostr: skipping account 34b6a398-... (profile=(multiple candidates)):
NO_CANDIDATE_MATCHED no candidate profile matched https://melvin.solid.social/#me —
tried: /home/ubuntu/solid-server/data: not-a-regular-file |
       /home/ubuntu/solid-server/data/melvin: not-a-regular-file

Cause

The melvin account has WebID https://melvin.solid.social/#me (pathname /), while the profile card lives at data/melvin/profile/card.jsonld.

In profilePathCandidates(), the URL pathname / yields an empty pathnameRel, so:

• Path-mode candidate: resolves to <dataRoot> itself → directory, not a file
• Subdomain candidate: resolves to <dataRoot>/melvin → also a directory

The function never probes the conventional profile location at profile/card.jsonld.

Other accounts with WebID https://xxx.solid.social/profile/card.jsonld#me work correctly because the pathname resolves to the actual file.

Possible fixes

1. Fix the WebID at the source — when this account was created (possibly before the current registration flow), the WebID was set to /#me instead of /profile/card.jsonld#me. Could be fixed by updating the account record in _webid_index.json.

2. Fallback in profilePathCandidates — when the pathname is / (root), additionally probe conventional profile locations: profile/card.jsonld, profile/card, profile/card.ttl.

3. Migration script — scan accounts for root-path WebIDs and update them to the canonical form.

Environment

• JSS v0.0.192
• Subdomain mode enabled, baseDomain: solid.social
• Account melvin WebID: https://melvin.solid.social/#me
• Profile file exists at: data/melvin/profile/card.jsonld