ants

Apps24 min readweb search client, NIP-50, NIP-19, NIP-65, Vertex and author-aware queries

ants

ants looks small until you read the rules behind the box. It is a Nostr search app by Gigi: part query language, part relay experiment, part profile resolver, part reminder that decentralized memory is harder than a feed.

The search box is the app

ants does not try to win you with a feed, a wallet, a media gallery or a giant settings panel. You open the official site and the first honest thing you learn is this: it is a search tool. The page title is simply ants. The repository subtitle says "advanced notes and text search." The live interface is spare: login, an input field, examples, and a product attitude that says search should stay search instead of becoming a tab hidden inside a timeline.

That plainness is refreshing because search on Nostr is not a decorative feature. It is one of the hard problems. In a centralized social network, search can sit on top of one company's database. In Nostr, there is no one database. There are relays. Some index text. Some do not. Some keep old events. Some drop them. Some specialize. Some enforce policies. Some know about the people you follow. Some have never seen the note you are trying to find.

Gigi's project page gives the clean public identity: ants is an advanced notes and text search tool built for Nostr, birthed at Sovereign Engineering, using Vertex for personalized profile lookups and search ranking. NostrApps gives the narrower app-directory identity: it searches global search relays and relevant outbox/write relays, with a by: directive for specific authors. Put those together and the product becomes clearer. ants is not trying to be your home client. It is trying to be the place you go when the feed forgets.

The README is refreshingly candid about the philosophy. ants would rather show too much than too little. It embraces false positives because Nostr search is often a question of discovery, not a courtroom database lookup. That is a useful stance. A cautious search tool that hides too much can feel clean while silently losing the thing you came for. ants prefers the messier answer: bring back more, then let the user filter, inspect and learn.

The name is small. The app is small. The problem is not.

Feeds are a bad archive

Most users first experience Nostr through a feed. That is natural. You follow people, read notes, reply, zap, mute, maybe add relays when something fails. But feeds are terrible memory tools. A feed shows what is recent or relevant according to one client. Search asks a different question: where is the thing I once saw, the quote I remember, the author I cannot name, the event another client lost, the thread that lives on a relay my main app is not reading?

That difference matters for every serious user. A creator needs to find old posts. A researcher needs to find a claim. A moderator needs receipts. A builder needs examples of an event kind. A community member needs the earlier argument, not the fifth retelling of it. If the only tool is scrolling, the network becomes forgetful. If search works, Nostr starts to feel less like a live chat and more like a public memory layer.

This is where NIP-50 enters the story. It defines a search capability that relays can expose, so clients can ask relays to search text rather than only requesting by fixed filters such as author, kind or tag. A Nostr search client does not magically know everything. It asks the relays that claim to search. The quality depends on what those relays indexed, how they rank, how fresh they are and which event kinds they understand.

ants is valuable because it makes that search role explicit. It does not hide search behind a tab inside a broad client. It says: type the thing, aim the search, see what comes back. That is enough to make it useful even before you understand every relay detail.

The query language is the product

The by: directive is the feature I would show someone first. It turns a vague search into an authored search. Instead of asking "where does this phrase appear anywhere?" you can ask "where does this phrase appear from this person?" That is closer to how humans remember things. You often remember who said it before you remember the exact wording.

The README shows that ants is much more than a plain keyword box. It supports author scopes such as by:fiatjaf and GM by:dergigi, self scopes such as by:@me and mentions:@me when you are logged in, profile lookups through p:, boolean OR, date ranges with since: and until:, media filters such as has:image and has:video, site shortcuts such as site:yt, and semantic shortcuts such as is:highlight or is:followpack. You can also search NIP references with forms like nip:05.

This matters because Nostr search is not only "find words." It is "find words by this identity, inside these event kinds, around this time, maybe containing this kind of media, maybe linked to this external site, and maybe resolvable from a bech32 entity." A client that makes those moves memorable is doing product design, not just adding syntax.

ants also treats direct entities as first-class citizens. It supports NIP-19-style paths for profiles and events: /p/npub..., /e/nevent..., /e/note..., hex IDs, and tag paths such as /t/asknostr or multiple tags. That is a subtle but important difference. Sometimes you do not need full-text search at all. You already have the entity. You need a place to resolve it, inspect it and move through related context.

Small tools often win by having one memorable move. For ants, the memorable move is not one command. It is the idea that search should be a language you can grow into.

Relay logic is where search becomes Nostr

Global search relays are the obvious first move. They index a lot and answer broad queries. If you search for a phrase, a username, a project name or a topic, they may find the public notes you expect. But Nostr is not built like one enormous search engine. A global relay can miss events for ordinary reasons: it never received the note, did not store it, did not index that event kind, dropped it under policy, or has not caught up yet.

That is why the second part of the ants description matters: relevant outbox/write relays. In Nostr, an author's write relays are the places where that user tends to publish. NIP-65 relay-list metadata gives clients a way to discover read and write relays for a public key. If you want to find something by a specific person, asking the relays where that person publishes can be smarter than shouting into a global index and hoping the index saw it.

The README is precise about this. ants has hardcoded relays for NIP-50 search and for general use. When a user logs in, it retrieves that user's relay lists from kind 10002, removes blocked relays from kind 10006, retrieves search relays from kind 10007, and uses those search relays in addition to the hardcoded list. When it connects to a relay, it checks NIP-11 relay information and reads which NIPs the relay says it supports.

That is the moment ants becomes more than a search form. It is teaching you that search is routed. The relay-status indicator shows which relays are involved, which support NIP-50, and which relays returned the results currently shown. Relays that returned results are shown differently, and the relay icon can filter results by relay. In a centralized search product, that kind of plumbing is invisible. In Nostr, making it visible is part of the education.

This is the heart of Nostr search: you do not only search text, you search topology. You ask, "Which relays would know?" For a popular account, global search might be enough. For a smaller account, a niche group, a deleted-from-one-relay post, or a recent note, the author's own write relays may be the better path. ants is designed around that insight.

Vertex makes names less blind

The hardest version of by: is not by:npub.... The hard version is by:gigi, by:HODL or p:john. Human names are messy. Nostr has public keys, NIP-05 identifiers, display names, profile metadata and impersonators. A useful search client has to decide which person you probably meant without pretending that the decision is obvious.

ants handles that with a two-track approach. If the user is logged in, the README says it can use Vertex for profile lookup through personalized PageRank, sending the user's pubkey as the source so results can be ranked through that user's social graph. If Vertex is unavailable, or if the user is logged out, ants falls back to relay search for profile events and ranks candidates with simpler signals such as direct follows, prefix matches, names and follower-reference counts.

This is one of the more interesting parts of the app because it admits that identity resolution is social. The "right" fiatjaf, Gigi or John depends partly on the network around you. A public key is absolute, but a nickname is not. Vertex supplies a Web-of-Trust layer so the app can make better guesses for the person using it, rather than only sorting by the loudest global signal.

There is one moving detail to read carefully. The README still talks about Vertex credits and pricing for reliable username resolution, while the Vertex homepage currently says Vertex is now free. That does not break the article's point. It means the operational model around Vertex is changing, and ants is tied to a live service whose policy can move. The durable fact is the product pattern: use personalized reputation when available; use relay-based fallback when not.

The codebase is small but not casual

The public trail is now clear. ants lives at dergigi/ants on GitHub under the MIT license. On June 6, 2026, the repository showed 20 stars, 6 forks, 34 open issues, 2,096 commits, two releases and a latest release, v0.4.2, published on May 10, 2026. The language breakdown is almost entirely TypeScript.

The package file names the app ants.dergigi.com and version 0.4.2. The stack is a modern web stack: Next.js 15, React 19, the Nostr Development Kit, NDK cache packages for Dexie and SQLite WASM, Fuse.js for fuzzy matching, fetch-opengraph for link metadata, Font Awesome icons, React Markdown, Prism for code rendering, Jest and Playwright tests. The development server runs on port 7473, which is a nice little signature if you know the app's culture.

The latest release is small but telling. It added support for viewing Nostr follow packs, kind 39089, through the is:followpack shortcut. It also added a real-relay search smoke suite in GitHub Actions, restored by:@me and mentions:@me, restored the NIP-05 endpoint at /.well-known/nostr.json for _@ants.sh, and restored the hosted Haven tutorial route. That is a search app doing the maintenance work a search app must do: syntax, identity, relay reality, tests against live infrastructure.

Gigi's project page adds the origin story. ants was birthed at Sovereign Engineering and uses Vertex. The same page places it beside other Gigi projects such as Boris, njump.to and Nostr Resources. That context is useful because ants feels like a maker's tool. It is opinionated, direct and built by someone who actually wants to search their own messy Nostr universe.

Why the rough edges matter

The README does not oversell the app. It says the current version is not very performant and will probably crash often. It says ants does not yet have many Web-of-Trust features. It keeps a development list that includes reducing excessive requests, adding a /kinds command, streaming search, relatr support, better relay manners, better blog-post support, Blossom image search by hash, better explanations for icons and symbols, UI cleanup and making things less buggy overall.

That honesty should stay in the article because it changes how you should use ants. This is not Google for Nostr. It is a living search workshop. The right expectation is not "type anything and receive the canonical answer." The right expectation is "learn the search language, watch which relays answer, compare results, and use the tool to understand the network's memory."

Search on Nostr will never behave exactly like search inside one company database. That is not a bug in ants. It is the nature of the protocol. A search tool cannot guarantee that a deleted event is gone. It cannot guarantee that every relay indexed every post. It cannot guarantee that every author's relay list is fresh. It cannot guarantee that ranking means importance. It cannot guarantee that "no result" means "nothing exists."

That last point is crucial. In a centralized product, no result often means the database did not find the thing. In Nostr, no result can mean the query was weak, the search relay missed it, the author's write relay was not checked, the event kind was not indexed, the note was on a relay with limited retention, or the content was not text-searchable in the way you expected.

A good Nostr search habit is therefore iterative. Search broadly. Search by author. Search with fewer words. Search a unique phrase. Try a URL. Try the public key. Check another client if the stakes are high. A tool like ants gives you a focused place to do that work, but it cannot remove the network's uneven memory.

How to test ants

Start with a phrase you know exists. Pick a public note from a visible account, copy a distinctive phrase, and search for it in ants. If it appears, open the result and compare it with another client. If it does not, try the author's identity with by:. That will tell you more about the search path than a random query ever could.

Next, test time. Search for something fresh, then something old. Search for a project name, a URL, and a phrase from a thread. Search for an author who uses unusual relays. The goal is not to produce a perfect scorecard. The goal is to understand how ants behaves when global search and outbox-aware search disagree.

Then test syntax. Try by:dergigi, p:dergigi.com, has:image, site:gh, is:highlight, bitcoin OR lightning and a date range with since: and until:. The point is not to memorize every shortcut. The point is to feel when the tool is doing direct relay filters, when it is doing full-text search, and when it needs profile resolution.

Then test privacy discipline. You do not need to log in for every search. If a query is sensitive, assume the search service or relays may see it. If you log in, watch what the app asks from your signer. A search client should rarely need powerful signing permissions. If it does ask, stop and read.

Finally, look at the relay-status view instead of only the results. Which relays were queried? Which returned something? Which support NIP-50? Which result disappears when you filter by relay? That is where ants becomes useful as a teacher. It does not only answer. It shows you why answers are uneven.

ants is best used as a small tool with a clear job. Keep it near the feed clients, but do not confuse it with them. When the feed forgets, search. When global search misses, ask by author. When a result is important, verify it somewhere else.

Sources worth opening

This article keeps claims close to the official app, Gigi's project page, the public repository, the current release notes, Vertex context and the Nostr standards behind search and relay discovery.

• ants official web app
• Gigi project page for ants
• ants source code on GitHub
• ants v0.4.2 release notes
• ants package metadata
• NostrApps ants listing
• NostrApps author identity for ants
• Vertex Web-of-Trust service
• NIP-05 DNS identifiers
• NIP-11 relay information document
• NIP-19 bech32 encoded entities
• NIP-50 search capability
• NIP-51 lists and relay-related user data
• NIP-65 relay list metadata
• NIP-01 basic protocol flow
• NIP-25 reactions
• NIP-27 text note references
• Nostr protocol NIPs repository
• NIP-01 basic protocol flow
• NIP-05 DNS identifiers
• NIP-07 browser signer capability
• NIP-10 text note threading
• NIP-11 relay information document
• NIP-19 bech32 encoded entities
• NIP-44 versioned encryption