Quick reply from a browser notification (P5-20, remaining half): inline reply via Notification Actions through the SW #203

New Issue

2026-09-17T23:25:32-04:00

jared commented

2026-09-17 23:25:32 -04:00

Migrated from LOTUS_TODO.md on 2026-09-17 (the file is now reference-only).

[~] P5-20 · Quick Reply from Browser Notification (partial)

Done: notifications show the real body, click navigates to the specific event + focuses the tab. Remaining: inline reply via Notification Actions API needs the SW push+notificationclick pipeline (switch new Notification() → serviceWorkerRegistration.showNotification() so the SW receives notificationclick; on event.action==='reply' POST m.room.message with the stored {roomId, threadId}). Ties into N107.

_Migrated from `LOTUS_TODO.md` on 2026-09-17 (the file is now reference-only)._ ### [~] P5-20 · Quick Reply from Browser Notification (partial) Done: notifications show the real body, click navigates to the specific event + focuses the tab. **Remaining:** inline reply via Notification Actions API needs the SW `push`+`notificationclick` pipeline (switch `new Notification()` → `serviceWorkerRegistration.showNotification()` so the SW receives `notificationclick`; on `event.action==='reply'` POST `m.room.message` with the stored `{roomId, threadId}`). Ties into N107.

jared added this to the Features 2026-Q4 milestone 2026-09-17 23:25:32 -04:00

jared added the enhancement priority: low area: notifications labels 2026-09-17 23:25:32 -04:00

jared commented

2026-09-19 14:12:59 -04:00

Done in d4420905:

Message notifications shown via the service worker now carry a text-input Reply action (actions: [{action:'reply', type:'text'}] — Chrome desktop and Android; other browsers just ignore it) and data: {path, roomId, threadId}.
sw.ts notificationclick: on event.action === 'reply' the SW sends event.reply itself as m.room.message (with the m.thread relation when the notification was for a thread) using the newest session it already holds for authenticated media — so it works with the tab in the background or closed. A failed send shows a "Reply not sent" notification that opens the room.
Not offered for encrypted rooms: the SW cannot encrypt, and a plaintext reply into an E2EE room would be wrong. Those notifications keep the plain click-to-open.
The sender is swReply.ts, unit-tested (content shape, thread relation, URL, bearer header, failure paths); verified headless that the SW notification carries the action + data.

Web Push (#202) is the other half — this reply path will work unchanged once a push handler shows the same notification shape.

Done in `d4420905`: - Message notifications shown via the service worker now carry a text-input **Reply** action (`actions: [{action:'reply', type:'text'}]` — Chrome desktop and Android; other browsers just ignore it) and `data: {path, roomId, threadId}`. - `sw.ts` `notificationclick`: on `event.action === 'reply'` the SW sends `event.reply` itself as `m.room.message` (with the `m.thread` relation when the notification was for a thread) using the newest session it already holds for authenticated media — so it works with the tab in the background or closed. A failed send shows a "Reply not sent" notification that opens the room. - Not offered for **encrypted** rooms: the SW cannot encrypt, and a plaintext reply into an E2EE room would be wrong. Those notifications keep the plain click-to-open. - The sender is `swReply.ts`, unit-tested (content shape, thread relation, URL, bearer header, failure paths); verified headless that the SW notification carries the action + data. Web Push (#202) is the other half — this reply path will work unchanged once a `push` handler shows the same notification shape.

jared closed this issue

2026-09-19 14:12:59 -04:00

jared referenced this issue from a commit

2026-09-19 14:13:01 -04:00

feat(notifications): inline reply from a browser notification (#203)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: LotusGuild/cinny#203