About Spes Publica

What it is

Spes Publica is a search engine built around a simple idea: help people search the web, don't monetize their behavior, and keep their searches and identities decoupled.

What's with the name Spes Publica?

Spes Publica /space pub lick uh/

Spes Publica is Latin for “public hope.” We think search should be a public good.

Spes is the ancient Roman goddess of hope. Romans built temples to her and put her on their coins. Typically she was depicted as a young woman, stepping forward and holding out a not-yet-blossomed flower bud. This simple symbol embodies the nascent hope within it, reinforcing her personification.

And “Publica” means that it belongs to everyone. It's the same word found in “res publica” (the public thing) which is where our modern term “republic” comes from. Roman coins once carried the inscription SPES PVBLIC, “public hope.” To us it means hope held in common, for all people rather than for one.

Between the two words we see a dot attached to the lily bud. More accurately in this context it is called an interpunct. The interpunct is a glyph that was historically used to separate neighboring words. Here it does the opposite, joining them. It's an incredibly simple symbol, but here it represents the potential for the bud to burgeon through its bulbils. The circumpunct (☉︎) traps the same dot inside a circle. Here we set it free, joining it to Spes, Publica, and the bud itself.

The graphic of the bud found in the logo is our version of Spes's flower. It deviates from the white lily of Western tradition and is instead Lilium bulbiferum, known by the common names orange lily, fire lily, tiger lily and St. John's Lily.

What makes it different

Some other search engines are built to learn from you, profile you, and monetize your behavior. Spes Publica is meant to be a tool for the public good, because search should be a tool, and not make you into one.

There are no AI systems running in the Spes Publica app. We're not reading your search query to build an advertising profile on you. We don't study you, profile you, or surveil you for the purpose of making money. We don't build a behavioral advertising profile on top of your queries. We don't quietly repurpose search data for personalization, targeting, or engagement optimization.

What we mean by private

Privacy in search doesn't exactly mean that reading the words you type is impossible. To find results, something has to read your search term. But what makes a search personal is knowing who asked. Spes Publica is built so a search and the person who made it are never put together: the part that knows you're connected can't read your search, and the part that reads your search never learns who you are. The search terms themselves might be logged temporarily or added to anonymized systems or databases, but never in a way that ties them to who performed the search.

How searches and searchers are kept apart

What Spes Publica will do

It's simple really:

We will provide a simple search experience.
We will stay free to use. (But we may explore non-behavioral revenue streams like scheduling priority, donations, subscriptions, or non-targeted advertising.)
We will devise anti-abuse systems and protect our service and systems.
We will have generalized administration and analytics tools running so long as they can't tie anything to specific user data. All monitoring tools will be depersonalized and high-level.

This is what we feel was the unwritten social contract of search before the rise of behavioral monetization.

What we won't do

We will not repurpose search data for personalization, targeting, or engagement optimization.
We will not store personal data associated with search terms as a dataset, or as part of the product at all.
We will not use your searches to build a behavioral advertising profile.
We will not add any tooling around the search itself for analytics, replay, or observability that could be tied back to a user.
We will not become another feed, dashboard, or engagement trap.
We will not build an ad empire on top of query history and user data.
We will not be a lawless anonymity tool.

Why this matters

It matters because you matter, and your privacy matters!

Searching is both ordinary and intimate. We search when we're curious, stuck, embarrassed, hopeful, planning, sick, lost, excited, learning, grieving, buying, fixing, or just plain bored. Search is a window into our minds. It is a powerful and personal thing.

We don't think a business should be built on disrespecting your privacy.
We don't think giving up privacy should be the price of searching the web.

That is exactly why the website you choose to search with should earn your trust. It shouldn't be a system for studying you, for steering you, or for turning your intent into a product. It should just help you search the web.

How the business works

Spes Publica is intended to stay free to use, but we acknowledge that money may be necessary to sustain the service. We will collect money by developing a system of scheduling priority rather than behavioral monetization. In plain terms: pay to skip the line if there is one and you want to. We may also explore other non-behavioral revenue streams, like donations, subscriptions, or non-targeted advertising.

The core principle is that this business will not be built on manipulating users nor on monetizing their behavior.

Stamps

Searching on Spes Publica is free. When it's busy, searches wait in line. A stamp lets one search skip the line, and that search also gets results from a paid search source. Stamps come in packs, and bigger packs cost less per stamp. See pricing.

Stamps are made so that we can't tell who spent them. We know an account bought stamps, but not which searches they were used on.

Why stamps, not credits?

Credits are something that's credited to your account. When you buy credits, you expect them to follow your account wherever you sign in. Stamps are different: they're held, like postage stamps or cash. A post office sells you stamps, but once a stamp is on a letter, nobody can tell who bought it. Ours work the same way, so we can't tell whose stamp was used on a search.

To keep things simple, we credit you with a count of stamps when you buy them, and your devices take a few at a time from that count as you search. Unused stamps go back to your count when you sign out.

How stamps work, in detail

Accounts

You don't need an account to search. An account is where you keep your stamps, and it asks for very little. You choose a username, and you sign in with a passkey, a password, or both. Your password is scrambled on your device before it's sent, so it never reaches our servers.

When you sign up you get a 12-word recovery phrase. Keep it somewhere safe. You can also add up to two recovery email addresses, which let you back in after a 48-hour wait. Nobody at Spes Publica can reset or recover an account for you.

The technical details are in how accounts and stamps work.

AI policy

AI is great. This product was developed with the assistance of various AI systems. This is not slop code. The reason this product exists is to meet the demands of people who want a space to interface with web search in relative anonymity and privacy.

We don’t run any AI, LLM or machine learning on you or your search. Your data doesn’t feed a Spes Publica model. That covers everything Spes Publica runs itself. The search engines we send your search to are separate companies with their own systems, and some of them use AI.

How is it different from other privacy-focused search sites, like DuckDuckGo?

DuckDuckGo is a great search engine, and we have a lot of respect for them. Our focus is a little different: Spes Publica is built so a search and the person who made it are never put together, and we won't show ads based on what you search. We want a search experience that is completely free of behavioral monetization, and that means not keeping anything that ties a search to a person.

How it works

When you use Spes Publica to make a search, your browser prepares the search term, then relays it to a separate search execution boundary that runs the search, and your browser shows the results.

What “protected relay” means

Every search result gives you two things: a link to the page and, sometimes, a preview image. Normally either can leak your identity and what you searched for. The protected relay is how Spes Publica plugs the leak.

How the relay works today

Relay images. Preview images are fetched for you by the search service, shrunk, and delivered with your results. Your browser never contacts the sites hosting those images, so they can't see your visit or use images to follow you across the web.
Direct links. Results link straight to the page, with no tracking redirect in between, and Spes Publica doesn't record which result you open. Links are also set not to tell the destination that you arrived from a search, or what you searched for.
What it can't hide. Once you open a page, that site sees your visit the way it would any other: your network address, your browser, and anything it tracks itself. The relay protects the search, not the browsing that follows.

How it could work, hardened

These are directions we may take, not things Spes Publica does today:

Cleaner links. Strip known tracking parameters (like utm_ tags and ad click IDs) from result addresses before you ever see them.
A private view of the page. Optionally open a read-only copy of a result through the relay, so the destination sees the relay's visit instead of yours.
Sturdier images. Remove hidden image metadata, re-encode every preview, and cache them so repeat fetches don't reveal what's being searched or when.
Harder-to-correlate timing. Batch and space out relayed requests so outside observers can't easily match a search to the fetches it causes.

Searches, not searchers

Your search terms only become private information when they're coupled with your identity, so that coupling is what Spes Publica is built to prevent.

How the two are kept apart

The relay is the part of Spes Publica your browser talks to. It knows a visitor is connected, but it only ever receives your search encrypted, so it can't read it.
The search service reads your search so it can run it, but it never learns who sent it: no network address, no cookie, no account.
Neither one keeps a log that would let a search and a visitor be matched up later. Search terms on their own may be logged temporarily, but never alongside anything that identifies you.
Results are deleted 15 minutes after a search finishes. They're encrypted for your browser the whole time.
To stop one visitor flooding the queue, the relay counts how many searches each connection makes, for a few minutes. It counts under a scrambled key, in memory only, and never next to anything about what was searched (which it can't read anyway).

What we keep about searches

Search terms on their own aren't tied to anyone, and they're the best way to see what's working and what isn't. So the search service keeps a short record of searches, built so that no entry can be traced to a person:

The search term, with email addresses, phone numbers and long numbers (such as card, account and tracking numbers) replaced before it's saved.
How it went: how many results came back, which sources answered, whether a helper such as weather or currency answered it, whether a stamp was used, and how long it took.
The date, but not the time. Each day's searches are stored in random order, so their order can't reveal when they were made either.
Nothing about who searched: no network address, no cookie, no session, no account. The search service never receives them, so it couldn't save them if it tried.

Individual searches are deleted after three days. Daily totals, such as how many searches there were and how many found nothing, are kept. If what we keep ever changes, we'll update this page first.

Being honest about today

Right now both halves run on servers we operate. Keeping them apart is a matter of how Spes Publica is built and run, not something that's technically impossible for us to undo. We want to make the separation stronger over time, for example by giving the two halves nothing in common they could be lined up by, and eventually by running the search service somewhere we can't look into.

How it will work

You type a query into the browser.
The browser runs the first policy check inside your browser.
If you are signed out, the browser generates a randomized local key for that search state. If you are signed in, your search-related state and logs stay protected behind your password.
The browser encrypts the search before Spes Publica handles it.
Spes Publica relays the protected search and handles routing, request tracking, and queue priority without needing plaintext query access.
A separate search execution boundary can decrypt or otherwise receive the query, perform the search, and return results back through Spes Publica.
The browser decrypts the response where the protocol supports it and renders the results.

If Spes Publica later offers paid priority, there may be a way to skip the line when the system is busy. Payment is for priority access only.

How it works today

You type a query into the browser.
The browser runs a very small local keyword check before submission.
The browser encrypts the search locally and wraps its per-session key for the separate execution boundary before Spes Publica relays the request.
The Spes Publica web service forwards that envelope to a separate execution service.
The relay creates a request record right away, then tracks it through a queued, running, ready, or failed lifecycle, including a server-decided queue tier and queue position while the browser polls for updates.
The execution service unwraps the query and looks it up in Spes Publica's own index first, so results it has show almost at once. It then asks the outside search engines through SearXNG, and folds their results in below what you can already see, ranked together with ours.
The execution layer normalizes result items into a cleaner shared shape.
The execution service encrypts the result payload back to the same browser-held session key before the relay stores or returns it.
The first result payload can come back before thumbnail work is done, and then first-party inline thumbnail previews can stream in afterward so the browser does not need to pull third-party image URLs just to render the page.
The browser keeps the active request ID out of the shareable URL, and readable results stay bound to the same anonymous session plus local browser-held key material.

So the shape is already browser -> relay -> execution -> browser, and the current MVP now has a real encrypted request/result path for signed-out sessions. What is still ahead is stronger hardening, compatibility work, and the signed-in protected-state story.

Why split relay and execution?

Because the product claim depends on boundaries. If one service did everything, it would be too easy for the relay itself to become the place where raw queries are visible, stored, debugged, or accidentally retained.

Separating the roles keeps the architecture honest, even while parts of the MVP are still placeholders.

Plain-language picture

These diagrams are simplified, but they show the core product promise clearly: Spes Publica should stay out of the business of reading and keeping your normal search text.

Spes Publica DIAGRAM:

[You]
  |
  | type a search
  v
[Your browser]
  - the first place where your search is readable before it is relayed
  - runs the first local policy check
  - generates or unlocks the key material for the search
  - encrypts the search payload
  |
  | sends a protected search request
  v
[Spes Publica]
  - forwards the request
  - handles request tracking and queue priority
  |
  | passes it to a separate search-running service
  v
[Search execution boundary]
  - can decrypt or otherwise receive the search
  - may still need to read the search in order to run it
  - can fetch, shrink, and wrap small thumbnail previews
  |
  | sends results back through Spes Publica
  v
[Your browser]
  - decrypts the response where the protocol supports it
  - receives first-party result previews instead of pulling third-party image URLs itself
  - shows the results to you

The key point is narrow but important: some search-running system may still need to read the search, but Spes Publica itself should not. The relay is a coordination layer, not a search-running layer.

BIG SEARCH DIAGRAM:

[You]
  |
  | type a search
  v
[Big search company]
  - receives the search directly in plain form
  - can connect it with your account, device, location, and clicks
  |
  +--> [Search history and retention]
  |
  +--> [Personalization systems]
  |
  +--> [Ad targeting and audience signals]
  |
  +-->   [Wider profile across products and services]
    |
    v
  [Results page]
    - can return image URLs that your browser then requests from third-party hosts and CDNs
    - spreads request data across more parties and creates extra tracking surface, including potential supercookie-style linkage
    - results and ads can be shaped by that larger profile

That is the difference in plain English: a typical large search platform can fold your search into a broader profile and make your browser fan out to third-party image hosts along the way, while Spes Publica is trying to keep its own role much narrower.

What is still early?

Searches and results are already encrypted in your browser. What's still early is around that core: the in-browser policy check is very small, signed-in accounts and their protected search state don't exist yet, and key rotation and recovery still need to be built.

We're prioritizing an honest product flow first, then backfilling protected search-state storage, key handling, and later integrity layers while retaining the trust model.

What happens in the browser

The browser is the first place where query inspection happens. In the current direction, client-side policy scanning belongs here rather than in Spes Publica's normal backend path. Today the browser already encrypts the search before Spes Publica relays it, and the policy check is still very small. Later versions should do more of the protection work here too, like password-protected search state for signed-in users.

What happens inside Spes Publica

Spes Publica acts like a relay and coordination layer. It serves the app, accepts the request envelope, forwards that envelope toward execution, and returns the result envelope back to the browser. The product aim is that normal search handling should not require Spes Publica to keep readable query text sitting around in storage or logs.

In the current MVP, that coordination layer also exposes a small request lifecycle: the browser gets a request ID immediately, the relay tracks the search as queued or running, and the results page polls until the request becomes ready or fails with a clear message.

Longer term, Spes Publica should also be able to hold only protected search-related user state and normal user logs rather than readable query history.

What happens at the execution boundary

Some system still has to actually perform search. That role belongs to a separate execution boundary. Today that means a dedicated execution service which can call SearXNG or a fallback provider. In a fuller version of the system, that boundary may evolve, but the architectural idea remains the same: search execution visibility is separate from Spes Publica-blindness.

That execution layer is also where result normalization belongs. Provider quirks get cleaned so that the browser receives a consistent shape: invalid links can be dropped, duplicates collapsed, and missing text fields backfilled before rendering.

That execution layer is where Spes Publica can keep provider quirks, normalization, thumbnail wrapping, and search-running visibility separate from the public relay.

Why not just say “end-to-end encrypted” and move on?

Because search is not a messaging app. Somebody, somewhere, usually has to interpret the query in order to produce search results. Spes Publica is trying to be clear about that.

The honest claim is narrower and better: the relay your browser talks to never sees your search term, and the search service that has to read it never learns who sent it.

How accounts and stamps work

Accounts and stamps are built so that we hold as little as possible, and so that nothing we hold can be tied to a search. This section describes exactly what happens.

A separate service

Accounts run as their own program on the server, with their own database. It isn't allowed to make connections to the internet. The only thing that talks to it is the relay, and the relay passes along only what the account service needs: the request itself, the account cookie, and the headers that show the request came from this site. It never passes your network address, your browser details, or any other cookie.

The account cookie is limited to account pages. Your browser never sends it with a search, so a search can't carry your account with it.

What an account stores

A random account number and the month it was made.
Your username, hashed on your device and then hashed again on the server with a secret key. The database has no plain usernames, and a stolen copy can't be checked against a list of them without that key.
Recovery email addresses, if you add any, as hashes made with the same secret key. We can't read them, list them, or email them unless you type one in.
A password record that can check a password without revealing it. There is no password in it.
The public half of each passkey.
The public half of your recovery key.
Your encrypted details, which only your devices can read.
Your stamp balance: how many paid-for stamps you have left.
Sign-in sessions, stored only as hashes of the cookie values. They end after 30 days.

It doesn't store your name, your network address, a log of sign-ins, or anything about your searches.

Passwords

Passwords use OPAQUE, a protocol designed so that the server never receives the password, not even while you sign in. Your device blinds the password with a random value before sending it, the server answers using its own secret key, and your device turns the answer into a key of its own. Only the right password produces the right key, and the server can't learn the password from any message it sees.

Your device also stretches the password with Argon2, which makes each guess slow. Guessing a password from a stolen database would also need the server's secret key. Guessing online is limited too: after five wrong passwords, each further try for that account has to wait longer, up to an hour.

Passkeys

A passkey is a key pair kept by your device and unlocked with Face ID, Touch ID or your device's lock. We store the public half. Signing in means your device signs a fresh challenge from us, and we check the signature. There's nothing to type and nothing to guess. On devices that support it, the passkey can also unlock your encrypted details.

The recovery phrase

Your 12 words are 128 bits of randomness, written in the standard BIP-39 word list so typos can be caught. From them your device derives three separate keys. One finds your account without a username. One signs a challenge to prove you have the phrase. One unlocks your encrypted details. We store only the public half of the signing key, so the phrase itself never leaves your device.

Recovery emails

You can add up to two email addresses for recovery. Each one is confirmed with a link before it counts, and stored only as a hash. To recover, you type your username and one of the addresses. If they match, we send a link to that address. We never send your username.

Opening the link starts a 48-hour wait. If you sign in any other way during the wait, the recovery is cancelled, so someone who gets into your email can't quietly take your account while you still have it. After the wait, the same link lets you set a new password or passkey and a new recovery phrase.

An email can't unlock your encrypted details, because we can't open them either, so recovering by email starts them fresh. Your stamp balance is kept, and stamps already on your devices stay there.

No support team

Your passkeys, password, recovery phrase and recovery emails are the only ways into an account. We can't reset a password, change a username, or move an account to someone new, and no one can ask us to. That rules out a common way accounts get stolen: talking a support team into handing them over.

Your encrypted details

Your username and your recovery email addresses are kept in a small encrypted file we call the vault. It's locked with a random key made on your device. That key is then locked again, separately, by your password, by your recovery phrase, and by each passkey that supports it. We store those locked copies but can't open any of them.

How stamps work

Stamps work in two stages. When you buy stamps or redeem a code, your account gets a balance: a number, like money in an account. A balance can't be spent on a search. Your devices turn it into stamps, a few at a time, and only stamps can be spent.

Without an account, a code is the balance: your browser keeps it and makes stamps from it in the same way, and the code's count goes down instead of an account's.

Each device keeps about 20 stamps. When it has fewer than 8, it makes more from your balance at a random moment while a Spes Publica page is open, between 20 seconds and 4 minutes later, and never within 20 seconds of a search.
To make a stamp, your device creates a random 32-byte value, scrambles ("blinds") it with a random number only the device knows, and sends us the scrambled version. We sign it and take one stamp off your balance. Your device then removes the scrambling. What's left is our valid signature on a value we have never seen. That's a stamp. This is an RSA blind signature, as described in RFC 9474.
The stamps stay on the device, in its browser storage. Searches spend them from there, without contacting the account service.
Signing out sends the device's unused stamps back. We mark them as used and add them to your balance, so they aren't left on a shared computer.

Why it works this way

The point is that a stamp can't be traced to the account that paid for it. Two things make that true.

We never see the stamp before it's spent. We only ever signed its scrambled form, so when a stamp arrives with a search we can check our signature on it, but nothing in our records matches it to the account that made it.
Stamps are made ahead of time, at random moments. If your device fetched a stamp right before each search, we'd see "this account just got a stamp" a second before "a stamped search arrived," and the timing would connect them. Making a small batch at random times, separate from searching, breaks that connection.

The cost is that stamps on a device belong to that device, like cash in a wallet. Your balance is safe on our server, and the handful on each device is only lost if that device's browser data is cleared.

How a stamp is spent

When you search, the page sends one of the device's stamps along with your encrypted search. The relay asks the account service whether the stamp is real and unused. It sends only the stamp: no account, no cookie, no address, no search.

If the stamp is good, it's recorded as spent and the search goes to the front of the line. It also includes results from the Brave Search API, a paid source that costs us about half a cent per search. The record of spent stamps is a list of hashes, with no times and no accounts, kept only so the same stamp can't be used twice.

What we can still see

Being exact about the limits matters as much as the protections.

We know each account's stamp balance, and when a device turns some of it into stamps. We don't keep a record of when.
A crypto payment buys a code, not stamps for an account. When a code is redeemed we don't record which account it went to, so a payment isn't linked to an account or to any search. If you buy a code and redeem it straight away, the timing alone could suggest which account it went to, and how many stamps it added. Waiting a while, or redeeming it along with other codes, blurs that.
If you're the only person using Spes Publica for a while, we'd know that the stamped searches in that time were yours, because nobody else had stamps to spend. Random timing can't hide that; only more people using the service can.
A stamp is spent when the search starts. If that search then fails, the stamp isn't returned, because we have no way to know whose it was.
The stamps on a device are stored by its browser. If you clear your browser data, those stamps (about 20 at most) are gone, because we can't tell which ones were yours to give them back. Your balance isn't affected.

Current state

Spes Publica is currently in early development. The search experience is not yet fully built out, and the service is not yet open to the public.

What comes next

Password-protected search state for signed-in users.
Better pagination, so you can go past the first page of results.
Stronger browser-side result decryption and compatibility hardening.
Execution-key rotation, recovery, and compatibility handling around the anonymous-session crypto flow.