The architecture of Obsidian Tasks Sync is structured to achieve the following goals:

• Decoupling between Obsidian and external task platforms
• Two-way synchronization with minimal data loss
• User-isolated authentication
• Extensibility to future providers (Microsoft To Do, Todoist, Notion)

Obsidian (Markdown Vault)
     │
     ▼
Plugin Core (main.ts)
     │
     ├── Views (UI components and setting tab)
     ├── Models (task format, remote interface, storage)
     ├── Repositories (file-based task persistence)
     ├── Remote Integrations (per platform)
     └── Libs (regex / utility functions)

• Entry point of the plugin
• Registers commands and setting tab
• Initializes remote platform integration and UI bindings

• UI components shown in the Obsidian interface

  • SettingTab.ts: plugin configuration screen
  • SyncFromRemoteButton.ts: dynamic sync button renderer

• Task.ts: shared task structure
• PersistStorage.ts: key-value configuration storage
• remote/: remote interface and platform implementations

export interface Remote {
  id: string;
  settingTab: RemoteSettingPanel;
  get(id: string): Promise<Task>;
  update(id: string, from: Task): Promise<void>;
  create(title: string, due?: string, args?: Record<string, string>): Promise<Task>;
  authorize(): Promise<void>;
  unauthorize(): Promise<void>;
  checkIsAuthorized(): Promise<boolean>;

  init(): Promise<void>;
  dispose?(): void;
}

• FileRepository.ts: task storage handler using Obsidian files
• Acts as a local state layer before/after syncing with remote

• Each provider (e.g., gtask, todoist) implements the Remote interface
• Also includes a platform-specific RemoteSettingPanel

• regexp.ts: common regular expressions used for parsing markdown tasks

• Local tasks contain a suffix like (gtask:abc123) for ID tracking
• Remote tasks may embed backlink or task hash in description or notes
• Sync direction is both ways; conflict resolution based on timestamps
• Sync operations are designed to be idempotent

To add a new task platform:

1. Create a folder under src/models/remote/{platform}
2. Implement the Remote interface
3. Implement a RemoteSettingPanel
4. Update main.ts to use your Remote

• All platform logic isolated under remote/
• UI and sync logic remain unaware of specific providers
• Fully mockable for testing and future platform additions

• No subtask nesting support from Google Tasks API
• Sync relies on predictable markdown syntax
• OAuth credentials must be manually configured by users

• Background sync scheduler
• Centralized sync status dashboard
• Unified task data abstraction layer
• Capability-aware remote dispatching (e.g. reminder support)