Adding NIP-05 verification (Assign npub to name server)

[sergey3bv]

Should solve #43

[sergey3bv]

Hey, @rabble, could you please review?

[NotThatKindOfDrLiz]

Thanks for the NIP-05 work. The direction is good: returning nip05 from /api/user/profile, serving /.well-known/nostr.json?name=..., and fixing the unknown-name response to return an empty names map are all useful changes. I also verified the schema and repository methods locally before writing this review.

I need to request changes before this can merge.

Merge blockers

1. Case-insensitive username uniqueness is not enforced.

normalize_nip05_username() now lowercases new writes, but the current database uniqueness is still case-sensitive. database/migrations/0001_initial_schema.sql has idx_users_username_tenant on (tenant_id, username), while database/migrations/0007_admin_search_index.sql adds only a non-unique LOWER(username) search index. UserRepository::check_username_available() and find_pubkey_by_username() also compare with username = $1.

That means an existing mixed-case username such as Alice could coexist with a newly normalized alice. Both collapse to the same NIP-05 local-part, which can produce two users for one alice@domain identity. That is identity-corrupting and should block merge.

Please add a migration that either backfills and enforces lowercase usernames or adds a unique index like (tenant_id, LOWER(username)) WHERE username IS NOT NULL, and update the availability/lookup paths to be case-insensitive or guaranteed-normalized. Please also add a regression test that specifically covers an existing mixed-case row conflicting with a new lowercase claim.

2. NIP-05 domain precedence needs to be fixed or explicitly justified.

resolve_nip05_domain() currently prefers NIP05_DOMAIN, then DOMAIN, then the tenant domain. In a multi-tenant deployment, that can show every tenant user as name@process-domain even when the tenant is served from a different host. Since /.well-known/nostr.json is resolved against the tenant domain, this can cause the profile response and the actual verification domain to diverge.

If Keycast is intentionally single-tenant for this deployment, please add a comment and documentation explaining why env vars intentionally override tenant domains. Otherwise, tenant domain should win and env vars should be fallback/local-dev overrides.

3. The dashboard badge should not overstate verification when domain resolution can be wrong.

The UI labels the local profile value as NIP-05 Verified. Once the domain precedence and uniqueness issues are fixed, that is probably fine because this service controls the corresponding nostr.json response. Until then, the badge can present a misleading verified identity if the profile returns a domain that does not match where discovery is actually served. Please resolve this together with blocker #2.

Follow-up issues created

Per our review workflow, I created the non-blocking follow-ups and assigned them to @sergey3bv:

• #74: Follow-up: return 4xx validation errors from profile username updates
• #75: Follow-up: add tests for NIP-05 domain resolution
• #76: Follow-up: remove hardcoded default NIP-05 domain
• #77: Follow-up: make NIP-05 badge e2e test domain-independent
• #78: Follow-up: consider stricter dot rules for NIP-05 usernames
• #79: Follow-up: document nostr.json no-name response shape change
• #80: Follow-up: add NIP-05 username length limit

Once the case-insensitive uniqueness/data-safety issue and the domain precedence issue are addressed, this should be in much better shape.