coffey-labs/ihasmail
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Notifications that arrive when ihasmail is closed

Browse Source 
ihasmail's notifications came from EventSource, which lives exactly as
long as a tab does -- so "desktop notifications" has always quietly
meant "while you are looking". That switch is now labelled as much, and
a second one does the thing people assumed the first one did.

Stalwart 0.16 signs Web Push with VAPID (RFC 9749) and can put the
message itself in the payload (draft-ietf-jmap-emailpush). The server
pushes straight to the browser's own push service: ihasmail's server is
not in the delivery path, there is no relay to run, and nothing beyond
the browser vendor's endpoint that Web Push requires of everyone.

Checked against the live 0.16.19 before any of this was written, because
an advertised capability is not a configured one:

  - the session publishes a real applicationServerKey, so no key
    generation or server configuration is needed
  - PushSubscription/get answers an ordinary user rather than refusing
  - emailpush is advertised, and its draft defines a filter, an ordered
    properties list and an urgency -- so the payload can carry sender and
    subject, and the server drops properties from the end when it will
    not fit rather than failing the notification

Three things this gets right that are easy to get wrong:

  - The verification handshake. A JMAP subscription delivers nothing
    until the client echoes back a code the server pushed, and the
    service worker cannot answer it -- no credentials in that context.
    It forwards the code to a tab, or leaves it in the cache when no tab
    was open to forward it to.

  - Key encoding. The W3C Push API produces unpadded base64url and
    Stalwart 0.16 was fixed to accept exactly that, so nothing here pads
    on the way out. The VAPID key needs padding on the way *in* for
    atob; getting that backwards fails at subscribe() with an opaque
    error, so it lives in one named function with tests.

  - Sign-out. A subscription belongs to the account, not the session.
    Without tearing it down, a shared machine keeps notifying for a
    mailbox nobody is signed into -- which is somebody else's mail.

The mock models the JMAP half, including refusing padded keys and
non-https endpoints, and creating subscriptions *unverified*. Delivery
cannot be mocked -- it runs through the browser vendor's real push
service -- but a mock that marked a subscription verified on creation
would let a client ship without the handshake, and the symptom in
production is "registered, and silent".

Not verified end to end: an actual notification arriving. That needs a
real browser, a real push service and real delivery, so it is live
testing or nothing.
This commit is contained in:
jcoffey-dev
2026-08-26 13:51:09 -07:00
parent e2f17f6f49
commit 96bc7b53d7
9 changed files with 648 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
web/src/views/settings/NotificationsSettings.tsx
+46 -1
View File
@@ -3,12 +3,21 @@ import { useSettings } from "@/store/settings";
import { Switch } from "@/ui/misc";
import { requestNotificationPermission, showNotification, playNewMailSound } from "@/lib/notify";
import { useSession } from "@/store/session";
import { disableWebPush, enableWebPush, webPushActive } from "@/lib/webpushEnable";
import { supportsEmailPush, webPushAvailable } from "@/lib/webpush";
import { toast } from "@/ui/toast";
export function NotificationsSettings() {
const s = useSettings((st) => st.settings);
const update = useSettings((st) => st.update);
const pushConnected = useSession((st) => st.pushConnected);
const [perm, setPerm] = useState<NotificationPermission | "unsupported">("Notification" in window ? Notification.permission : "unsupported");
const [background, setBackground] = useState(false);
const [busy, setBusy] = useState(false);
const canBackground = webPushAvailable();
useEffect(() => {
void webPushActive().then(setBackground);
}, []);
useEffect(() => {
if ("Notification" in window) setPerm(Notification.permission);
}, [s.desktopNotifications]);
@@ -26,10 +35,46 @@ export function NotificationsSettings() {
}
update({ desktopNotifications: v });
}}
label="Desktop notifications for new mail"
label="Desktop notifications while ihasmail is open"
hint={perm === "denied" ? "Notifications are blocked in your browser settings." : perm === "unsupported" ? "Not supported in this browser." : "Shows a system notification when new mail arrives in your Inbox while the tab is in the background."}
disabled={perm === "denied" || perm === "unsupported"}
/>
{/*
The distinction worth drawing for the user: the switch above needs a tab
open, this one does not. Everything before this shipped only the first
kind, while calling it "desktop notifications".
*/}
<Switch
checked={background}
disabled={!canBackground || busy || perm === "denied"}
onChange={async (v) => {
setBusy(true);
try {
if (v) {
const p = await requestNotificationPermission();
setPerm(p);
if (p !== "granted") return;
const res = await enableWebPush();
if (!res.ok) { toast.error(res.reason); return; }
setBackground(true);
toast.success("Background notifications are on");
} else {
await disableWebPush();
setBackground(false);
}
} finally {
setBusy(false);
}
}}
label="Notify me even when ihasmail is closed"
hint={
!canBackground
? "Needs a browser with the Push API and a mail server that publishes a push key."
: supportsEmailPush()
? "Your mail server delivers these directly to your browser, so they arrive with no tab open. The sender and subject travel in the notification."
: "Your mail server can wake this browser, but will not include the sender or subject."
}
/>
<Switch checked={s.notificationSound} onChange={(v) => update({ notificationSound: v })} label="Play a sound for new mail" />
<div className="row mt-16">
<button className="btn" onClick={() => { showNotification("ihasmail test", { body: "This is what a new-mail notification looks like." }); playNewMailSound(); }}>Test notification</button>