🗳️ Wishlist

[hesprs]

📢 This issue is the meta feature request for Sync Engine, it aggregates all triaged and waiting feature requests. Please do not comment in this issue, to propose a feature request, open a new issue as normal, maintainers will move your request here after some communication and triage.

Each comment in this issue stands for a feature request, if you agree with a feature request, react with Thumbs Up 👍 on the corresponding comment. Features with the most thumbs up will be implemented with higher priority. Already implemented feature comments will be removed.

Since most feature requests can be achieved via modules, we highly recommend you to implement the module by yourself and contribute to this repository. See how to develop a module for more detail.

To discuss a feature request, please open a thread in Discussions.

---

🗳 Feature requests that you can vote for:

• Preserve file creation and modification time
• Conflict resolve & diff preview UI
• Setup wizard
• Support for Google Drive backend
• Native Koofr backend
• Zero-cost realtime collaboration

[hesprs]

Preserve File Creation and Modification Time

• Request: [Feature Request]: Sync creation and modification date #159
• Issued at June 26, 2026
• Achievable by a module
• Implementation blueprint:

Register a remote filesystem wrapper and vault request middleware. The filesystem wrapper prepends the creation and modification time to the filename and strip off the timestamps and save to an in-memory Map returned from deeper filesystem stack. Upon deletion or stat, it relies on this map to fire requests toward the correct prefixed filename. Upon write, it also checks for existing old file and fire deletion toward that file.

The vault request middleware shares the same in-memory Map. Upon each file write, it looks on the creation and modification time in the map, and injects the ctime and mtime header into the request. Then the file is written with original creation and modification time.

[hesprs]

Conflict Resolve & Diff Preview UI

• Request: [Feature Request]: 删除文件确认+差异对比 #145
• Issued at May 29, 2026
• Module enhancement
• Implementation blueprint:

This will be an enhancement on existing Smart Merge module. The module needs to register an additional conflict resolution strategy "Manual UI resolve". When that option is selected, the three-way merge should stop at line-level instead of recurse into words. It there are conflicts, it opens a UI modal rendering a Git-like diff, and the user can manually decide which part wins for each conflict.

[hesprs]

Setup Wizard

• Request: [Feature Request]: Setup Wizard #206
• Issued at August 8, 2026
• Core enhancement
• Implementation blueprint:

Open a large modal when the user firstly enables the plugin, showing paginated and interactive guides that work through the following:

1. Language
2. Sync Engine's modular philosophy
3. Backend and their configurations (which needs the plugin to expose setup wizard registration to modules)
4. Additional modules (Encryption, Smart Merge, ...)
5. Documentation and donation
6. Start the first sync (or skip)

[hesprs]

Support Google Drive Backend

• Issued at August 9, 2026
• Achievable by a module
• Implementation blueprint:

The filesystem in Google Drive is standard hierarchical, check connection is simple, and Google Drive API v3 doesn't support batching so there's nothing to optimize around. The hardest part is authorization. Since we need mobile compatibility, and Obsidian mobile runs on Capacitor + pure WebView, a plugin cannot monitor a browser tab or use Google's SDK. The most practical option is using Google's Device authorization flow, which doesn't require the user to manually paste the auth token (like Remotely Save) nor need a third party server (like Google Drive Sync) to work.

[hesprs]

Native Koofr Backend

• Issued at August 12, 2026
• Achievable by a module
• Implementation blueprint:

Koofr's WebDAV implementation suffers from bugs from time to time, unreliable for long-turn usage. Adapting Koofr's REST API v2 could unlock better performance for users using Koofr's service and reduce the occurrence of bugs due to Koofr's WebDAV server.

Koofr's API is simple and authorization is password-based. The filesystem is standard hierarchical. There's no batching support so nothing to optimize. So the implementation would be straightforward.

[hesprs]

Zero-Cost Realtime Collaboration

• Issued at August 12, 2026
• Achievable by a module
• Implementation blueprint:

Sync Engine's radical optimization makes realtime collaboration possible. Provided clients already share the same remote backend, the only one missing is an event bus between clients to notify file changes.

The MQTT protocol will be used, where many clients need to subscribe to the same topic, and each one of them can publish messages to notify all other clients, while receivers trigger syncs to pull the changes. The content forwarded by the broker are the complete remote stat + their exclusion / inclusion rules + sending time only, file contents never goes through this channel. Each client synthesizes the stats with their cache according to the exclusion / inclusion rules, then push the stats into the executeSync() routine and syncs with remote.

All messages will be symmetrically encrypted at client side. Clients should share the secret securely outside of the broker. All undecryptable or sending time mismatch messages will be ignored.

Since there are many public free MQTT brokers, so the cost of realtime collaboration is effectively 0.