iPhone app and push

Note

The iPhone app is in private testing — it isn’t on the App Store yet. Pairing and push already work end to end; expect it to be less polished than the rest of InfraInbox.

InfraInbox Push is the built-in destination every workspace already has — there’s nothing to create, only phones to pair to it. A paired phone gets notifications for every workspace it’s a member of.

Pair a phone

1. In the dashboard, go to Settings → Devices and click Pair a phone.
2. A QR code appears. It’s valid for 10 minutes.
3. On the phone, open the app, choose Pair, and scan the code.
4. The dashboard updates on its own once the phone claims it, showing the device’s name, platform and when it paired.

Revoke a device from the same page at any time — it stops receiving push immediately.

What the Devices page tells you

Each paired phone lists its push registrations, one per line: the transport, then a word for its health.

Word	What it means	What to do
delivering	Pushes are getting through.	Nothing.
failing	The registration is still live, but every push since the last success has failed; the line says how many.	Open the app on that phone. Repeated failures usually mean it hasn’t been opened since a reinstall or a restore. If the count keeps climbing, re-pair it.
gone	The transport dropped the registration. It is no longer pushed to; the app registers a new one the next time it opens.	Open the app on that phone.

The row also shows the app version the phone reported, when it paired and when it was last active. Times are the workspace’s, named at the top of the page.

How the push is protected

Each notification is encrypted specifically for the phone it’s going to before it leaves InfraInbox, using the phone’s own registered public key (Web Push / RFC 8291). For a self-hosted server sending through InfraInbox’s relay, the relay only ever forwards that already-encrypted payload — it has no key that can open it.

Check it works

From the Devices page, or from the app itself, send a test push to a specific device. It bypasses rules, quiet hours and silences entirely and carries no incident — it exists only to prove the phone actually receives something, so a failure here means the phone side (permissions, the app itself), not your routing.

If a notification arrives but reads only “New alert”, the phone received it and could not open it. InfraInbox checks every push against the app’s message format before sending, so a push it could not build correctly shows as failed on the Deliveries screen rather than reaching the phone.

What you get

• Every incident routed to @default — the built-in push plus whatever your rule adds — reaches every paired phone, unless a rule marks it silent for push specifically.
• A destination shows No phone registered when nothing is paired yet, or when a phone is paired but hasn’t opened the app since (push registration happens on open, not at pairing time) — either way, nothing is delivered until that’s resolved.
• Silent delivery, where a rule sets it, arrives without interrupting you (iOS’s passive/time-sensitive levels), still visible in the app.

In the app

The app is a pocket inbox for every server you pair it with, not only a notification target.

• Inbox: Active and Resolved tabs that load more as you scroll, and filters by severity, state and server that the app remembers between launches. Opening an incident marks it read; the tab and the app icon show how many are unread. Swipe a row to acknowledge it or snooze it for an hour.
• Incident detail: a readable timeline of who did what, from which channel and when; Delivered to, the destinations that heard about it; the source, first and last seen, occurrences, reopens and flapping. From there you can copy the details, open the source’s link, snooze for a time you choose, and resolve after a confirmation. The source row opens the source and offers Mute source.
• Sources: every source with its status first, and a source’s open incidents and recent events. Mute a source for 1 hour, 8 hours, 24 hours or until you unmute it.
• Servers: a welcome screen on first run, then each paired server’s status. Rename, reorder or remove a server there.
• Self-signed and private-CA servers: when your server’s certificate isn’t publicly trusted, the pairing QR carries its pin, and the app trusts that server through the pin alone. A certificate with a new key is refused rather than accepted, so re-pair after replacing it. Plain http:// works only for a private address, and the inbox then shows a lasting warning.

Next

• Routing rules — silence push specifically for a rule, without silencing every destination
• Keys and credentials — how pairing tokens and other credentials are handled