Live reload for external file changes

[nextlevelshit]

When editing notes with an external editor (like Vim) while having the web interface open for navigation or graph visualization, it would be useful if the browser automatically reflected changes made on disk.

Use case:

• Edit a note in Vim
• Web interface updates without manual refresh
• Especially helpful when using the graph view to see new links appear

Possible approaches:

• File system watching with WebSocket push to connected clients
• Optional flag like --watch or --live-reload
• Polling fallback for systems without inotify

I understand this adds complexity—just wanted to see if others have similar workflows or if there are workarounds I missing.

[alonswartz]

This is a good suggestion, with one important clarification first: a browser refresh alone won't help if the backend is serving cached note / graph state. The backend needs an explicit way to re-read from disk and invalidate caches.

I think this is best approached in layers:

1. Explicit cache invalidation (core)

A backend trigger to re-read notes from disk and rebuild derived state (links / graph).

This could take the form of a simple API endpoint (e.g. /api/reload), and possibly a signal-based trigger (e.g. SIGUSR1) for scripting and integrations.

Once this exists, users can wire up their own workflows - external file watchers, Vim autocmds, or git/rsync hooks for remote setups to trigger a reload, without Notesium doing any watching itself.

2. Automated invalidation (+ notification)

Backend watches the notes directory (fs events + polling fallback) and triggers the same reload path as (1).

This is also where a WebSocket could make sense: the backend can notify connected clients that out-of-band changes occurred.

3. Live reload (UX enhancement)

Clients can react to those notifications by refreshing affected views (graph view benefits most).

A WebSocket channel could also replace the current --stop-on-idle heartbeat implementation which relies on periodic pings.

---

I've hesitated so far mainly due to complexity vs reach (cross-platform FS watching, debouncing noisy saves, long-lived connections), but breaking it down this way makes it possible to add value incrementally. Layers 2 and 3 need a little more thought, but implementing layer 1 should be fairly easy and provide immediate utility.

[alonswartz]

Web daemon: explicit reload / cache invalidation #111