Noogle
Noogle is not just another search box. It is a Nostr DVM client: a Vue app that asks specialized Data Vending Machines to search notes, search profiles and perform other tasks, then makes the payment, relay and trust tradeoffs visible enough for careful users to inspect.
What Noogle really is
Noogle is a Nostr search and Data Vending Machine client. The live page is a search app at noogle.lol, but the interesting part is not only the input box. Noogle uses Nostr job events to ask external DVMs to perform search and related tasks, then it presents the replies in a web interface.
That makes Noogle different from a normal centralized search engine. A normal search site usually owns the crawler, index, ranking system and result page. Noogle is closer to a dispatcher and reader. It signs or creates a request, sends it through Nostr relays to selected service providers, waits for feedback and result events, and combines what comes back.
The No Bullshit Bitcoin release note described Noogle as a demo application that uses kind 5302 to ask DVMs to search Nostr content. The same note says the page combines results from available search DVMs, supports from:npub filters, and can use from:me when a user is logged in through a Nostr browser signer such as Alby or nos2x.
So the right mental model is not Google for Nostr. The better model is a web UI for sending search jobs into a Nostr-native market of data-processing services. Sometimes that looks like a search box. Underneath, it is a DVM workflow.
Why it belongs in Miscellaneous
Noogle sits awkwardly between categories. It is a search client, a DVM showcase, a payment experiment, a NIP-89 directory and a browser-search integration. It is not a social timeline client, not a wallet, not a relay, not a developer library by itself and not a pure AI product. Miscellaneous is the honest place for it until the DVM category becomes large enough to stand on its own.
That does not make it minor. Search is one of the hardest missing pieces in Nostr. Relays store events, clients read from relays, but users still need ways to find relevant notes, profiles, media and services across uneven relay coverage. Noogle explores one answer: let specialized DVMs compete or cooperate on search work.
The Miscellaneous label also helps avoid overclaiming. Noogle is a demo and a toolkit surface, not an official canonical Nostr search layer. If it returns useful results, great. If it returns incomplete results, that does not mean Nostr search is impossible. It means the particular DVMs, relays, indexes, filters and UI path used in that moment gave you that answer.
That is the useful tension. Noogle is small enough to inspect, but ambitious enough to show what Nostr-native search might become.
The DVM idea underneath
DVM stands for Data Vending Machine. In Nostr terms, a user publishes a job request, service providers can react, and a provider publishes a result event if it processes the job. The official NIP-90 text reserves the 5000-7000 event-kind range for DVM use: 5000-5999 for job requests, 6000-6999 for job results and 7000 for job feedback.
For Noogle, the key search jobs are kind 5302 and kind 5303. The data-vending-machines repository defines 5302 as Nostr content search: a client asks a search DVM to return notes based on a prompt, and the output is a JSON-stringified list of tags that should be event or address tags. It defines 5303 as Nostr people search, where the output should be profile pubkey tags.
Noogle's Search.vue code lines up with that. It creates a kind 5302 request for note search and a kind 5303 request for profile search. It also listens for kind 7000 feedback and kind 6302 or 6303 result events. That is the DVM pattern in miniature: ask, wait, inspect status, receive result.
The important reader point is that Noogle does not have to own every index. It can ask DVMs that already know how to search. The tradeoff is that the user now depends on the DVMs' quality, availability, pricing, spam policy and honesty.
NIP-90 has a warning now
Noogle is historically tied to NIP-90, but you should know the current status of that NIP before treating it as settled infrastructure. The official NIPs repository currently marks NIP-90 as draft, optional and unrecommended, with a warning that use-case-specific microstandards are preferred. That does not erase Noogle; it changes how you should read the protocol claim.
The live ecosystem has already produced specific DVM kinds, and Noogle uses those concrete kinds for search. But the broad NIP-90 umbrella became too flexible and messy to be a clean final answer for every data-processing use case. That is why the specific 5302 and 5303 definitions matter more than a vague statement that Noogle uses DVMs.
A good article has to keep both truths in view. Noogle is a real DVM client with real code and a live UI. At the same time, the standards layer around DVMs is still unsettled. Builders and users should expect naming, status codes, payment flows, encryption choices and task definitions to evolve.
That is not a reason to ignore Noogle. It is a reason to test it like an experiment, cite the exact event kinds, and avoid pretending the whole DVM universe is already finished.
What the live app exposes
The live Noogle page describes itself as decentralized Nostr search and other stuff. Its web app manifest names the product Noogle, sets the description to Other Stuff on Nostr and provides PWA icons. The HTML also links an OpenSearch descriptor, which means browsers can expose Noogle as a search provider.
The OpenSearch file is specific: it names Noogle, describes the service as searching Nostr, and points search terms to a noogle.lol query URL. That is a small but useful product signal. Noogle is not only a demo page you open manually; it wants to sit near the browser's search habit.
The `/nip89` page is the other important live surface. It presents Nostr NIP 90 Data Vending Machines and explains that Noogle is a demo client showcasing multiple DVM use cases: content search, profile search, content discovery and other processing tasks. It also says the DVMs are not running or being hosted on the site itself, but communicate through Nostr and are announced through NIP-89 style metadata.
That last detail is easy to miss. If a DVM is listed in Noogle, it does not mean noogle.lol operates that DVM. It means Noogle can discover or display it. The service provider boundary remains important for trust, pricing and result quality.
The NIP-89 directory role
Noogle is also a DVM directory. Its Nip89view component presents DVM cards with names, images, kinds, descriptions and payment badges such as free, flexible or subscription. It includes a copy-event-json button so users can inspect the announced DVM event.
NIP-89 is usually discussed as recommended application handlers, but Noogle uses the same broad idea of application/service announcements to make DVMs discoverable. That matters because a DVM ecosystem is useless if clients do not know which services exist, which kinds they support and what they cost.
The directory view is also a safety surface. A user should not only see search results. They should be able to ask which DVM answered, what kind it handled, whether it requested payment and whether it has a public announcement event. Noogle's interface moves in that direction by keeping active DVM state and DVM metadata in the UI.
Directory data is not the same as trust. A NIP-89 announcement can be false, stale, incomplete or impersonated if the user does not verify keys and reputation. But it gives clients a way to surface service identity instead of hiding every provider behind one search box.
How the search request works
Noogle's Search.vue file does several concrete things that are worth spelling out. It parses the user's query, looks for words that start with from:, removes those filters from the plain search text and turns some of them into user filters. It also handles a signed-in path where from:me can refer to the current user's own pubkey and following list.
The code then builds requests for known search providers. Current source references include hard-coded public keys for a nostr.band search DVM, a nostr.wine search DVM and a profile search DVM. It encrypts request content with NIP-44 when possible, falls back to NIP-04 decryption in some response handling paths, and tags each request with the selected provider pubkey and relay list.
After sending the request, Noogle listens for feedback and result events. Feedback events of kind 7000 can report status, payment requirements or errors. Result events of kind 6302 return note-search results, while 6303 returns profile-search results. The UI tracks active search DVMs and removes them as they finish or fail.
This is useful because it tells you exactly what Noogle is not doing. It is not merely querying one relay with a NIP-50 search field. It is sending DVM job requests to selected providers and aggregating the replies. That is a different architecture with different failure modes.
How it differs from NIP-50 search
NIP-50 is the relay search capability. A client sends a normal Nostr subscription request with a search field, and relays that support NIP-50 interpret the human-readable query. NIP-50 also says clients should use supported_nips to learn whether a relay supports search and should expect different implementation quality across relays.
Noogle's DVM model is different. Instead of asking a relay to search its own event store directly, Noogle asks DVM providers to process a search job. Those providers may use their own indexes, APIs, relays, spam filters, ranking logic or external systems. The result comes back as a job result event.
That difference is the whole point. NIP-50 is simple and relay-local. DVM search can be richer and more specialized, but also more dependent on provider identity and payment flow. A good Nostr search stack may use both approaches: relay search where it is available, DVM search where specialized indexing or ranking is useful.
For a reader, the practical rule is to compare results. If Noogle finds something another client misses, ask which DVM found it. If Noogle misses something a NIP-50 relay finds, remember that DVM providers have their own coverage limits. Search quality is a property of the whole path, not only the input box.
Payments, zaps and NWC
Noogle's payment code is not decorative. The Nostrability NWC tracker points to Noogle's Zap.vue as NWC evidence, and the current file exists under `ui/noogle/src/components/helper/Zap.vue`. That helper imports WebLN, Alby's SDK and Nostr primitives for building zap requests.
The code first looks for a stored NWC object in localStorage. If the stored URL starts with `nostr+walletconnect://`, it creates an Alby `NostrWebLNProvider`, enables it and sends the payment through `sendPayment(invoice)`. If no NWC connection is available, it tries a WebLN provider. If that fails, it copies the invoice so the user can pay elsewhere.
The same helper can build zap requests around a user's lightning address, amount, target event and target user. It constructs LNURL-pay callback requests and signs zap request events. That means Noogle can interact with the Nostr payment stack at several levels: DVM payment-required events, WebLN invoice payment, NWC wallet connection and classic NIP-57 style zaps.
The safety point is plain. If you only copy an invoice, the risk is one payment. If you store an NWC URL in the browser, the risk is the permission attached to that URL and the security of localStorage. Use a dedicated wallet connection, small budgets and revocation. Do not paste a broad main-wallet NWC secret into experimental web apps.
The localStorage risk
Noogle's helper code reads the NWC URL from browser localStorage under an `nwc` key. That is common in lightweight web apps, but it is not the same as a hardened secrets vault. Browser extensions, injected scripts, compromised dependencies, cross-site scripting bugs or a shared device can turn localStorage into a weak place for powerful wallet credentials.
This does not mean Noogle is unsafe by default. It means the NWC permission should be scoped as if a browser page is holding it. The wallet should limit amount, expiry and methods. The connection name should be easy to recognize later. The user should know how to revoke it.
The healthiest setup is a test wallet or sub-wallet with a very small allowance. Search DVM payments should not require a large balance. If a provider asks for payment, you can decide case by case whether the result is worth it. If a prompt feels vague, cancel it.
Noogle is a good place to practice this because the app is transparent enough for technical users to inspect the code path. But transparency is not a substitute for limits. The right wallet habit remains the same: make experimental connections disposable.
Search quality and spam
Noogle exists because Nostr search is hard. Relays have partial views of the network. Imported RSS or bridge content can pollute search results. Spam can be cheap. NIP-50 support is uneven. DVMs can improve that by using specialized indexes and filters, but they also introduce provider-level judgment.
The Stacker News search discussion is a useful outside signal. A user complained that Nostr search results were polluted by imported Mastodon and RSS content. Another user named Noogle as a dedicated search client, while also noting that it did not have many advanced search options at that time. The original poster replied that Noogle's results were not polluted in the same way.
That is exactly the product promise and limitation. Better results can come from better DVM choices, not from magic. A DVM can exclude spam, rank by relevance, focus on Nostr-native content, search profiles separately or use a different index. Another DVM may be stale, biased, narrow or down.
When you use Noogle seriously, treat each result as a lead. Open the underlying note, check the author, inspect date and relay context, and compare against another search path. Noogle can help you find things. It does not remove the need to verify them.
Privacy and query leakage
Search queries can be sensitive. In Noogle, a query may be sent to one or more DVM providers. Depending on the path, it may be encrypted to a provider, included in a job request, linked to your signing key or connected to a payment event. That is a different privacy profile from typing into a local client field.
The Search.vue code uses NIP-44 encryption for provider-specific request content and has fallback decryption logic involving NIP-04. That is good, but you should still assume the chosen DVM provider can learn the query it is asked to process. If you sign in and use from:me or provider-specific filters, your query can become more personally meaningful.
Do not send private investigations, legal issues, medical searches, doxxing attempts or sensitive personal names through an experimental DVM workflow unless you are comfortable with the involved providers and relays. Use public, low-risk searches first. If you need private search, look for a tool built specifically around that privacy model.
The DVM model can eventually improve privacy by letting users choose providers and encrypt task details. But provider choice is not automatic privacy. You still have to ask who receives the job, what is encrypted, what metadata is visible and whether payment creates a link.
What developers can learn
Developers should study Noogle because it is not only an app; it is a reference surface for how DVM clients feel. The code shows request construction, relay lists, provider pubkey targeting, event encryption, result handling, status feedback, search aggregation, profile search and payment fallbacks in one Vue app.
It also shows how quickly the UX grows. Once a client can send DVM jobs, search is only the first task. The repository includes components for image generation, chat, filters, recommendation and summarization. The `/nip89` view says the site is a demo client for a variety of DVM use cases, not only a search page.
The engineering lesson is that DVM clients need excellent state handling. A user may send one query to multiple providers, receive several feedback events, be asked for payment, receive partial or final results, and need to know which provider produced which answer. If the UI hides that too much, DVMs become another opaque search engine.
The product lesson is just as important. A DVM marketplace needs names, prices, reputation, supported kinds, error states and clear wallet prompts. Noogle has many of those ingredients, but the broader ecosystem still needs conventions that make them easy for non-technical users.
Limits before you rely on it
Noogle should not be your only evidence source. DVM results can be incomplete. Provider indexes can lag. A DVM can be offline. Relays can miss events. Profile search can confuse names, display names and pubkeys. A result can point to a note that another client cannot fetch because of relay mismatch.
The NIP-90 status warning matters here too. If a standard is in motion, clients and providers may not agree forever on event shapes, feedback semantics, payment expectations or encryption defaults. Noogle's current implementation is real, but real does not mean final.
The app also depends on web-app realities: JavaScript bundles, browser storage, external relays, Nostr signers, wallet providers and optional payment APIs. A failure in any layer can look like a bad search. Before blaming the search result, check whether the app loaded, whether your signer is available, whether relays are reachable and whether the DVM replied.
Use Noogle as a discovery tool and DVM laboratory. For high-stakes research, confirm with source links, other clients, raw event IDs and multiple search paths.
What to test first
Start with a public, harmless query. Search a known term, a known author or a known event topic. Compare the results with another Nostr search path such as a NIP-50-capable client, nostr.band or your normal Nostr client. You are looking for behavior, not only the result count.
Then try filters. Use from:npub with a public account and see whether the results narrow as expected. If you sign in, test from:me only with a query you are comfortable linking to your identity. Watch whether profile search appears separately from note search.
Open the DVM directory page. Look at which services are announced, which kinds they support and whether their payment badge says free, flexible, subscription or a fixed amount. The directory tells you who may be doing the work.
Only after that should you test payments. If a DVM asks for payment, use a small amount, a limited wallet connection and a path you can revoke. Confirm whether the app uses NWC, WebLN or invoice copy. The first paid test should teach you how recovery works when a payment fails.
Where Noogle is useful
Noogle is useful when you want to see DVM search as a product, not only as a NIP. It is also useful when ordinary client search feels polluted, narrow or unavailable. A dedicated DVM client can make different search providers visible and let you compare them.
It is useful for developers who want to build on DVM patterns. The repository gives you concrete Vue components and helper code, not only prose. The NostrDVM framework around it gives Python-side service-provider tooling for running DVMs, announcing services and handling payment-related setup through LNbits or lightning addresses.
It is less useful when you need guaranteed coverage, private search, enterprise audit trails or a polished mainstream search experience. The app is a public experiment in a young category. It gives you access to interesting machinery, but it also asks you to understand that machinery.
That is the charm. Noogle makes Nostr search feel like a network of services rather than a single box pretending to know everything.
The practical close
Noogle matters because it shows a different path for Nostr search. Instead of waiting for every relay to become a perfect search engine, it lets specialized DVMs receive jobs, process them and return results through Nostr. That turns search into a service layer that clients can discover, compare and pay for.
The tradeoffs are real. NIP-90 is currently marked with a warning. DVM providers can be uneven. Search results can be incomplete. Wallet connections can be over-permissioned. Query privacy depends on provider choice and encryption details. A tiny search box can hide a lot of trust decisions if the UI is not careful.
Use Noogle with that frame. Search public things, compare results, inspect the DVM directory, keep wallet permissions small and treat paid jobs as experiments unless the provider has earned more trust. In that lane, Noogle is one of the more concrete windows into what DVMs can become: not a finished answer, but a working map of a search marketplace being invented in public.
Sources worth opening
Start with the live Noogle app, the noogle.lol NIP-89 page, the NostrDVM repository, the ui/noogle source files, the DVM kind definitions for 5302 and 5303, NIP-90, NIP-89, NIP-50, the No Bullshit Bitcoin release note, the NWC/WebLN sources and the Nostrability tracker entry that points to Noogle's NWC payment code.
- Noogle live app
- Noogle NIP-89 and DVM directory page
- Noogle web app manifest
- Noogle OpenSearch descriptor
- Noogle PWA icon
- NostrDVM repository
- NostrDVM README
- Noogle UI directory
- Noogle UI README
- Noogle package metadata
- Noogle Search.vue
- Noogle Zap helper
- Noogle AboutPage.vue
- Noogle Nip89view.vue
- Noogle store.js
- No Bullshit Bitcoin Noogle release note
- getAlby awesome-nwc listing
- getAlby awesome-nwc raw README
- Nostrability NWC interoperability tracker
- NIP-90 Data Vending Machine
- NIP-90 mirror
- Data Vending Machines kind 5302
- Data Vending Machines kind 5303
- Data Vending Machines kind registry
- NIP-89 Recommended Application Handlers
- NIP-50 Search Capability
- NIP-44 encrypted payloads
- NIP-04 encrypted direct messages
- NIP-57 Lightning zaps
- Nostr Wallet Connect official site
- Alby NWC JS SDK guide
- WebLN documentation
- Stacker News discussion on Nostr search clients
