Push: hardcoded VAPID subject uses reserved .invalid TLD; Apple returns 403 BadJwtToken

[sccrgoalie1]

Summary

The hardcoded VAPID sub claim uses a reserved .invalid TLD, which Apple's Web Push service
rejects with 403 BadJwtToken. Every attention push to an iOS subscriber fails. FCM does not
validate the sub claim, so this is invisible on the qualified Chrome/Android client.

In the v0.4.0-prealpha.1 bun archive the send call is:

send(subscription, payload, {
  subject: "mailto:security@omp-session-gateway.invalid",
  publicKey: ..., privateKey: ...,
})

.invalid is reserved by RFC 2606 and can never resolve. Apple enforces that VAPID sub is a
usable mailto: or https: contact and refuses the JWT outright.

Observed

A false → true ask transition on a Control-capable session produced no notification. The daemon
logged, at the moment of the transition:

{"level":"warn","event":"push.delivery_failed","status":403}

Repro

Same VAPID keypair, same stored subscription, same version-2 attention payload, changing only the
subject:

VAPID sub	Apple response
mailto:security@omp-session-gateway.invalid (shipped)	403 {"reason":"BadJwtToken"}
https://github.com/alphastorm/omp-session-gateway	201 — notification delivered

Driven through the web-push npm package against web.push.apple.com, reading the keypair and
subscription out of push-state.json.

Suggested fix

Either make the subject configurable (a push.subject field validated as mailto:/https:), or
default it to a resolvable https: URL such as the repository URL. The existing
validateSubject check passes .invalid today because it only tests the URL scheme, not whether
the contact can exist — a .invalid host could be rejected there as well.

Scope / honesty about the environment

• This is not a claim against the supported matrix. The host is Ubuntu 26.04 x86-64, which is
  not an advertised host, and the client is iOS Safari, which has no compatibility claim.
• Background Web Push is documented as best-effort and outside the stable core claim, so this is
  reported as a defect in the code path, not a regression against a support promise.
• The subject constant is platform-independent, so the diagnosis does not depend on the
  unadvertised host.

Possibly useful data point

On the same setup, an iOS 26 Safari PWA installed to the home screen registered a normal
web.push.apple.com subscription, and the session directory, View, and Control all worked against
stock OMP 18.1.21. That is one person's anecdote from an unqualified combination, not evidence for
a support claim — but it suggests this constant may be the only thing standing between the current
code and working iOS alerts.

[alphastorm]

Apologies for the delay, just seeing this. Thanks for flagging @sccrgoalie1, will look into it today!

[alphastorm]

Thanks for the precise report and the side-by-side repro — it made this a one-constant fix.

Fixed in #182. The VAPID sub is now the repository URL (the value your repro got a 201 with), and a regression test rejects any reserved-name contact (.invalid, .test, .example, localhost) so it can't come back. I went with a fixed resolvable https: contact rather than a push.subject config field: the contact identifies the application server to the push service, every install shares the same one, and it keeps setup zero-config. You're right that web-push's validateSubject only checks the scheme — that's upstream's check, so the guard lives in this repo's tests.

Signed build to test: v0.4.1-prealpha.1

• omp-session-gateway-0.4.1-bun.tar — SHA-256 8b33baebda87217bf5021648c370c6a1b801031fdfc47fed9474d2e48be2f3f7
• Same install shape as v0.4.0: extract, then bun apps/gateway/src/cli.js install --origin … --allow … from the archive directory (existing config and readiness token are preserved). Verification steps: docs/RELEASE.md.
• Your existing push-state.json and iOS subscription carry over; only the JWT contact changed.

It's an engineering pre-release: unqualified on every host and client, not GitHub Latest, and it doesn't add an iOS or Ubuntu support claim — same scope you described. If you can re-run the false → true ask transition and confirm Apple returns 201 and the alert lands on the iOS PWA, I'll close this out.

Two optional questions, no private details needed: roughly how many sessions do you run and is it mostly View or Control from the phone? And which setup step had the most friction (Tailscale Serve, collab.autoStart, the archive install, or the PWA install)?

[sccrgoalie1]

@alphastorm i typically run 3 or so sessions at a time. I often control. The install was pretty easy but I did let Claude run with it and do most of the work for me.

The two things I’ve run into so far and I don’t think they are part of this repo are I only get notifications when input needed is fired which doesn’t seem to be the only time I might be needed. Might be nice to know when an agent stops. The other is my remote collab sessions don’t stay open they eventually close. Claude’s diagnosis was once a web socket disconnects that’s it the collab sessions just dies for good until manually restarted.

Thanks for your work on getting remote running it’s the main thing I’ve been missing