Feature: first-class persistent presence so amq who active reflects real availability

[ohade]

One gap I keep hitting: amq who's active is derived from recent AMQ CLI activity (last_seen freshness) in a root. Without a persistent watcher, presence goes stale between an agent's turns, so active doesn't actually tell me whether a peer will consume a message soon. Running monitor in a pane helps, but it doesn't survive the pane closing, the machine sleeping, or a reboot.

What I'd want is a supported persistent presence and drain daemon that survives pane close, sleep, and reboot, plus an amq who that distinguishes "watcher-backed live" from "last activity, may be stale". Right now I end up writing my own keepalive wrapper around it, which means the liveness signal means something different depending on the setup.

Curious whether this fits how you see presence working. I can share the stopgap keepalive I built if it's useful as a reference.

[avivsinai]

Thanks — this splits into two asks, and they get different answers.

A supported persistent presence/drain daemon: no. AMQ is deliberately file-based with no daemon, database, or server, and process supervision that survives pane close, sleep, and reboot is exactly what launchd/systemd (or your orchestrator) are for. Owning a daemon would also blur what presence means — today it's a passive artifact any reader can interpret. What we can do is ship a documented recipe for running amq wake/amq monitor under a supervisor — if you're up for sharing your keepalive wrapper, it'd be a useful reference for that doc.

The amq who ambiguity: valid, and fixable without a daemon. Today active only means "last_seen was refreshed in the last 10 minutes". But AMQ already has a stronger passive artifact: a valid wake lock, which is process-identity-verified (same machinery doctor --ops uses). who/doctor --ops could distinguish a presence source — e.g. notifier_live (verified live amq wake holding the lock) vs recent_activity. One precision worth being honest about: a live wake proves your peer will be notified promptly, not that messages get consumed — wake injects notifications; monitor is what drains. Consume-backed liveness would need a monitor heartbeat, which we're not adding now.

Tracking the who/doctor distinction + supervisor recipe as follow-ups.

[avivsinai]

Resolved within the daemon-free boundary agreed above. Issue #206 was closed by PR #230 (a8d9b8fd5a9cace05252fe5882e2a092cb0d15f8): who and doctor --ops now distinguish verified notifier_live from recent_activity, and the documentation includes launchd/systemd supervision recipes for wake and monitor. A live notifier proves prompt notification, not message consumption; AMQ still owns no daemon.