{"id":"a9cfe135069fdfa2dca2a588b8e7403ba41a528164f8cb5f30e484e5e4be8798","pubkey":"2b39b4ffe62933df970e19366c22c1e092f953f83fcfed754e0f04d5a3b459f9","created_at":1781353189,"kind":30817,"tags":[["d","nip-50"],["title","NIP-50: Search Capability"],["summary","The search field on a filter, and what a relay is expected to make of it."],["s","draft"],["t","nostr"],["t","nip"],["alt","A specification: NIP-50: Search Capability"],["client","openspecs-import"],["published_at","1673970550"],["proxy","https://github.com/nostr-protocol/nips/blob/656cecc7c0a815b6a2b218d3b5d6f078b3f4dbab/50.md","web"],["x","64c393e0146f11564505ba8dd73e4798a34762b0d35a02663dd678a98941240e"]],"content":"NIP-50\n======\n\nSearch Capability\n-----------------\n\n`draft` `optional` `relay`\n\n## Abstract\n\nMany Nostr use cases require some form of general search feature, in addition to structured queries by tags or ids. \nSpecifics of the search algorithms will differ between event kinds, this NIP only describes a general \nextensible framework for performing such queries.\n\n## `search` filter field \n\nA new `search` field is introduced for `REQ` messages from clients:\n```yaml\n{\n  // other fields on filter object...\n  \"search\": <string>\n}\n```\n`search` field is a string describing a query in a human-readable form, i.e. \"best nostr apps\". \nRelays SHOULD interpret the query to the best of their ability and return events that match it. \nRelays SHOULD perform matching against `content` event field, and MAY perform\nmatching against other fields if that makes sense in the context of a specific kind. \n\nResults SHOULD be returned in descending order by quality of search result (as defined by the implementation),\nnot by the usual `.created_at`. The `limit` filter SHOULD be applied after sorting by matching score.\nA query string may contain `key:value` pairs (two words separated by colon), these are extensions, relays SHOULD ignore \nextensions they don't support.\n\nClients may specify several search filters, i.e. `[\"REQ\", \"\", { \"search\": \"orange\" }, { \"kinds\": [1, 2], \"search\": \"purple\" }]`. Clients may \ninclude `kinds`, `ids` and other filter field to restrict the search results to particular event kinds.\n\nClients SHOULD use the supported_nips field to learn if a relay supports `search` filter. Clients MAY send `search` \nfilter queries to any relay, if they are prepared to filter out extraneous responses from relays that do not support this NIP.\n\nClients SHOULD query several relays supporting this NIP to compensate for potentially different \nimplementation details between relays.\n\nClients MAY verify that events returned by a relay match the specified query in a way that suits the\nclient's use case, and MAY stop querying relays that have low precision.\n\nRelays SHOULD exclude spam from search results by default if they support some form of spam filtering.\n\n## Extensions\n\nRelay MAY support these extensions:\n- `include:spam` - turn off spam filtering, if it was enabled by default\n- `domain:<domain>` - include only events from users whose valid nip05 domain matches the domain\n- `language:<two letter ISO 639-1 language code>` - include only events of a specified language\n- `sentiment:<negative/neutral/positive>` - include only events of a specific sentiment\n- `nsfw:<true/false>` - include or exclude nsfw events (default: true)\n","sig":"6ff9a0a4ac4e096c2ba89a75abf66186353881b43fe0679c9042353b90a82dcece91f96cd5750b00393e4eeb42a0679e52b700e27c41f747a37d2126a5e51693"}