Push notifications
In-app notifications only fire while a tab is open, which misses the case that matters. Web push covers it: the browser wakes a service worker even with Slick closed.
There is nothing to configure and no third party to sign up with. A VAPID keypair is generated on first boot and stored in the database, and delivery is handled by whichever push service the browser already uses, Google’s for Chrome, Mozilla’s for Firefox, Apple’s for Safari. Those services relay ciphertext: the payload is encrypted to keys the browser generated, so only that browser can read it.
Turning it on
Section titled “Turning it on”Preferences, then Notifications, then Push notifications. It is per browser, not per account, so a laptop and a phone are two separate subscriptions.
Requirements
Section titled “Requirements”- A secure context.
https://orlocalhost. One more reason to read Deploying with TLS. - iOS needs the app installed. Safari on iPhone allows push only from a home screen app. Share, then Add to Home Screen, then enable it in Preferences. The web manifest that makes this work ships with the app.
What gets sent
Section titled “What gets sent”A push goes only to people with no connection open, so an open tab and a phone never both fire for the same message. Beyond that it follows the same rules as in-app notifications: every message in a direct message, and any message that mentions you by name, filtered by your Mentions and Direct messages preferences.
Encrypted channels push Sent a message in an encrypted channel rather than
content. The server has no key and does not guess.
Managing keys
Section titled “Managing keys”Leave VAPID_PUBLIC_KEY and VAPID_PRIVATE_KEY unset unless you have a reason
not to. If you do set them, understand that changing the public key
invalidates every existing subscription, because browsers bind to it. People
will have to turn push on again, and nothing will tell them to.