NIP-50 search relays and the limits of finding things on Nostr
NIP-50 is small on the page and huge in product consequence. It adds a search field to relay queries, but it also forces you to ask what a search result really means inside a relay-based network.
Search is a relay promise, not a network guarantee
When you type a phrase into a platform search box, you are usually asking one company to search its own database. Nostr feels different because there is no single database. Events live on relays. Some relays store them. Some relays ignore them. Some prune. Some index. Some specialize. Some are down. Some require payment or authentication. A search result on Nostr is therefore never just "what exists." It is "what this search surface found from the relays and indexes it knows."
NIP-50 is the protocol hook for that surface. It does not create a universal search engine. It gives relays a way to say: yes, you can send me a search query, and I will try to return matching events. That is useful because human memory rarely works by event id. You remember a phrase, a name, a topic, a project, a domain, a hashtag, a quoted sentence or a half-remembered conversation. Structured filters by id, pubkey and tag are powerful, but they do not replace plain-language search.
The danger is expectation. If a client labels a NIP-50 query as "Search Nostr," many users will assume absence means nonexistence. That is wrong. Absence may mean the chosen search relay did not index that event kind, did not crawl that relay, filtered spam, did not support the extension, ranked the result too low, ignored old data, required auth, had stale data or simply failed. A decentralized search box needs humility built into the interface.
Once you understand that, NIP-50 becomes more useful, not less. You stop treating search as an oracle and start treating it as a discovery tool. A search relay can help you locate likely events. Then you inspect the event id, author, tags, timestamp, source relays, reposts, replies, quotes and related context. Finding is the first move. Verification is the second.
That is the right mental model for builders too. A NIP-50 search result should not be the only evidence your app needs. If the result matters, fetch the event from relays, verify the signature, check the author, follow links to related events and show users enough provenance to trust what they see. Search is a doorway into the event graph, not the event graph itself.
What NIP-50 actually adds
NIP-50 introduces a search field for REQ filters. A client can send a subscription request that includes a human-readable search string. The relay interprets the string to the best of its ability and returns matching events. The standard says relays should at least match against the content field and may match against other fields when that makes sense for particular event kinds.
That modest shape is deliberate. Search algorithms differ. Searching short notes is not the same as searching profiles, long-form posts, community definitions, file metadata, relay lists or app data. A relay can implement full-text indexes, language analyzers, tag indexing, profile search, domain filters or ranking logic suited to its purpose. NIP-50 gives them a shared query entry point without pretending every implementation will rank the same way.
A client can combine search with other filters. It can search only specific event kinds. It can restrict by author, ids, tags, time windows or other filter fields. That matters because broad search becomes noisy fast. If you want long-form articles about relays, searching every short note may bury the result. If you want profiles, event kind limits matter. If you want posts from a specific author, combine search with the author pubkey.
The spec also says results should be returned by descending search quality, as defined by the implementation, rather than the usual created_at order. That single sentence changes UX. A search relay is allowed to rank. It can decide which events are better matches. It can apply scoring. It can apply spam filtering. It can apply language handling. The client should not assume NIP-50 results are simply newest first.
Limit handling is important. NIP-50 says the limit filter should be applied after sorting by match score. That means a relay should rank candidates first and then return the top results. If a relay applies limit too early, you get arbitrary slices before relevance. A client cannot always know how the relay implemented this, so serious clients should compare relays and learn which indexes have useful precision.
Capability discovery belongs to NIP-11. A relay that supports search should list NIP-50 in its supported_nips metadata. Clients should check that metadata before depending on search. They may still send search filters to unknown relays if they are prepared to handle strange or irrelevant responses, but a better user experience starts by showing which relays advertise search support.
Ranking and scope are the real editorial layer
Search ranking is editorial power, even when it is implemented as software. Which result is first? Which event kind is included? Which spam filter is applied? Which language is assumed? Which domains or identities are trusted? Which old events are still indexed? Which relays feed the index? These choices decide what you find first and what you never see.
That does not make search relays bad. It makes them important. A useful search relay can rescue old knowledge from the feed. It can help you find developers, documents, communities, reports, marketplace listings, media, code references and public discussions. It can make Nostr feel navigable. But because search relays shape visibility, they should publish scope and clients should show scope.
"Search results from relay.nostr.band" is a different claim from "Search results from your write relays." "Profile search from a curated directory relay" is different from "full-text public note search." "Search in this community" is different from "search the public network." The label needs to match the corpus. If the label overpromises, users will mistake missing results for missing reality.
Scope also changes trust. A search relay focused on high-quality profiles may intentionally exclude low-quality or spammy profile events. That can be good for onboarding. It can also hide edge cases. A relay focused on a paid community may search a cleaner subset. A public broad search relay may show more mess. A local relay may search only venue or group context. None of these is wrong if the boundary is clear.
The best Nostr search design should let you compare. Search this relay. Search your current relay set. Search known NIP-50 relays. Search profiles only. Search long-form content only. Search community posts only. Search with spam hidden or included. You do not need every toggle in the first screen, but serious users need a path to understand what the search box is doing.
Verification should travel with results. A result card can show author, date, event kind, matching snippet, source relay, whether the signature verifies and whether the result came from a search index or a live relay fetch. Without that, search results become screenshots of trust. With it, they become doors into inspectable events.
Extensions and spam are where search becomes practical
NIP-50 allows query strings to include key:value pairs as extensions. Relays should ignore extensions they do not support. The listed examples include include:spam, domain:<domain>, language:<two-letter-code>, sentiment:<negative/neutral/positive> and nsfw:<true/false>. These extensions show why search cannot be one-size-fits-all.
Spam filtering is especially important. NIP-50 says relays should exclude spam from results by default if they support spam filtering. That is a practical expectation, not a moral luxury. Search surfaces attract abuse because appearing in results can be more valuable than appearing in a chronological feed. If spam wins search, the archive becomes unusable.
But spam filtering also creates risk. A relay can hide too much, be gamed by reports, penalize unfamiliar languages, suppress new users, or shape results around hidden trust rules. This is why clients should query several search relays and compare precision. The spec explicitly encourages querying several NIP-50 relays because implementation details differ. Diversity is a quality feature.
The domain: extension is interesting because it can tie search to NIP-05 identity domains. Searching for events from users whose valid NIP-05 domain matches a domain can help with organizational context, but it can also overemphasize people with DNS-backed identity. Useful, not neutral. The same goes for language filters. They help people search in the language they need, but language detection can fail and mixed-language communities may be harder to map.
NSFW and sentiment filters show the boundary between search and moderation. A relay can make adult media easier or harder to discover. It can classify tone. It can provide safer defaults. It can also misclassify. If products expose these filters honestly, users gain control. If products hide them, ranking becomes invisible governance.
As a builder, treat extensions as optional and negotiated. Do not assume a relay supports them unless its behavior proves it. If your product depends on an extension, document which relays support it and what happens when they do not. Graceful degradation matters because NIP-50 is draft optional, and optional means you will meet variance in the wild.
Search is not the same as discovery
NIP-50 helps you find events by query. NIP-65 helps clients learn where authors prefer to publish and read. NIP-66 helps the ecosystem monitor relay liveness. NIP-11 tells clients what a relay claims to support. These pieces overlap, but they are not interchangeable.
If you want to follow someone reliably, search is not enough. You need their relay list, their outbox relays and working relay connections. Search may help you find their profile or posts, but it should not be the daily route for receiving their events. Outbox discovery is the routing layer. Search is the retrieval shortcut when you do not already know where to look.
If you want to verify an old event, search is not enough. You need the event id, signature verification, source relays and context. A search result can point you there. It should not be the final authority. Search indexes can lag, include deleted results, miss edits, rank stale events or show partial threads.
If you want to understand relay health, search is not enough. A search relay might return beautiful results while its write path is closed, its index is stale or its source relays are narrow. NIP-66-style monitoring and direct relay checks are still needed. Search answers "what did this index find?" Liveness answers "is this relay usable now?"
This distinction helps prevent centralization by habit. If one excellent search service becomes the default path for everything, users may slowly re-create platform dependency. A search relay can be wonderful and still not deserve to become the only map. Use search broadly, label it honestly and keep routing decentralized.
The search UX you should expect
A good Nostr search interface should show the query, the corpus, the result kind and the provenance. It should tell you whether you are searching one relay, several search relays, your current relay set or a curated directory. It should let you narrow by event kind. It should surface old but relevant events without hiding recency. It should show enough context to avoid quote-snippet traps.
Search results should not collapse all event kinds into one undifferentiated stream. A profile result, a public note, a long-form post, a community definition, a relay list, a report and a file metadata event are not the same thing. Event kind labels matter. A result that looks like a normal post but is actually a report or an app-specific object can mislead users.
Snippets should be careful. A search match inside a quoted note, a reply, a repost, an encrypted placeholder or a machine-generated tag can look like more than it is. Good snippets show enough surrounding context and link to the original event. If the client can fetch the event from multiple relays, it should make that visible.
Empty states should teach. "No results from this relay" is better than "No results." "This relay does not advertise NIP-50" is better than a spinning box. "Try search relays that support NIP-50" is better than failure. When products teach the relay model during failure, users become more competent without reading specs.
Advanced search should remain reachable. Kind filters, author filters, domain filters, language filters, date windows, search relay selection, spam inclusion and exact phrase handling are not needed for every casual query, but they matter for researchers, journalists, builders, community moderators and people trying to reconstruct an old conversation. Nostr needs search UX for both casual discovery and serious investigation.
Search relay operators are running an index, not just a relay
Running a NIP-50 relay is more than accepting and serving events. You are building an index. You decide what to ingest, how to tokenize, how to rank, how to filter spam, how to update stale records, how to handle deletion and expiration, how to store snippets, how to scale queries and how to protect the service from abuse. Search is operationally heavier than basic relay storage.
The relay should advertise NIP-50 in NIP-11 if it supports the search filter. It should also publish useful policy outside the machine-readable field. Which event kinds are indexed? Which relays feed the index? Are writes accepted or is it index-only? Are spam filters applied? Are extensions supported? Are results ordered by relevance, recency or a hybrid? Are deleted or expired events removed from the index? Does the index include profiles, long-form posts, media metadata or communities?
Index-only relays can be honest and useful. A project such as a dedicated search relay may reject client event submissions and populate its index from source relays or import jobs. That is not a flaw if users understand it. It means the relay is not a general publishing endpoint. It is a search service speaking relay language.
Performance matters because search is tempting to hammer. Broad queries, bots, repeated autocomplete, scrapers and expensive filters can turn search into a denial-of-service surface. Operators need rate limits, query limits, caching, abuse controls and maybe payment or auth for heavy use. Again, the honest relay publishes its limits rather than pretending search is free forever.
Moderation matters because search amplifies. Spam buried in a chronological relay is annoying. Spam ranked at the top of search is infrastructure damage. Illegal content, impersonation, malware links and adult material all create higher risk when search makes them easy to discover. Search operators should think carefully about default filtering and make controls visible.
Retention matters too. If an event is deleted or expires, does the search index remove it? If the source relay prunes an event, does the search relay keep it? If a user updates a profile, does profile search return stale identities? The answers do not have to be identical across every search relay, but they must be knowable if people will trust the results.
Your search routine
When you search Nostr, start by asking where you are searching. If the client does not tell you, treat results as partial. Try another search relay. Try a kind filter. Try the author's pubkey. Try a known source relay. Try exact phrases and broad concepts. If the result matters, fetch the event and verify the signature rather than quoting the search snippet.
When you publish something you want found later, help search work. Use clear titles for long-form posts. Use meaningful tags. Avoid hiding important context in images only. Publish to relays likely to keep and index the event. Check whether search relays can find it after a delay. If the work is important, keep a canonical link and event id.
When you build a client, do not label partial search as total search. Show the relay scope. Check NIP-11 for supported NIPs. Query several NIP-50 relays when appropriate. Let users filter by kind. Preserve event provenance. Handle unsupported extensions gracefully. Teach the difference between no result and unsupported search.
When you run a search relay, publish your scope and limits. Tell people whether you index kind 1 notes, profiles, long-form posts, communities, media metadata, reports, relay lists or app data. Tell them what you exclude. Tell them how spam works. Tell them whether deletion and expiration affect results. The clearer the index, the more useful the result.
The final habit is simple: search, then verify. NIP-50 can make Nostr feel much more usable, but it should not become another invisible authority. Use it as a map, not a court ruling. A good map tells you where to go. It does not replace the place.
Concrete search situations
Imagine you remember a post about "outbox discovery" but not the author. A NIP-50 search relay can find candidate notes or long-form posts by that phrase. If the client lets you narrow by kind, you can move from noisy short notes to longer writing. If it lets you narrow by author after you recognize a name, the search becomes cleaner. If it shows source relays, you can fetch the result directly instead of trusting the index card.
Imagine you are looking for a developer's profile. A broad text search for the name may return mentions, quotes, old posts, impersonators and jokes. A profile-aware search surface can focus on metadata events and valid NIP-05 domains. That makes onboarding easier. But it also means the search surface chooses which identity signals matter. If it ranks verified domains above unverified keys, that may help normal users and disadvantage people without DNS identity. The design should name the signal.
Imagine you are a community moderator looking for reports about a scam domain. A search relay that indexes kind 1984 reports, URL tags and text content can help you see patterns. A relay that searches only kind 1 notes will miss much of that picture. The same query produces different social consequences depending on which event kinds are indexed.
Imagine you are trying to find a local event. A global search relay may bury it under unrelated posts. A local relay or community search surface may be much better. NIP-50 does not require every search to be global. In many cases, scoped search is the whole point: search this venue, this group, this conference, this city, this project, this marketplace or this app context.
Imagine you are rebuilding old research. You need more than a phrase match. You need dates, authors, relays, event ids, deleted or expired state, repost trails, replies and maybe archived copies. NIP-50 can start the trail, but serious research still needs source discipline. A result list is not a citation until you know what produced it.
What search cannot prove
A search result cannot prove that something is complete. It can show that an indexed event matched a query. It cannot show that no other relevant event exists. It cannot show that every relay was searched. It cannot show that a missing result never happened. It cannot show that an index was unbiased. It cannot show that the author is who the display name suggests. You still need event verification and context.
A search result also cannot prove that an event should still be public. A relay may index an event that another relay removed after a deletion request. It may show an event whose expiration was not honored. It may surface a private-context screenshot or old conflict without social context. Search makes memory available, but availability is not the same as judgment.
Search cannot solve relay selection either. You might find a person through search and still fail to follow them because your client does not use their write relays. You might find an old event and still fail to load replies because thread participants used different relays. NIP-50 helps discovery, but NIP-65 and outbox discovery still carry the routing job.
Search cannot protect you from malicious matching. A spammer can stuff phrases into content. An impersonator can mention famous names. A marketplace scam can use trusted tags. A search relay can fight this with spam filters and reputation, but filters are imperfect. The user-facing result needs enough provenance that you can decide whether a match is meaningful or bait.
Search cannot replace human curiosity. A Nostr result often needs a second click, a profile check, a relay check, a timestamp check and a context check. That sounds like friction, but it is also agency. You are not trapped inside one company's result page. You can inspect the signed event and compare relay views.
Profile, domain and people search
People search is emotionally different from document search. If you search for a name and the first result is wrong, you may follow the wrong person, trust the wrong key or miss the actual builder. Nostr display names are not unique. Profile metadata can be copied. Avatars can be reused. NIP-05 domains help, but they are not universal. A good search surface should rank and label identity signals carefully.
For profiles, a relay may search kind 0 metadata, NIP-05 identifiers, display names, names, about fields and maybe follower context. It may prefer recently updated profiles. It may prefer profiles seen on reliable relays. It may use web-of-trust signals. These choices are product decisions. They should not be hidden behind "best match" as if best were objective.
The domain: extension can help when you are trying to find accounts tied to a known identity domain. That is useful for organizations, media projects, software teams and communities that use NIP-05 consistently. It is less useful for pseudonymous culture, new users or people who intentionally avoid domain-backed identity. Search should support both styles: domain-assisted identity and key-native identity.
People search also needs protection against stale profiles. A user can update their profile, move relays, rotate identity practices or abandon a key. A search index that still ranks a very old profile first can mislead people. If possible, clients should show updated time, source relay and whether the profile was fetched recently. A profile result without freshness is only a guess.
If you are trying to find someone important, do not stop at the search result. Check their NIP-05 if they use one. Check whether known people follow or reference that key. Check recent posts. Check whether the key appears on multiple relays. Check official links if the person or project has them. NIP-50 can help you discover a candidate. It cannot make identity trust automatic.
Local, paid and private search
Some of the most useful NIP-50 experiences will not look like public web search. A local relay can let members search venue announcements, menus, events, badges, posts, media and community rules. A paid relay can offer cleaner search across admitted users. A private project relay can search team decisions and public release notes. A marketplace relay can search listings. A music or media app can search tracks, highlights, long-form posts or creator profiles.
That kind of search should be scoped on purpose. If you are in a local room, you may not want the whole network. You may want the dinner schedule, the event recap, the organizer's note, the local badge or the group's moderation rule. A smaller corpus can feel more useful because it matches the task. The danger is only when a scoped search is visually framed as universal.
Paid search relays can fund better indexing, moderation and uptime. They can also become soft gates. If the best search lives behind payment, users outside that relay may see a thinner network. That is not automatically wrong, but it matters. The healthier ecosystem has multiple search routes: free public indexes, paid high-quality indexes, local indexes, personal archives and app-specific search. Diversity keeps search from becoming the new platform layer.
Private search raises privacy questions. If a relay indexes encrypted event envelopes, app state or membership data, the operator must understand what is exposed. Searching encrypted content is usually not possible without decryption, and decrypting on a server changes the trust model. Apps should not smuggle sensitive search into public relays and then act surprised when data leaks.
Local and private search should have clear deletion and retention behavior. If an event expires, should it remain searchable inside the local archive? If a member leaves, do their posts remain? If a moderator removes content, does search show a tombstone or nothing? These are community design questions, not only technical knobs.
Search as a research tool
Researchers will use NIP-50 because it is the easiest way to collect candidate events by topic. That is useful, but it also creates methodological risk. If you search one relay for "zaps" and count results, you have counted that relay's indexed matches, not Nostr's global conversation about zaps. If you search one language or one time window, your result has that bias. If spam filtering is on, the dataset is already moderated.
Good Nostr research should name the search relays, query strings, event kinds, date ranges, filters, extensions, spam settings and retrieval date. It should explain whether results were re-fetched from source relays and whether signatures were verified. It should state what was missing. This sounds fussy, but it is how you avoid turning a partial index into a grand claim.
Search can still be powerful for research. It can surface public debates, technical proposals, app launches, bug reports, scams, community norms, moderation patterns, media links and adoption signals. It can show how language travels across clients and relays. It can help map who participates in a topic. But it should be combined with relay metadata, event graph analysis, follow graphs and manual reading.
For journalists and archivists, NIP-50 can be the start of a source trail. Find the event. Open the author profile. Check timestamps. Look at replies and reposts. Check other relays. Capture event ids. Compare search results across relays. Ask whether the post is original or copied. Nostr gives you signed material, but interpretation still takes work.
The best public search tools will make that work easier by exporting event ids, showing source relays, preserving query metadata and explaining index scope. That is the difference between search as a toy and search as public infrastructure.
How NIP-50 fits the relay stack
Put NIP-50 beside the other relay NIPs and the shape becomes clearer. NIP-11 tells you whether a relay claims search support. NIP-65 tells clients where authors prefer to write and read. NIP-66 helps you understand whether relays are alive and monitorable. NIP-42 may gate access to a search relay. NIP-43 can describe access metadata. NIP-09 and NIP-40 affect whether deleted or expired events should remain searchable. Search does not live alone.
If a client wants to provide high-quality search, it should not simply broadcast search filters everywhere. It should discover relays that support NIP-50, group them by role, handle rate limits, cache results, label scope and fall back gracefully. It should also know when search is the wrong tool. If the user wants to follow an author, use relay lists. If the user wants relay health, use monitoring. If the user wants a known event, fetch by id.
If a relay wants to support NIP-50 well, it should not merely accept the field and do a naive substring scan forever. It should decide its corpus, indexing strategy, spam posture, deletion behavior, extension support, ranking method and limits. It should return useful results quickly. It should expose support in NIP-11 and explain scope to humans.
If the ecosystem wants search without centralization, it needs many search relays with different strengths. Broad public indexes. High-quality paid indexes. Profile directories. Local room search. Community search. Media search. Marketplace search. Developer search. Archive search. The protocol lets them coexist because a client can query several relays and compare results instead of submitting to one search monopoly.
That is the beautiful tension of NIP-50. It makes Nostr easier to use by adding a familiar search motion, but it keeps the relay model visible if clients do their job. You get discoverability without pretending there is one database behind the curtain.
Sources worth opening
Open these when you want the exact standard and real-world search-relay context.
- NIP-50: Search Capability
- NIP-11: Relay information document
- NIP-65: Relay list metadata
- NIP-66: Relay discovery and liveness monitoring
- filter.nostr.wine relay readme and NIP-50 support notes
- Vertex relay documentation for profile discovery and NIP-50 profile search
- Searchnos: an index-only NIP-50 relay project
- Nostr Watch for relay discovery and liveness context