NIP-50: Search Capability
A protocol without search feels smaller than it is
Nostr's base query model is precise: ids, authors, kinds, tags, time ranges and limits. That is powerful for structured software. It is not how people look for a phrase, a topic, a quote, an article or an old conversation they barely remember.
NIP-50 adds a search field to the ordinary REQ filter. A client can ask for events matching a human-readable query such as best nostr apps, optionally constrained by kinds, ids or other filter fields. Relays interpret the query to the best of their ability and return matching events.
The standard is deliberately loose about search algorithms because search quality is not one algorithm. A relay may use full-text indexing, language models, spam filters, domain filters, ranking rules or simple keyword matching. NIP-50 standardizes the request shape, not the ranking engine.
Search field, ranked results and optional query extensions
The search field lives inside a normal filter object. A client may send several filters in one request, and each may include a search query. Results needs to be returned in descending order by result quality, not by ordinary created_at, and the limit needs to be applied after sorting by match quality.
Clients need to check NIP-11 supported_nips before expecting support, but they may send search filters to other relays if they can tolerate noisy or unsupported responses. The official source also recommends querying several supporting relays because each relay's index and ranking rules may differ.
The extension syntax uses key:value pairs in the query string. Current optional extensions include include:spam, domain:<domain>, language:<code>, sentiment:<negative/neutral/positive> and nsfw:<true/false>. Relays needs to ignore extensions they do not support.
From keyword filter to search capability
NIP-50 started in January 2023 as Artur Brugeman's keyword filter. Within days, the language shifted to search capability and added supported_nips guidance plus client-side filtering hints. That early rename matters because the standard is broader than keyword matching.
In March 2024, nostr.wine contributed event-classification extensions, and Alex Gleason added search by NIP-05 domain. Vitor Pamplona clarified result ordering in June 2024. In June 2026, an autocomplete extension was added and then reverted, showing that the boundary of search syntax is still actively guarded.
That history tells people how to use NIP-50 responsibly. It is stable enough to build search clients and search relays around. It is not a guarantee that every relay ranks, filters or indexes the same way.
Search is a relay product, not just a filter flag
A relay implementing NIP-50 needs an index and a ranking policy. A client implementing it needs relay selection, fallback behavior, result verification and spam tolerance. The official source explicitly allows clients to stop querying relays with low precision. That is practical advice: open search invites bad matches, spam and uneven quality.
Nostr client feature matrices often include search, but that does not mean every app is using NIP-50 across supporting relays. Some search products rely on their own indexers. NIP-50 is valuable because it gives relay-native search a shared query shape, even if specialized search engines remain useful.
A good search page needs to tell you which relays were queried, whether the query was constrained to kinds or domains, whether spam filtering is active and why a result appears. Otherwise search becomes another opaque feed.
Search can quietly become the new gatekeeper
Search shapes what people believe exists. A relay that ranks poorly, filters aggressively, misses languages or lets spam dominate can make Nostr feel distorted. NIP-50 does not solve that. It gives clients a way to ask and compare.
The second risk is privacy. A search query reveals intent to the relay receiving it. That may be harmless for public topics and sensitive for personal, political or medical searches. Search clients need to make relay choice visible and avoid spraying private queries everywhere by default.
Read NIP-50 in the wild
NIP-50 describes relay search capability. It lets a relay say that it can search text, which changes client discovery from pure event fetching to query-driven exploration.
Search is never neutral. Relay coverage, indexing policy, ranking, spam filtering and language handling decide what appears. A client needs to show that search results come from a relay with its own view of the network.
What changes when you actually use it
For you, NIP-50: Search Capability is felt when a relay accepts, rejects, indexes, hides, charges for or returns events. Relays are not passive pipes. They make policy and infrastructure choices that shape what a client can show. The source terms draft, relay, REQ, content, .created_at, limit matter because they are the narrow places where a product can distinguish a relay decision from a network failure.
What changes for builders and operators
For builders and operators, NIP-50: Search Capability is observability. Log what the relay accepted, rejected, counted, authenticated or refused. Then show enough of that to users so they can repair configuration instead of assuming Nostr is empty or broken.
What the official file makes concrete
The official file is organized around Abstract, search filter field, Extensions. Inspect draft, relay, REQ, content, .created_at, limit, key:value, kinds because these are the pieces most likely to surface as product behavior.
NIP-50: Search Capability belongs to infrastructure, not scenery. Acceptance, indexing, authentication, retention, payment and filtering all shape what you actually see.
Where it breaks
The failure mode in NIP-50: Search Capability is blaming the network for one server's policy. A relay may reject an event for payment, spam, size, auth, retention or software reasons. If the client collapses those cases into one empty state, the user loses the ability to act.
Where this appears outside the markdown
In the ecosystem, NIP-50: Search Capability lives where users rarely look and operators spend real money: websocket services, relay policies, indexes, rate limits, authentication, monitoring and retention. A good hub page has to make that infrastructure readable because relay behavior decides whether Nostr feels alive, empty, expensive or hostile.
The nearby-standard trap
The nearby-standard trap in NIP-50: Search Capability is treating all relay standards as one reliability story. Discovery, authentication, information documents, search, counts, monitoring and management each expose a different slice of relay behavior. Read NIP-01 and the adjacent source links before calling a relay 'good' or 'broken'.
Language that keeps the feature honest
Good product copy for NIP-50: Search Capability names the relay decision. It says whether access, payment, indexing, search, storage, rate limit, auth or policy shaped the result. That language gives you something to fix instead of making the network feel mystical.
What this page does not promise
NIP-50: Search Capability does not make every relay equal. A relay can be public, paid, local, archival, search-oriented, authenticated, heavily moderated or almost disposable. The standard gives clients and operators a way to communicate one part of that behavior. It does not replace uptime checks, policy reading, payment terms, retention expectations or the practical question of whether your own events can be found later.
Read it as a field test
Start NIP-50: Search Capability with the server behavior you can observe: accept, reject, count, search, authenticate, limit, store, delete or report. Then connect it to draft, relay, REQ, content, .created_at, limit. A relay NIP becomes readable when it explains what a relay can honestly promise and what still depends on policy, money and operations.
Where the standard earns trust
The source links give you places to test the interpretation in public: Nostr.co.uk NIP-50 explainer, nostr-rs-relay NIP-50 issue, Relay type nomenclature discussion, rust-nostr supported NIPs. Use those links to move from the spec to live libraries, mirrors, pull requests, guides or products.
Official NIP-50 source is the anchor for exact wording, and NIP-50 commit history shows how that wording moved over time. The strongest secondary clues here are Nostr.co.uk NIP-50 explainer, nostr-rs-relay NIP-50 issue, Relay type nomenclature discussion. Treat this evidence chain as part of the article, not as footnotes. A NIP page becomes useful when you can move from claim to source to working behavior without guessing.
Keep the chain visible for NIP-50: Search Capability: first the human promise, then draft, relay, REQ, content, .created_at, limit, then the implementation record, then the real-world failure case. That order keeps NIP-50 useful without turning it into marketing copy or protocol trivia.
Three questions to carry forward
- What exact relay behavior is being described: discovery, auth, search, count, information, payment, moderation or management?
- Can you see whether a failure came from policy, payment, indexing, rate limit, auth or downtime?
- Does the relay expose enough public information for you to decide whether it belongs in your own relay set?
What to verify before you rely on it
- Find
draft,relay,REQ,content,.created_atin the official file and check where the UI exposes the same concept. - Read NIP-01 and the adjacent source links as context before treating NIP-50 as a complete product story.
- Open at least one implementation, mirror, pull request or library source from the source links before trusting that the idea is mature.
- Test the unhappy path: missing relays, stale metadata, invalid signatures, blocked events, expired state, revoked permissions or unavailable media.
- Write the user-facing copy in plain language. If a standard changes authority, privacy, money, moderation or recovery, say that before the click.
Direct sources
Use these sources for NIP-50: Search Capability in that order: Official NIP-50 source for the current wording; NIP-50 commit history for the change record; Nostr.co.uk NIP-50 explainer, nostr-rs-relay NIP-50 issue, Relay type nomenclature discussion for public context. The article gives you the consequence in plain language, but the source trail is where exact fields, status notes, unresolved debates and implementation proof stay checkable.
