Open notification back-ends

Status: Accepted · Audience: Both · Area: B — Running it

---

Purpose

B5 decides what is worth telling someone and when. This feature decides how the message actually gets there — through open, self-hostable delivery channels rather than a hosted notification service, and, in keeping with the project, it confirms the message was delivered rather than firing it into the dark. An alert that silently fails to send is worse than no alert, because it teaches the operator the stack is quiet when it is actually on fire.

Behaviour

It refuses a hosted notification plane

Delivery MUST go through channels the household can self-host or own. A hosted coordination service that sits between the stack and the operator’s devices is refused as a built-in back-end, for the same reason the rest of the stack avoids proprietary control planes — it may be documented as a manual option, never configured as a default.

It fans out through one open abstraction

Rather than teaching each service a dozen delivery targets, notifications go through a single open fan-out layer that speaks to many back-ends. The operator configures the back-ends once — a self-hosted push service is the ethos default — and every notification source points at the one endpoint.

It confirms delivery, it does not assume it

Configuring a back-end is not complete until a test notification is sent and its arrival observed — for a self-hosted push service whose history is readable, that round-trip is provable end to end. A back-end that cannot demonstrate a delivered-and-observed test message is reported as unproven, not as ready.

It wires the stack’s own events in

The services that emit events — the download and automation apps, the media server — are pointed at the fan-out endpoint as part of setup, so the household’s existing event sources reach the chosen back-ends without per-service fiddling.

The household chooses the channel, the operator owns the policy

Which back-end a person receives on is their choice; what is worth sending stays B5’s policy. Delivery never becomes a second place to re-decide severity.

It respects the privacy stance

What a notification contains is subject to the same privacy posture as everything else: no household watch or request detail leaves to a back-end the operator did not choose.

On the companion

The sentence this feature opens with is about a phone whether or not it says so: an alert that silently fails to send is worse than no alert, because it teaches the operator the stack is quiet when it is actually on fire. A phone is the device the alert was expected on, and the one place where no notification and a notification that never sent are indistinguishable from the inside (N17).

It refuses a hosted notification plane is carried literally rather than loosely. N17-R1 forbids the companion operating, requiring or shipping a notification service, relay or push identity of its own: what delivers a message is the back-end the operator configured, and the app subscribes to it as any other client would. An app that shipped its own push identity would be a hosted notification plane in all but name, arriving through the one surface this feature did not have in view when it refused one.

That has a cost, and N17-R2 makes saying so part of the design rather than a caveat on it: a self-hosted service reaching a sleeping phone is that service’s problem and that service’s app. An app quietly promising delivery it cannot provide would reproduce this feature’s own failure one layer up.

It confirms delivery, it does not assume it becomes N17-R3 and N17-R4. Sent and confirmed-delivered stay different facts, and a back-end configured and never used is a third state — one that looks identical to a working one right up until the moment it matters.

States

Edge cases

Acceptance criteria

Related

• B5 Notifications & alerting — what is sent and when
• G8 Privacy stance — what a message may contain
• C1 Diagnostics — a common source of events worth delivering
• G4 Error & remedy model — how a failed delivery reads