[LordMelkor]

Problem

Notification controls are four category switches (mentions, direct messages, thread replies and agent completions) plus channel Mute. There's no way to be notified when a particular person posts. An ordinary post in a channel you're in never alerts.

Change

• People on your list. Choose Notify me when they post on someone's profile. Their posts in channels you're in then alert, as the new person category. Stop notifying removes them.
• Settings → Notifications → People on your list shows everyone you added, with Remove and Clear list. A People on your list switch under Notify me about turns these alerts off without clearing the list.
• Same rules as other alerts. Nothing while you're viewing the conversation, nothing once it's read, nothing from a muted channel, and nothing from a thread you opted out of. Only otherwise-uncategorized posts become person:
  • A listed person who also mentions you or DMs you alerts once, as a mention or DM.
  • A reply in one of your conversations stays thread, including while its conversation lookup is pending.
  • Replies outside your conversations don't alert.
• Storage. The list is saved on this device, per account, in the existing notification preferences, up to 200 people. It's read again at delivery, so removing someone cancels an alert that's still waiting.
• Plugins. The notificationPeople service's methods reject calls made through any plugin's context except the bundled Profiles plugin's (buzz.profiles), the same check review-access.ts uses for plugin management. The typed ctx.notifications contract has no people methods. This isn't isolation. Plugins are trusted, unsandboxed code (docs/plugin-architecture.md), so a plugin that digs into host objects, rewrites its own context or keeps another plugin's rendered panel can still reach the list, as it can every other notification preference.
• Documented in docs/notifications.md and docs/buzz-help.md.

No FOUNDATION file is changed.

Intent

Original request: kray's #buzz-feedback post (Nov 2): "Would be great to be able to customize notifications: eg. channel activity vs mentions, posts by certain people". This PR is the "posts by certain people" half. A per-channel "all activity" mode is a separate PR.

Must change: a "people" list. A post by a listed person in a channel I'm in notifies me (category person, one rule in notifications/messages.ts, toggle on the profile card, list in Settings). A post that also mentions me alerts once.
Out of scope: per-channel "all activity" mode (separate PR), keyword alerts, schedules, digests.
Acceptance: with a person on the list, their post in a joined channel notifies; others' posts don't (beyond existing rules).

Validation

• messages.people.test.ts:
  • A listed person's top-level post alerts, and an unlisted person's doesn't.
  • A mention from a listed person alerts once, as a mention.
  • The category switch silences person alerts.
  • A muted channel stays quiet.
  • A reply in a thread you opted out of stays quiet, even while you're viewing it.
  • A pending reply is classified as thread.
  • Removing a person cancels a waiting alert.
• Preferences, Settings and profile tests:
  • The list round-trips, is capped and restores as empty from older saved values.
  • The Settings list removes and clears, and gives unnamed people with similar keys distinct labels.
  • The profile toggle adds and removes, and another plugin is refused the list.
• The regressions fail without their fixes. Focused tests (notifications and unread) 449/449 at round 1. tsc --noEmit and biome check pass. Full suite at 9f169d66, on main b1e1cd82: 19,408 passed and 5 failed, in 3 files this diff doesn't touch (App.profile, IdentitySettings, MessageReactions). Run alone, those 3 files pass 89/89, so the failures are timeouts on a heavily loaded shared machine. After rebasing onto main 41e64bf0 and the round-2 fixes, TypeScript passes and the notifications, profiles, unread and settings tests pass 522/523. The one failure is a 5 s timeout in unread-startup.test.ts, which passes 52/52 when run alone.
• Review rounds (each finding checked against the frozen intent above):

  • Round 1 (sq agents review): three P2s, all fixed.

    • A person alert could override a thread opt-out while viewing.
    • A pending reply's classification changed.
    • The list wasn't re-read at delivery.

  • Round 2 (sq agents review): one P2, fixed. Any plugin could call the people-list service. Its methods now reject calls from every plugin except Profiles, and the profile toggle's test checks that another plugin is refused.

  • Round 2 pressure test (Sigil): found that a plugin can still reach the list at runtime through ctx.root, the untyped ctx.notifications object, a context it rewrote with ctx.extend(), or the Profiles panel's rendered props from ctx.panels. That is the trusted-plugin model the whole plugin API has, not a gap in this change, so the docs and this body now say exactly what the check covers and that it isn't isolation. Making plugins untrusted is out of this card's scope.

  • Round 3 (sq agents review): two P2s, both fixed.

    • A removed person's alert waited on channel preferences before the list was checked, so re-adding them revived it.
    • After a failed save, clicking the toggle again reversed the choice. It now offers Retry saving.

    A third finding repeated the plugin-trust route, which is handled above.

  • Round 4 (sq agents review): one P2, fixed. With 200 people listed, adding one reported a failed save, and Retry saving cleared the error without adding anyone. The card now says the list is full and offers no retry.

  • Round 5 (sq agents review): one P2, fixed. In Settings, two unnamed people whose npubs end alike got the same label and Remove button name. The list now uses publicKeyLabels, which lengthens colliding abbreviations.

  • Final sq agents review at d56eca58, on main 41e64bf0: no findings.

  • Rebase review (sq agents review) at 03a10cb5, after squashing and rebasing onto main b1436b09: three P2s, all fixed in 09209d36. Each has a test that fails without its fix. Production change: about +26/−10.

    • A listed person's post that the relay signs on their behalf (an actor or leading p tag) didn't alert. Matching now uses the author Buzz displays, from the existing messageAuthor resolver. The same tag from any other signer stays untrusted.
    • A broadcast reply in a thread you opted out of still sent a person alert. Opted-out threads no longer count for person alerts. Broadcast unread counting is unchanged.
    • Two listed people with the same resolved name had identical rows and Remove buttons. Those rows now show their key, and their Remove labels name it.

    Not changed: an alert for a relay-signed post names the signer, as every other alert category does on main.
    Full suite at 09209d36: 20,475 passed and 25 failed, in 6 files this PR doesn't touch (App.profile, ProfileSettings, solo-worker, DraftPreview, MessageReactions, relay/startup). Run alone, those 6 files pass 206/206, so the failures are timeouts under machine load.

  • Pressure test: an independent agent (Sigil) found no blocker at the round-1 head. Later it confirmed both round-3 fixes: each regression fails on the parent, and reversing only the retry handler fails at the saved-choice assertion. It also confirmed that the trust-model wording matches its four access probes, and found nothing else. 338 tests, TypeScript and Biome pass at b1ceb869 (now c9e29980 after the rebase). At the final head (0c6cec09) it confirmed the full-list message, that freeing a slot lets a 200th entry save, and that removal works at capacity. 339 tests in 29 files, TypeScript and Biome pass. Round 1 also checked that pending lookups keep thread precedence, that removing a person cancels their waiting alert, and that an opted-out thread stays quiet even with Notify while viewing on. 268 tests in 23 files and TypeScript pass. Native notification delivery wasn't exercised.

• Design, matching existing behavior:
  • The list is saved on this device, like the other notification preferences.
  • Replies outside your own conversations don't alert, because Buzz doesn't count them as unread.

Try it (AGENTS.md step 3, for a human)

1. Open a teammate's profile and choose Notify me when they post.
2. Have them post in a channel you're in, while you're looking at a different channel. Expected: a notification " posted in #channel".
3. Have someone not on your list post there. Expected: no notification.
4. Mute the channel and have the teammate post again. Expected: no notification.
5. Go to Settings → Notifications → People on your list. Expected: the teammate is listed. Click Remove, and their next post doesn't notify.

🤖 Generated with Claude Code

[morgmart]

🤖 Design review: this isn't critical path for the Nov 10 launch. Please hold it until after launch, or build it as an external plugin that isn't bundled into the app. Questions: #buzz-design-review.