Notifications

On your phone instead of an inbox

Requests rarely sit unanswered out of unwillingness, usually nobody looked. Nexview can say the moment something is waiting: on your phone, within seconds, with the poster attached and a link straight to the approval list.

For each person

Web push to your own phone

Since 0.31.0, alerts on your own device no longer need an operator. Under Profile → Notifications → Web Push, everybody allows notifications in their own browser, and from then on that device gets what concerns them, even while Nexview is closed: the title is ready, the request is decided, a child wishes for something.

What arrives is decided by the same switches as for e-mail, for the account and therefore the same on every device. Every device then appears in a list with its last delivery, and a test message tells you right away whether anything really arrives.

Messages are encrypted end to end and signed with a key your installation generates once. They travel through the browser's push service, that is Google, Mozilla or Apple, which only sees that something arrives, not what. Web push needs https. On an iPhone, Nexview has to sit on the Home Screen first, and the page says on every device what is still missing.

Seven ways

From ntfy to Apprise

An administrator sets the services up once. They are shared inboxes for the whole installation, deliberately separate from the bell and the personal e-mail address everybody configures in their own profile.

ntfy and Gotify you can run yourself, Telegram goes through a bot of your own, and Discord needs nothing but a channel's webhook address, messages arrive there as a coloured card with the poster on it. Anyone who wants none of it takes e-mail, or nothing at all, and the bell remains.

On top of that come two connections for everything else: a plain webhook and Apprise. Both are further down. And whatever is still missing belongs on the suggestion list, that is how the existing channels came about.

Screenshot: the settings showing tabs for ntfy, Gotify, Telegram and e-mail, with one tile per inbox — **One tile per inbox**, plus a “+” tile for the next. The power switch takes a target out of service temporarily without deleting it.

Two levels

Connection on top, inboxes underneath

Services with two levels get both: an ntfy server carries any number of topics, a Telegram bot any number of chats. The connection is stored once, address, token, and the inboxes underneath each pick what they want to hear about.

Per inbox you set language, one channel in German, a second in English, urgency from quiet to high, and the events.

Six are on offer: request waiting for approval, finished downloading, decided (approved or rejected), cancelled, new ticket and feedback on a title.

So one channel can report only approvals while a second hears about everything that finishes, without anybody setting up two bots. A family channel can carry only finished downloads while the operator's channel also sees tickets.

Screenshot: the Telegram tab with the bot instance and the option to add another — **Telegram sets itself up.** A built-in guide covers the way from **@BotFather** to the first message; the token check fills in the bot's username, and “fetch chats from the bot” lists everyone who has written to it, no third-party ID bot, nothing to copy by hand.

The universal connection

Webhook: to anything that listens

Instead of a particular service, Nexview sends every message as a POST with fixed JSON to an address of your choosing. Optionally with an Authorization header, should the far end want one.

It is meant for anything you can wire up yourself: Home Assistant, n8n, Node-RED, or a script of your own that is three lines long and does exactly one thing.

The shape of the message stays the same whichever event triggers it, so whoever reads it does not have to build something different for every case.

Over a hundred services

Apprise, and with it almost everything

Apprise is a project of its own that passes messages on to over a hundred services: Signal, Matrix, SMS, Pushover, Slack and many more. Run an Apprise API yourself and Nexview hooks onto it with an address and a configuration key.

The point is what Nexview does not learn: the credentials of the target services stay inside the Apprise server. Nexview knows only the address and the key, not your Signal account and not your Slack token.

This is the channel comparable tools do not have. Anybody wanting their messages through Signal or Matrix has to wait elsewhere until somebody builds that particular service in.

The proof

A four-digit code decides

An HTTP 200 from a push service only means accepted, never arrived. A misspelled topic, an app with no subscription, a muted notification, all are answered politely, and you would notice only weeks later, when the first real message fails to show up.

So the test message carries a four-digit code, and only somebody who can type it back gets to save. Setting up ntfy or Telegram therefore creates connection and first inbox in one confirmed step.

E-mail targets skip the code on purpose: behind a shared mailbox or an automation there may be nobody to read it.

Reliability

What happens when it jams

Underneath the channels sits an outbox with a beat of its own: every ten seconds, instead of the two minutes the rest of the sync runs on. Three attempts per message; after that the last error stays visible on the tile rather than being swallowed.

And one message per event and inbox is sent, not per recipient. A request three administrators are watching announces itself once, not three times.

The personal routes are untouched by all this: the in-app bell, your own e-mail address and web push are configured by each person in their profile, per event. The channels described here are what the installation reports, not what an individual receives.