Building SlashNote: An Offline-First Markdown Notebook
Why I’m building SlashNote around local-first data, native Rust capabilities, Git-based synchronization, and fast local search instead of treating the network as the center of the application.
Building SlashNote: An Offline-First Markdown Notebook
Most note-taking applications start from the assumption that the network is always available. I wanted to build something around the opposite assumption. SlashNote is an offline-first Markdown notebook designed for Desktop and Android. The idea is simple: your notes should remain useful when there is no connection, your data should remain understandable outside the application, and synchronization should not be the thing your entire workflow depends on.
Start With the Data
The most important decision was to make Markdown the center of the system. A note should not become useless because a particular application disappears. Markdown is plain text, readable by humans, supported by countless tools, and easy to move between systems. That makes the filesystem and the Markdown files much more important than the UI itself.
The interface becomes a way of working with the data rather than the place where the data is trapped.
Offline First
Offline-first is more than adding a loading state when the network disappears. The application should be useful without a network connection in the first place. Creating a note, editing it, searching through notes, and navigating the local collection should not require a round trip to a server.
This changes the architecture. Instead of thinking:
UI → API → Database → UI
the application can operate primarily around local state and local files, with synchronization treated as a separate concern.
That makes the application feel much more immediate and also gives the user more control over their own data.
Why a Native Core?
SlashNote uses a native Rust core for functionality that benefits from being closer to the operating system and filesystem. Rust gives the project a strong foundation for working with files, local processing, and native capabilities while keeping the core relatively small and predictable.
The goal isn't to use Rust simply because it is technically interesting. The goal is to put the right responsibilities in the right layer.
The interface should handle interaction and presentation. The native layer should handle operations where filesystem access, performance, and platform integration matter more.
Git as Synchronization
Another interesting part of SlashNote is synchronization. Instead of designing a completely separate synchronization protocol around another backend, SlashNote uses Git through libgit2.
This creates an interesting relationship between notes and version control. A change to a note isn't just another database mutation. It can exist as part of a history.
That means Git can provide concepts that are already useful for developers:
- commits
- history
- branches
- synchronization
- conflict handling
For a Markdown-based application, this is particularly useful because the underlying data is already represented as files. The synchronization layer doesn't need to invent an entirely new representation for the notes.
Search Should Stay Local Too
Having thousands of notes is only useful if you can find something quickly. SlashNote uses Tantivy for local search. Instead of sending every search query to a remote service, the application can maintain a local search index and perform searches directly on the device.
This fits the same architectural principle: keep the core workflow local whenever possible.
The result is not only about performance. It also means that searching through your own notes doesn't inherently require sending your queries or note contents to a remote server.
Desktop and Android
Supporting both Desktop and Android introduces another architectural challenge. The interface and platform capabilities are not identical, but the underlying ideas should remain consistent.
The project therefore separates the application experience from the native capabilities underneath it. That separation makes it possible to think about SlashNote as one product rather than two completely unrelated applications.
What I'm Learning From SlashNote
The biggest lesson from this project isn't a particular framework or library. It's that architecture becomes much clearer when the application's fundamental constraints are decided first.
For SlashNote, those constraints are straightforward:
- Notes should remain useful offline.
- Markdown should remain portable.
- Local data should be first-class.
- Synchronization should not define the entire application.
- Search should be fast and local.
- Native capabilities should live in an appropriate layer.
Once those decisions were made, the technology choices started making more sense.
SlashNote is still a work in progress, but that's also what makes the project interesting to me. I'm not just building another notes UI. I'm exploring what a modern note-taking application looks like when local ownership, plain-text data, native capabilities, and version-controlled synchronization are treated as first-class architectural concerns.