Browser notifications

Open Notifications → Browser Notifications to register this browser for the selected account-wide or environment scope. Device registration and notification preferences are separate: select Push for the categories you want in Notification Delivery Preferences. Current source access, quiet hours, snoozes and suppression still apply. Test notifications remain intercepted.

Account-wide devices can receive account notices and Live environment notices you currently have permission to read. Registering one grants no organization access. Environment devices cover only that selected environment and reset generation. Test notifications remain intercepted in either case. A working installation needs an enrolled Push provider, application server key and sender, HTTPS, browser support and your browser permission. The presence of device metadata does not prove delivery.

Register a device

Load the current configuration and choose an authorization duration, up to 30 days. Prepare Browser Subscription requests browser permission only after you click it. Review the provider, public application server key, scope, reset generation for an environment, and deadline, then explicitly confirm registration. Each scope supports up to eight active, unexpired devices: eight account-wide devices and eight for the selected environment/reset. Delivery merges those sets and removes duplicate endpoints, for at most sixteen destinations. Account opt-in takes precedence when the same endpoint appears in both sets. A frozen delivery never adds another device or falls back to another registration after reservation.

The browser keeps its native subscription keys. Katara receives the endpoint and subscription encryption material only during registration and encrypts them for sending. Device lists, operation receipts and audit metadata omit endpoints and authentication secrets. Push messages contain a fixed wake-up marker; the browser shows a generic Katara notification and opens the Notifications page. Message bodies and account or resource identifiers are not included in that payload.

An endpoint remains assigned to the first account that registered it, even after revocation. The same account can opt in account-wide and separately across environments. After expiry or an environment reset, registering the same endpoint retires the stale registration for that environment. A different account must create a new browser subscription. Remove Local Browser Subscription explicitly unsubscribes the local endpoint; it does not revoke server records. Resolve unknown registration outcomes first, and revoke known records separately.

Inspect an uncertain result

Registration and revocation use an exact operation UUID. The portal saves only scope, identifiers, versions, timestamps, the operation key and a request digest in tab storage. It never saves the endpoint or browser authentication material. After a lost reply, use Inspect Saved Operation before retrying. Registration recovery requires explicitly preparing the same browser subscription again and matching the saved digest. A different request cannot reuse that key.

A completed receipt describes the original mutation. It does not establish that the device is currently active, unexpired or authorized after a reset. Reload the current device list and review an exact revision before revocation. No recovery flow retries automatically.

SDK and delivery behavior

TypeScript exposes client.notificationPush; Python exposes client.notification_push. Environment methods are configuration, register, list, get, revoke and operation. TypeScript adds registerAccount, listAccount, getAccount, revokeAccount and accountOperation; Python uses their snake-case forms. Account requests require scope: "account" and cannot select another user or supply organization or reset pins. Registration takes subscription material separately from the public metadata request. Keep the exact request and operation UUID until its result is known. Human-session authentication is required.

Delivery freezes the eligible device set and records each device attempt before transport. Up to eight sends run concurrently under the exact current delivery lease. Accepted or uncertain attempts are not dispatched again. A device that definitely never reached transport can be recorded as denied; if recording the outcome itself cannot be confirmed, the reserved attempt remains uncertain. An uncertain device outcome takes precedence over accepted outcomes when reporting aggregate delivery. Provider acceptance is not proof that a browser displayed a message.

The sender uses Web Push encryption and VAPID authentication. Only explicitly enrolled HTTPS destinations are permitted; redirects and private-network DNS answers are refused. Operators must preserve the independent endpoint ownership index key. Unsupported replacement is refused, and encryption-key rotation needs an explicit retained-key migration strategy.

Local protocol and database checks cover encryption, destination restrictions, current authority, both subscription scopes, sixteen-device bounded dispatch and one-attempt outcomes. Installed browser compatibility, provider enrollment and external delivery acceptance remain separate checks.

Operator configuration

The API and notification worker read the same reviewed enrollment through KATARA_NOTIFICATIONS_PUSH_ENROLLMENT_FILE. The file must be an absolute path to a regular file owned by the process user with mode 0600. Symlinks, pipes, unknown fields and files over 32 KiB are refused. An absent setting disables this adapter; an invalid configured file prevents startup. No keys or provider enrollments are created by loading it.

The version 1 JSON envelope contains schema_version, key_id, encryption_key, endpoint_index_key, vapid_private_key, contact and providers. The three private keys are canonical padded base64 encoding of 32 bytes; the VAPID value is a valid P-256 private scalar. contact is a reviewed HTTPS contact URL. Each provider declares an id, exact HTTPS origin and path_prefix. Keep this file out of client bundles, logs and source control. The public configuration returns only provider metadata and the derived public application key. The worker pool must allow at least nine connections.