🗳️ 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
• Native Koofr backend
• Zero-cost realtime collaboration
• Support Dropbox backend
• Support Chinese cloud service backends (百度网盘, 阿里云盘)
• QR code settings export

---

🏆 Already implemented feature requests:

• Support Google Drive backend on August 23, 2026 by @Quzzar and @hesprs

[hesprs]

Preserve File Creation and Modification Time

• Request: [Feature Request]: Sync creation and modification date #159
• Issued on 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 on 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. If 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 on 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 on 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

• Request: [Feature Request]: Google Drive Near-Real-Time Bidirectional Synchronization #290
• Issued on 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.

To resolve the race condition that one client's concurrent upload overrides another clients'. The most elegant solution is not trying to prevent it, but heal it after it happens. It works like:

1. Client A records a tiny in-memory CRDT of files edited.
2. Client A uploads a file.
3. Client B uploads the file concurrently, overriding A's file, race happens.
4. Client B notifies collaborators via MQTT.
5. Client A receives the MQTT and downloads the file.
6. [Critical] Client A analyzes the file, and sees exactly recent edits get reverted, and sees mtime of the file is close. It replays the lost edits on the file and re-uploads.
7. Race condition is healed.

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.

[hesprs]

Support Dropbox Backend

• Issued on August 23, 2026
• Achievable by a module
• Implementation blueprint:

Dropbox allows custom URI redirection in PKCE authorization, and Obsidian has public API allowing custom URL handling. So PKCE implementation is feasible on both mobile and desktop.

Dropbox's filesystem is standard hierarchical, but supports various batching. The implementation should batch deletions and movements to supercharge sync speed.

[hesprs]

Support Chinese Cloud Service Backends (百度网盘, 阿里云盘)

• Issued on August 24, 2026
• Achievable by modules
• Implementation blueprint:

Baidu Netdisk (百度网盘) is the easiest one to implement. It supports Device Code authorization (same as Google Drive) which eliminates the need of third-party server for auth. One special point is that its refresh token is one-time and access token needs to be refreshed per 30 days. Despite that, it automatically scopes Sync Engine access to its App folder. Baidu Netdisk supports batching of file movement and deletion.

Aliyun Drive (阿里云盘) has forbidden personal Cloud OAuth registration. This forces Sync Engine to use a third-party server with poor user experience, a publicly trusted one is OpenList public token server. It also scopes Sync Engine to isolated App folder. In terms of batching, it supports the same comprehensive batching operations as Aliyun PDS.

Quark Drive (夸克网盘) does not provide any documentation on its API. Community relied on reverse engineered APIs that have very poor UX. Sync Engine does not plan to support it.

---

React Thumbs Up 👍 to vote for Baidu Netdisk, Popper 🎉 to vote for Aliyun Drive.
请使用 点赞 👍 为 百度网盘 投票，使用 拉花彩炮 🎉 为 阿里云盘 投票。