Notifications

Notifications are the channel through which a space can speak up without being looked at. CTXR treats that channel with restraint: it exists for moments that are genuinely worth interrupting someone for — you’ve arrived somewhere, something you follow has news — and for nothing else.

The permission

Same shared model as every capability (Reach overview): requested on your gesture, asked natively by the browser, granted to the device. The combined dialog can set notifications and location in one go, which is the common case — most notification use here is location-aware. Revoke it at any time and the result is simply silence; nothing else changes.

Pull, not push

This is where the privacy stance shows. Permission for notifications may be granted, but no unsolicited data crosses between spaces or accounts. The model is pull, not push: you check the sources you follow, the system tells you “there are updates,” and actually fetching them requires your interaction. The platform never quietly streams a space’s content onto your device. It’s the same gate the deep-link-behind-a-login-wall already uses — GDPR-clean by construction, because consent and a user action sit in front of every retrieval.

Local first, push later

The mechanism arrives in two steps, and the distinction matters for what’s possible:

  • Local notifications (shipped). The page itself decides to notify, using the browser’s own Notification machinery — no server keys, no third-party service, no data leaving the device. This is what powers Proximity today. Because the page is the sender, local notifications work while the app is open in the foreground.
  • Web Push (v2, in development). Real server-sent push using VAPID and aes128gcm, built on the standard library alone — no external packages, consistent with file-based and dependency-free. Push changes how a message is delivered (it can reach a closed app), not the promise that nothing reaches you without your say-so.

What a notification looks like

A notification names its subject, states the essential fact (a place and its distance, say), and offers a direct action — open the page, get directions. Notifications about the same subject replace each other rather than stack: you’ll never find a pile of duplicates about one place in your notification tray.

Where the operating system draws the line

The browser shows notifications, but the operating system owns the tray, the sound, the banners — and several rules that no website can change:

  • iOS requires installation. On iPhone and iPad, web notifications only work once the site is added to the home screen as an app. In the browser tab alone, the capability simply isn’t offered.
  • Focus modes and notification settings win. Do Not Disturb, per-app notification toggles, banner styles — all decided at OS level, all able to silence or restyle what the site sends. A “missing” notification is often sitting quietly in the notification centre.
  • Buttons are a bonus. Action buttons on a notification (open, directions) appear on platforms that support them; on iOS the notification itself is the button — tapping it opens the page. The essential action always survives, the decoration may not.
  • Foreground vs closed. Until Web Push v2 lands, the app must be open for notifications to fire — see the foreground boundary under Geolocation. Push removes that limit for content messages; what it cannot do, even then, is track your position in the background. The two boundaries are different on purpose.