Skip to content

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.

Preferences, then Notifications, then Push notifications. It is per browser, not per account, so a laptop and a phone are two separate subscriptions.

  • A secure context. https:// or localhost. 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.

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.

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.