notify: shared-list activity #95

New issue

Closed

opened 2026-08-16 12:32:13 +00:00 by nalum · 1 comment

nalum commented

2026-08-16 12:32:13 +00:00

Owner

If built: likely a digest, not per-item banners ("5 items added to Shopping today"), or scoped to a list a member explicitly watches. Per-item emission at ItemService/Create with a list_uid would fire constantly during meal-plan pushes (PushIngredients) — that alone rules out the naive version.

Usual kind plumbing if it survives design: proto enum, notify method, en+ga messages, webhook decorator, web push-preference checkbox + PUSH_KINDS entry, Android channel.

Follow-up from the event-notifications audit (PR #90).

Items added to shared lists notify nobody. For a household this is probably noise — flagged in the audit as the weakest candidate — but the ask exists, so it gets its issue and a design gate: define who would ever want the buzz (the person about to go shopping?) before building anything. If built: likely a digest, not per-item banners ("5 items added to Shopping today"), or scoped to a list a member explicitly watches. Per-item emission at `ItemService/Create` with a `list_uid` would fire constantly during meal-plan pushes (`PushIngredients`) — that alone rules out the naive version. Usual kind plumbing if it survives design: proto enum, notify method, en+ga messages, webhook decorator, web push-preference checkbox + PUSH_KINDS entry, Android channel. Follow-up from the event-notifications audit (PR #90).

nalum referenced this issue

2026-08-16 14:27:32 +00:00

plan: open-backlog execution order (2026-08-16) #100

nalum commented

2026-08-16 14:37:56 +00:00

Author

Owner

Design-gate verdict (2026-08-16): closed as won't-do. Flagged weakest in the audit and the household considers it noise. Reopen if a real ask appears (the digest and watched-list shapes in the body remain the starting points).

nalum

2026-08-16 14:37:56 +00:00