Feature: Desktop notification to document owner when a note is added

[Camel9527]

Problem

When a reviewer adds a note to selected text in a shared workspace, the note is persisted to SQLite and broadcast to connected clients over WebSocket — but only those who currently have the page open see it. If the document owner is away from the browser, they have no way to learn that a note was added. There is no asynchronous notification channel today.

Proposed behavior

When someone adds, edits, or deletes a note in a shared workspace, the document owner receives a native desktop notification (macOS Notification Center / Windows toast / Linux desktop notification).

• The owner is the user running the Markon desktop app — no email address or identity config needed.
• The notification includes: workspace name, file name, a short excerpt of the note, and the change type (added / edited / deleted).
• Clicking the notification opens the corresponding file and locates the note.
• Rapid successive notes are coalesced / debounced, not one notification per note.

Scope

• Applies to the Tauri desktop app (crates/gui), where a desktop session exists to display notifications.
• Applies only to shared mode (--shared-annotation); local-mode notes never reach the server.
• Pure CLI / headless-server runs have no desktop session — silently ignored, no error.

Implementation considerations

• Notification mechanism — Tauri 2 ships an official notification plugin (tauri-plugin-notification) that surfaces native OS notifications. The desktop app already uses Tauri 2 with several plugins; this would be an addition.
• Event path — The note-persistence path already broadcasts over WebSocket. The GUI process needs to receive note added / edited / deleted events (or a dedicated channel from core) and surface a notification.
• Click-through — Locating a specific note from a notification requires notes to have a stable identifier / anchor (related to the stable-identifier need in Support clickable links and permalinks for annotations #36).
• Throttling — A reviewer adding many notes in quick succession should not spawn one notification per note; a debounce / coalesce window is needed.
• Permission — macOS requires notification authorization; first use should prompt for permission, with graceful fallback if denied.
• No identity config — The recipient is implicitly the desktop user, unlike an email-based approach.

Use cases

1. Async review — A reviewer adds notes; the owner is notified via desktop notification without keeping the browser tab focused.
2. Local share — Owner runs Markon on their Mac and shares via LAN/reverse proxy; reviewers add notes remotely and the owner sees native toasts.
3. Team collaboration — Multiple reviewers; the owner gets coalesced notifications rather than one per note.

Open questions

1. Mute control — Should the owner be able to toggle notifications off, or set quiet hours?

Acceptance criteria

• Adding, editing, or deleting a note in shared mode, with the desktop app running, each triggers a native OS notification.
• Notification shows workspace, file name, note excerpt, and change type.
• Rapid successive notes are coalesced / debounced, not one per note.
• Clicking the notification opens the corresponding file and locates the note.
• Notification permission denial does not break note saving or the app.
• Pure CLI / headless runs (no desktop session) are silently ignored — no crash, no error.
• Docs cover the shared-mode-only and desktop-app-only limitations.

Environment

• Markon desktop app (Tauri 2), latest (main)

[kookyleo]

Thanks for the proposal. For now Markon’s shared mode is scoped to small-team collaboration, where teams usually already have an IM/Slack-style channel for notification and discussion. We do not want Markon itself to grow a parallel notification layer at this stage, especially because desktop notification behavior would need permissions, ownership rules, batching, mute controls, and deep-link handling across environments.\n\nSo this is out of scope for the current product direction.