Search, the big missing piece of Nostr.
Is anyone working on NIP-50 and related?
Discussion
Only if relays don't support it. Works pretty well on nostr.band for example.
Unfortunately, I can't say the same, check my basic test that I posted a short while ago.
Hm I have 2 search DVMs running, one is requesting nostr.band and the other nostr.wine. at least when I request the relays with them i think it works every time. E.g. check noogle.lol
https://noogle.lol/?q=daniele+gossip
doesn't highligth my profile, it seems it focuses only notes.
Yesterday I saw nosbook
This is inching toward what I'd like to have: the ability to search profile data (name, description, ...)
I gave nosbook.org a try, but the results are not really accurate or complete.
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.
What do you have to say about relay.nostr.band, nostr.wine, relay.noswhere.com and search.nos.today?
In mother Nostria, you don't find the search, the search finds you.
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.
I always do that kind of search (readable name + term) and never find what I want because it only finds notes that have that name written in plaintext, never matching against kind:0 metadata.
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
Given the point of all this public 'social media' chatter, is to either seek attention or pay attention; is not the entire endavour of Nostr a matter of search?