Oddbean

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