2 Commits

Include renames

Author	SHA1	Message	Date
Lotus CIandClaude Opus 5.5	005fc9e768	fix(notifications): notification replies re-check encryption at send time and use the right account (#299) ... 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	2026-10-17 20:52:12 -04:00
jaredandClaude Opus 5	d4420905e6	feat(notifications): inline reply from a browser notification (#203) ... Message notifications shown through the service worker now carry a text-input 'Reply' action (Chrome desktop/Android). On notificationclick with action==='reply' the SW sends the typed text itself — it already holds the newest session's access token for authenticated media — as m.room.message (threaded when the notification was for a thread), 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). The sender lives in swReply.ts so it is unit-tested; verified headless that the SW notification carries actions + {roomId, threadId}. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA	2026-09-19 14:12:23 -04:00