Why "Search All Messages" is a nightmare to build (and why I'm doing it anyway)

I’ve spent the last few months obsessed with a problem that somehow still isn’t solved: finding one conversation across the 5+ apps we all use for work.

This didn’t start as a SaaS idea. It started with me trying to find a project spec. I checked Slack. Then Telegram. Then Gmail. Eventually I found it… in a LinkedIn DM. That context switching is a quiet but constant mental tax, and after a while it just broke me.

So I started building a unified search tool. And it turns out: doing this properly is way harder than it looks.

1. The AST → SQL problem

You can’t just dump strings into a database and call it “search” if you want anything powerful.

If someone types:

from:alice "budget" after:2024-01-01

that needs to be tokenized, parsed into a real grammar, compiled into an AST, and then transpiled into optimized SQL. Anything less and your Postgres instance will cry the moment you add real filters across multiple platforms with different schemas.

This part alone took way more time than I expected—but it’s the only way to get fast, expressive search without hacks everywhere.

2. The privacy wall (almost made me quit)

Most “unified inbox” tools solve search by copying all your messages into plaintext on their servers.

That was a hard no for me.

I’ve been trying to design a system where even I can’t read user data. That pushed me into the world of searchable symmetric encryption and local-first indexing. In short: the heavy search index lives on your device, and the server is basically a blind sync layer.

It’s painful. Everything becomes 10x harder. But it’s also the only architecture I’d personally trust with my own messages.

3. Schema fragmentation is real

Every platform is a walled garden.

Slack has blocks. Telegram has deep history and edits. Email is… email. Trying to normalize all of that into a single “relationship timeline” without destroying context is a constant tradeoff.

Too rigid, and you lose platform-specific meaning. Too flexible, and you end up with a giant JSON blob that’s impossible to search well. I’m still not convinced there’s a perfect answer here—only less bad ones.

---

Where this is now

I’m building this under the name Unibox (unibox.today). It’s firmly in the “ugly but works” phase. Right now I care way more about search speed and privacy guarantees than polished UI.

If you’ve ever tried to build cross-platform search:
How did you deal with API rate limits?
And how did you prevent “context collapse” when merging completely different messaging models?

If you’ve been down this rabbit hole, I’d love to compare notes.