OrgNote in 2026: Summary and Current Progress

First of all, I would like to thank everyone who supports me - not only through Patreon subscriptions, but especially through your warm words.

I wish you all a happy New Year. You are amazing, and I wish you success in your learning, as well as peaceful skies above in the coming year 🙏🏻

• New address for the development website: https://dev.org-note.com
• Local platform-agnostic file system
• Better approach to storing files via an S3-like API on the server side
• OrgNote now supports any type of file, including Markdown

While all file types are supported for reading, indexing and rich editor currently works only for Org files

• New buffer concept (highly emacs inspired) for content rendering.
• Panes and tabs support, including mobile support
• First successful run on a real iOS device via Xcode
• Async queue and cron tasks for the extensions API
• Configuration migration to TOML format
• Improved error handling with more verbose error messages
• Org editor was significantly improved
• Real-time synchronization via WebSockets
• Some new built-in extensions
• Over 1500 unit tests for the client side

At the moment, a few hundred users are using the main prototype version of the app. I decided to keep it online for now while focusing on the development version: https://dev.org-note.com

I wouldn’t recommend using it seriously right now due to frequent restarts and possible data loss, but you’re welcome to play around with it.

In the early prototype of OrgNote, I used a simple in-memory storage for notes. It worked fine, but there were no real files on disk. This confused a lot of people and caused issues with syncing and backups. It also meant that OrgNote could not be used without a backend service.

The new file system approach is fully agnostic. You can easily switch between different file systems or add a new one via an extension. The idea is straightforward: you just need to implement the file system interface.

export interface FileSystem {
  readFile: <
    T extends 'utf8' | 'binary' = 'utf8',
    R = T extends 'utf8' ? string : Uint8Array,
  >(
    path: string,
    encoding?: T
  ) => Promise<R>;
  writeFile: (
    path: string,
    content: string | Uint8Array,
    encoding?: BufferEncoding
  ) => Promise<void>;
  readDir: (path: string) => Promise<DiskFile[]>;
  fileInfo: (path: string) => Promise<DiskFile | undefined>;
  rename: (path: string, newPath: string) => Promise<void>;
  deleteFile: (path: string) => Promise<void>;
  rmdir: (path: string) => Promise<void>;
  mkdir: (path: string) => Promise<void>;
  isDirExist: (path: string) => Promise<boolean>;
  isFileExist: (path: string) => Promise<boolean>;
  utimeSync: (
    path: string,
    atime?: string | number | Date,
    mtime?: string | number | Date
  ) => Promise<void>;
  init?: (params?: FileSystemParams) => Promise<FileSystemParams | void>;
  mount?: (params?: FileSystemParams) => Promise<boolean>;
  pickFolder?: () => Promise<string>;
  prettifyPath?: (path: string) => string;
  wipe?: () => Promise<void>;
  watch?: (
    listener: (change: FileSystemChange) => void,
    params?: FileSystemParams
  ) => WatcherHandle | Promise<WatcherHandle>;
  copyFile?: (src: string, dest: string) => Promise<void>;
}

With this approach, I can now implement the Android SAF file system. As a result future versions of the app can be published on Google Play with native file system support on modern Android devices. For example, it becomes possible to use tools like Syncthing for syncing files.

In the previous version, MongoDB was used as the main storage for notes. This made it possible to implement server-side search and publishing.

With the new approach, data is stored in any S3-like storage without inspecting its content.

Right now, the development version does not include a publishing mechanism. In the future, I’m considering using static site generators for publishing notes, but I haven’t fully decided which approach makes the most sense yet.

Thanks to the agnostic file system approach, we can store any file type without inspecting its content. Right now, the only limitation is file size.

The previous version worked well with a single open file. This was sufficient for simple tasks, but it became limiting when working with multiple contexts at the same time.

The new approach is based on buffers. This concept will be familiar to anyone who has used Emacs. You can open multiple buffers for the same file, split windows, and work with different files simultaneously.

I also added support for tabs and windows. This approach is inspired by how the Obsidian note-taking app works.

Tabs for mobile devices were inspired by Safari web browser:

One of the biggest issues in the prototype was syncing a large number of files.

I have decided to use two different approaches to solve this problem.

The first one is a persistent queue, which can process tasks sequentially or in configurable batches.

The second approach is based on cron jobs, which can run background tasks in a way similar to a traditional cron manager. Both of these approaches are available via the OrgNote public API and can be used in extensions.

I also added a simple queue manager to the UI for developers:

The previous revision of the app used a JSON-based configuration. This approach is still available (marked as deprecated), but over time I found that TOML is one of the best formats for configuration. It is more readable and much easier to extend.

The orgnote.el package has also been migrated to TOML-based configuration files.

I'm still not completely sure how to best monitor user-side errors. I want to avoid proprietary solutions like Sentry, since they may lead to data leakage. At the same time, I still need meaningful stack traces to debug issues effectively.

To address this, I added a new global error handler that should make debugging runtime errors much easier. Let's see if it helps.

I wasn’t focusing heavily on this goal, but during the process I ended up implementing several interesting features and improvements related to Org file editing:

• The ID property is no longer required
• Support for placeholders for common keywords
• Better folding logic
• Performance improvements in multiline widgets
• A better image widget with zoom support

This functionality is not very stable yet, but there are already early signs that seamless data synchronization between Emacs and the OrgNote app is possible.

I got a lot of feedback about the right panel, so I decided to introduce a dedicated sidebar for additional context. It is also exposed through the OrgNote API and can be reused by extensions.

Some built-in extensions already use this sidebar, such as headline navigation:

Another example is a simple tool for debugging the Org mode AST in real time:

• First successful run on a physical iOS device 🎉
• Over 1,500 client-side unit tests to improve overall stability

This year I plan to:

• Integrate an agenda and a habit tracker
• Integrate a calendar
• Publish the development version to production
• Publish the iOS app to the TestFlight
• Add search within current document

Extensions:

• Graph view
• Backlinks

I also hope to find some time to integrate AI providers and MCP servers for working with notes, but for now it looks like a very non-trivial task.