The implementation of NIP-50 is usually fine, I think. The main problem is that ...

dtonon / daniele

npub1000…vwqk

2024-10-21 14:05:35

in reply to nevent1q…pp3w

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.

Author Public Key

npub10000003zmk89narqpczy4ff6rnuht2wu05na7kpnh3mak7z2tqzsv8vwqk

Seen on

wss://nos.lol wss://nostr.mom wss://pyramid.fiatjaf.com wss://wot.dtonon.com

Show more details

Published at

2024-10-21 14:05:35

Kind type

1 Short Text Note

Event JSON

{ "id": "000034e92fc069f292dc829a25cb98d72942d8e336233ae954face035d344b5c", "pubkey": "7bdef7be22dd8e59f4600e044aa53a1cf975a9dc7d27df5833bc77db784a5805", "created_at": 1729519535, "kind": 1, "tags": [ [ "p", "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d" ], [ "e", "000012cc13898593d1dc59e014a2b44edd448891147aca02b0b4ab903b80d500", "wss://nostr.wine/", "root", "7bdef7be22dd8e59f4600e044aa53a1cf975a9dc7d27df5833bc77db784a5805" ], [ "e", "00002968e2e7a4e23da5e1b6666cda40380b88a89736df254b00b92567213a2a", "wss://nostr.wine/", "reply", "3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d" ], [ "nonce", "7378697629483837796", "18" ] ], "content": "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.\n\nMy 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:\nnak req --search \"daniele gossip\" -k 0 wss://......\n\nResults:\n\nrelay.nostr.band: found\nnostr.wine: found\nrelay.noswhere.com: error\nsearch.nos.today: zero results\n\n50% success, not exceptional.\n\nLet's see how the search for \"daniele gossip\" works in some clients:\n\nCoracle: zero results\nNostrudel: found\nSnort: found a note, not the profile\nPrimal: found a note, not the profile\nHabla.news: found a note, not the profile\nGossip: zero results\nAmethist: zero results\nVoyage: zero results\nNostur: zero results\nDamus: not found\n\n10% success, disappointing.\n\nSome 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.\nWeight fields, proximity or fuzzy full text search are still science fiction.\n\nI will do more tests.", "sig": "07e619717acf6162d5c3885b89456f8ddd430d8dc7676927e296a178a25b481e1a6bfb113669b382be5254df2239c94612ea6881d7ac9788a315d550239abc7f" }