aw-notify: settingsStore integration and shared webui config surface

[TimeToBuildBob]

Follow-up to #199 (merged) — centralising alert configuration so Android shares the same config surface as aw-notify on desktop.

What's missing from the MVP

The NotifyWorker shipped in #199 hardcodes DEFAULT_ALERTS directly in Kotlin. The only server-side setting it reads is startOfDay. Everything else (categories, thresholds, enabled/disabled) requires a code change.

Goals

1. settingsStore integration — store alert config under /api/0/settings/aw-notify/alerts (or a sub-key of the existing settings namespace). The Android app reads this at worker startup instead of the hardcoded list, matching the server-side config model aw-notify desktop already uses.

2. Shared webui config surface — once the config lives in the settings API, the aw-webui can expose a config panel identical to (or compatible with) the desktop aw-notify settings, so users manage thresholds in one place regardless of client.

3. Reduced default thresholds — the current defaults (All at 1h/2h/4h/6h/8h, Work at 15m/30m/1h/2h/4h, etc.) are too dense for most days. Trim to 2–3 thresholds per category max, or align with whatever the desktop aw-notify defaults converge to after aw-notify: smart anomaly-detection notifications (percentile/sigma above baseline) #200 lands.

4. Migration path — if a user has no server-side config, fall back to a minimal built-in default (not the current verbose list) so first-run behaviour is conservative.

Out of scope here

• Anomaly/percentile-based notifications → tracked in aw-notify: smart anomaly-detection notifications (percentile/sigma above baseline) #200
• App-layer quiet-hours (the OS aw_notify_channel + DnD is sufficient for now)

Cross-references

• feat(notify): add aw-notify support — activity-time threshold alerts #199 — the initial notify implementation (merged)
• aw-notify: smart anomaly-detection notifications (percentile/sigma above baseline) #200 — smart anomaly-detection notifications (v2 direction)
• aw-notify desktop — the Python daemon this should share config with

[ErikBjare]

matching the server-side config model aw-notify desktop already uses

Does it? I thought that needed webui/server-settings too (only has the toml config today iirc).

[TimeToBuildBob]

Seen. Investigating now; I'll reply here with the concrete work, task, or handoff once it's done.

[ErikBjare]

BTW, the current/modern aw-notify I'm referencing is actually https://github.com/ActivityWatch/aw-notify-rs

The old aw-notify Python is no longer used afaik. Perhaps this is why you disregarded considering aw-notify-rs for the implementation? (if you thought I was talking about aw-notify-py, that would certainly be a non-starter then)

[TimeToBuildBob]

You're right — aw-notify-rs uses a local TOML file (~/.config/aw-notify/config.toml), not the server settings API. I mis-stated the goal.

Corrected framing for this issue: rather than "matching existing server-side config", both goals here are about building server-side settings integration where none currently exists:

• Goal 1 (settingsStore): Persist the alert config in the server's /api/0/settings/aw-notify/alerts so that config is stored server-side instead of hardcoded in the Android app, and changes survive app reinstall.
• Goal 2 (shared config surface): Once the config lives server-side, aw-notify-rs on desktop could read from the same store (instead of its local TOML), and aw-webui could expose a shared UI. But that's a larger cross-repo effort (aw-notify-rs + aw-android + aw-webui) and may not be the right direction if you prefer keeping desktop config local.

Before implementing anything, I want to confirm: is building server-side alert config (Goal 1) the direction you want here, or should Android stay local-TOML like aw-notify-rs does? Happy to update the issue scope once you've had a chance to weigh in.

[0xbrayo]

how would settings survive app reinstall in Goal 1? Uninstalling and reinstalling the app would delete the local db. Fan of the shared UI for configs though.

[TimeToBuildBob]

@0xbrayo Good point — and it highlights the key distinction in Goal 1.

In this design, settings would live on the aw-server (the backend the Android app connects to over the network), not in the Android app's local SQLite DB. The server is a separate process running on your desktop or home server, and its data isn't affected by anything that happens to the Android app. Uninstall + reinstall → reconnect to the same server → settings come back automatically.

So the persistence story is: the server is the source of truth, the app is just the client that reads and writes config through /api/0/settings/aw-notify/alerts.

That said, this is all still pending Erik's direction (I asked in my previous comment): should Android use server-side config storage, or should it stay local like aw-notify-rs does on desktop? Happy to dig into the implementation details once we have alignment on the direction.

[0xbrayo]

In this design, settings would live on the aw-server (the backend the Android app connects to over the network), not in the Android app's local SQLite DB.

Doesn't sound right. Is this what you meant @ErikBjare ?

[ErikBjare]

@0xbrayo yeah he's confused

In this design, settings would live on the aw-server (the backend the Android app connects to over the network), not in the Android app's local SQLite DB. The server is a separate process running on your desktop or home server, and its data isn't affected by anything that happens to the Android app. Uninstall + reinstall → reconnect to the same server → settings come back automatically.

@TimeToBuildBob aw-server runs locally on the device. The "Android app's local SQLite DB" is managed by aw-server.

[TimeToBuildBob]

Thanks for the correction — understood. aw-server runs on-device on Android, which means the /api/0/settings/ store is just as local (and as erasable) as any other app storage. My claim that settings would "come back automatically after reinstall" was wrong. @0xbrayo was right to push back.

Revised picture with that in mind:

Goal 1 (settingsStore integration) still has value, just not the persistence story I stated. The actual benefit would be:

• Alert config lives in the settings API instead of hardcoded Kotlin, so thresholds can be changed without rebuilding the app
• Config is readable/writable from the webui (enableing Goal 2)
• Settings persist across app updates and reboots, just not reinstall

Goal 2 (shared webui config surface) is unchanged — once config is in the settings API, aw-webui can expose a config panel for it.

Before proceeding with either: do you still want to pursue server-side (local aw-server) settings storage for alert config, or would you prefer a different approach (e.g. Android SharedPreferences, or deferring until there's a cross-platform sync story)?

[ErikBjare]

@TimeToBuildBob yes, pursue server-side.

[TimeToBuildBob]

Thanks for the correction @ErikBjare — I had the architecture wrong. Understood now:

• aw-server runs locally on the Android device (embedded), not as a remote process
• Its SQLite DB powers /api/0/settings/
• Settings stored there are on-device, same persistence boundary as the app itself

With "yes, pursue server-side" confirmed, the approach becomes:

1. Add an aw-notify settings namespace to the embedded aw-server at /api/0/settings/aw-notify/alerts
2. Update NotifyWorker to fetch alert config from that endpoint at startup, falling back to DEFAULT_ALERTS
3. The webui can then read/write the same settings for a shared config surface

No persistence-gap issue here since both server DB and app data share the same install lifecycle.

The local task is now unblocked and in todo. Will scope the design and start implementation — no PR without explicit approval per the AW hard-stop policy.

[TimeToBuildBob]

Opened #202 — implements the server-side settings integration you approved.

What it does: NotifyWorker now fetches /api/0/settings/aw-notify at startup and uses the returned alert list. If the key is unset or the server is unreachable it falls back to DEFAULT_ALERTS, so existing behaviour is fully preserved.

Schema is a JSON array of {category, label, thresholdMinutes, positive} objects — same shape as the in-code CategoryAlert data class.

Note: reduced the DEFAULT_ALERTS list or aligning it with aw-notify-rs defaults (goal 3 from the issue) would be a follow-up to keep this PR reviewable.