Resolve people search by pubkey and alias#1707
Conversation
Desktop member/DM/@mention typeahead only searched kind:0 content via NIP-50 FTS, so hex pubkeys never matched and aliases only hit when they appeared as content tokens. Route pure kind:0 directory queries through the users table (display_name, nip05_handle, pubkey hex), prefer real stored profiles when present, and score mid-string pubkey matches on the desktop re-ranker. Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com> Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2f10f8424f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| // No stored kind:0 — synthesize from the users-table row so pubkey / | ||
| // alias / display_name search still surfaces the person. | ||
| let Some(event) = synthetic_kind0_from_user(user) else { |
There was a problem hiding this comment.
When a user deletes their kind:0 profile with NIP-09, handle_standard_deletion_event soft-deletes the event but does not clear the cached users.display_name/avatar/NIP-05 fields. Because the real-profile query ignores deleted rows, this new fallback synthesizes a fresh kind:0 from that stale cache for any matching people search, so deleted profile information reappears in member, DM, and @mention search results. Please either clear/invalidate the user cache on kind:0 deletion or avoid synthesizing from rows whose live profile was deleted.
Useful? React with 👍 / 👎.
| COALESCE(NULLIF(display_name, ''), NULLIF(nip05_handle, ''), LOWER(encode(pubkey, 'hex'))) | ||
| LIMIT $5 | ||
| LIMIT $5 OFFSET $6 |
There was a problem hiding this comment.
This query now supports OFFSET paging, but rows with the same score and label, such as many users named Alex, have no unique ordering before LIMIT/OFFSET. PostgreSQL may return those ties in different orders between page requests, so the desktop next_cursor flow can duplicate users or skip some entirely. Add a stable final sort key such as the pubkey hex before applying the offset.
Useful? React with 👍 / 👎.
1 participant
Summary
buzz_db::search_users(name / NIP-05 / pubkey) was unuseduserstable, prefer real stored kind:0 profiles when present (keeps NIP-OA agent tags), synthesize a directory-shaped kind:0 otherwise, and score mid-string pubkey matches in the desktop re-rankerTest plan
cargo test -p buzz-relay --lib people_directory/synthetic_kind0rank_matches_mid_string_pubkey_hexcargo check -p buzz-db -p buzz-relayRelated: mobile add-people surface is #1706 (separate gap). This PR is the search backend that both clients depend on.