Oddbean

Thanks for the suggestion. It searches just the "display name," ignoring the more important "name" (and probably all other fields). This is, unfortunately, a good example of the state of the search.

The implementation of NIP-50 is usually fine, I think. The main problem is that clients do not use it, and the custom search approaches are rather inaccurate. My basic test is searching myself by display name (since it's more common), adding a word from the bio; using the name (that on Nostr is not unique, of course), plus an additional keyword should be a basic way to find someone. Example: nak req --search "daniele gossip" -k 0 wss://...... Results: relay.nostr.band: found nostr.wine: found relay.noswhere.com: error search.nos.today: zero results 50% success, not exceptional. Let's see how the search for "daniele gossip" works in some clients: Coracle: zero results Nostrudel: found Snort: found a note, not the profile Primal: found a note, not the profile Habla.news: found a note, not the profile Gossip: zero results Amethist: zero results Voyage: zero results Nostur: zero results Damus: not found 10% success, disappointing. Some clients work better with a single world ("daniele"), but it's just a casualty, since a single keyword is often meaningless without a context or a proper sorting. Weight fields, proximity or fuzzy full text search are still science fiction. I will do more tests.

search.nos.today doesn't keep the events older than 30 days regardless of the event kind on the current configuration deployed. The reason I'm doing this is because I just wanted to have a chronological search (especially for events written in Japanese language) and to limit the resource required. Therefore, it is not suitable for searching metadata. I think it might be better to vary the TTL depending on the kind. Its backend implementation, searchnos, however, do parse JSON of metadata content and index. https://github.com/darashi/searchnos/blob/fa5991197bf183fd0a18904a5cddb5253309ae4e/src/index/text.rs#L6-L11

Language filtering is nice (even if not standard), but also Ditto fails by basic test: nostr:nevent1qqsqqqp5ayhuq60jjtwg9x39ewvdw22zmr3nvge6a9204nsrt56ykhqpzamhxue69uhky6t5vdhkjmn9wgh8xmmrd9skctcpypmhxue69uhkx6r0wf6hxtndd94k2erfd3nk2u3wvdhk6w35xs6z7qgmwaehxw309a3ksun0de5kxmr99ej8gmmwdahzucm0d5hsh2gz33

Language filtering is standard in NIP-50. As for "daniele gossip", we only index the display name and nip05 for kind 0 events, because indexing the bio would return wrong results and we didn't figure out a good way to weight the fields.

Relays don't have to split in multiple queries, they have to implement a good search using weighted fields, proximity and fuzzy. Often the problem is client side, as you can read from my quick test.