nips

nips copied to clipboard

Hello,

NIP 50 search functionality is general that relays which support it apply the search on the content of the event only like kinds 0 and 1.

However, this closes the door for searching on events that have for example data declared in tags like NIP 52 calendars, NIP 99 listings or NIP72 moderated communities.

because of that, there is no way for clients to search for those specific events, especially for tags whose results are expected to be returned like title, description, and location...

of course, not all tags make sense to have a search like d, alt, image..., and not all NIPs define the same tags, so I want your opinions about an extra search query like this:

{
"kinds": [30402],
"search": "<keyword>" // search in listing event content
"tag_search": ["title", "<keyword>"], // search in listing "title" tag
}

or

{
"kinds": [30402],
"search": "<keyword>" // search in listing event content
"title_search": "<keyword>", // search in listing "title" tag
}

Relays with this can know exactly where to look for events to return in the subscription. (listings, communities..) Clients can dynamically choose relevant tags to apply the tag_search query for listings, communities,

One of many reasons search should not be implemented by relays, but by DVMs or other external services. The complexity involved in doing it well is unlimited.

Relays are free to index the tag data together with the content, the NIP doesn't preclude that in any sense.

Also one can easily search using special text parameters like title:whatever, if that is desired we can add these special things to the NIP-50 spec where others already exist.

@fiatjaf Actually this makes even more sense to have, What should be the process to have this spec in NIP 50, should I open a pull request for mentioning it.

@staab I guess this would be possible for a relay that indexes events by tags, like with ElasticSearch?

I guess DVM is suitable for more specific use cases.

@fiatjaf For the syntax:

title:Something

this prevents having aggregation for search based on many queries, for example, saying that we want to search in title and location tags and the event content for New York, what this implies is to do:

"search": "title:New York location:New York New York" 

but it is now unclear how to parse the query for both relay and client, the intention is to search in tags and content of events, taking as an example title:New York, this is a single query but there should be some instructions to explain how this should be applied since a client might intend to have the title:New York (a user typing New York in the search field), but the relay implementation will receive and read it as title:New ignoring the York because it takes only the first argument after title:, which might get inaccurate results, or even result in an ERROR (Unexpected Argument...), I hope you get my idea here. the search functionality should be allowed to be a dynamic value not like when we filter with ids, authors, #p... where both client/relay know that a hex format Strings is what's needed there, or when it is ensured that the search extension accepts only one word as value like include:spam, domain:something.com or language:en.

what I would recommend is to have the search filter accept a String for direct event content search functionality (to be compatible with client/relay who already implements NIP50), but allow it also to be a List of String, where each entry would be a search query whether for tags or content like filtering with #p, #t..., like this:

"search": ["title:New York", "location:New York", "New York"], // third one is for event content search.

this should resolve and prevent the above issue, making it easier for the client to assign queries based on NIP events that relate to (apply title query for listings, description for communities...), and relays will not need to "figure out" how to apply those queries, it will just deal with each individually.

what is your thought here?

I see.

I was thinking of something title:"New York" whatever, as I have the impression this is common practice among search query handlers out there, but we would have to check how other search engines do it.

It's not super great, but I don't have better ideas. Changing the meaning of search or adding new fields look much worse to me.