Follow-up from the #1778 web-push review.
The notifications table has no user_id column and notifications.add() broadcasts to targets=["broadcast"], so the feed (and now the web-push fan-out added in #1778) is global by design: every notification, including external-agent access requests, is delivered to every subscribed device across all users.
This is consistent with the existing global-notification model and does not cross a new auth boundary (any authenticated user can already read every notification via the feed and SSE). It is therefore acceptable for the current single-operator install and not a blocker on #1778.
Before multi-user GA (a first-class taOS goal), notifications should be scoped per user:
- add a user_id (or target-set) column to the notifications table
- have
add() take a target user / audience
- push only to that user's subscriptions (
list_for_user instead of list_all)
- keep broadcast as an explicit opt-in for genuinely system-wide notices
Tracking so the push delivery surface is tightened alongside the rest of the multi-user separation work.
Follow-up from the #1778 web-push review.
The notifications table has no user_id column and
notifications.add()broadcasts totargets=["broadcast"], so the feed (and now the web-push fan-out added in #1778) is global by design: every notification, including external-agent access requests, is delivered to every subscribed device across all users.This is consistent with the existing global-notification model and does not cross a new auth boundary (any authenticated user can already read every notification via the feed and SSE). It is therefore acceptable for the current single-operator install and not a blocker on #1778.
Before multi-user GA (a first-class taOS goal), notifications should be scoped per user:
add()take a target user / audiencelist_for_userinstead oflist_all)Tracking so the push delivery surface is tightened alongside the rest of the multi-user separation work.