pastilhasandClaude Opus 5
15f262539f
Design in docs/push-notifications.md. The short version: Apple and Google are unavoidable — iOS suspends apps so only APNs can wake one, and Android only accepts pushes from FCM — but Expo is not. Its push service is a relay in front of both and does not remove either credential, so we talk to Apple and Google ourselves. Both protocols were verified in Bun before designing around them: node:http2 works as a client (APNs is HTTP/2-only), and ES256 signing produces the raw 64-byte r||s form Apple requires rather than Node's default DER, which is silently rejected. No push library is needed for either channel. The load-bearing decision is the payload: a push is a doorbell, not a message. Apple and Google see metadata regardless, so they must not also see content — a notification carries a category and an id, never a subject, sender or error, and the app composes the visible text locally and fetches the real thing over the tailnet on tap. This commit is the registry: push_devices, holding native APNs/FCM tokens. environment is a column because APNs sandbox and production are different hosts AND different token namespaces — a debug-build token fails against production with a silent BadDeviceToken, so guessing is not an option. Registration upserts on (token, bundle_id) because tokens rotate and the app re-registers every launch. Failure counting prunes dead tokens; a hard rejection deletes at once. Nothing sensitive lands here: a token is useless without the APNs key or FCM service account, both of which stay in the sidecar's env. NOTE: `bun db:push` will fail until the telegram/whatsapp/discord rows are deleted from server_integrations — the CHECK constraint added earlier refuses while they exist. That is the enforcement working, not a problem to route around. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>