Paso 1 de 4
Pon la consulta en search
El campo search contiene texto libre. Los relays lo comparan con el content y, cuando tiene sentido para el kind, también con otros campos.
NIP-50
Capacidad de búsqueda
BorradorMensajes de relayRelay
Añade un campo search a los filtros REQ para que los clientes puedan pedir a los relays resultados de búsqueda de texto completo, como "mejores apps de nostr". Los relays ordenan los resultados por relevancia en lugar de por fecha y pueden soportar opciones clave:valor extra como language:en.
De un vistazo
- Estado
- En uso, pero todavía puede cambiar.
- Último cambio
- 13 jun 2026
Pruébalo
Edita el formulario o el JSON: ambos se mantienen sincronizados, la insignia indica si el resultado es válido y, al tocar cualquier campo, se explica qué hace.
Explicación
Selecciona cualquier campo del formulario o del JSON para ver qué hace.
Cómo funciona este NIP
En el curso
Ningún capítulo del curso cubre este NIP todavía. El editor de arriba es la forma más rápida de empezar.
NIPs relacionados
Se basa en
- NIP-11 Documento de información del relay
Los relays anuncian el soporte de búsqueda en supported_nips.
Amplía
- NIP-01 Descripción del flujo básico del protocolo
Añade un campo al filtro REQ.
Ver también
- NIP-51 Listas
Los usuarios listan sus relays de búsqueda preferidos en una lista kind 10007.
- NIP-05 Asociar claves de Nostr a identificadores de internet basados en DNS
La extensión domain: se basa en identificadores NIP-05.
Especificación
El texto de las especificaciones se cita en inglés del repositorio nostr-protocol/nips. Nuestras explicaciones y la interfaz están traducidas. Código fuente en GitHub en el commit 0046368
Leer la especificación406 palabras, citadas del repositorio en el commit 0046368.
Abstract
Many Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids. Specifics of the search algorithms will differ between event kinds, this NIP only describes a general extensible framework for performing such queries.
search filter field
A new search field is introduced for REQ messages from clients:
{
// other fields on filter object...
"search": <string>
}
search field is a string describing a query in a human-readable form, i.e. "best nostr apps".
Relays SHOULD interpret the query to the best of their ability and return events that match it.
Relays SHOULD perform matching against content event field, and MAY perform
matching against other fields if that makes sense in the context of a specific kind.
Results SHOULD be returned in descending order by quality of search result (as defined by the implementation),
not by the usual .created_at. The limit filter SHOULD be applied after sorting by matching score.
A query string may contain key:value pairs (two words separated by colon), these are extensions, relays SHOULD ignore
extensions they don't support.
Clients may specify several search filters, i.e. ["REQ", "", { "search": "orange" }, { "kinds": [1, 2], "search": "purple" }]. Clients may
include kinds, ids and other filter field to restrict the search results to particular event kinds.
Clients SHOULD use the supported_nips field to learn if a relay supports search filter. Clients MAY send search
filter queries to any relay, if they are prepared to filter out extraneous responses from relays that do not support this NIP.
Clients SHOULD query several relays supporting this NIP to compensate for potentially different implementation details between relays.
Clients MAY verify that events returned by a relay match the specified query in a way that suits the client's use case, and MAY stop querying relays that have low precision.
Relays SHOULD exclude spam from search results by default if they support some form of spam filtering.
Extensions
Relay MAY support these extensions:
include:spam- turn off spam filtering, if it was enabled by defaultdomain:<domain>- include only events from users whose valid nip05 domain matches the domainlanguage:<two letter ISO 639-1 language code>- include only events of a specified languagesentiment:<negative/neutral/positive>- include only events of a specific sentimentnsfw:<true/false>- include or exclude nsfw events (default: true)