Inline notification replies (#203) are posted by the service worker as plainm.room.messages, because a worker can't encrypt. Two gaps:
The Reply action was left out only for rooms that were encrypted when the notification was shown. A reply typed hours later, into a room that has since enabled encryption, went out unencrypted.
The worker posted with Array.from(sessions.values()).pop(), the newest session, not the notification's account.
Change
sendNotificationReply first does GET /rooms/{id}/state/m.room.encryption/. Only a definite 404 lets the plain reply go out. If the state exists the result is encrypted; any other answer counts as failed, so it fails safe.
The page now passes its userId with the session (setSession), and notifications carry data.userId. New pickReplySession uses that account's session only. An old notification without a user id may reply only when exactly one session exists.
"Reply not sent" says why, e.g. "This room is now encrypted, so "…" wasn't sent. Open the app to reply."
Verified
Unit tests: the encryption check order; encrypted, error and send-failure results, where no PUT happens on refusal; session picking; failure texts.
The real helper against the local Synapse: an encrypted room gives encrypted, an unencrypted room gives sent.
I didn't drive a real OS notification reply; headless Chromium has no inline-reply UI.
Fixes #299.
Inline notification replies (#203) are posted by the service worker as **plain** `m.room.message`s, because a worker can't encrypt. Two gaps:
1. The Reply action was left out only for rooms that were encrypted **when the notification was shown**. A reply typed hours later, into a room that has since enabled encryption, went out **unencrypted**.
2. The worker posted with `Array.from(sessions.values()).pop()`, the newest session, not the notification's account.
**Change**
- `sendNotificationReply` first does `GET /rooms/{id}/state/m.room.encryption/`. Only a definite **404** lets the plain reply go out. If the state exists the result is `encrypted`; any other answer counts as `failed`, so it fails safe.
- The page now passes its `userId` with the session (`setSession`), and notifications carry `data.userId`. New `pickReplySession` uses that account's session only. An old notification without a user id may reply only when exactly one session exists.
- "Reply not sent" says why, e.g. "This room is now encrypted, so "…" wasn't sent. Open the app to reply."
**Verified**
- Unit tests: the encryption check order; encrypted, error and send-failure results, where no PUT happens on refusal; session picking; failure texts.
- The real helper against the local Synapse: an encrypted room gives `encrypted`, an unencrypted room gives `sent`.
- I didn't drive a real OS notification reply; headless Chromium has no inline-reply UI.
`tsc` clean · unit tests pass · ESLint clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
The service worker posts inline notification replies in the clear (it
cannot encrypt). The Reply action was only withheld for rooms that were
encrypted when the notification was shown, so a reply typed hours later
into a room that has since turned on encryption went out unencrypted.
It also posted with the newest session the worker knew, not the
notification's account.
The worker now GETs the room's m.room.encryption state first and only
sends on a definite 404; notifications carry the user id and the worker
uses that account's session (or refuses). "Reply not sent" says why.
Fixes#299
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #299.
Inline notification replies (#203) are posted by the service worker as plain
m.room.messages, because a worker can't encrypt. Two gaps:Array.from(sessions.values()).pop(), the newest session, not the notification's account.Change
sendNotificationReplyfirst doesGET /rooms/{id}/state/m.room.encryption/. Only a definite 404 lets the plain reply go out. If the state exists the result isencrypted; any other answer counts asfailed, so it fails safe.userIdwith the session (setSession), and notifications carrydata.userId. NewpickReplySessionuses that account's session only. An old notification without a user id may reply only when exactly one session exists.Verified
encrypted, an unencrypted room givessent.tscclean · unit tests pass · ESLint clean.🤖 Generated with Claude Code
https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5