Mobile: compose, render, and notify for @channel/@here channel mentions

[LordMelkor]

🤖 Filed by kray's AI agent on his behalf.

Problem

#3197 adds @channel and @here channel-wide mentions (NIP-CM, ["notify","channel"|"here"] marker tag) with relay, CLI, SDK, and desktop support. Mobile is the missing surface — mirroring how #2792 tracked mobile support for user groups (#2728).

Today on mobile:

• A received @channel/@here renders as plain text — no mention chip, no visual signal that the message notified the channel.
• @channel events do reach mobile users' Home mention feed (the feed is relay-side, one row per event), so mobile already benefits passively — but the message body doesn't explain why it's in the feed.
• The composer has no way to send a channel mention: no autocomplete rows for the reserved tokens, no notify tag attached on send.
• Notification handling: mobile's should_notify_for_event ladder needs the same two NIP-CM rules the desktop ladder got — @channel/@here escalate to mention-tier for channel members, and channel mutes suppress them (direct p-tag mentions keep piercing mutes). @here is observation-time live-only (own presence online AND within the 120s freshness window; no retroactive badge).

Scope

1. Render: chip @channel/@here when the event carries the corresponding notify tag (reserved tokens resolve ahead of display names, per NIP-CM).
2. Notify ladder: extend mobile/lib/features/channels/unread_badge/should_notify_for_event.dart with the NIP-CM escalation + mute-suppression rules (see desktop/src/features/notifications/lib/channelNotifyEscalation.ts and lib/feed.ts for the reference semantics, including the direct-mention-pierces-mute precedence).
3. Compose: autocomplete rows + confirmation prompt, mirroring desktop ("Notify everyone in this channel" / online-only copy for @here), attaching the ["notify", mode] tag on send.
4. Keep event kinds in sync: mobile/lib/shared/relay/nostr_models.dart mirrors desktop/src/shared/constants/kinds.ts.

Render + notify ladder (1+2) are the user-facing gap and can land before compose (3) — receiving correctly matters more than sending, and CLI/desktop already cover authoring.

References

• Spec: docs/nips/NIP-CM.md (in-repo)
• Desktop implementation: feat: @channel and @here channel-wide mentions (NIP-CM) #3197
• Prior art for the mobile-follow-up pattern: Mobile: user groups — mention compose, group management, and pill rendering #2792 (mobile user groups)

[hetsaraiya]

Hi @LordMelkor , I’m planning to pick this up. I’ll implement tag-backed rendering and the mute-aware notification ladder first, followed by non-DM autocomplete, confirmation, and sending for [at]channel and [at]here. The implementation will remain human-only and apply the 120-second online check for [at]here.
One detail I want to confirm is late-join catch-up. Mobile does not currently have a reliable per-member join timestamp, so I propose using the bounded mentions feed as the authority for historical [at]channel escalation and limiting raw marker escalation to live delivery.

[LordMelkor]

Thanks @hetsaraiya — the plan and the ordering both look right. Render + the notify ladder before compose is exactly the split I'd want, since receiving correctly matters more than sending and the CLI/desktop already cover authoring.

One heads-up before you start: #3197 hasn't merged yet, so docs/nips/NIP-CM.md and the desktop reference files (channelNotifyEscalation.ts, the mute-precedence bits in feed.ts) only exist on the feat/channel-mentions branch. You'll want to base off that branch to read the spec and the reference semantics. Expect the ladder to be stable but the file layout to possibly shift before it lands.

On late-join catch-up — good news, the concern dissolves. A client is never supposed to compute the join bound. The relay enforces it server-side: mentions-feed branch 2 joins channel_notifications against channel_members with joined_at <= received_at (the relay's admission time, not the client-authored created_at). So mobile having no per-member join timestamp is by design, not a gap. Your instinct to treat the bounded feed as the authority for historical @channel is correct — just don't add any client-side join reasoning on top of it.

Two refinements to "limiting raw marker escalation to live delivery":

1. @channel should have one owning path, not a history/live split. The spec's rule is that @channel notifications are owned by whichever single path mobile already uses for direct-mention notifications, with the other path skipping notify-tagged events. A history/live split means an event that both arrives live and appears in the feed notifies twice. Pick one owner, or dedupe by event id.
2. @here is observation-time live, not live-socket live. The predicate is only: own presence online AND |now − event.created_at| ≤ 120s. Delivery path is irrelevant — a launch or reconnect catch-up fetch that surfaces a 30-second-old @here should escalate exactly like live delivery, because the reader genuinely is here. Nothing persists either way. Gating on "arrived via the live socket" would under-notify.

Also worth flagging since mobile's feed path is client-categorized (activity_provider.dart assigns the mention category itself): the relay files @channel items under mention for every member it resolves — it doesn't know about mutes. So the mute rung has to be applied on the activity/inbox path too, not just the badge ladder. Ladder order is load-bearing: broadcast and direct p-tag mentions pierce a channel mute; @channel/@here sit below the mute and are suppressed by it. And a reader never escalates their own message at any rung.

Minor: don't offer the tokens in DM channels (the relay rejects the tag there), and reserved-token precedence is case-insensitive and beats display names on both the send and render paths.