Fifteen Years Ago, I Became an Evernote User

Fifteen years ago, I became an Evernote user. A happy time, when my thoughts were all about startups, Silicon Valley, and technology. And although today's Obsidian evangelists are absolutely certain that they are the first to create a second brain, allow me to say: I was building my second brain in the 2010s using Evernote and Moleskine. And Evernote's OCR search through images and documents was absolutely magical. It's no coincidence, apparently, that before that, engineers had been working on OCR solutions for the US government.

This article is about how you can build a local search for images and photos that will work without large corporate services, without LLM/SaaS, and without sending personal data outside.

What Evernote Meant to Me

Of course, as is the case now, behind a fairly simple but good product there must be something more. An idea or distribution. After all, it's a note-taking service. For me, it was the idea that overseas, a bearded Russian guy, Stepan Pachikov, a tech guy, took it, built it, and made some crazy money from it. I used it, recommended it to friends, participated in his hackathons, and even won prizes there.

Of all of Evernote's features, only three were the most valuable in my opinion. But it was precisely these that kept me as a user until 2022 — the year I abandoned SaaS services from large companies. More than ten years of subscription...

So, what were these anchor features:

1. Search through documents, images, and photos

   An incredibly useful thing. It's clear that with proper tag and folder organization, you can find any, even the oldest, note or document just by navigating through some system. But if you add very accurate search to the system, the process becomes much more pleasant. I had many medical documents that were very easy to find by keywords present in the image or scan. And I didn't have to manually perform preliminary indexing and organization just for the sake of organization. Just adding one tag — and the OCR search did its job. Yes, at that time the search was indeed just OCR. But we'll come back to this.

2. Alarm on notes

   I had several successful use cases: the alarms would go off a couple of times a year and helped me not miss the right moment, bringing back the context of what I needed to do. Now I use email for this.

3. Skitch (screenshot annotator)

   In my profession, I need to communicate with other people, showing certain elements of a product and leaving comments on them. Similar services existed and still exist. The Linux alternative still can't draw normal arrows.

Recently, while browsing through screenshots on my PC in search of one specific image, I thought how cool it would be to have search like in Evernote. And yes, I know that there are and have been many similar solutions. Not only commercial products but also open-source ones — just search on GitHub. But all of them, as always, are "not the same," "the old one was better." Although, of course, it wasn't actually better; the search in Evernote worked on the OCR principle. Obviously, since the company still exists, I dare assume that it has been improved to hybrid search. That is, a combination of OCR (search by text recognized from an image) and semantic search, i.e., search by embeddings obtained from the image using some model. We'll be talking about small models that can be run on ordinary user hardware and have a very limited focus on what they do.

What Do I Want from Image Search?

If an image shows a cat or a metal grate, I would like to be able to write that query and get similar images. I would really like to search for images by color palette. You might ask why, but it's incredibly convenient. In my use cases, when I remember the design of a service clearly, searching for "profile form" might not help, but "purple color + profile form" will find the result. I want to search using not only English text but also Russian in queries. So that I can write "metal grate" or "металлический люк" and get similar results. Of course, the search should also account for text on the image if there's a lot of it, as well as the meaning of that text. For example, I took a screenshot of a YouTube recipe for pizza dough, which was written with a marker on a board. The text in the image contains the words water, flour, and salt. Ideally, I would want to find it by the query "pizza recipe" or just "recipe." Also, the search should be fast. Okay, I'm willing to wait for long indexing and preliminary analysis of the image database, but the search itself should be near-instantaneous. So, is it possible to do this using modern models without using external services and APIs?

Step 1. Semantic Search.

Or search by image embeddings and the embedding obtained from the user's text query. To solve this, we need a multimodal embedding model, preferably with an MIT/Apache license. And there is one: Nomic Embed Vision. Like any trendy transformer-based model with a BERT architecture. The beauty of this model for our engineering task is that text and images as input produce vectors from the same space. We can search for text by image, image by image, or image by text. A downside is that Russian language queries don't work optimally, but we'll fix that too, later.

Let's figure out how I'm going to test the quality of the models adopted in the search pipeline. I'll do it using a qualitative method — whether I like it or not — on my local folder with screenshots. There are about 500 of them in total. The global goal is to feed my entire knowledge base, notes, screenshots, and references, but for now, we'll limit ourselves to searching through screenshots. I had a list of images that I wanted to find in my screenshot folder. And the search should find them. No complex benchmarks or methodology, I just need to enjoy the search. So, we take Rust, take the ONNX Nomic Vision models, and see what happens.

The very first result worked perfectly. Of course, it was a coincidence, but a fortunate one. I had a screenshot from a YouTube video on how to weld a manhole cover in a parking lot so that the management company could bury a pump there. Finding this image was instantaneous, having only Semantic search with a single model at hand. The embeddings themselves can be stored in any database with vector support and search capabilities. SQLite has a plugin, and there's also LanceDB. They are ideal because they don't have excessive complexity in support and interaction. Remember, SQLite is installed on practically every smartphone in the world and is an absolutely bulletproof database.

The only problem was with queries in Russian. I tackled this head-on and selected a small model for translating between Russian and English. https://huggingface.co/Teradata/opus-mt_tiny_rus-eng Queries started working significantly better. Of course, we lose some quality with each such step. If the model were already multilingual, it would be better, but we're taking the simple path. Training a similar model would require not only a stack of 16+ H100/H200 GPUs but also extensive work with datasets, which is unacceptable for my task. However, with modest effort (by lengthening the model pipeline), the target result improved significantly, and it became possible to search for a metallic object using the word "метал" (metal) as well as "metal."

Step 2. Search by Colors.

This is my long-standing dream of how I would like to search through my library of image references. And colors fit perfectly into a vector form. To implement this search, we need to do two things. First, extract dominant colors or a kind of palette from the image. Second, encode this color palette as a vector. Then we can simply search for similar vectors, exactly as I did before with embeddings from the Nomic Vision model. To extract the palette, you can use different algorithms, but as I like to approach such tasks, I start with the simplest solutions that can yield a significantly good result in ML. There's k-means clustering, and that's what I used. There are several good libraries for Rust; I used https://crates.io/crates/kmeans_colors. For each image, k-means extracts 5 dominant colors in the Lab color space, concatenates them into a single flat vector, and indexes them in LanceDB. When a user searches simultaneously by text and color, the system first performs a semantic search (vector or hybrid), and then re-ranks the results based on a combined score. In this score, semantic relevance is primary, and color proximity is a refining factor.

Let's test the color search.

Bam! It works, of course, in combination with semantic search. For example, I want to search for login UX screenshots. And I remember that the site I'm looking for is orange or red.

Works like a charm. Exactly what I wanted. In the my next youtube video, I'll talk about what else can be added to this pipeline to make it even better. Let me remind you that the search already works absolutely magically, and we haven't even done OCR yet — we haven't recognized the text on the images and added it to so-called hybrid search.

More than 20 years have passed since work on Evernote began. If at the beginning of this SaaS journey, image search technology was indeed a formidable weapon against competitors, over time the technology has become very cheap to develop and implement. Yes, of course, Tesseract OCR became open-source decades ago too. But it's like heaven and earth compared to what we can now run locally on a user's machine and with what level of quality.

We are supposedly supposed to be entering an era of thousands and thousands of new applications and services that can solve old problems much more simply, quickly, and better. LLMs seem to have solved the software problem and left only the problem of the idea. But where are these thousands of new startups?

P.S.

You can try the result by downloading the application via the link. The application is currently only available for macOS, Linux and Windows. Battle tested only on Linux yet.. I am continuing to work on it right now and don't yet see what will become of it. For now, a working idea has emerged: to create my own Skitch. But with entirely local models for search and image processing. If you're interested, you can subscribe at https://zatsepin.dev/subscribe or on YouTube at https://www.youtube.com/@yurizatsepin

Imagine this: your Claude Code or Cursor AI agent deletes a file or starts rewriting it from scratch. The file contents haven't been saved in a git commit yet—it's still in an unstaged state. Everything is gone. All you can do is hope the AI agent can reconstruct something from memory and checkpoints, but these are workarounds at best—and you might miss the moment.

When I switched from pure Git to JJ on top of Git, this scenario became impossible. I became much more confident about my code while working with AI agents. Let me show you why JJ will improve your life as a programmer and how to integrate it into your workflow without breaking your team's existing processes.

Why Git Doesn't Handle Parallel Development

Git is fundamentally outdated for systems where code is being written in parallel with you on your machine.

Git's paradigm is simple: you collect some changes locally, put them in a box, label that box with a hash identifier, and send it through a pipeline of boxes. That box seems immutable to you—you'd rather not touch it again, except maybe to read what was done in it. If something happened before you assembled the box, you just write it again. Usually you haven't gone far, and what could go wrong anyway?

In gaming terms, git commits are like manual saves you make by hand. But you don't have autosave.

The Underlying Tension

For years, this concept worked brilliantly. Though we must admit, Git's interface for all its possibilities has always been quite complex. The ongoing struggle with how commit history looks across different companies suggests something might not be optimal in this system.

JJ (Jujutsu) is designed to solve Git's usability problems while maintaining full compatibility with existing repositories and workflows.

JJ is a version control system that sits on top of Git, providing a much more intuitive interface and powerful features for managing your code history—especially when working with AI agents.

Let me show you three core concepts that make JJ powerful:

• JJ log operations: undo and redo
• Working copy as a commit
• Advanced operations: squash, split, edit

Part 1: JJ Operations with Undo/Redo

Let's set up your first JJ project:

mkdir jj-step-0 && cd jj-step-0 && jj git init
touch README.md
echo "first try" >> README.md
jj diff

If you run the command jj log, you'll see that you already have a Change ID and Commit ID. On the left is the Change ID, on the right is the Commit ID.

Change ID is a permanent identifier of the logical task you're working on. Unlike a Git hash (which in jj is called Commit ID), Change ID doesn't change when you edit files, change descriptions, etc. Change ID never changes—even if you do amend, rebase, or edit a commit message. The main commands jj edit, jj describe are performed on the selected Change ID.

Change ID is a random 16-byte number, represented as a string of 12 characters from z-k. This makes it look unique and easy to read.

In jj, the working directory is always a "live" commit. Any change to files immediately becomes part of the current revision. The working copy is marked with the @ symbol in the output of jj log. The commit hash will change with each edit you make in the project. That's why it's not so important during work.

jj commit -m "First"
jj

Our first commit is created. And at this point there are no changes in the new working directory, so it's time to start writing a feature with the help of an AI agent.

echo "Cool staff" >> README.md
touch new-file.md && echo "One more thing" >> new-file.md
jj diff

Something terrible happens: your AI agent decides to rewrite new-file.md from scratch and deletes the original content, replacing it with something strange.

Let's simulate what the AI did:

rm new-file.md
touch new-file.md
echo "Bad staff" >> new-file.md

What now? We're not going to beg the AI to restore our work. Instead, let's see what JJ has saved:

jj evolog --color=always -p

Good! JJ maintains a history of all changes in the working commit (there's no unstaged here), as well as a history of all operations you've performed. Each modification, deletion, or addition is a separate operation with its own hash. Now let's undo what the AI did:

jj undo
jj diff

Done. And our "Cool staff" is back in place. If we realize the AI was right, we can go back with:

jj redo

Important: undo and redo operate on operations, not file changes. If you made a commit and realized you need to add something else, just use jj undo.

Key JJ Commands for Operations

Part 2: Managing Commits and History

Now let's explore how JJ simplifies managing commit history and messages. Let's start a new project:

cd .. && mkdir jj-step-1 && cd jj-step-1 && jj git init

Let's work on three features in the project:

touch file.md
echo "Feat 1" >> file.md
echo "Feature 2" >> file.md
jj commit -m "Feat 1 & 2"

touch file2.md
echo "Feature 3" >> file2.md
jj commit -m "Feat 3"

Wait, you realize you should be writing "Feature" everywhere, not "Feat" in your code. The new company rules require it—did you miss that? We need to go back and fix the first commit. With JJ this will be incredibly simple.

jj edit r

Notice we're using just the first letter r instead of the full Change ID value. JJ uses "minimally sufficient" commit references—just enough characters to uniquely identify a revision without collisions in your current project context. As your project grows, more characters will be needed.

Now we're "inside" the first commit. We can modify file.md as needed and change the commit message with:

jj describe

Splitting Commits

Since we're here, let's split the first commit into two separate commits—one for each feature. Well, you shouldn't do different tasks in one commit. This is incredibly simple with:

jj split

Press 'F' to unfold all changes, select "Feature 1" and confirm with 'c'. Set your commit message to "Feature 1", save, and set another message for the second commit. You should now have a clean history.

Return to our latest commit with the third feature:

jj edit u

And start working on a fourth feature:

jj new -m "WIP 4 feat"
touch README.md && echo "Blazing fast project" >> README.md

JJ has a concept where you don't need to use the commit command explicitly. You can start work by preserving the old commit with a description, and begin work on something new with a description like "WIP 4 feat". Later, at any moment, you can rename the commit description and start a new one. This concept explicitly tells you what work you've started and what you're currently doing.

Wait—README.md should probably be part of the first commit. That's not right! But there's no problem, just squash your current work into the first commit and continue:

jj squash --to r

Edit the commit message and you're done!

Conclusion

We've practiced with JJ and studied its powerful and user-friendly interface for Git. The beauty is that you can use it without changing your team's processes—JJ works on top of regular Git.

You can maintain cleaner history and worry much less about AI accidentally damaging your local work. The confidence this brings is invaluable in our anxious world.

Of course, I can't promise a seamless transition. Mastering tools like JJ takes a long time, and you might hit moments where pure Git seems easier. Honestly, I accepted JJ only on my second attempt at using it. Like trying olives for the first time, it might not appeal to you immediately—but if you keep going, everything will work out just fine.

I haven't covered everything JJ can do, but I hope this was helpful and that you'll feel inspired to try it and make your work even better.

Subscribe

Subscribe to my channel at https://zatsepin.dev/subscribe for access to my exclusive content, project source code, and much more.

References

• https://docs.jj-vcs.dev/
• https://jj-for-everyone.github.io/
• https://steveklabnik.github.io/jujutsu-tutorial